Я хочу разумной поддержки отраслевых стандартов. Без этого вашим продуктом никто пользоваться не будет. Вот тогда действительно и наступит застой. lts это поддержка другого рода.
если не брать фронтенд, то это в подавляющем большинстве - Node.js.
Если не брать фронтенд, то о js на сервере лучше вообще забыть как о страшном сне. По уму оно и на фронте лучше бы об нём забыть. Ну да ладно. Что есть то есть.
Так вот, никакой объективной причины/повода/смысла тянуть js на сервер никогда не было и нет. Там работают вполне себе половозрелые, состоявшиеся взрослые языки и фреймворки на соответствующих своим задачам языках. Никому там нах не упал этот недоделанный js. Он не даёт никаких преимуществ от слова вообще.
А зачем же он там возник? Это объясняется просто. Резко усложнился фронт. Потому что всё теперь под браузером. Такая политика, такая философия. Потребовалось реально много js програмеров. И появилась куча вот этих js програмеров, умных мальчишек с недалёким горизонтом планирования (простите парни) у которых "реализация ООП в js шикарна".
Но и бэкэнд же нужно делать. Людей где брать в промышленных масштабах? Как вот утилизировать навыки этих всех js мальчишек, самозабвенно влюблённых в js и никогда не знавших по жизни ничего иного кроме как прочитанного из интернет статей? Переучивать их и развивать? Годами? Да ну нах кому они упали. Пусть сами себе варятся. Учатся отличать ФП от ООП. Никто не будет за это платить.
А сделать можно просто. Дадим фреймворк, работающий на сервере на их родном js. Node/Next... Для большинства задач мощности этих фреймворков достаточно. Людей можно брать с фронта. Главное чтобы они любили свой бэк и верили в него. Бизнесу это выгодно. Сразу появилась большая масса "серьёзных", знающих js людей, уже готовых пилить серверную часть. Неважны детали. Главное языком владеть. И язык этот -- javascript.
Не к Maven, а к Gradle, в котором конфигурации можно писать либо на Kotlin, либо на Groovy.
В Gradle, как и в Maven, в 90% случаев можно вообще ничего ни на чём не писать. Просто грамотно указать чего вы хотите. Да, порой это мутно немного. Увы, есть такое. А Groovy/Kotlin это уже как бонус. Для тех проектов которые плохо организованы и нужно тут подпрыгнуть, а тут пригнуться, тут с того утянуть, а тут это вот отфильтровать. Есть такие дурные, тянущиеся веками проекты, где неумные програмеры ленятся один раз перехерачить всё и сделать по уму. Дабы не заклеивать бесконечно дырки лейкопластырем.
Мне кажется это зависит от места куда загружается программа. Если непосредственно в саму щётку стеклоочистителя, то там конечно лучше в двоичных кодах лабать, а вот если в реле, то ассемблер... только он. Си он слегонца высоковат будет. Может даже в память не вместиться.
Зен гаден -- это сайт. Просто приятный милый сайтик, посвящённый "таинствам" CSS. Его вроде один человек поддерживает. Энтузиаст. Там этого Javascript-а -- кот наплакал. Скорее можно говорить о стабильности HTML. Но даже и он не раз менялся за свою историю. Когда говорят об аде Javascript, то речь идёт о тяжёлых SDI/MDI приложениях, заменяющих то, что раньше называлось "толстый десктоп клиент". Ибо всё переносится под браузер.
Одно время, совсем не так и давно, лет 7-8 назад, заметки про Javascript начинались словами: "пока я писал этот абзац, на планете, скорее всего, появилось ещё более десятка новых javascript фреймворков и мой текст возможно уже устарел...". Эту лавину "шлака" немного удалось притормозить c появлением Typescript и сплочением трезвомыслящей общественности вокруг большой тройки голов фреймворков, но времена по прежнему оставались стрёмными. И "какой-нибудь" Гугл всё ещё мог себе позволить в одну ночь отрубить одну голову выбросить на свалку первую версию известного фреймворка. Но некая стабильность всё же впереди замаячила. Но увы, похоже это только мираж... ))
Как я уже писал выше -- язык программирования не должен "вертеться" конкретно вокруг именно ваших рук. Какими бы замечательными они и не были. Он должен принимать в расчёт среднестатистические руки доступные в индустрии.
И в этом смысле (в смысле безопасности использования) язык С -- достаточно плохой, опасный язык. Но это было сделано сознательно с целью сохранения максимальной эффективности откомпилированного кода. Не забываем сколько ему уже лет и на тот момент это был прорыв для своего класса задач. Ассемблер он ведь куда опаснее. Ну а далее появились С++, Rust... и сейчас уже нужны достаточно весомые основания чтобы начинать проект на чистом С. Человек, сейчас выбирающий язык С для реализации "обычной" задачи -- просто впустую тратит своё время и деньги работодателя.
Для примера, в Java тоже есть несколько рантаймов, а кол-во SDK вообще тьма.
Неправда. Количество SDK всего несколько штук. Ну там 6 примерно. Причём массово используется лишь примерно пара. Остальные возникли по своим причинам и вы можете вообще про них не знать.
Рантайм может компоноваться в зависимости от нужд развёртываемого приложения с целью не тащить ненужный код. Это появилось позже для удобства. И он всё равно будет состоять из стандартных кусков. Увы, но вы для красного словца довольно сильно передёргиваете несложные и известные факты в свою пользу. Это не есть хорошо. ))
Быстрая эволюция возможна только для инструментов на которых ничего большого и серьёзного не реализовано. Как только что-то большое и серьёзное появляется, вы вынуждены взвешивать каждый следующий шаг в изменении вашего инструмента, дабы поддержать совместимость и преемственность. Иначе у вас всё работающее -- рухнет. Это основная причина из-за которой широко используемые инструменты не могут скакать во всё новое как небольшие поделки.
Перефразирую известную фразу -- у меня нет для вас других программистов.
Всегда найдётся тот, у которого кривые руки. Абсолютно в любом деле. А когда что-то поставлено на поток и требуется в промышленных масштабах -- таких будет десятки тысяч. Вот именно поэтому (!) и ценятся те инструменты, которые не поощряют плохие практики работы. Чтобы вот эти вот с кривыми руками коленки себе и другим не прострелили. И да, javascript в этом смысле язык достаточно неудачный. Он появился скорее как забава и изначально не был предназначен для тех вещей, для которых его сейчас используют. Ну а затем понеслось/поехало. И имеем то, что имеем. И тянуть сложно и отползать накладно.
Maven, Gradle (Groovy, Kotlin). Пакетов эти тонны и в разных стилях.
А продолжить вот этот вот список (Maven, Gradle...) сможете? Ну хотя бы на 2-4 имени (только без Ant -- это уже история). Groovy и Kotlin (и Clojure, и Scala, и JRuby и Jython и ...) -- языки программирования, использующие в качестве среды выполнения JVM, а не системы сборки проектов. К чему вы их упомянули рядом с Maven как будто это вещи одного порядка? Их много языков программирования, которые практически "бесшовно" встраиваются в Java. Специально для тех кто любит разнообразие и типа "ненавидит" каноническую Java.
Пакетов тонны потому, что проектов тысячи тонн. И задач миллионы тонн. А вот разных стилей совсем немного. И то, как правило, если дисциплины на проекте нет и код ревью не делается достаточно профессионально.
Наверное интересный инструмент, но для меня вот это вот SQLiteDB сразу всё пресекает. Как только начинается некая DB, так я сразу становлюсь заложником инструмента. Как олдскульный чел, мне уже надоели эти зависимости. Хочу простоты. ))
Вот зачем названия нодов и связи складывать в БД? Название файла это и есть название нода. А несложный тег внутри легко сохранит ссылку на другой нод. И даже если он исчезнет или переместится, вы визуально видите эту ссылку и сможете легко восстановить.
Obsidian показывает иерархически сложенные заметки на левой панели, но это далеко не всё. Ключевая суть Obsidian -- реализация подхода Zettelkasten. Zettelkasten -- это такой подход к хранению информации, когда вы можете сцепить любые заметки между собой специальным тегом и видеть вашу информацию в виде такой сетевой/граф структуры связанных заметок. Эдакая база знаний с возможностью и видеть связи и мгновенно по ним перемещаться не глядя на иерархию физического расположения заметок.
Пользуюсь им уже наверное больше года. До этого использовал Microsoft One Notes, который реально выбесил своей закрытостью формата и использованию некоей структуры навроде БД. Да, можно было экспортировать в pdf и прочее, но когда каждый месяц открывая заметки видишь, что какая-то записная книжка с некоего перепугу не открывается и надо там немного станцевать с бубном. Нет, информация не терялась, но, как уже сказал -- выбешивало. Надо что-то глянуть, а он тебе такой, ай ну не открывается, авторизуйтесь ещё разок и переоткройте записную книжку и тд.
Принял решение уйти от любых закрытых или сложных форматов. Никаких баз данных, никаких HTML/Word/RTF etc. Текст. Plain text и файловая система. А если точнее, то давно существуют такие форматы как Markdown или чуть более сложный AsciiDoc, которые можно читать даже если Obsidian возьмёт и исчезнет. Это текстовые файлы с дополнительными несложными префиксами, позволяющими выделить заголовки, поставить ссылки и прочее.
И вот Obsidian -- на файловой системе, поддержка иерархической и сетевой организации информации, тексты в Markdown (можно переключать из режима редактирования в режим просмотра где префиксы отрабатываются и текст выглядит красиво). Поиск по всем файлам. Доволен как слон.
Единственная деталь -- написан на модном электроне. Лучше бы какой Qt или JavaFX. Но работает хорошо. Ни разу не упал, ни разу ничего не напутал. И вполне шустро на i7 не последнего поколения. Интерфейс можно настроить, скачав понравившуюся тему, которую также можно поменять под себя (там CSS)
Вполне разумно Егор всё рассказал. Согласен практически со всем. Не очень уверен что так уж важен инстаграмм, но вот на stackoverflow хотя бы раз другой вопрос и задашь. Очень согласен с тем, что нужно хорошо понимать, для чего вы ищите человека и не измудохивать алгоритмами всех входящих, если на то нет объективной необходимости.
По поводу 1000 интервью. А в чём проблема с количеством? Человек явно сказал, что не считает нужным часами пытать человека. Достаточно 15 минут чтобы составить впечатление. Дальше уже есть другие факторы. Испытательный срок и прочее. То есть за полдня в неделю можно поговорить с 10 человеками. В год — уже 400 человек. Пару лет и тысяча. В реальности конечно не пару, а может пять/шесть. Ну так оно и есть. И да, он, видимо, давно не чистый программист. Книги пишет, компанией занимается. Кода видимо также плотно касается, но это давно не основная работа. Не увидел в целом вопиющих противоречий.
PS: Вот с этим комментарием автора текста категорически не согласен
… мне кажется, что индус средних лет просто не вписался бы в команду молодых белых парней...
Будучи сам в возрасте и зная кто работает в IT (а это уже давно не детская отрасль) не люблю личностных выводов/намёков на пол/возраст и прочее.
Да ну какое там радужно. После того, как на рынок вышли мобилы, и там три ключевых разработчика ОС не смогли найти общего языка, и javascript оказался единственным кроссплатформенным «клеем»…
Qt пошла по рукам. JavaFX стагнирует. Javascript возомнил себя победителем, и теперь все новые проекты это чисто Франкенштейны типа Электрона. Цивилизация куда-то не туда свернула, пытается выкарабкаться всякими там TypeScript…
В JavaFX, как и в Swing, при прочих равных, стараются избегать абсолютного позиционирования (разные платформы, разные шрифты, разное разрешение...), а предпочитают использовать специальные layout managers. Это контейнеры, которые расставляют расположенные на них визуальные объекты по определённому закону. В виде сетки, разбивая на некие группы, поддерживая нужные расстояния между ними, меняя их размер с изменением размера охватывающего контейнера ну и прочее. Есть несколько стандартных, есть написанные сторонними людьми. Ну и свой можете написать. SceneBuilder также предлагает класть их как подложку, что некоторых может озадачить, если раньше не сталкивались с таким подходом.
По поводу цикла статей. Есть проект на гитхабе, где человек собирает ссылки на материалы, касающиеся JavaFX. Сторонние библиотеки/фреймворки, книги (их уже много, потому неактуально), статьи, блоги etc. Сейчас, когда материалов уже много, это менее актуально, но тем не менее. Опять же JavaFX работает для всех языков программирования доступных на Java машине (Clojure, Groovy, Kotlin, Scala, Ceylon, JRuby, Jython, Nashorn (это вариант javascript)).
Хайпа давно никакого нет, потому как сейчас десктоп инструменты не провоцируют хайпы в принципе. Столица плавно переместилась в Веб. Опять же — инструменту уже 8 лет, он вполне зрелый, чего тут хайпать? Недавно, правда, был один хайпец. Начинаяя с версии Java 11, JavaFX больше не часть JDK. Она стала отдельным модулем, называется OpenJFX и перешла в поддержку компании Gluon и OpenJDK комьюнити. Доступна из maven репозитория и версионно с JDK больше не связана. Если действительно следите за общим фоном Java-мира, то в конце прошлого году точно должны были слышать. Штаб находится тут. На Амазоне вы легко найдёте более сотни разных книг/учебников.
Мне сложно понять, какой конкретно острый угол фреймворка вызывает у вас такое яростное неприятие, поскольку инструмент с большего крайне удобен, интуитивно понятен, да и вообще хорошо и быстро работает. Изъяны есть. Как и везде. SceneBuilder я не использовал. Сейчас вообще десктоп инструменты используются значительно реже. Я также использую данный фреймворк лишь эпизодически. Хотя и давно. Как он может безумно (!) проигрывать хоть чему-то, мне не понять. Обычно так эмоционально выражаются апологеты другой платформы (скажем .NET), знакомые с Java инструментами крайне поверхностно, но изначально идеологически настроенные против.
Из своего опыта, могу сказать, что некоторое отчуждение испытывали люди, которые впервые сталкивались с более новой концепцией построения GUI. JavaFX использует некий базовый контейнер-подмосток, на котором может быть выстроена одна иди несколько сцен, состоящих из любых графических элементов. Каждую сцену, вместе со всем её содержимым, можно как угодно трансформировать (масштабировать, скручивать, поворачивать...), анимировать, менять цвета и яркости. И даже источники света размещать. Некая форма с кнопками это всего лишь частный случай сцены. А в целом получается очень гибкая графическая конструкция (и 3D). Идея не нова, таким же образом построены Qt и WPF. Но люди пришедшие из WinForms, Swing, Delphi и ожидающие увидеть доску на которую накидываются контролы, порой, с мороза, чувствуют себя неуютно. Им всё кажется излишне сложным и избыточным. К чему такая мощь для кнопочек? Ну только лишь для кнопочек может и ни к чему.
Ещё одна не всем привычная и пугающая новичков фишка — реактивность свойств. Любое свойство графического объекта может быть «сцеплено» с другим свойством другого объекта. То, в свою очередь, с неким свойством третьего и так далее. Меняя одно свойство, автоматически меняются связанные. Примерно как пересчитываются связанные клетки в Excel. Ну и сцена обновляется. Идея не нова, она положена в основу реактивного программирования, но если вы не имеете навыков такого рода построения интерфейса, то… вы опять же сразу не оцените всю мощь и гибкость такого подхода. И будете по привычке искать какие-нибудь события для того, что бы их «как обычно» обработать.
Есть ещё одна особенность, которую некоторое количество людей люто, патологически ненавидят. JavaFX — фреймворк класса 'lightweight'. Другими словами — все свои контролы он рисует сам и не использует родные контролы операционной среды. Ну и стало быть интерфейс может выглядеть не как родной, нейтивный. Также устроен и Qt. И старенький Swing.
Рискну показаться категоричным, но на сегодняшний день действительно сильными кроссплатформенными десктоп инструментами (с поправкой в том числе и на количество доступных специалистов на рынке) являются Qt (C++) и OpenJFX (Java и со.). Все остальные либо сырые, либо немного устарели, либо просто «модные».
Я хочу разумной поддержки отраслевых стандартов. Без этого вашим продуктом никто пользоваться не будет. Вот тогда действительно и наступит застой. lts это поддержка другого рода.
Если вы хотите куда-то что-то копать, то это имеет смысл только если делать из копанья адекватные выводы. Не переворачивать их с ног на голову.
И если покопать, то быстро становится понятно, что Java экосистему удалось удержать в разумных рамках. Стоило некоторой крови. Это да.
А вот js удержать не удалось. И это "лоскутное одеяло" сейчас беда для всей индустрии.
Если не брать фронтенд, то о js на сервере лучше вообще забыть как о страшном сне. По уму оно и на фронте лучше бы об нём забыть. Ну да ладно. Что есть то есть.
Так вот, никакой объективной причины/повода/смысла тянуть js на сервер никогда не было и нет. Там работают вполне себе половозрелые, состоявшиеся взрослые языки и фреймворки на соответствующих своим задачам языках. Никому там нах не упал этот недоделанный js. Он не даёт никаких преимуществ от слова вообще.
А зачем же он там возник? Это объясняется просто. Резко усложнился фронт. Потому что всё теперь под браузером. Такая политика, такая философия. Потребовалось реально много js програмеров. И появилась куча вот этих js програмеров, умных мальчишек с недалёким горизонтом планирования (простите парни) у которых "реализация ООП в js шикарна".
Но и бэкэнд же нужно делать. Людей где брать в промышленных масштабах? Как вот утилизировать навыки этих всех js мальчишек, самозабвенно влюблённых в js и никогда не знавших по жизни ничего иного кроме как прочитанного из интернет статей? Переучивать их и развивать? Годами? Да ну нах кому они упали. Пусть сами себе варятся. Учатся отличать ФП от ООП. Никто не будет за это платить.
А сделать можно просто. Дадим фреймворк, работающий на сервере на их родном js. Node/Next... Для большинства задач мощности этих фреймворков достаточно. Людей можно брать с фронта. Главное чтобы они любили свой бэк и верили в него. Бизнесу это выгодно. Сразу появилась большая масса "серьёзных", знающих js людей, уже готовых пилить серверную часть. Неважны детали. Главное языком владеть. И язык этот -- javascript.
В Gradle, как и в Maven, в 90% случаев можно вообще ничего ни на чём не писать. Просто грамотно указать чего вы хотите. Да, порой это мутно немного. Увы, есть такое. А Groovy/Kotlin это уже как бонус. Для тех проектов которые плохо организованы и нужно тут подпрыгнуть, а тут пригнуться, тут с того утянуть, а тут это вот отфильтровать. Есть такие дурные, тянущиеся веками проекты, где неумные програмеры ленятся один раз перехерачить всё и сделать по уму. Дабы не заклеивать бесконечно дырки лейкопластырем.
Мне кажется это зависит от места куда загружается программа. Если непосредственно в саму щётку стеклоочистителя, то там конечно лучше в двоичных кодах лабать, а вот если в реле, то ассемблер... только он. Си он слегонца высоковат будет. Может даже в память не вместиться.
Зен гаден -- это сайт. Просто приятный милый сайтик, посвящённый "таинствам" CSS. Его вроде один человек поддерживает. Энтузиаст. Там этого Javascript-а -- кот наплакал. Скорее можно говорить о стабильности HTML. Но даже и он не раз менялся за свою историю. Когда говорят об аде Javascript, то речь идёт о тяжёлых SDI/MDI приложениях, заменяющих то, что раньше называлось "толстый десктоп клиент". Ибо всё переносится под браузер.
Одно время, совсем не так и давно, лет 7-8 назад, заметки про Javascript начинались словами: "пока я писал этот абзац, на планете, скорее всего, появилось ещё более десятка новых javascript фреймворков и мой текст возможно уже устарел...". Эту лавину "шлака" немного удалось притормозить c появлением Typescript и сплочением трезвомыслящей общественности вокруг большой тройки
головфреймворков, но времена по прежнему оставались стрёмными. И "какой-нибудь" Гугл всё ещё мог себе позволить в одну ночьотрубить одну головувыбросить на свалку первую версию известного фреймворка. Но некая стабильность всё же впереди замаячила. Но увы, похоже это только мираж... ))Как я уже писал выше -- язык программирования не должен "вертеться" конкретно вокруг именно ваших рук. Какими бы замечательными они и не были. Он должен принимать в расчёт среднестатистические руки доступные в индустрии.
И в этом смысле (в смысле безопасности использования) язык С -- достаточно плохой, опасный язык. Но это было сделано сознательно с целью сохранения максимальной эффективности откомпилированного кода. Не забываем сколько ему уже лет и на тот момент это был прорыв для своего класса задач. Ассемблер он ведь куда опаснее. Ну а далее появились С++, Rust... и сейчас уже нужны достаточно весомые основания чтобы начинать проект на чистом С. Человек, сейчас выбирающий язык С для реализации "обычной" задачи -- просто впустую тратит своё время и деньги работодателя.
Неправда. Количество SDK всего несколько штук. Ну там 6 примерно. Причём массово используется лишь примерно пара. Остальные возникли по своим причинам и вы можете вообще про них не знать.
Рантайм может компоноваться в зависимости от нужд развёртываемого приложения с целью не тащить ненужный код. Это появилось позже для удобства. И он всё равно будет состоять из стандартных кусков. Увы, но вы для красного словца довольно сильно передёргиваете несложные и известные факты в свою пользу. Это не есть хорошо. ))
Быстрая эволюция возможна только для инструментов на которых ничего большого и серьёзного не реализовано. Как только что-то большое и серьёзное появляется, вы вынуждены взвешивать каждый следующий шаг в изменении вашего инструмента, дабы поддержать совместимость и преемственность. Иначе у вас всё работающее -- рухнет. Это основная причина из-за которой широко используемые инструменты не могут скакать во всё новое как небольшие поделки.
Перефразирую известную фразу -- у меня нет для вас других программистов.
Всегда найдётся тот, у которого кривые руки. Абсолютно в любом деле. А когда что-то поставлено на поток и требуется в промышленных масштабах -- таких будет десятки тысяч. Вот именно поэтому (!) и ценятся те инструменты, которые не поощряют плохие практики работы. Чтобы вот эти вот с кривыми руками коленки себе и другим не прострелили. И да, javascript в этом смысле язык достаточно неудачный. Он появился скорее как забава и изначально не был предназначен для тех вещей, для которых его сейчас используют. Ну а затем понеслось/поехало. И имеем то, что имеем. И тянуть сложно и отползать накладно.
Хватило этого предложения. Дальше не читал.
А продолжить вот этот вот список (Maven, Gradle...) сможете? Ну хотя бы на 2-4 имени (только без Ant -- это уже история). Groovy и Kotlin (и Clojure, и Scala, и JRuby и Jython и ...) -- языки программирования, использующие в качестве среды выполнения JVM, а не системы сборки проектов. К чему вы их упомянули рядом с Maven как будто это вещи одного порядка? Их много языков программирования, которые практически "бесшовно" встраиваются в Java. Специально для тех кто любит разнообразие и типа "ненавидит" каноническую Java.
Пакетов тонны потому, что проектов тысячи тонн. И задач миллионы тонн. А вот разных стилей совсем немного. И то, как правило, если дисциплины на проекте нет и код ревью не делается достаточно профессионально.
Наверное интересный инструмент, но для меня вот это вот SQLiteDB сразу всё пресекает. Как только начинается некая DB, так я сразу становлюсь заложником инструмента. Как олдскульный чел, мне уже надоели эти зависимости. Хочу простоты. ))
Вот зачем названия нодов и связи складывать в БД? Название файла это и есть название нода. А несложный тег внутри легко сохранит ссылку на другой нод. И даже если он исчезнет или переместится, вы визуально видите эту ссылку и сможете легко восстановить.
Obsidian показывает иерархически сложенные заметки на левой панели, но это далеко не всё. Ключевая суть Obsidian -- реализация подхода Zettelkasten. Zettelkasten -- это такой подход к хранению информации, когда вы можете сцепить любые заметки между собой специальным тегом и видеть вашу информацию в виде такой сетевой/граф структуры связанных заметок. Эдакая база знаний с возможностью и видеть связи и мгновенно по ним перемещаться не глядя на иерархию физического расположения заметок.
Пользуюсь им уже наверное больше года. До этого использовал Microsoft One Notes, который реально выбесил своей закрытостью формата и использованию некоей структуры навроде БД. Да, можно было экспортировать в pdf и прочее, но когда каждый месяц открывая заметки видишь, что какая-то записная книжка с некоего перепугу не открывается и надо там немного станцевать с бубном. Нет, информация не терялась, но, как уже сказал -- выбешивало. Надо что-то глянуть, а он тебе такой, ай ну не открывается, авторизуйтесь ещё разок и переоткройте записную книжку и тд.
Принял решение уйти от любых закрытых или сложных форматов. Никаких баз данных, никаких HTML/Word/RTF etc. Текст. Plain text и файловая система. А если точнее, то давно существуют такие форматы как Markdown или чуть более сложный AsciiDoc, которые можно читать даже если Obsidian возьмёт и исчезнет. Это текстовые файлы с дополнительными несложными префиксами, позволяющими выделить заголовки, поставить ссылки и прочее.
И вот Obsidian -- на файловой системе, поддержка иерархической и сетевой организации информации, тексты в Markdown (можно переключать из режима редактирования в режим просмотра где префиксы отрабатываются и текст выглядит красиво). Поиск по всем файлам. Доволен как слон.
Единственная деталь -- написан на модном электроне. Лучше бы какой Qt или JavaFX. Но работает хорошо. Ни разу не упал, ни разу ничего не напутал. И вполне шустро на i7 не последнего поколения. Интерфейс можно настроить, скачав понравившуюся тему, которую также можно поменять под себя (там CSS)
По поводу 1000 интервью. А в чём проблема с количеством? Человек явно сказал, что не считает нужным часами пытать человека. Достаточно 15 минут чтобы составить впечатление. Дальше уже есть другие факторы. Испытательный срок и прочее. То есть за полдня в неделю можно поговорить с 10 человеками. В год — уже 400 человек. Пару лет и тысяча. В реальности конечно не пару, а может пять/шесть. Ну так оно и есть. И да, он, видимо, давно не чистый программист. Книги пишет, компанией занимается. Кода видимо также плотно касается, но это давно не основная работа. Не увидел в целом вопиющих противоречий.
PS: Вот с этим комментарием автора текста категорически не согласен Будучи сам в возрасте и зная кто работает в IT (а это уже давно не детская отрасль) не люблю личностных выводов/намёков на пол/возраст и прочее.
Qt пошла по рукам. JavaFX стагнирует. Javascript возомнил себя победителем, и теперь все новые проекты это чисто Франкенштейны типа Электрона. Цивилизация куда-то не туда свернула, пытается выкарабкаться всякими там TypeScript…
Оно может и неплохо, что FX ушла в Open мир. :)
По поводу цикла статей. Есть проект на гитхабе, где человек собирает ссылки на материалы, касающиеся JavaFX. Сторонние библиотеки/фреймворки, книги (их уже много, потому неактуально), статьи, блоги etc. Сейчас, когда материалов уже много, это менее актуально, но тем не менее. Опять же JavaFX работает для всех языков программирования доступных на Java машине (Clojure, Groovy, Kotlin, Scala, Ceylon, JRuby, Jython, Nashorn (это вариант javascript)).
Мне сложно понять, какой конкретно острый угол фреймворка вызывает у вас такое яростное неприятие, поскольку инструмент с большего крайне удобен, интуитивно понятен, да и вообще хорошо и быстро работает. Изъяны есть. Как и везде. SceneBuilder я не использовал. Сейчас вообще десктоп инструменты используются значительно реже. Я также использую данный фреймворк лишь эпизодически. Хотя и давно. Как он может безумно (!) проигрывать хоть чему-то, мне не понять. Обычно так эмоционально выражаются апологеты другой платформы (скажем .NET), знакомые с Java инструментами крайне поверхностно, но изначально идеологически настроенные против.
Из своего опыта, могу сказать, что некоторое отчуждение испытывали люди, которые впервые сталкивались с более новой концепцией построения GUI. JavaFX использует некий базовый контейнер-подмосток, на котором может быть выстроена одна иди несколько сцен, состоящих из любых графических элементов. Каждую сцену, вместе со всем её содержимым, можно как угодно трансформировать (масштабировать, скручивать, поворачивать...), анимировать, менять цвета и яркости. И даже источники света размещать. Некая форма с кнопками это всего лишь частный случай сцены. А в целом получается очень гибкая графическая конструкция (и 3D). Идея не нова, таким же образом построены Qt и WPF. Но люди пришедшие из WinForms, Swing, Delphi и ожидающие увидеть доску на которую накидываются контролы, порой, с мороза, чувствуют себя неуютно. Им всё кажется излишне сложным и избыточным. К чему такая мощь для кнопочек? Ну только лишь для кнопочек может и ни к чему.
Ещё одна не всем привычная и пугающая новичков фишка — реактивность свойств. Любое свойство графического объекта может быть «сцеплено» с другим свойством другого объекта. То, в свою очередь, с неким свойством третьего и так далее. Меняя одно свойство, автоматически меняются связанные. Примерно как пересчитываются связанные клетки в Excel. Ну и сцена обновляется. Идея не нова, она положена в основу реактивного программирования, но если вы не имеете навыков такого рода построения интерфейса, то… вы опять же сразу не оцените всю мощь и гибкость такого подхода. И будете по привычке искать какие-нибудь события для того, что бы их «как обычно» обработать.
Есть ещё одна особенность, которую некоторое количество людей люто, патологически ненавидят. JavaFX — фреймворк класса 'lightweight'. Другими словами — все свои контролы он рисует сам и не использует родные контролы операционной среды. Ну и стало быть интерфейс может выглядеть не как родной, нейтивный. Также устроен и Qt. И старенький Swing.