1. О станции
2. Сотрудничество
3. Контент
4. Платформы
5. Капитан
6. Стек капитана

О станции

Звёздное небо завораживает мириадами сверкающих огоньков, укрывающих в себе бесчисленные миры и, возможно, более развитые цивилизации. К сожалению, технологии Земли не позволяют дотянуться до них, отдавая дальние межзвёздные путешествия в дерзкие руки фантастов и мечтателей.

С другой стороны, мы и так уже находимся в межзвёздном пространстве, мчась сквозь него на планете - огромном космическом корабле, использующим энергию звёзд. А раз есть готовая космическая платформа, то должна быть и космическая станция на ней, одна из которых представлена в здешних бортовых журналах - космическая станция Аналитики (КСА).

Её название подчёркивает исследовательские цели проекта, влияющие на саморазвитие:

• В экспериментах уточняются детали, вскрываются ошибки и систематизируется информация, содействуя обучению и улучшению результата.
• Публичный характер работы повышает мотивацию, создаёт опасения опозориться, растерять свой авторитет наивными подходами, формируя портфель разнообразных аналитических инструментов, способствуя росту самообразования в целом.
• Демонстрация результата и процесса его достижения поддерживает самореализацию и самоутверждение.
• Появляется возможность отслеживать своё саморазвитие, что важно в сложном технологичном мире с нейросетевым ИИ, эффективность управления которым сильно зависит от уровня мышления. Хотя это относится не только к ИИ, а ко всему в принципе.
• и т.д. и т.п.

Таким образом, основная цель проекта - улучшение мышления и эволюция самых разных навыков с квалификацией. Можно смело сказать, что станция - личный дневник саморазвития. В свою очередь, цель определяет формат - исследования и эксперименты. Это роднит проект с научно-исследовательскими станциями или любыми другими местами проведения научных исследований, что повлияло на выбор имени блога.

Из этого следует очень важное следствие - все материалы не могут рассматриваться как обучающие, станция не является обучающим техноблогом.

Цели и формат ориентируют станцию на всех тех, кто стремится к звёздам - новым открытиям и свершениям, стараясь вырваться из густой темноты первобытной человеческой природы к яркому свету знаний. Небесные маяки вели за собой первых исследователей Древнего мира, олицетворяя высшие ценности и достижения человеческой цивилизации. Теперь же, спустя множество тысячелетий на ленте времени, они ровно также ведут за собой и нас. Per aspera ad astra - "через тернии к звездам".

Это целиком некоммерческий проект, ибо исследовательские цели не уживаются с экономическими. Важное следствие здесь - недостаток времени из-за потребления его основной работой и обслуживанием быта, что напрямую влияет на скорость исследований.

Сотрудничество

Отсутствие монетизации делает станцию независимым проектом, с которым невозможно никакое экономическое сотрудничество:

• Станция не размещает у себя рекламу, не занимается никакими заказными обзорами.
• Станция не принимает бесплатные подарки любого рода, технические или иные.
• Станция использует ровно те технологии, которые подходят к её текущим задачам, не продвигая и не рекламируя их, а равно никакие другие. Меняются задачи - меняются инструменты их решения.

Чужеродную и вставляемую рекламу со стороны самих социальных сетей и платформ станция контролировать никак не может, но никак и ничем с ней не связана.

Контент

Всё в живой и неживой природе развивается эволюционно, станция - не исключение. Развитие блога проходит через этапы, каждый из которых напрямую влияет на последующие.

1. Исследовательские и обучающие инструменты.

• Графический движок. Симуляторы - обучающая цель, изучение различных предметных областей. GUI, закрывающий потребность станции в системных приложениях, улучшение знаний по десктопу. Поддержка математики в стеке, что тесно связано с графикой и т.д.
• RTOS для эмбеддеда и изучения самых глубин устройства железа и операционных систем на нём.
• Асинхронный сетевой фреймворк для поддержки бэкенда.
• Экспертная система для изучения перспектив логической парадигмы на фоне роста нейросетевого ИИ.
• и т.д. и т.п.

2. (Ещё не разблокирован)
3. (Ещё не разблокирован)

