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

И ставлю окно контекста на максимум всегда, но если потом просто переспросить по какому-то ключевому и неоднозначному моменту задачи "дай две-три строчки, которые поясняют вот этот момент" - буквально в 70% случаев АИ потом пишет "ой, вы правы, извините, я ошибся, на самом деле...". И часто после следующего уточняющего вопроса снова ошибается, и так далее.

То есть мы взяли стажёра на 200 долларов в месяц, и каждый pr теперь вот так надо за ним перепроверять??

=

Вот кто так спалился 100%, вообще не рекомендую:
жпт o4 мини
гемини 1.5 флэш
клод 3 хайку
дипсик v3

Смешное: хвалёная китайская deepseek v3, которую в конце года прям превозносили, что дескать совсем дешёвая, а в кодировании по независимым тестам прям рвёт всех... ага, оказывается в этом же пионерском ряду "за полгода с нуля на зп 150k".

Вдобавок ещё и в плане креатива ноль: попросил её дать пять идей по условной теме, так она выдала ну совсем шаблонные фразы.

Старый добрый жпт4о пока в этом плане лучше всех, а если не жмотица, то клод 3.5 стабильно хорош и в кодинге ,и в креативах.

Наблюдение продолжаю.

/ai Но, безусловно...
Реальность -- это то, что отказывается останавливаться, как бы нам субъективно этого не хотелось.
Поэтому давайте будем в 2025-м реалистами, и всё же сосредоточимся на том, что уже невозможно остановить.

жпт-о1-мини хороша в плане кода... только дороговата 😁

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

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

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

ну и фамилии "найденных" авторов на это сразу намекают :)

Автор: Иван Иванов
Автор: Мария Смирнова
Автор: Алексей Петров

(ai: "хорошая попытка, деточка")

Много думаю над тем, как продуктивнее всего обучить всем этим продвинутым темкам , чтобы в итоге научиться разрабатывать программы в парадигме топологически-ориентированного программирования (превращаем гомотопическую теорию типов в своеобразный DSL, язык "беспредеметной" области :)

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

А я хочу всё же попробовать обучить этому "наскоком", потому что всю математику под капотом тут знать в принципе не обязательно, если ориентироваться на некоторый условно прикладной уровень, потенциально доступный рядовому миддлу, который прошёл базовый курс по функциональному программированию. Немного похоже на машинное обучение: математики там тоже много, но чтобы начать создавать реальные проекты на DSL ML-фреймворков вроде PyTorch, всего-то надо пройти восемь ноутбуков моего курса например.
Что получится, не знаю, но если не попробовать , так и не узнать никогда.
Завтра выложу совсем простенький тренажёр по Martin-Löf Type Theory (альфа-версия).

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

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

То есть нулевой шаг пожалуй всё же будет изучать не алгебру и комбинаторную логику, а порешать задачки по геометрии, делая особый акцент на доказательстве теорем с большим количеством шагов доказательства. Сколь большим? Ну например доказательство Григорием Перельманом гипотезы Пуанкаре заняло около 200 шагов. А тибетские просветлённые мастера могли выстраивать логические цепочки длиной в несколько тысяч шагов.


Для разминки: задача об изогональных сопряжениях в треугольнике ABC. Пусть P — произвольная точка на плоскости снаружи треугольника, и не лежащая на его сторонах. Докажите, что существует случай, когда все три точки пересечения прямых PA PB PC со сторонами треугольника лежат на одной прямой (по теореме Паскаля о шестиугольнике). Помедитируйте сперва на визуальном решении.

Задачки Яковлева для школьников физмата и абитуры мехмата порешайте.

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

Можете поиграться:
Интерактивный Конструктор Типов MLTT
(ссылочка пока временная)

MLTT (теория типов Мартина-Лёфа) предлагает нам три ключевые концепции:

