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

(список всех материалов для донов)

Вот кусочек:

...Если вы принимаете те факты, что разработки игр очень сложна, что оплата будет низкой и что вам желательно получить хорошее профильное образование, в идеале, на дорогих курсах, добавлю ещё одну серьёзную проблему: вам придётся освоить C++. Потому что разработчикам игр понадобится немало навыков, без которых программисты из других сфер вполне могут обойтись.
Конечно, можно разрабатывать игры, и не зная C++. Множество игр написаны на самых разных языках программирования, причём немало и таких, которые сделаны в удобных фреймворках, по сути вообще не требующих знания программирования. Однако крупные игровые студии, выпускающие топовые игры, полагаются на C++ как один из основных языков разработки.
В будущем это может измениться конечно, но я очень сильно сомневаюсь. Потому что игры всегда идут в авангарде ИТ, выжимая по максимуму возможности из любого оборудования. Это означает, что даже если C++ перестанет использоваться, его место займёт какой-то другой язык, также позволяющий очень эффективно использовать возможности железа (а это сложно), потому что необходимо добиваться максимальной производительности на оборудовании, которое использует игра.

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

слева самый крутой science based программист
в центре самый слабый курсант моей Школы
справа выпускник Школы

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

Не смог даже явного победителя определить, в июле будет Сергей Крайнюков,
давно и хорошо пишет. Подписка и лайк 💥 => "Android Developer Blog"

Сергею на текущий курс ("Ясная архитектура") скидка 1,000 рублей, и также скидки предыдущим победителям -- Дарья и Светлана (обе -- первый курс ООАП).

Такое мы одобряем:

AMD Zen 5 architecture: A ground up redesign that lays the foundation for future Ryzen CPU architectures
Zen 5 now supports native AVX-512. Interestingly, AMD says Zen 5 processors will run AVX-512 without any frequency penalty. Strix Point supports full AVX-512 too which will remain challenging for notebook cooling and TDPs...

16-ядерный Ryzen 9950X выходит 31 июля например (уже принимают заказы по ~600 долл.)

В тему, мой пост про сишечку полгода назад:

...Резюме, что и в Си правильно (и положено по стандартам) думать не в императивных строках кода, а в абстракциях sequence points (а если хотите абстрактные типы данных, применяйте union :).

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

(Например, в конце 2023-го Intel выпустила обновление либы x86-simd-sort,
которая за счёт поддержки AVX-512 ускорила на порядок сортировку в NumPy и OpenJDK. А на днях Xeon 5-го поколения Emerald Rapids показал с помощью AVX-512 на рабочих нагрузках, характерных для работы AI, выигрыш в 2-10 раз.
И вот если формализовать модель векторного стриминга AVX, и под неё разработать суперкомпилятор Си, и получить космическую оптимизацию... если кулера хватит :)

Когда я пытаюсь объяснить ребятам, что крайне важно, особенно в эпоху AI, учиться computer science, математике, формальной верификации, их глаза обычно стекленеют, и я вижу, как они думают "о чём вообще говорит этот дед?".

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

Постоянно встречаю заметки в духе "Zig -- это преемник Си / новый Си", хотя ещё недавно считалось, что это Rust. Про Zig я говорил, в чём он получше Rust навскидку.

=>

Сенсация этого года: Zig бьёт все рекорды по зарплате в сфере разработки
За Zig кстати по доходности идут Erlang и F# 💯

Top benefits of the Zig programming language

Introduction to Zig, a Potential Heir to C

Мысли о Zig и Rust

Посмотрю насколько у него компилятор лёгкий, может в какой-нибудь курс по АСД добавлю его поддержку.

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

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

Советы для тех, кто хочет использовать F# на работе, но часто получает отказ:

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

...при условии, что вы сами выберете инструменты.

Спасите проект, получите многомерную прибыль.

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

Предлагаю такие названия:

самое_главное_значение
очень_важная_переменная_1
это_та_самая_переменная
оЧеРеДнАяПерЕмеНнАя22
я_не_знаю_как_тебя_назвать
мои_данные
что_то_универсальное
столько_вариантов_и_ни_одного_правильного

финальный босс:

наконец_конечное_значение_42

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

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

Ставь китика, если реально используешь Guava в своих проектах.

Это "a set of core Java libraries from Google that includes new collection types (such as multimap and multiset), immutable collections, a graph library, and utilities for concurrency, I/O, hashing, primitives, strings, and more!"

Я её случайно отрыл, когда разбирал в новом курсе на примерах темку потенциальных багов в concurrency.