Таким образом, на данный момент станция занимается созданием себе исследовательских и обучающих инструментов, подготавливая инфраструктуру для следующих этапов.

Платформы

Концепт космической станции предполагает широкий спектр знаний и разнообразные сложные задачи в процессе космических миссий. Это требует квалификации, которая требует обучения, которое требует очень большого количества времени, которое нельзя взять из ниоткуда.

Дефицит времени и сильная усталость из-за высоких айтишных нагрузок плохо сочетаются с времяпровождением в соцсетях, отчего частью платформ станция пользуется редко, либо вообще не использует, оставляя их только ради удобства её аудитории.

В таких жёстких условиях полноценная модерация аккаунтов просто невозможна, отчего повсеместно комментарии выключены, экономя время, как и давая очень важную и нужную возможность оставить проект без управления на неопределённый срок, не опасаясь за него.

Этот сайт появился первым, теперь он служит хранилищем сложных и объёмных техноотчётов, кои выходят редко в силу их трудоёмкости, обычно подводя итоги глобального эксперимента или исследования. Но по мере развития станции исследования становятся всё сложнее и дольше, занимая уже не месяцы, а годы.

Поэтому сам ход исследований сопровождается девлогами - заметками, журналом разработки, для чего используются Вконтакте, копия ленты которого идёт в Telegram. И к ВК, и к Telegam есть очень много вопросов, отчего я не уверен, что в далёком будущем станция сохранит в них своё присутствие, но тут посмотрим.

Цель - переход на видеоконтент, дающий много преимуществ в сравнении с текстовым, особенно по экономии времени. Но видео пока ещё очень мало и Youtube канал постепенно наполняется наиболее качественными, отборными видеозаписями из девлогов, подготавливаясь к своему запуску.

Поскольку станция находится на этапе создания исследовательских инструментов, то и девлоги работают в тестовом режиме, отчего в будущем может всё поменяться, а с каких-то платформ станция может уйти.

Список активных платформ продублирован в правой панели сайта, которая смещается (должна) в самый низ на небольших экранах.

Капитан

Мой путь в IT начался в далёком 2011 году. На дальнейшую эволюцию и формирование моего технологического стека - набора используемых IT-инструментов и языков программирования, повлияло множество различных факторов.

Отсюда первое важное следствие: не нужно ориентироваться на инструменты и языки программирования, которые я использую, ибо они очень точно подстроены под мои текущие задачи, когда как завтра я могу выбрать совершенно другие инструменты из-за изменений задач или способов их решения. К любым IT-инструментам я отношусь строго прагматично, не являясь фанатом ни одного из них.

Основная проблематика IT-отрасли, как и любой другой - сложный баланс между широтой и глубиной знаний, что противоречиво в своей сути: широкая общая квалификация ведёт к ошибкам в тонких нюансах, которые она не покрывает, а глубокая специализированная упирается в комплексность задач, требуя множества знаний из других наук и областей. Равноценное же сочетание обоих стратегий управления знаниями очень проблематично как в силу огромного объёма информации, так и из-за ограничений по времени, памяти и прочим ресурсам человека, упираясь в самое неприятное свойство психики - забывание.

Эти проблемы корнями уходят в эффект Даннинга — Крюгера и прочие похожие, избежать которых совершенно невозможно, что даже можно вспомнить Козьму Пруткова: "нельзя объять необъятное". Невозможно выучить всё на свете, всегда нужно жертвовать какими-то знаниями, а эти эффекты будут бить в эти пропущенные области с наибольшей силой, выбирая самое слабое место и нанося самый большой урон результату. Поиск наиболее выгодного баланса в знаниях требует постоянных экспериментов, проб и ошибок, что завтра может сильно поменять и меняет набор рабочих инструментов, как и способы его использования.

Поскольку любая система в IT - сложная система, то в ней начинают проявляться самые разные системные эффекты. От взаимодействия простых частей друг с другом появляется новая сложность - эмерджентность, затрудняя соблюдение универсальных принципов навроде SOLID и GRASP: распределение ответственности, сохранение малой взаимосвязанности, высокой специализации компонентов системы. Это вступает в конфликт с сохранением архитектурной простоты, а в случайных местах начинает накапливаться непредсказуемость и хаос - энтропия, также требуя её компенсации в виде усложнения какого-то другого участка системы, либо уже системы с ней связанной, создавая замкнутый круг.