1. Зависимые типы. Типы могут зависеть от значений/предикатов/..., например, тип "матрица размером 2x3" или "чётное число" (внутри такого типа могут существовать только чётные значения). Соответственно, мы можем много дополнительных проверок рантайма перенести на фазу компиляции (был такой прекрасный язык Паскаль/Дельфи, а потом Оберон, а до них Алгол 68).

2. Индуктивные типы: позволяют создавать сложные структуры данных из других типов, от натуральных чисел до деревьев и т.д.

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

Потому что в MLTT сами типы -- объекты, которые имеют свои собственные типы... И рассуждая в такой парадигме логически, мы неизбежно придём к парадоксу существования "типа всех типов" (Type : Type).
Вот есть тип R, который определяется как "тип всех типов, которые не содержат самих себя". Будет ли R элементом самого себя? Ведь он по определению "не содержит себя", значит, он должен быть элементом типа R...

===

Ну и вот что тут непонятного? Любой сообразительный старшеклассник, хорошо изучивший информатику, это поймёт.
Ну разве что про универсумы не очень, но вы сразу их осознаете вот на таком простейшем примере:
- Универсум Type0 (или Set): содержит "простые" типы, такие как Nat (натуральные числа), Bool (логические значения) и т.д.
- Универсум Type1: содержит типы, которые могут включать в себя типы из Type0, например, типы функций или типы, зависящие от значений.
- Универсум Type2: содержит типы, которые могут включать в себя типы из Type1, и так далее.

И отсюда до гомотопической теории типов HoTT собственно остался всего один шаг: унивалентность. И это на самом деле тоже совершенно простая вещь на нашем программистском уровне, которую ввёл Воеводский:

Эквивалентность типов эквивалентна их равенству.
(Если два типа A и B эквивалентны (то есть существует биекция/отображение между ними, сохраняющая структуру), то они равны как типы: A = B)

И такое дополнение, напоминающее утиную типизацию, однако внезапно позволило формализовать идеи из алгебраической топологии и теории категорий в рамках теории типов!

=

Этот мой тренажёр быстро вас обучит синтаксису всех этих трёх ключевых концепций MLTT (я нагенерил 256 шаблонов задачек, на трёх уровнях сложности). Там даже никакой справки не требуется, по подсказкам и школьник разберётся, просто такой странный квест из простых синтаксических паззлов. А кто проходил мой курс по F#, конечно будет вообще легко и понятно.
А кто не проходил, просто вот на это взгляньте:

A → B означает тип функции (функциональный тип), которая принимает аргумент типа A и возвращает результат типа B.
Например, если A -- это тип натуральных чисел (Nat), а B -- тип булевых значений (Bool), то Nat → Bool — это тип функции, которая принимает натуральное число и возвращает булево значение (например, функция проверки натурального числа на чётность)
В тренажёре вместо "→" указываете "=>"

Дальше, соответственно, можно будет двигаться в семантику MLTT и далее.
Но мне ежедневно сливать на AI по 10-20 долларов, чтобы делать такие вещи в public domain, слишком накладно выходит, совсем не по карману.
Поэтому, следующие версии буду делать только через ваши донаты :)

/don только не надо пожалуйста звёздочки донатить, что я с ними буду делать? в крипту переводить? )

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

Найм сломан окончательно и бесповоротно, сильных сеньоров сокращают сразу сливают с собесов, мощные миддлы мучительно многими месяцами маленькое место мыкают, на одну джуниорскую вакансию прилетает 8096 откликов... Что вообще происходит? Почему так? А как будет? Сколько ещё? И куда теперь?

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

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

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

Коренная причина, как я уже говорил, прозаична и очевидна просто по здравому смыслу: вот ровно 100% по мемчику с картинки.

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

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

/muz обещанный mp3-плеер готов, но я решил евоный ui сделать поудобнее, с конфигом и печеньками, на днях выложу.

Кстати, совершенно нормальная схема вката в айти (без иронии),и требования вполне разумные.

Только надо уточнить один малюсенький момент по поводу "... 20 000 и т.д."