Если ваша система общается сразу с несколькими stateful-системами, то поздравляю, вы программист распределённых систем! :)

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

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

Я закончил первый курс (База:) нового трека по software design 💥

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

Четыре основных раздела + два дополнения.

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

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

3. Как код, выглядящий просто, может оказаться реально сложным, и как избегать такого.
Разбор на примерах вроде бы простого, но коварного кода.
7 способов, как не доводить простой код до неочевидных ошибок.
Защищаем код от внезапных изменений в требованиях. Три классических подхода.

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

5. "Знание" кода.
Вы можете нередко услышать, как опытные программисты в разговоре упоминают, что одна часть их кода "знает" о другой части кода. Что имеется в виду?
6 видов зависимостей, разбираем на примерах.

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

=

18 заданий (все с разбором), 30+ примеров, много тематических отсылок к СильнымИдеям.

Курс для Java-истов, но в принципе, и C#-истам зайдёт.

Уровень -- крепкий джуниор, ну может быть миддл-лайт.

=

На следующем, втором курсе трека займёмся демистификацией самого процесса проектирования.

Продолжаю рассказывать донам про сверхвозможности Postgres, которого одного достаточно, чтобы развернуть на нём большую инфраструктуру.
Сейчас выходит немало статей в духе "SQL - это навсегда", где отмечается, что многие из известных NoSQL-технологий уже активно удаляются из кодовых баз BigTech, потому что они не работают.

Дед сказал собирать вещи, кажется, началось, срочно бежать изучать функциональное программирование: в Node.js добавили поддержку TypeScript.

node foo.ts

TypeScript прекрасен как язык программирования: мощная система генериков (почти как в Haskell или Scala), статическая типизация с тайп-чекингом в процессе кодирования, тип union, дискриминантное объединение (создание типов с разными наборами полей по условию), и даже можно объявлять static строки :)
На этом фоне ООП курит далеко в стороне.

Да, но под капотом всё ещё JS, и как только вы выходите за пределы TS, чтобы интегрироваться с остальной частью экосистемы JS, начинается сплошная боль и страдание :)

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

Возможно как раз, добавление TS в Node.js как-то это всё немного упорядочит.

И позавчера я говорил, какая есть JS-библиотека/фреймворк, которой можно научиться сейчас, а потом просто сосредоточиться на коде, не беспокоясь о том, что он скоро устареет.

Напоминаю, CI/CD - это когда:
1. Систему можно развёртывать на протяжении всего жизненного цикла.
2. Команды отдают приоритет развёртываемости системы, а не новым функциям.
3. Все разработчики имеют быструю автоматизированную обратную связь о готовности системы к деплою.
4. Развёртывание возможно по требованию в любой момент.

Более того ↑ ↑ ↑ немало k8s-проектов, где микросервисов больше, чем пользователей.

От курсанта:

Узнал, что у нас есть целый микросервис, который высчитывает нужно ли поднимать сотруднику з/п и на сколько.
Также, к сожалению, узнал, что в этом сервисе есть ифчик из разряда if employee.LastRaise < 6 месяцев, тогда пересмотр не положен даже, если з/п уже отстает от рыночной.

Сильно сомневаюсь, что ютуб у нас "специально" тормозится: проверить невозможно, а понадувать щёки на этой темке "вот какие мы крутые" самое оно :)

Гугл -- это половина интернета, и постоянно открыто рассказывает, какие у него проблемы с устаревшим оборудованием по всему миру. Думаю, нереально залочить только один его сервис, а тем более как-то "ухудшить". CDN у Google арендует океан компаний (телеграм и порнхаб например), и если пытаться гугла отключить, то в РФ накроется много чего, причём проблем будет гораздо больше нежели с недавнем мировым сбоем Windows (например, упадут все андроид-устройства).

Ростелеком -- владелец MSK-IX (те самые пиринговые стыки), и другие владельцы магистральных сетей связи последние годы активно вкладываются в своё развитие (и офигевают от подобных "инициатив", но помалкивают), питерские напрямую трафик гонят с Франкфуртом и Амстердамом, странно если вдруг их принудительно заставят что-то там у себя ломать.

Впрочем, подозреваю, "официальные" планы имеют под собой внушительных лоббистов (рейдерский отжим трафика:), которые потом будут например предоставлять к ютубу и прочим быстрый доступ в России за денежку (через православный впн).

В Китае кстати ютуб забанен/тормозится, однако там имеется немало успешных ютуберов-миллионников 😎