S0ER

На канале Диджитализируй была прикольная попытка показать как создаются проекты с нуля. Получилось два видоса и усё.

Это супер иронично, потому что именно так в 99 случаев из 100 происходит в реальности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инженер Google Дэн Рева обнаружил в Telegram для macOS уязвимость, которая позволяет злоумышленникам использовать камеру и микрофон ноутбука.

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

Это стало возможно, потому что Telegram для macOS не использует встроенный механизм безопасности Apple Hardened Runtime.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#linux

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

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

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

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

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

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

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

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

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

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

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

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

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

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