"и т.д." -- значит ли приведённый пример, что моя зп 0-10-20... через год будет 120,000 рублей, через два года 240,000 рублей, через пять лет -- 600,000 рублей, и т.д.?

Какая конкретно числовая последовательность из On-Line Encyclopedia of Integer Sequences тут подразумевается?

И не будет ли это на самом деле A000005 ?
10, 20, 20, 30, 20, 40, 20, 40, 30, 40...

Или даже A000120 ?
10, 20, 10, 20, 20, 30, 10, 20...

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

Склоняюсь к C4 или BPMI, но жпт пока рисовать диаграммы не умеет (на самом деле, уже немного умеет, скоро дам донам материал на эту тему). Но лучше чем текст, никогда ничего не было и не будет в плане КПД, картинки -- всегда лишь вторичное удобное дополнение. Тут идеально подходит BDD (курс по которому у меня в активном процессе, ~50% готово).

Но это конечно немыслимо

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

- и не только без навыка функционального проектирования ("Functional Core, Imperative Shell", потому что AI лучше всего пишет автономные чистые функции),

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

По этим темкам у меня уже много материалов и готово, и ещё делается, причём теперь практически все новые материалы и курсы будут доступны не только моим курсантам, но и (почти) всем (это пока я делаю прикорм :)

С 9 января продолжим в рабочем режиме. 🚀

На какой формат лучше всего заменить эти ваши бесконечно мучительные нетипизированные де/сереализации через жсон? 98% и не знают, что есть вот такой прекрасный "language-neutral, platform-neutral extensible mechanism for serializing structured data".

И нет, это не хмл: "think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages".

Срочно встраиваем в свои проекты Protobuf отсюда.

Для меня вполне ожидаемо: SpecFlow традиционно плохо поддерживал кириллицу. Не жалко совершенно.

As cool as a cucumber.

Обновлённый список наших блогеров на 08.01.25.

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

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

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

/dev в vk сегодня разбираю легендарную статью "Big Ball of Mud": семь классических антипатернов разработки.

"все LLM склоняются к среднему значению" (с)

Классная статья, как пацаны пытались применять ai в реальной программистской работе (лучшим ожидаемо оказался клод 3.5)
"What we learned copying all the best code assistants"

Важно! Есть несколько техник улучшения генерируемого кода, буквально ллм-ке надо просто сказать "пиши код получше, братан!", и она реально будет стараться побольше.
Как давать промпты, которые могут ускорить код в 100 раз (пример):
"Your code is not fully optimized, and you have been fined $100. Make it more optimized."
"Can LLMs write better code if you keep asking them to "write better code"?"
И тоже лучше всего прокатывает с клодом 3.5.

/meta-learn Донам в паблике для начинающих программистов продолжаю выкладывать продвинутые материалы по продуктивному самообучению и тайм-менеджменту.
"Принцип Парето (80/20) — это мощный инструмент для анализа и оптимизации, но его применение может быть глубже и неожиданнее, чем кажется на первый взгляд. Вот четыре малоизвестные и, возможно, контр-интуитивные рекомендации, которые развивают эту идею, основываясь на свежих исследованиях и подходах..."
(через месяц материал сгорит, теперь как и многие другие)

Программисты, у которых нет устойчивого личного бренда в эпоху AI, уже в текущем десятилетии практически обречены на выбор новой профессии.
В лучшем случае - на униженное вымаливание среднерыночный зарплаты в офисе 24/7 среди десятков откликов от таких же безликих и никому не известных сеньоров.

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

Вам кажется, что разбираться в легасе-коде очень тяжело (я уж молчу о том, насколько тяжелее будет вносить в него правки)? Попробуйте-ка разобраться в объёмном коде, сгенерённом AI, а потом его ещё и посопровождать.

/ai как у меня дыхание перехватило, когда я увидел яндексовские цены на евоный жпт )))

