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

О станции

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

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

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

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

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

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

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

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

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

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

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

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

Контент

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

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

• Симуляторы - наиболее важная, обучающая цель.
• GUI, закрывающий потребность станции в системных приложениях.
• Визуализации. Пока только для AI-созданной музыки с периодичностью раз в 2-3 месяца. Сами тексты композиций сочинены без AI, самостоятельно, для целей развития когнитивных, языковых, творческих навыков, а также для повышения сложности задачи.

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

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

Платформы

Станция - распределённая система, бортовые журналы которой копируются в разные соцсети.

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

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

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

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

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

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

Капитан

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стек

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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