Я закончил первый курс (База:) нового трека по 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 вообще давно заявляли, что "интеграционный тест" — это бесполезный термин.

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

Потеряны миллиарды долларов на баге Crowdstrike, однако ваш менеджер и ваши коллеги продолжают твердить: "Да не нужен нам Rust / Zip , у нас и так всё отлично получается на <unsafe language>".

Власти Швейцарии потребовали, чтобы весь государственный софт был опенсорсным: "public money, public code" (интересно будет на него посмотреть, кстати).

💯 у нас такое в принципе невозможно и никогда не будет, потому что имеется 100500 "объективных" причин ("Батарея не стреляла по 15 причинам. Во-первых, не было снарядов...").

Во-первых, это как мы будем всем показывать такой говнокод?..

Смею утверждать, что многие люди никогда не видели абстракцию.

Они видели, например, entity services, загромождённые огромным количеством методов.

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

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

P.S. Сегодня в вк выложил пост, как связаны распределённые системы и моноиды :)

"Наша временная приляпка для временной проблемы превратилась в долгосрочную проблему" )))

Немного от курсантов:

Теперь думаем, что нам нужен ченж-лог, и нормальное версионирование, чтоб люди понимали, что текущее обновление, может что-то сломать...

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

Я помню, когда проект с вами на Go делал, казалось, что я писал тогда код и проектировал систему в скоупе programming in small практически такого же качества. Только эти сервисы, которые достались мне, писались людьми, у которых на тот момент в LinkedIn был указан опыт 8 лет, и предыдущие позиции чуть ли не CTO...

Ещё неделю назад эта рекомендация висела вот тут на сайте CrowdStrike (которая нанесла ущерб в миллиарды долларов своим "локально протестированным" null-поинтером). Видимо, все программисты -- пакистанцы на удалёнке.

Ну прежде всего, не надо ни впн, ни анти-дпи, провайдер блокирует в основном сомнительный UDP-трафик 443 или пытается выявить QUIC (например, протокол шифрования Kyber обнаруживает), поэтому в хроме просто их задизаблите. Это уже на 90% работает, если качество непринципиально (я просто слушаю фоном обычно).

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

Девушка откликнулась на вакансию ↑↑↑ и вот какие вопросы задавали начинающему джуниору:

1. Параметр Generic-класса (всегда ли можем получить класс объекта с помощью getClass() в runtime).
2. Java heap memory: string pool и интернирование строк.
3. Аннотации в Spring (в целом было много вопросов за что какая аннотация отвечает, чем отличаются, в каких случаях что используется).
4. Жизненный цикл бинов.

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

Много раз замечал, что 98% тех, кто говорит "алгоритмы вам на работе никогда не понадобятся" (и это действительно так), сами как раз очень даже хорошо разбираются в темке АСД (на уровне 1-2 курсов универа).

Я попросил ChatGPT продолжить "def how_to_sex():" ...