Сложность напрямую влияет на производительность и обработку ошибок, которые начинают носить непредсказуемый характер в силу эффекта количественно-качественного перехода: при изменении количества всегда меняется и качество. Запускается рассинхронизация разных участков системы между собой с неравномерностью их развития: где-то логика новая, где-то старая, а где-то совсем легаси, оставшееся от самых первых версий. Это вступает в конфликт с требованием консистентности: с ростом системы разные участки её всё сильнее различаются между собой, а не должны.

Все эти негативные изменения нельзя заметить сразу из-за классической проблемы определения перехода системы из одного состояние в другое. Она известна как проблема "куча", частый вариант - "лысый" и т.п: при добавлении какого зерна все зёрна превращаются в кучу, или же с выпадением какого волоса человека можно посчитать лысым. В этом случае сначала медленно, а потом очень резко можно сделать систему примитивной, нестабильной, с плохой производительностью, сопровождаемостью и прочим багажом недостатков.

Вишенкой на торте нависает диалектический закон "отрицания отрицания" - новое занимает место старого, но постепенно само превращается в старое и отрицается следующим, более новым. Новая технология требует фундаментальных изменений, что парадоксально легче даётся упрощённым и примитивным архитектурам, когда как сложные и продвинутые архитектуры, прекрасно работающие в старых условиях из-за длительной своей эволюции, становятся нежизнеспособными в резко изменившихся условиях.

Всё это создаёт трудноразрешимые проблемы от тесно связанных друг с другом:

1. Фундаментальных диалектических законов и противоречивости любого технического решения в частности: если решается одна проблема, то обязательно добавляется какая-то другая, обычно не одна.
2. Системных эффектов внутри сложных систем.
3. Конфликтов с другими системами, особенно экономической.
4. Недостатков той или иной стратегии управления знаниями.
5. Ограничений и особенностей человека.
   и т.д. и т.п.

Психология сильно влияет на взаимодействия и психологические эффекты в группах, отчего просто так смасштабировать команду и получить высококачественный продукт в общем случае не выйдет, например, в силу закона Эшби: субъект управления должен быть более или хотя бы не менее сложным, чем управляемый. Поскольку один управляющий содержать в себе очень много знаний не может, то управление будет распределяться по множеству специалистов, которые должны при этом между собой очень тесно и эффективно взаимодействовать, вновь образуя сложную систему, также требующую управления, опять-таки создавая при этом бесконечный замкнутый круг.

Усугубляется всё и цикличным характером развития любых систем: за этапом подъёма и развития неминуемо следует спад и деградация, отчего множество компаний со временем теряют былое качество своих IT-продуктов, деградация которых неотрывно следует за деградацией самой компании как сложной системы в силу различных системных, психологических, экономических и прочих эффектов.

В итоге мы получаем IT-инструменты с хаотичным разбросом энтропии в многочисленных сложных подсистемах, что повышает непредсказуемость и нестабильность их управления с работой, повсеместно создавая множество справедливых жалоб на IT со стороны пользователей и не только: крайне низкое качество части IT-инструментов раздражает и самих разработчиков, меня в том числе. Причём из-за постоянного хаотичного наслоения абстракций друг на друга с годами всё будет становиться ещё интереснее.

Эти эффекты сильно снижают полезность сложных сторонних IT-продуктов, особенно с небольшим количеством информации о внутреннем устройстве и работе, высокая энтропия которых будет сильно уменьшать преимущества использования, таким образом технически обосновывая существование и популярность в IT NIH-синдрома и связанного тесно с ним "велосипедостроения".

Так, во всех IT-продуктах есть критичные проблемы, вытекающие из противоречивости технических решений. Если продукт работает на задачах высокой производительности, то из-за сложности и наслоения абстракций достичь её невозможно: многочисленные мелкие штрафы суммируются, понижая потолок производительности до смехотворных значений. Небольшие оптимизации не помогают, а значительные не позволяет ни язык, ни фреймворк.

