Не будет никакого "самоочищения" все попытки что-то улучшить будут упираться в необходимость качественно обучить хулиард фронтендеров, а это бизнесу сильно дорого встанет, проще барахтаться с кучей херовых абстракций. ИМХО.
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. но одну закладку все же поставил, там где мысль про локальные инварианты. Это дельный совет - смысл в том, что инварианты должны быть ближе к месту их использования. Глобальных инвариантов не должно быть много.

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

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

Можно будет опробовать на стриме, если не забуду. )

Чтобы не быть голословным, вот пример реального кода из Angular (https://github.com/angular/angular/commit/0d9705be0b2b9df22934c8a3aad8c65201b305ad) который жестко нарушает несколько принципов из книги: запрет на switch, ограничение размера, запрет на комментарии, запрет на сеттеры и геттеры, правило "вызов или передача".

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

У ITYouTubers есть папка с телеграм-каналами людей, которые входят в сообщество. Сегодня меня обвинили в лицемерии потому что я ее не опубликовал (весь разговор можно посмотреть на канале "Круги на полях IT", который есть в этой папке) - https://t.iss.one/addlist/I8prigGqDr5kYjBi

Upd. может кто не знает, можно удалять из папки каналы, которые не нравятся

Ребята запускаю сбор тем на субботний стрим:

1. ЗЭН - пишите в комментариях вопросы (буду выбирать самые популярные или которые понравятся мне) - ответ будет в субботнем стриме

2. Ревью кода и проектов - может быть вам интересно узнать мое мнение по вашему репозиторию (можно от фрагментов кода, до своих проекто) на github - тогда можно написать ссылку в комментариях и примерно чего вы ожидаете, буду выбирать на свое усмотрение и желание и в субботу на стриме будет обзор

3. Как всегда все что будет на https://donate.s0er.ru буду рассматривать в обязательном порядке (если по АйТи, все провакационные вопросы и подколы не рассматриваю).

Как обычно проходят субботние стримы можно посмотреть вот здеь - https://www.youtube.com/watch?v=6opSSjokwm4

Мы набрали ровно 10к подписчиков на этом канале! Огромное спасибо всем подписавшимся.

Субботний стрим начинается в пятницу! ) В честь 10к подписчиков запускаю стрим досрочно https://youtube.com/live/ee7wqFTU9Ug?feature=share

Получил доступ в GigaChat. Надо сказать результаты весьма скромные, например, он не умеет отвечать "не знаю", придумывает на лету, исходя из контекста. )

Начинаю набор в Naris (III Сезон)!

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

Я решил возродить концепцию devs2devs и набрать людей, которые хотят подтянуться в командной разработке с использованием нормальных архитектурных практик. Поэтому открываю 3 набор со сроком участия 3 месяца (1 июня - 1 сентября).

Сам проект строится на nestjs+angular2, требование к кандидатам простые - базовые знания JS (TS) и желание учиться, учитывая опыт devs2devs обязательно требование - иметь возможность уделять проекту 8 часов в неделю.

Общение будет идти в отдельном закрытом чате в телеге, там же буду публиковать всю необходимую инфу. Если хотите участвовать, то напишите мне на почту [email protected] письмо с темой "Участие в Naris", где нужно указать почему вы хотите поучаствовать в проекте и какие знания у вас есть. А так же обязательно указать есть ли у вас возможность тратить время на проект и по какому графику (например, "в выходные по паре часов".)

Работа строится так:
1. Вы присылаете письмо, я его рассматриваю
2. Приглашаю тех кто подходит в чат телеги
3. Вы регистрируете на сайте с гит-репозиторием
4. Выполняете любой вступительное задание
5. Если задание выполнено и принято, то начинаем работу (если нет, то прощаемся)
6. Работа строится двухнедельными спринтами, в рамках которого нужно выполнять таски


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

P.S. набор будет 20 человек, отвечать буду 29-31 мая. Если ответа нет, значит не взял в команду. Участие бесплатное.

Про абстракции

Когда вы становитесь архитектором и работаете в АйТи, то очень быстро учитесь видеть абстракции, в абстракциях, которые навернуты сверху других абстракций.

Вот так, например, выглядит температура и влажность в моей комнате, если смотреть глазами осцилографа.

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

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