S0ER

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

Начинаю набор в Naris (III Сезон)! Сейчас я делаю проект soer.pro, в котором делаю движок Naris, в этом проекте я реализую концепцию взаимодействия по общей шине и сервисный подход. В нем сейчас есть хороший инфраструктурный слой, который построен на микрокубере, с мониторингом и всеми плюшками. Для меня принципиально чтобы проект был учебным, особенно с позиции архитектуры, т.е. все о чем я говорю в архитектурных стримах в нем используется. Я решил возродить концепцию devs2devs и набрать людей, которые хотят подтянуться в командной разработке с использованием нормальных архитектурных практик. Поэтому открываю 3 набор со сроком участия 3 месяца (1 июня - 1 сентября). Сам проект строится на nestjs+angular2, требование к кандидатам простые - базовые знания JS (TS) и желание учиться, учитывая опыт devs2devs обязательно требование - иметь возможность уделять проекту 8 часов в неделю. Общение будет идти в отдельном закрытом чате в телеге, там же буду публиковать всю необходимую инфу. Если хотите участвовать, то напишите мне на почту soersoft@gmail.com письмо с темой "Участие в Naris", где нужно указать, почему вы хотите поучаствовать в проекте и какие знания у вас есть. А так же обязательно указать есть ли у вас возможность тратить время на проект и по какому графику (например, "в выходные по паре часов".) Работа строится так: 1. Вы присылаете письмо, я его рассматриваю 2. Приглашаю тех кто подходит в чат телеги 3. Вы регистрируете на сайте с гит-репозиторием 4. Выполняете любой вступительное задание 5. Если задание выполнено и принято, то начинаем работу (если нет, то прощаемся) 6. Работа строится двухнедельными спринтами, в рамках которого нужно выполнять таски В чем польза для участников: практика разработки в команде, использование современных методик разработки, разбор проблемных мест проекта, прокачка навыков писать код, обсуждения и фан от разработки.

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

https://t.me/it_podcasts/103 Подкаст от Алексея Голобурдина, который вам больше известен как Диджикалитазиру... тьфу... Цифровизируй, короче говоря. Алексей решил нетривиальную задачу и смог объединить слова "Python", "Лаконичность" и "Архитектура" в одном предложении, при этом ни разу не рассмеявшись. Так же Алексей установил, что в среднем программисты на PHP слабее, чем на Python, поэтому грузчиками им лучше не работать. В общем и целом подрый бодкаст, который стоит послушать, хотя бы ради поднятия настроения.

Когда-то я пытался систематизировать знания в виде "шпаргалок", чтобы можно было быстро искать какие-то важные вещи. Но в итоге гугл победил шпаргалки. Проще запомнить один типовой кейс - поиск, чем копить кучу файлов, в которых со временем так же приходится искать инфу и про которые тупо забываешь. Но подсказки хороши в тех случаях, когда нужно собрать ключевые запросы для дальнейшего поиска по новым темам, когда нужно составить родмап по изучению нового. Помните раньше в школах были книги с кратким изложением скучных книг? По сути это те же шпаргалки только вид сбоку. В общем, все это пишу чтобы показать вот этот канал - https://t.me/it_tochka в нем публикуется очень много "шпор", которые кому-то могут оказаться полезными Это не реклама, узнал о канале когда смотрел стату по своему каналу и увидел, что там есть упоминания обо мне. Классическое "За что же, не боясь греха, Кукушка хвалит Петуха? За то, что хвалит он Кукушку."

Субботний стрим начинается в пятницу! ) В честь 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", который есть в

Инженер Google Дэн Рева обнаружил в Telegram для macOS уязвимость, которая позволяет злоумышленникам использовать камеру и микрофон ноутбука. Более того, запись видео и звука будет работать, даже если соответствующие разрешения отключены. Это стало возможно, потому что Telegram для macOS не использует встроенный механизм безопасности Apple Hardened Runtime.

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

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