У них не было проектов, невыполненных заданий, технического долга и длинного бэклога; у них не было списков фич, сюжетных сценариев и оценок продуктивности; у них не было scrum-мастеров и тренеров по гибкой работе; у них не было спринтов, итераций и временных рамок; у них не было аналитиков, тестировщиков и product owner-ов; у них не было ретроспективных обсуждений, тройных сессий amigos и критериев приемлемости; у них не было серверов сборки, стендов UAT и показателей охвата тестированием.
И тем не менее (или благодаря этому всему?) они ухитрялись выкатывать устойчивые сервисы для трейдинга не за месяцы, а за минуты...
=

У меня была идея смоделировать подобный успешный (и крайне редкий) опыт и сделать несколько материалов, а может и курсов, по теме
как выдавать (достаточно качественный) продукт БЫСТРО.

FAST!

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

...В частности, и по таким причинам, общаться ни с кем выше синьорского уровня у меня желания нету совершенно никакого. Сейчас пропорции курсантов у меня примерно такие: 30% сеньоры, 50% миддлы, остальные джуны и начинающие с нуля, и добавлять новые типы курсантов принципиально не планирую.

Поэтому я решил, что заниматься темой FAST! не буду :)

...А сосредоточиться в этом году хочу на том, как - ясно и прозрачно, легко и просто, быстро и дорого - упаковывать в своей голове системы всё большего масштаба (миллионы строк кода). Такие своеобразные формальные свёртки проектных знаний с минимумом потерь. Иначе будете как Олег, который никак не мог понять, почему его код постоянно даёт сбои (а потому что он изначально не знал, почему тот вообще работал). Ведь ковыряться в легаси-коде, в неполной документации, в кривой и противоречивой корпоративной wiki можно бесконечно и чаще всего совершенно непродуктивно. Да и пилить с нуля систему, которая уже на втором десятке тысяч строк стремительно превращается в big ball of mud, ничуть не лучше.

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

Первые три обязательных шага Базы (курсы по ним я сделал, будет отдельный трек):
-- Ясное Легаси
-- Ясное TDD по Кенту Беку
-- Ясное BDD

Они дадут прежде всего минимальное понимание темы, без которого что-то изучать дальше бессмысленно. Но там как раз и начинается самое интересное: как например вывернуть BDD "наизнанку", стать инди-хакером, взламывающим, как Эллиот Андерсон, дебильные организационные процессы, "организованные" бездарными и никчемными менеджерами, не сверху, а снизу, через корпоративный КОД.
=

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

Как это сделать — фундаментальная тема программной инженерии. К счастью, есть набор эвристик, которые могут помочь. Сколько их? Я отобрал (буквально, отжал у ряда гуру computer science :) где-то около 50-ти. При том, что практически каждая из них автономна (как вышеупомянутая про устранение предупреждений линтера), и вы сможете хакать и править с их помощью кривейшие организационные процессы разработки в вашей конторе практически сразу же после изучения, при этом никак не согласовывая свою подпольно-революционную активность ни с кем, кроме адекватных понимающих сеньоров.

Курсантам на треке "Элитный программист" выложил БАЗУ: мощный материал "Дофаминовый детокс" (как обмануть свой мозг, чтобы он начал с удовольствием делать сложные вещи).

Вероятно, у вас нет проблем с компьютерными играми или постоянным просмотром соцсетей. Также нет сомнений в том, что перед экраном вы можете сидеть целый день, не теряя концентрации (например, при игре в Доту2 за боевого петуха). Но подумайте об обучении в течение хотя бы одного часа… УФ!! Это может быть тяжело. Или даже поработать над своим сайд-проектом в течение часа… Хм. Звучит не так привлекательно. Одно занятие лёгкое и не требует особых усилий , а другое сложное и требует приложения усилий. Однако некоторым людям нравится длительно заниматься сложными видами деятельности (например, мне), и не особо уставая. Как стать таким же?..

/boost Я завёл бусти 🙈 Пока исключительно в тестовых целях, хочу понять, насколько там реально продавать отдельные материалы в виде платных постов для всех. Платных подписок не планируется! Опубликовал там целиком "Дофаминовый детокс", пока 99 рублей. Ну или отнеситесь к этому просто как к донату :)

