Наблюдение: Python постепенно превращается в TypeScript 😁

Если вы активно работаете с базами данных, или серверным программистом на бэке, и при этом не слышали о проблеме N+1 , то сейчас где-то заплакал котик.

Eric Von Reinhard, работавший ведущим программистом в швейцарском Google, в качестве лучшего языка программирования на перспективу в 2022-м рекомендует изучать Python.

Отмечу только в дополнение к вот этому его аргументу

"Companies compete all the time and they look for fresh developers who know a modern language… not the old Java and C++."

что Python тащит сегодня с собой вообще всё, начиная с 1991 года, и почти всё из этого всего вам никогда не понадобится.

Ну, началось! А я уже не один год говорю -- нейросетки это хорошо, но мир таки захватит AI на формальной логике :)
В The NetHack Challenge 2021 (программы, мастерски играющие в легендарную рогульку) победил с ощутимым отрывом AutoAscend -- чистый символьный AI. Нейросетки тут не конкуренты, потому что они не умеют "думать стратегиями" и скорее всего никогда не научатся.

Я на нетхак потратил когда-то наверное тысячу часов :) До Амулета Йендора добирался...

P.S. И немного о грустном: в свежем Tortoise "The Global AI Index" Россия в мировой AI-гонке остаётся стабильно в третьем десятке, 32-е место.

Мир с помощью AGI (символьного :) через 2-3 десятилетия захватят США + Великобритания, или Китай, на 99%. Довольно внезапно с 12-го на 5-е место (за год!) поднялся Израиль. Впрочем, нифига не внезапно: он на первом месте в мире по относительному финансированию темы AI и на душу населения, и по исследовательским работам.

+15 "Разворачиваемость" вашего проекта (скорость лёгкость простота его деплоя) -- это одна из неотъемлемых, ключевых, абсолютно обязательных целей любого правильного проектирования.

Читаю "Real-World Cryptography" David Wong -- очень классный учебник, рекомендую и по теме, и не только: много bad/best practices, которые отлично подходят к повседневному программированию. Каждому уважающему себя миддлу-сеньору желательно изучить, в спокойном темпе главка в месяц, в алгоритмы/код особо можно не погружаться, достаточно понимания, всё очень хорошо объясняется, с картиночками для малышей :)

Узнал из этой книги, что Майкл Хайден, бывший директор АНБ и ЦРУ, заявил “We kill people based on metadata” :) В связи с этим вопрос, насколько вы доверенная сторона, насколько ваши ИТ-системы спроектированы так, что гарантируется (в идеале формально) что к этим метаданным нету нежелательного доступа, что они не могут быть скомпрометированы, сфальсифицированы? Викиликс вот говорит, что в АНБ дела с этим не очень... Впрочем, везде с этим не очень; более попсовую по теме можно почитать "The Perfect Weapon" David Sanger.

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

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

Сегодня довольно активно применяется GraphQL, довольно часто ребята кто у меня занимается эту СУБД упоминают.
Ну, GraphQL -- это своего рода WSDL/SOAP для миллениалов и поколения Z :)
(рассказывал про это всё)

Что будет следующим? web3 , что-то типа WSDL с сильной типизаций, с акцентом на семантику, и уж совершенно точно не JSON-ы.

Чем отличается гуру от хорошего сеньора (10+ лет опыта)? Если вы сеньор, то вы (или какой-то другой сеньор) можете вписаться в подавляющее число ИТ-проектов самого разного профиля, и помочь большому количеству людей практически в любом таком проекте.

Если вы гуру (20+ лет опыта), то вы можете вписаться уже лишь в относительное небольшое число весьма специфических ИТ-проектов :) и при этом только вы тот единственный человек, кто может помочь небольшому количеству людей в этих конкретных проектах.

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

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

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

Ну блин, ребята... Поизучайте сперва материалы из Сильных Идей про три уровня думания о программе. Как уходить от кода (и от тестов для уровня кода) на логический уровень абстракций, которых в коде не может быть по определению, и которые и надо учиться выражать в виде формальных спецификаций, реализуемых далее в виде тестов...

Ok, это моя недоработка :) В следующем году будем с этим очень плотно разбираться.

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

Я бы даже сказал, что эта схема работает так продуктивно, что похожа на жульничество :)

8 когнитивных багов начинающих архитекторов распределённых систем:
- сеть работает надёжно;
- задержка нулевая;
- полоса пропускания бесконечна;
- сеть безопасна;
- топология сети неизменяема;
- стоимость трафика нулевая;
- сеть гомогенна (только винда например :);
- для суппорта сети достаточно одного админа на удалёнке.

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

+16 Важные коаны проектирования :)
- плоское лучше, чем вложенное;
- разреженное лучше, чем плотное.

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

"Чем более масштабируема сеть, тем более централизованной она становится, и в конечном итоге все эти ваши "масштабируемые" криптовалюты будут делать то же самое, что и обычный процессинг кредитных карт" (с) Гради Буч

все криптопроэкты -- это зашкваренные версии классических highload-архитектур, старайтесь не вляпаться в 2022-м :)

с Наступающим! 🎄

По мотивам Unix:
- заставьте каждый компонент делать хорошо ровно одну вещь;
- делайте каждую функцию фильтром, естественно компонуемым/комбинируемым с другими функциями;
- чистый код лучше чем умный код;
- храните данных в "плоских" текстовых файлах (просто, читабельно, легко редактируемо);
- меньше по размеру это значит лучше (лучше много независимых модулей чем один монолит; только не забывайте, что если у вас 10 слабо изолированных микросервисов, как-то связанных в фоне друг с другом, вы легко можете получить 3,628,800 монолитов).

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

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

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

Программисты в 1980-х: "Всё есть указатель на непрерывный буфер значений... потому что Cи".
Программисты в 1990-х: "Всё есть объект, потому что бизнес-логика и базы данных".
Программисты в 2000-х: "Ясность кода и паттерны проектирования, потому что железо дёшево, и любой может писать код".
Программисты в 2010-х: "Мы проводим ежедневные митинги, чтобы выяснить, какой JavaScript-фреймворк нам попробовать сегодня, потому что мы гибкая команда".
Программисты в 2020-х: " Всё есть указатель на непрерывный буфер значений... потому что дата-ориентированный дизайн и кэширование".
В каком десятилетии застряла ваша компания? :)

+16 Полезное: algorithm for passing programming interviews , очень рекомендую выучить эту модель решения типовых задачек по алгоритмам.

Бонус: как за одну неделю подготовиться к прохождению интервью по System Design в MMANGA.

Только конечно важно понимать, что скилл прохождения интервью по System Design -- далеко/совсем не то же самое, что скилл System Design в реальном проекте, когда на вас вся ответственность за архитектуру :)

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

Очень хорошая бесплатная игра Bitburner — медитативный хакерский киберпанк с программированием на JavaScript :)

На тему программирования видео принципиально не смотрю, а вот мотовидео помногу регулярно, и так удачно...
"Как стать программистом в 30+"
Очень честно и реалистично, рекомендую!