Пять строк кода Если коротко, то большая часть книги - "Демагогия". Несколько дельных советов, на тонны ненужной, местами вредной воды. Некоторые мысли, после прочтения: 1. Автор взял чисто процедурный код, и начал рефакторить его в объектный вид. Очень странный подход, понятно что процедурные языки - это одно, объектные - другое. Смысл два подхода мешать в одну кучу? Есть огромные кодовые базы, написанные в процедурном стиле. На ООП будем их все переводить? 2. На практике трудно найти кодовую базу, построенную в соответствии со всеми советами книги. Для собственного развлечения можете посмотреть реальные проекты на гитхабе, и в истории поисать "refactor", а потом сравнить с советами в книге. Спойлер: совпадений будет минимум. 3. Про комментарии стандартная дичь, тут могу только передалать слова классиков "чтобы вам код только без комментариев читать". Я много читаю кода, могу твердо сказать, комментарии - это как глоток свежего воздуха, без них код сухой и скучный. Авторам книги могу посоветовать писать книги без примеров кода, или наоборот без строчки текста. Сразу поймете, что есть мысли "для текста", есть мысли "для кода". Одно другого не исключат. 4. Книга написана для объема, куча воды и рассуждений автора. Опять же, ради интереса можете посмотреть список источников, используемых в "Совершенном коде" Маконнела, и здесь. Не зря у Роберта Мартина книга вызвала одобрение, он тоже не любит работать с источниками, но любит рассуждения. "Совершенный код" на порядок "практичнее", чем "Пять строчек кода". Нужно учиться работать с источниками, а не просто рассуждать. 5. На практике использовать все советы крайне сложно, реальные проекты на гитхабе тому доказательство, такой уровень грануляции как "пять строчек кода" - это просто невыполнимо. Можно БЛ написать с таким подходом, но библиотечный, утилитарный, инфраструктурный код писать в таком стиле смысла нет. Книгу стоит прочитать, если вы любите порассуждать о коде где-нибудь за кружечкой чая в баре. На практике мало пользы будет.

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

Ядро Linux - Ядро Linux представлено своим исходным кодом - Ядро развивается, поэтому существует множество версий (можно сказать, что одно и то же ядро представлено множеством версий) - Скомпилировать его можно используя разные опции (опций очень много несколько тысяч, поэтому вариантов компиляции огромное количество) - Ядро скомпилированное из оригинальных исходников, независимо от опций, называют "ванильным" ядром - На ядро перед компиляцией можно наложить разные патчи, это позволяет создавать разные варианты ядер - Бывают патчи для поддержки нового оборудования, увеличения безопасности, увеличения производительности, для поддержки реально времени и т.д. - Ядра Линукса с разными наборами патчей имеют свои названия (например, Zen-ядро) - В дистрибутивах линукса редко используется ванильное ядро, вместо этого авторы дистрибутива поддерживают свой набор патчей, с помощью которых выпускают свои версии ядер

Немного про DDD и анемичные модели В идеальном мире можно выработать правила и требования, которые будут всегда справедливы и подходить для любой ситуации. В реальном мире всегда приходится искать компромиссы, все категоричные суждения "это хорошо, а это плохо", без способности объяснить "почему?" - это все про идеальный мир. Как происходит в реальном сейчас расскажу. Начну с того, что изучив несколько разных архитектур, вы, наверное, заметите, что основная идея любой архитектуры - разделить обязанности и провести жесткие/мягкие границы между ними. Сейчас очень популярны сервисные и микросервисные подходы, поэтому популярное место проведения границ - это код. А разделение обычно делается на "инфраструктуру" и "бизнес-логику". В Domain Driven Design есть такое понятие как "анемичная модель", это как правило модель, которая не содержит логики и имеет только set/get методы. В данном подходе это плохо тем, что логика выносится за пределы модели и соответственно ее сложнее сопровождать, тестировать и развивать. Чем ближе связанные друг с другом вещи находятся, тем проще с ними работать. Согласно логике DDD анемичной должна быть база данных. Целостность и логика должны быть заботой кода (с использованием транзакций), а в БД должны только хранится данные. В задачах где требования целостности укладываются в BASE это работает очень хорошо. Но анемичная БД очень грустная штука, когда речь идет об ACID, просто потому что реализовать на уровне клиента целостность будет сложнее. Во многих бухгалтерских приложениях среднего размера, в системах отчетности и т.д. близость обработки к данным - это большой плюс. Можно сильно сэкономить и на размере команды, и выиграть в скорости работы. В больших приложениях "жирная" СУБД становится проблемой, но если задача хорошо ложиться на реляционную модель, то можно и в таком случае логику держать на уровне СУБД. Как только мы начинаем выносить логику на СУБД, то мы автоматом множим анемичные модели в коде. Это как закон сохранения энергии, чтобы где-то прибыло, нужно чтобы где-то убыло. Можно ли сказать, что вынос логики на уровень СУБД - это всегда зло? Нет! Во многом такой подход позволяет проще решать вопросы целостности и скорости работы. Естественно есть минусы - сложно горизонтально масштабировать, сложнее тестировать, сложнее дебажить. Но зато до определенного размера - быстрее работает, надежнее работает, меньше людей нужно для сопровождения. Архитектура - это поиск компромиссов, раздутые бюджеты и многочисленные команды разрабов может позволить далеко не каждый проект. Нормальный разработчик на уровне БД может решить гораздо больше проблем и сильно оптимизировать бюджет. Вывод сказанного простой - есть разные решения для одних и тех же проблем, любые решения нужно обдумывать и уметь обосновать, а просто повесить для себя "маркеры" по типу "это анемичная модель, все пропало" - это не про архитектуру, это какая-то странная религия, которой многие увлечены в последнее время. #ddd #архитектура #мысли

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

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

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