Фишка из 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/ слегка зависает, но это же мелочи для русского хайлоада? :)

Есть ли перспективы у no-code? Нет, абсолютно. Потому что в этой темке не бывает никаких революционных изобретений. Это просто поиск компромиссов между универсальностью и простотой UI, стараясь угодить выбранной рыночной нише. Вдобавок за этим стоит, очевидно, достаточно объёмный код, и этот легаси-хвост сильно затрудняет быструю подстройку под нужды разных клиентов. А агрессивная монетизация даёт в основном саморазрушительный эффект.
Расходимся, в no-code вообще не на что смотреть.

А вот low-code, где есть хотя бы немножечко кодинг, перспективно однозначно. Причём чем визуальнее тут программирование, тем лучше, как в scratch или squeak например -- потому что сегодня это направление очень сильно взлетает и в профессиональной разработке, на моём новом формате занятий "hard work" будем это обязательно изучать.

Если вы не можете записать что-то на русском языке, вы не сможете это запрограммировать.

Дико уважаю:
I started BPS.space almost 7 years ago in the fall of 2015 with the goal to propulsively land a model rocket. I had no background in aero, EE, coding, etc so it took a lot of trial and error, but today I finally stuck the landing

Конечно в ней есть утечки памяти, но кого это волнует, она же ракета!

Что такое хорошая абстракция? Пока на сегодня лучшее и достаточно формальное определение, которое я нашёл для учебных целей :) такое:
matt.might.net/articles/intro-static-analysis/

Например, множество целых чисел ...,-2,-1,0,+1,+2,... отображаем в абстрактный домен {-,0,+}, где "-" -- все отрицательные числа, "+" - все положительные.

Теперь можем сделать раскладку операций над этим доменом:
{+} + {+} = {+}
{+} + {-} = {+, 0, -}
{+} * {-} = {-}
и т. п.

И теперь мы можем выполнять очень простой статический анализ без необходимости оценивать полное выражение, то есть нам не надо вычислять -4 * +3, чтобы понять, что результат будет отрицательным.

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

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

Подробно разбираем в СильныхИдеях эту крайне важную тему.

Залипательное: shark.fish/curiosity/
Ну, да, программистам нередко вот так именно и приходится разбираться -- с легаси-кодом, с issues тимлида, с "ТЗ" заказчика :) А то и с официальной документацией, которая подчас круче любого квеста.

Я где-то около 10 лет назад наверное играл в его же cube composer (сами найдите), тоже крайне рекомендую, микро-тренировка в функциональном мышлении.

Вот наконец и топовые гуру вроде ЛеКуна заговорили о важности symbol manipulation в современном ML/DL/AI.

Ребята без особого проектного опыта, которых повысили и поставили на новый проект с нуля, часто в порыве энтузиазма (но уже немножечко учитывая предыдущий печальный опыт, когда хотелки менеджеров/заказчиков постоянно меняются и растут) заявляют так: "Я хочу разработать универсальную систему, которую можно будет использовать для случаев, которые я ещё не предусмотрел!".

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

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

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

Проще всего понатыкать в классы геттеров-сеттеров, но это совсем детский сад.