Если же продукт очень хорошо оптимизирован, то он может затруднять расширение или кастомизацию, которая должна следовать многочисленным ограничениям его хитроумных оптимизаций. Даже небольшое усложнение архитектуры приложения сразу же делает его очень проблемным для сопровождения, создавая дилемму установки запятой в классическом правиле "усложнять нельзя использовать" - при любом варианте будет очень больно.

Или продукт не имеет быстрого прототипирования, без которого очень сильно повышается трудоёмкость, за вменяемый срок ничего толкового сделать на нём нельзя. Однако если ускоряется прототипирование, например, через разделение логики между кодом и шаблонами с привлечением GUI-билдеров, то усложняются обновления из-за обратной совместимости версий шаблонов, а их логика вообще массово обходит проверки компилятора, выворачивая наизнанку изначальную суть программирования по отлову ошибок на этапе компиляции.

Или фреймворк имеет огромное количество настроек, но из-за их количества и сложности ими невозможно пользоваться, лишь надеяться на значения по умолчанию. Либо же не имеет настроек вообще, а должен.

Если продукт для автономных устройств, то он может быть завязан на капризную сеть, бонусом не имея достаточных средств отладки и починки, что расходится с самой сутью автономии. Многие (и я тоже) сталкивались с обновлением подобных проблемных систем через несколько лет эксплуатации - это просто техномусор.

Если продукт, наоборот, стационарно-сетевой, то его он не имеет никаких ограничений и средств безопасности в своей базовой архитектуре, что противоречит непредсказуемости хитроумных атак и наличием 0-day уязвимостей, которые есть всегда и везде. Более того, настройки по умолчанию иногда вообще оставляют входные двери открытыми для посетителей. И т.д. и т.п.

С противоречиями работают разные методологии, например, всем известная теория решения изобретательских задач (ТРИЗ) с алгоритмами (АРИЗ) Альтшуллера. Но в них самих тоже есть противоречия: вводя методичность и повышая эффективность решения, они следом резко повышают свою трудоёмкость, без каких-либо гарантий на потраченное время, иногда вырождаясь в классическое бумаготворчество без полезного результата. Либо же результат может создать новых проблем больше, чем решить старых: что-то придумать достаточно легко, но, как говорится, есть нюанс.

Учитывая эти многочисленные проблемы выше, как и множество других, повторяю - не нужно ориентироваться на технологии, которые я использую, поскольку единого успешного рецепта не существует, всё всегда ситуативно. У каждого разработчика стек будет очень сильно различаться, в зависимости от множества самых разных факторов, как я уже упоминал выше. Например, очень важен фактор региона.

Мой регион, к сожалению, был не очень сильный в IT, оставляя единственный шанс выжить - постоянное и агрессивное самообучение. Ценой времени собственной жизни, разумеется. Это осложнялось известной дилеммой "квалификация или монетизация": то, что обладает более высоким обучающим и квалификационным потенциалом труднее монетизируется в силу своей сложности, малопопулярности или же каких-то других факторов, как и наоборот.

Отсюда трудный выбор: либо использовать технологии, сильно облегчающие трудоустройство и монетизацию знаний, но в обмен получить риск с возрастом не выкачать общую квалификацию к необходимому мне уровню, испортив свою эволюцию. Либо же использовать языки с более высоким обучающим потенциалом, но и намного более проблемные в монетизации и трудоустройстве.

Разумеется, моя внутренняя сущность, увлекаемая тягой к знаниям, настояла на втором варианте - приоритет обучения. Однако нужно помнить, что такой выбор в жестоком конкурентном экономическом мире может быть очень, очень, очень и очень опасным. Здесь нужно подумать очень много раз, ибо на еду, обслуживание быта, медицину и прочее постоянно нужны деньги и немалые.

Повышение сложности управления знаниями эволюционно порождает за собой тайм-менеджмент и ценность времени: потеря большого количества времени в прошлом будет влиять на оценку и его восприятие в настоящем. Хотя время и так наиболее ценный ресурс, учитывая скоротечность и, увы, неминуемую конечность человеческой жизни.

