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

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 (те самые пиринговые стыки), и другие владельцы магистральных сетей связи последние годы активно вкладываются в своё развитие (и офигевают от подобных "инициатив", но помалкивают), питерские напрямую трафик гонят с Франкфуртом и Амстердамом, странно если вдруг их принудительно заставят что-то там у себя ломать.

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

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

Смешная история, как микрософты 10 лет пытались пофиксить баг производительности в F# , и в этом году наконец таки закрыли тикет )))


Что ни в коей мере не умаляет крутости F# самого по себе:

- Система типов: мощность Rust + простота TypeScript;
- Выразительность и эргономичность: ощущение будто пишешь стенографию;
- Прагматичность: полный доступ ко всей инфраструктуре .NET.

P.S. В этом ноябре закончится поддержка .NET 6, но зато доступна .NET 9 превью-6.

Пишите больше модульных тестов, нежели интеграционных.
Или нет?

Write tests. Not too many. Mostly integration.
Или нет?

Интеграционные тесты -- это скам :)
Или нет?

А Google и Twitter вообще давно заявляли, что "интеграционный тест" — это бесполезный термин.

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