картинка — это стёб, если вдруг кто не понял.

🔥 СРОЧНО! СЛИВ ИНФОРМАЦИИ ОТ ИЗВЕСТНОГО СЕНЬОРА!

Вы до сих пор пишете async/await как джун?
Ваш код похож на спагетти из промисов?
Тимлид морщится, глядя на ваши асинхронные функции?

STOP! 🛑

Я раскрою вам СЕКРЕТНЫЕ ТЕХНИКИ, которые применяют только 1% элитных JavaScript-программистов!

В этом ЭКСКЛЮЗИВНОМ материале вы узнаете:
- 💣 Убойные паттерны работы с асинхронным кодом
- 🏃‍♂️ Как избежать "callback hell" раз и навсегда
- 🎯 Продвинутые техники обработки ошибок
- 🚀 Секреты оптимизации производительности
- 🧠 Мышление сеньора при работе с промисами

БОНУС!
Получите готовые шаблоны кода, которые используют в FAANG-компаниях!

Эти знания стоят $500/час консультации, но сегодня вы получите их практически БЕСПЛАТНО! Всего за 49 рублей!
Уже завтра цена сильно вырастет!

❌ НЕ ПОВТОРЯЙТЕ типичных ошибок миддлов
✅ ПИШИТЕ код как настоящий сеньор

Перестаньте писать async/await в JavaScript подобным образом! Вот как это делают сеньоры => Забирайте знания ТУТ, пока они доступны!

Время продаж ОГРАНИЧЕНО!

#javanoscript #programming #async #senior #development

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

СРОЧНО УХОДИМ с node.js, который всё теснее связывается с недружественной облачной коммерческой экосистемой vercel, на независимые альтернативы.
Прежде всего это
- Vite (a blazing fast frontend build tool powering the next generation of web applications)
и
- Remix (a full stack web framework that lets you focus on the user interface and work back through web standards to deliver a fast, slick, and resilient user experience. People are gonna love using your stuff).

qBittorrent -- лучший торрент-клиент, в нём нет ни рекламы, ни фишинга, ни другого мусора, говорили они...

В конце октября 2024 года разработчики выявили и устранили существовавшую более 14 лет уязвимость в системе безопасности qBittorrent, позволявшую злоумышленникам совершать MITM-атаки на пользователей.

Совершенно не удивлён, и дальше, по мере роста объёмов кода, безумно ускоряемого "с помощью" AI, будет только хуже.

Есть ОДНА архитектурная тема, которую надо всегда держать в уме ПЕРВОЙ, если вы взялись за разработку системы, которая в перспективе может существенно вырасти по нагрузке. Это БАЗА System Design, чтобы вам ни говорили разные умные курсы, учебники или техдиры на собесах.
Причём из этой абстракции одной произрастает почти всё остальное: управление нагрузкой и асинхронщина, надёжность и декомпозиция, балансировка и детерминизм, и многое многое другое. Как ещё например вы сможете обеспечить low cohesion между микросервисами, если без ЭТОГО.

И это не просто один из квадратиков, который надо не забыть куда-то впихнуть в диаграммку system design, когда вас на собесе попросили "спроектировать архитектуру нетфликса". Это базовая архитектурная парадигма.

(пауза)

Конечно же это ОЧЕРЕДИ (сообщений, задач, потоковой обработки...)

Только не забывайте, что Kafka это pull, а RabbitMQ это push.

"Мелочи не играют решающей роли, они играют всё!"
-- Харви Маккей,
"Никогда не пейте в одиночку, или Копайте колодец до того, как почувствуете жажду"
"Как плавать среди акул"
(его книги очень рекомендую кстати)

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

roslyn\csc.exe GameEngine.cs /warn:4 /warnaserror

javac -Xlint:all -Werror GameEngine,java

С линтерами посложнее, но тоже вполне реально.