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

1. Ясный код.

2. Вычислительное мышление.

Это пока были хипстерские шаги, а вот далее начинается секретная кроличья нора :)

3. Чистое функциональное программирование.

4. Транспиляция (эквивалентные преобразования исходных текстов программ на разных языках) -- запилить свой транспайлер.

5. Гомоиконичность (изоморфность синтаксиса и AST, код как сущность первого класса) -- попрактиковаться в Лиспе на сотне задачек с акцентом на "code as data".

6. Ссылочная прозрачность.

7. "Well typed programs cannot go wrong" Robin Milner 1978

8. Изоморфизм Карри-Ховарда.

Я всегда радуюсь, когда мне удалось обучить очередное живое существо программированию с целью сделать этот мир чуточку лучше, и даю обет бодхисатвы всегда этим заниматься с безмерным усердием, даже если для этого мне придётся мучиться в адах в миллиарды раз дольше трёх неисчислимых великих кальп, равных количеству временных промежутков (thang cig) в каждом дне из тысячи великих кальп!

Технически, в каждом дне 900 тханг чит, в году их 328500.
В великой кальпе 4,32 миллиарда лет, да на тысячу,
получаем 1 419 120 000 000 000 000 тханг чит.
Берём это как дни, да на три неисчислимые кальпы, да на, допустим, 9 миллиардов раз,
и получаем округлённо в годах
100 000 000 000 000 000 000 000 000

100 септиллионов лет! Вот на что я готов ради вас, дорогие! )))

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

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

Хотя конечно, когда проект исходно был спроектирован криво, он весь целиком одна сплошная опасность :) И надо всё переделывать с нуля.

Очень надеюсь, что в ближайшие годы проекты наподобие
Bun (a fast all-in-one JavaScript runtime)
или Deno (a modern runtime for JavaScript and TypeScript)
сбросят таки node.js с пьедестала.

Мы все часто слышим, что написанию хорошего кода (и качественной разработке в целом) можно научиться только опытным путём, методом проб и ошибок, через реальные проекты; или даже, возможно, хорошими программистами рождаются, а не становятся. И при этом мы постоянно читаем о принципах, которые лежат в основе хорошего кода: инкапсуляция, модульность, связность... Многие из них контринтуитивны, то есть были изобретены/открыты в академических кругах, мировыми специалистами в computer science.

Нету ли тут некоего противоречия? :)

Diagram as Code: рисуем красивые диаграммки питон-кодом.

Diagrams lets you draw the cloud system architecture in Python code. It was born for prototyping a new system architecture design without any design tools. You can also describe or visualize the existing system architecture as well.

Отличное выступление на PyCon 2015:
"Beyond PEP 8 -- Best practices for beautiful intelligible code"
Distillation of knowledge gained from a decade of Python consulting, Python training, code reviews, and serving as a core developer. Learn to avoid some of the hazards of the PEP 8 style guide and learn what really matters for creating beautiful intelligible code.

Классный пример, как 20 строчек кода отрефакторить в 3 строки, да и вообще поразбирайтесь с этим примером, рекомендую.

Более подробный разбор этого доклада сделаю для занимающихся у меня, в СильныхИдеях -- про то, что надо прежде всего уметь выявлять общие структуры управления и абстрагироваться от них. На самом деле, подобных паттернов не так уж много (только не путайте их конечно с искусственными "паттернами проектирования"). Усвойте эти принципы, и у вас появится внутренняя сила, которая не позволит вам писать плохой код, и вы будете блистать своими скиллами на собеседованиях и код-ревью :)

Ну если только вы не занимаетесь у меня ))) я бы сперва настоял на том, чтобы вы прежде всего исправили магическую константу: жёстко закодированный IP-адрес (мой курс Ясный Код в помощь).

Программисту обязательно нужна раздельная/сплит клавиатура: чтобы можно было программировать на пляжном шезлонге (ну или в подобном "личном" кабинете :). Правда, в магазинах она безумно дорогая, лучше на али заказывать.

Джуниоры нужны всё меньше?

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

А брат этого товарища занимается разработкой фреймворка синтеза программ, который оптимизирует сам себя, и умеет генерировать formula simplifiers под конкретные предметные области.

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

Доктор философии скрестил ежа с ужом Питон с Лиспом. Получилось очень забавно.

Фишка из web3 — как организовывать журналирование без, например, SS-таблиц или LSM-деревьев, когда ноды могут покидать сеть и возвращаться в неё произвольно по своему усмотрению: брать цепочку proof-of-work в качестве целостной и доказанно корректной информации о том, что произошло, пока узла не было в онлайне.

...то странное чувство, когда как обычно внезапно закончились минуты на каршеринг GitLab CI/CD, а оплата долларами теперь традиционно сильно усложнена, и в результате вся система у знакомых пацанов встала почти намертво )))

Остаётся импортозамещённый cicd яндекс, причём они даже вроде с GitLab как-то совместимы, хотя там честно говорится, что "Пайплайн CI/CD сложно применять для больших и сложных монолитных систем". Так CI/CD как раз и нужны именно для таких систем в первую очередь )
Маленькие и несложные монолиты полезно как раз вручную обслуживать.

Многострадальный Python превратили ещё и в функциональный язык.

Задачка, которую 99% гуманитариев решают правильно, а 99% программистов ошибаются.

Строка "x+(x-x)+x" палиндром?
(никакого подвоха в плане кодировок символов и т.п.)

Спойлер: нет.

"Top Competitive Programmer vs. LeetCode's HARDEST Questions" )))))

"Top Competitive Programmer vs. FAANG Interview Questions" тоже хорошо.

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

Между прочим, интерфейс AutoCloseable из Java 7, методы наподобие File.open в Ruby, паттерн RAII в Rust и C++, и даже хаскелевская bracket -- это всё один и тот же мета-паттерн, впервые реализованный как макро with-open-file в Common Lisp в 1980-х годах.
Разбираем его в очередном материале в СильныхИдеях.

Hazel is a live functional programming environment that is able to typecheck, manipulate, and even run incomplete programs, i.e. programs with holes.

Вот это действительно Наука, а не эти ваши кококопилоты )))

Будущее редакторов для программистов уже тут: tylr.fun

Когда вы разрабатываете ТЗ для некоторой системы, есть обязательные мета-требования, подходящие практически к любой предметной области:
- пользователям должны быть везде доступны undo/redo;
- "пакетные" операции на клиенте ("автоматизация" пользовательской работы: макро, настраиваемые хоткеи....);
- управляемая сборка мусора;
- создание моментальных снимков состояния системы (условный сэйв/лоад в любой момент времени, а не то что в автосимуляторах, когда во время гонки невозможно сохраниться);
- синхронизация состояний;
- ребейзинг по истории изменений с возможностью просмотра дифов.

Если вы их не добавите, это значит, что вы создаете софт, которым сами не захотите пользоваться.

Время срочно записывать Carbon в свои скиллы :)

Хорошая новость, что симпатичный курс HighLoad Junior
о котором я говорил недавно: "От организаторов конференции Highload++, и я его раньше рекомендовал. Однако, сервис по обучению highload от мастеров highload сам по себе оказался крайне ненадёжным и очень хрупким :)"
вроде бы ожил: пришла рассылка, в которой (вроде бы) все активные ссылки на материалы наконец-то рабочие.

Правда, highload.guide/blog/ слегка зависает, но это же мелочи для русского хайлоада? :)