Как и в IT, масштабирование системы знаний под более высокие нагрузки требует различных тонких оптимизаций и совершенно других алгоритмов.

Стек

Так, мой стек (набор используемых IT-инструментов) прошёл несколько эволюционных этапов, на каждом из которых я не учитывал какой-то важный фактор:

1. Использование одного языка программирования. Здесь я не учитывал очень сильную специализацию языков, что вскрылось позже усложнением решаемых задач, которые мой язык уже не вывозил, как и не способствовал росту общей квалификации, создавая проблемы в переключении на другие задачи, сильно отличные от текущих.

2. Использование большого количества языков для максимального охвата возможных задач и роста квалификации. Я не придавал значения системным эффектам: взаимодействие инструментов друг с другом, потери времени из-за энтропии в сложных системах и прочее. Жизнь превращается в пытку и постоянные итерации по языкам без ощутимого результата от всей этой языковой оравы.

3. Поиск пересечений в задачах и выбрасывание менее ценных языков из стека, возможности которых могут покрыть другие языки, хотя бы и с ограничениями. Здесь я не учитывал полезность очень специализированных языков: высокий обучающий потенциал, концентрированное коммьюнити, как и проблематичность их замены, ибо дьявол кроется в их тонких специализированных деталях.

4. Возврат в стек некоторых специализированных языков. Проблемы управления стеком никуда не исчезли, а часть знаний постоянно забывалось, потребляя время на их вспоминание. Я совершенно не учитывал психологию со множеством когнитивных ограничений человека.

5. Поддержка знаний постоянной практикой в виде пет-проектов для уменьшения забывания, повышения роста квалификации и поддержки IT-областей, которые в повседневной работе мало или вообще не используются. Однако проблем добавилось ещё больше: каждый язык программирования очень трудоёмок и содержит в себе огромнейшее количество нюансов, которые нужно помнить и практиковать.

6. Попытка в агрессивные оптимизации: поиск наиболее выгодных комбинаций между языками с учетом их взаимодействия друг с другом, исключение перекрытия задач между ними, эксперименты с возвратом-удалением языков, динамическое распределение приоритетов и времени и т.п. Однако несмотря на попытку баланса, в практике обнаруживались технические странности и нестыковки, которые не покрывались литературой и материалами в сети - я совершенно не учитывал комплексность знаний и задач как таковых.

7. Принятие разброса знаний по разным наукам и областям, причём часть из них находятся в гуманитарных. Эффект Даннинга - Крюгера суров: чем ниже в чём-то квалификация, тем болезненней ошибки в т.ч. в связанных науках и областях. Так, обучающий материал, да и готовый продукт, инструмент, что угодно может быть очень высокого технического качества с учётом малоизвестных другим деталей и нюансов, но не делать поправок, например, на какой-то простейший наивный системный или психологический эффект. Эта грубая ошибка снижает практическую ценность до нуля или даже с заходом в отрицательный диапазон полезности: "гладко было на бумаге, да забыли про овраги", создавая классическое расхождения теории с практикой. Однако потери времени на другие науки еще больше осложняют управление знаниями и тайм-менеджмент, делая оптимизации в п.6 смешными, примитивными и, что самое главное - недостаточными.

8. Попытка балансировать теперь уже между разными науками, учитывая множество факторов и тонких оптимизаций. Здесь я не учитывал общесистемные законы взаимодействия систем друг с другом: если вы очень тщательно планируете, продумываете, выверяете, стараетесь, прокачиваете знания, а кто-то этого вообще никак не делает, то ваш общий результат будет очень посредственным, мягко говоря. Ваша квалификация может упереться в низкую квалификацию других, отчего значительная часть прилагаемых усилий будет малоэффективной и не иметь особого смысла. С этим трудно что-то сделать.

9. Поиск наиболее выгодной комбинации между разными знаниями, что задача нетривиальная и требует постоянных экспериментов, в которых я и нахожусь по сей день.

По итогам этих экспериментов мой стек со временем эволюционировал в классическую слоистую структуру, чем-то напоминающую "луковую" архитектуру (Onion architecture) Палермо, как и любые схожие "слоистые" системы в т.ч. и в физическом мире. Языки программирования очень тщательно подогнаны друг к другу с поиском синергий, а каждый выполняет строго определённый круг задач.

