Дима пытается втиснуться между двумя титанами мысли )

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

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

Женя SOeR Сергеев (даже не будем говорить о всех регалиях, он слишком известен 🤫) в нашей студии!

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

А также: кого бы забанил Женя на Ютубе, если бы мог? Какой проект самый любимый? Что с фанатами?

Го смотреть!

https://youtu.be/aWoAmBqc2FE

Не будет никакого "самоочищения" все попытки что-то улучшить будут упираться в необходимость качественно обучить хулиард фронтендеров, а это бизнесу сильно дорого встанет, проще барахтаться с кучей херовых абстракций. ИМХО.
https://t.iss.one/t0digital/629

Такая фигня в этом стриме. Такое ощущение, что они психологическую помощь оказывают, а не о менторстве говорят.
https://m.youtube.com/watch?v=PTUbnLLwcMc

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

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

Немного про DDD и анемичные модели

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

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

В Domain Driven Design есть такое понятие как "анемичная модель", это как правило модель, которая не содержит логики и имеет только set/get методы. В данном подходе это плохо тем, что логика выносится за пределы модели и соответственно ее сложнее сопровождать, тестировать и развивать. Чем ближе связанные друг с другом вещи находятся, тем проще с ними работать.

Согласно логике DDD анемичной должна быть база данных. Целостность и логика должны быть заботой кода (с использованием транзакций), а в БД должны только хранится данные. В задачах где требования целостности укладываются в BASE это работает очень хорошо.

Но анемичная БД очень грустная штука, когда речь идет об ACID, просто потому что реализовать на уровне клиента целостность будет сложнее. Во многих бухгалтерских приложениях среднего размера, в системах отчетности и т.д. близость обработки к данным - это большой плюс. Можно сильно сэкономить и на размере команды, и выиграть в скорости работы. В больших приложениях "жирная" СУБД становится проблемой, но если задача хорошо ложиться на реляционную модель, то можно и в таком случае логику держать на уровне СУБД.

Как только мы начинаем выносить логику на СУБД, то мы автоматом множим анемичные модели в коде. Это как закон сохранения энергии, чтобы где-то прибыло, нужно чтобы где-то убыло.

Можно ли сказать, что вынос логики на уровень СУБД - это всегда зло? Нет! Во многом такой подход позволяет проще решать вопросы целостности и скорости работы. Естественно есть минусы - сложно горизонтально масштабировать, сложнее тестировать, сложнее дебажить. Но зато до определенного размера - быстрее работает, надежнее работает, меньше людей нужно для сопровождения.

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

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

#ddd #архитектура #мысли

Ядро Linux, факты:

- Ядро Linux представлено своим исходным кодом

- Ядро развивается, поэтому существует множество версий (можно сказать, что одно и то же ядро представлено множеством версий)

- Скомпилировать его можно используя разные опции (опций очень много несколько тысяч, поэтому вариантов компиляции огромное количество)

- Ядро скомпилированное из оригинальных исходников, независимо от опций, называют "ванильным" ядром

- На ядро перед компиляцией можно наложить разные патчи, это позволяет создавать разные варианты ядер

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

- Ядра Линукса с разными наборами патчей имеют свои названия (например, Zen-ядро)

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

#linux

Купил книгу на вечер, открыл на рандомной странице и прочитал совет "никогда не используйте switch", а знаете почему? Потому что это ведёт к багам!
Думаю, я готов пойти дальше - никогда не используйте языки программирования! Ведь это тоже ведёт к багам.
Но выводы о книге по одному совету делать не буду. Буду "почитать".

Пять строк кода

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

Некоторые мысли после прочтения:

1. Автор взял чисто процедурный код и начал рефакторить его в объектный вид. Очень странный подход, понятно что процедурные языки - это одно, объектные - другое. Смысл два подхода мешать в одну кучу? Есть огромные кодовые базы, написанные в процедурном стиле. На ООП будем их все переводить?

2. На практике трудно найти кодовую базу, построенную в соответствии со всеми советами книги. Для собственного развлечения можете посмотреть реальные проекты на гитхабе, и в истории поисать "refactor", а потом сравнить с советами в книге. Спойлер: совпадений будет минимум.

3. Про комментарии стандартная дичь, тут могу только передалать слова классиков: "чтобы вам код только без комментариев читать". Я много читаю кода, могу твердо сказать: "комментарии - это как глоток свежего воздуха, без них код сухой и скучный".
Авторам книги могу посоветовать писать книги без примеров кода, или наоборот без строчки текста. Сразу поймете, что есть мысли "для текста", есть мысли "для кода". Одно другого не исключает.

4. Книга написана для объема, куча воды и рассуждений автора. Опять же, ради интереса можете посмотреть список источников, используемых в "Совершенном коде" Маконнела и здесь. Не зря у Роберта Мартина книга вызвала одобрение, он тоже не любит работать с источниками, но любит рассуждения.
"Совершенный код" на порядок "практичнее", чем "Пять строчек кода". Нужно учиться работать с источниками, а не просто рассуждать.

5. На практике использовать все советы крайне сложно, реальные проекты на гитхабе тому доказательство, такой уровень грануляции как "пять строчек кода" - это просто невыполнимо. Можно БЛ написать с таким подходом, но библиотечный, утилитарный, инфраструктурный код писать в таком стиле смысла нет.

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

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

#книга #отзыв