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

О станции

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

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

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

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

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

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

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

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

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

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

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

Платформы

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

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

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

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

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

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

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

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

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

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

Капитан

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мой регион, к сожалению, был не очень сильный в 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 и прочих языков, накопивших за долгие годы огромные кодовые базы. Нейросети уже более-менее могут переписывать код с одного языка на другой, но не всегда и не весь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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