В центре стека находится ядро - язык с наиболее критичными задачами поддержки и роста квалификации, которая переносится с него на остальные используемые мною языки и IT-инструменты. Требования к кандидату на эту роль максимально суровые, что обусловлено способностью языков формировать привычки, как и нарабатывать необходимый опыт, определяющий, фактически, квалификацию.

Этот язык должен быть системным, поскольку в IT всё и везде опирается на системщину, уходя корнями в интерфейсы операционных систем. Множество библиотек медиа, сетевых, алгоритмических, математических и прочих написаны на системных языках, над которыми надстраивают свои обёртки высокоуровневые языки. Также системные языки открывают путь в наиболее авторитетные и сложные области IT, тесно соприкасающиеся с электроникой как и с дальнейшим проходом в инженерные науки, законы которых фундаментально влияют на принимаемые технические решения в родственном им IT.

Он должен одновременно задействовать все уровни абстракций для предотвращения забывания работы с ними, от простого и понятного низкоуровневого процедурного кода с тонкими оптимизациями до сложных объектных иерархий, плавно перетекающих в моделирование и объектный анализ, близкий к формальной логике, что удобно для человеческого мышления. Тоже самое касается и различных парадигм.

Бывает, что языки отказываются от некоторых парадигм, прикрываясь их ненужностью, бесполезностью, неудачностью, что противоречит любви инженерии к гибридизации разных подходов по ситуации: на каких-то задачах хороша одна парадигма, а на резко отличных от них - другая. На более сложных и комплексных задачах они могут потребоваться все вместе. Поскольку для языка общего назначения максимально критична универсальность, то при отсутствии парадигмы часть задач станет недоступной в т.ч., опять-таки, влияя этим на квалификацию, что меня совершенно не устраивает.

Язык должен быть схож с синтаксисом С-семейства, с которым я работаю, для переиспользования между языками идей и кода, так и уменьшения проблем от переключения между разными синтаксисами и возникающих из-за этого ошибок в коде. В этом случае при обнаружении архитектурной недоработки в приложении на одном языке, автоматически улучшается архитектура и на другом, что порождает полезный синергический эффект между кодобазами из-за их схожести.

Язык должен быть компромиссным, имея на борту механизмы компенсации особенностей разных парадигм, особенно ускоряя прототипирование. Чем больше времени тратится на мертворожденные идеи, тем ниже эффективность такой разработки, ибо время - очень критичный ресурс на сложных задачах. Изначально реализация почти всегда ошибочна или неэффективна, что требует экспериментов. Скорость прототипирования позволяет быстро тестировать и отбрасывать неудачные идеи, высвобождая время для других задач и, главное, роста навыков по другим областям, что также требует времени.

Также в сложных ООП-иерархиях с внедрением зависимостей из-за высокого расслоения кода и делегации может быстро теряться контроль за жизненным циклом объектов, требуя сборщик мусора либо его аналога, но с возможностью отключения. В процедурном низкоуровневом коде мне нужна высокая совместимость с С, но и возможность улучшать безопасность и не только, добавляя срезы массивов с проверкой границ, контроль за временем жизни в областях видимости, перегрузки операторов для реализации умных указателей и прочего, перевод части расчётов в compile-time и т.д. и т.п.

Напоследок, язык не должен быть популярным, ибо в любом малопопулярном сложном инструменте - небольшое, но очень и очень технически сильное коммьюнити, концентрированное, ибо в трудностях растёт квалификация. Из-за небольшого количества обучающих материалов инструмент изучать сложнее, из-за малого количества вакансий мотивация у значительной части разработчиков некоммерческая, язык сложнее монетизировать, что срабатывает фильтром, отсеивая слабых, как и не связанных идейно с IT людей.

Часто мы становимся теми, с кем находимся рядом, подравниваясь под других: будучи в окружении сильных, становимся сильнее, а находясь рядом со слабыми - слабее, ибо сильные тянут вверх, а слабые - вниз. Отсюда и мой особый интерес к наиболее сильным коммьюнити в IT, чья квалификация порождается выживанием, формируясь в суровой борьбе за своё существование на фоне многочисленных проблем и ограничений в ресурсах - финансовых, людских и прочих.

На данный момент моим требованиям наиболее полно отвечает D (Dlang), в котором я также вижу попытки решения технических проблем, в которые я упирался.

Так, например, в процессе изучения IT я выискивал правила дизайна кода - контроля за рисками (ошибками, исключениями, нарушениями контрактов, опасными операциями с памятью и т.д.), побочными эффектами функций, оптимизациями и прочим, ибо встречаемые мною были максимально бесполезными, а квалификация авторов таких идей вызывала сильные сомнения.

Позже я обнаружил, что эволюция атрибутов в языках навроде D концептуально близко подходит к нужному мне списку правил, позволяя вспоминанием этих атрибутов при написании функции оценивать потенциальные риски по исключениям, памяти, побочные эффекты и т.п., накладывая локальные или глобальные ограничения на разные участки кода и архитектуры. Не идеально, со своими особенностями и проблемами, но хотя бы уже что-то, лучше, чем ничего.

Однако у всего есть цена и любая универсальность влечёт за собой и сложность, что, в свою очередь, повышает трудоёмкость системного языка, поэтому опыт и аналогии системного стека использует следующий слой - высокоуровневые языки с задачами ускорения разработки и снижения трудоёмкости, которая у системных языков значительно выше.

Тут появляется много проблем, но особенно критичны затраты времени на поддержание языка в стеке. Любое усложнение будет увеличивать потребление времени на сопровождение высокоуровневых языков, а оно будет сниматься с системных, нанося им урон. Если в языке нет какого-то функционала, то он быстро забывается, либо искажается из-за формирования любым инструментом различных когнитивных привычек, что сильно повышает риск ошибок при обратном переключении на системные языки. Очень большая проблема на самом деле, корнями уходящая в психологию человека.

Траты времени сильно увеличиваются высокой энтропией с отсутствием у многих инструментов какой-либо борьбы со сложностью. В итоге знание подкапотной работы и системного стека, с которым связан и на котором работает высокоуровневый язык никто не отменял, это всё очень сильно влияет на конечный результат, особенно в части борьбы с багами, ограничениями, оптимизацией, интеграцией в систему, отладкой и т.п. более сложными задачами, напрямую пересекаясь с проблемами скрытой сложности выше. Это сам по себе огромнейший пласт знаний, без которого проблематично обойтись.

Но к этой массе добавляется ещё и огромное количество абстракций со стороны самого высокоуровневого языка и его тулчейна, часть из которых высокоспецифичны, более глубокие слои всё труднее изучаются из-за недостатка материалов, кои нужно собирать по крупицам, теряя время, как и не переносятся опытом на другие инструменты и языки, отчего они могут быть совершенно бесполезны, что делает эту модель знаний очень проблемной.

Здесь мне интересна богатая инфраструктура Java с очень большим бонусом в виде Groovy. Эта выгодная связка дала возможность быстро решать часть задач, экономя время, что критично при наличии в стеке сложного системного языка с постепенным расширением и усложнением структуры IT-знаний, требующих вагоны времени.

JavaFX позволил заполучить десктопный фреймворк, не отставая от наиболее технологичных из мира C#, что было необходимо мне при переходе на Linux. GUI-тулкиты универсальны и способны улучшить практически любую сферу деятельности, начиная от экономии времени в быту и заканчивая рабочими IT-инструментами. Хотя в самом Java-комьюнити (особенно СНГ) JavaFX не особенно популярен, но находит широкое признание среди не Java-программистов. Мой случай - яркий тому пример, я не специализируюсь на Java.

Нельзя забывать и эволюцию IT, что предполагает постоянное знакомство с новыми идеями и технологиями для борьбы с устареванием знаний. Я пристально отслеживаю различные языки программирования, их инфраструктуру, знакомлюсь с докладами на конференциях, экспериментирую с пет-проектами в поисках возможных улучшений и оптимизаций своего стека.

Так, в последние годы меня заинтересовал Dart: легковесный и мощный тулчейн, JIT\AOT из коробки, а относительно высокая схожесть синтаксиса с С-семейством сильно понижает затраты времени на поддержку языка в стеке, облегчая обмен кодом между другими моими С-подобными языками.

Ну и над всем этим надстраивается слой более специализированных языков, задачи которых решить другими инструментами проблематично. Из-за своей специализации эти языки часто имеют скудные обучающие материалы, недостаток которых частично могут компенсировать системный и прикладной слой по аналогии. Так, мне очень нравится Prolog своей концепцией и возможностями, но, увы, материалов по нему в IT катастрофически мало, что замедляет любое достижение нужного мне результата.

Агрессивный тайм-менеджмент здесь сразу же рождает большую проблему для блога: сложность создания проработанных материалов из-за огромных затрат времени на проверку ошибок, исправление неточностей и шлифование деталей. Осложняется это и повсеместно некачественными первоисточниками, маркетинговыми статьями с аккуратным замалчиванием ошибок и проблем, а иногда вообще отсутствием материалов как таковых.

Это множество айтишных проблем выше обесценивают красивые слова в IT, выводя на первое место результат и соответствие его разным требованиям, особенно нефункциональным, лишний раз подтверждая известную пословицу: "языком молоть - не мешки ворочать". Все идеи и подходы нужно доказывать именно практическим результатом, но часто этого не происходит.

В некоторых случаях результат упрощён, хелловордный, практическая полезность которого очень низка, а простая внутренняя структура и простое взаимодействие элементов в ней делает его примитивным. Любое малейшее усложнение сразу же наворачивает весь исходный концепт, обесценивая его, а все решения проблем нужно выискивать самому.

В каких-то случаях результат - продукт большой команды, что нарушает однозначную причинно-следственную связь между результатом и автором материала, ибо его роль в общем результате неизвестны и запросто могут быть околонулевыми. Как и в предыдущем случае, множество деталей, уходящих корнями в сложные процессы и взаимодействия в многочисленной команде, как и перемешивание разных задач между разными разработчиками, здесь не учитываются. Но "дьявол кроется в деталях", причём очень тонких, технических, которых автор не знает в силу своей очень специализированной специализации. Такие материалы ровно также могут быть совершенно бесполезными для практики.

Иногда результат просто странный, сделанный ровно наоборот тому, что диктует предметная область и особенности эксплуатации. Здесь, помимо технических противоречий, вовсю срабатывает множество психологических ловушек, например, закон тривиальности, ибо проще рассуждать о простом. Пересекается с ним и Парето, как и множество других когнитивных искажений.

Думаю, вы много раз наблюдали, как комментаторы к случайной технической статье вместо обсуждения наиболее сложных и важных деталей цеплялись к малосущественным уточнениям и мелочам, либо вообще к орфографии, либо даже к автору, переходя на личности, замусоривая этим ленту, обесценивая её техническую полезность. Всё это сильно осложняет перенятие опыта и практическую адаптацию его к своим задачам. И т.д. и т.п.

Как видно из множества проблем выше, IT, как и любая другая область, построена на противоречиях, постоянно требующих жертв и сложных компромиссов, за упрощением или игнорированием которых последует неминуемое наказание, сразу либо позже. В таких условиях очень и очень легкомысленно быть уверенным в своих силах и знаниях: крайне проблематично учесть все изощрённые требования разных наук, как из-за их количества, так и из-за сложного взаимодействия между собой.

Из-за этого все используемые станцией технологии могут быть проблемными, как и выбраны ошибочно: на ранних этапах (а вернее, на всех) часть критических недостатков остаётся неизвестной, они вскрываются по ходу дела, а могут и затаиться на неопределённый срок, как повезёт. Учитывайте это!

Кроме того, нельзя забывать и ещё об одной фундаментальной проблеме, сопровождающей всех и каждого: errare humanum est - человеку свойственно ошибаться и с этим тоже трудно что-то сделать. Все иногда ошибаются и станция - не исключение.

Поэтому снова напоминаю, что станция - исследовательский проект, не более. Ну а теперь вперёд, к самым ярким звёздам!