S0ER

Запись стрима про бизнес-логику https://www.youtube.com/watch?v=gFFDolTeAQw

ChatGPT теперь везде - https://xakep.ru/2022/12/23/chatgpt/

Стрим переносится на завтра (суббота) на 10:00 по Мск https://youtu.be/gFFDolTeAQw

Я помню во времена моей бурной молодости, в фидо распространялся файл, который бы завернут большим количеством разных архивов (более 20 штук). И задача была распаковать этот файл, чтобы прочить "поздравляю, вы очень упорный человек". Во времена, когда не было интернета, это действительно была задача для упорных. Сейчас все самые странные штуки можно найти на гитхаб. Как вам такой "зверь" - https://github.com/leachim6/hello-world здесь собраны примеры программ "Hello world" на всех (ну или почти всех) языках программирования.

На гитхабе набирает обороты проект tweetGPT, который генерирует ответы в твиттере, используя chatGPT. Теперь осталось сделать так, чтобы сами посты генерировались тоже через chatGPT и мы получим модифицированный тест тьюринга, когда надо чтобы бот, общаясь с ботом смог определить, что с другой стороны бот. )))) https://github.com/yaroslav-n/tweetGPT

Если хотите разобраться в подробностях как происходит сборка программы и линковка библиотек на С, то гляньте вот это мое видео - https://youtu.be/HBFA6dKW7qE думаю, многие вопросы прояснятся.

Ммммм... компиляция си в webasm такие штуки я люблю... https://github.com/emscripten-core/emscripten

Я много работаю через терминал, поэтому всегда интересно найти что-то новое и красивое. Сегодня решил попробовать ещё один, написанный на pytho, с поддержкой GPU. Терминал называется KITTY и сейчас активно собирает звезды на гитхаб https://github.com/kovidgoyal/kitty

Я профессионально занимался архитектурой программных проектов более 10 лет, у меня сложилось свое понимание о том как нужно работать с архитектурой. Хочу сделать наблюдение про "чистую архитектуру". Встречаю людей, которые говорят, что на самом деле архитектура сильно переоценена и главное - это что нужно бизнесу и что можно все сделать удобным тебе образом и все будет ок. Собственно в контексте "чистой архитектуры" так оно и есть. И сейчас поясню в чем, на мой взгляд, тут недопонимание. Любимая метафора всех, кто говорит про архитектуру, - это строительство домов. Возьмем эту же метафору за основу. У нас есть дом, который построили по проекту, есть ли в этом проекте архитектура? Безусловно - да! Теперь в дом заехали жильцы и начали делать дизайн своих квартир. С легкой подачи Роберта Мартина, дизайн - это архитектура. При этом мы свободные в некоторых рамках - можем красить стены, можем переносить розетки и даже можем убирать или изменять какие-то конструкции (в некоторых пределах) - это дает ощущение, что архитектура неважна. Ведь мы можем ее легко менять и ничего страшного не происходит. Вот в этом и состоит проблема - есть некоторый набор действий, которые позволяют отклоняться в принятии решений от того, что предлагает нам архитектура проекта. Но если мы зайдем слишком далеко, например, решим убрать все несущие стены, то окажется, что такое изменение может привести к разрушению всего дома. Лично я не склонен считать дизайн частью архитектурного решения, поэтому мне кажется, что "переносить розетки" в проекте каждый может так как считает нужным. Для меня архитектура - это как раз тот набор принципов и правил, по которым строится основа проекта, нарушение этих правил приведет к неминуемой проблеме. Чистая архитектура - это уровень кода (есть еще уровень программ, уровень системы, уровень организации), поэтому во многом она затрагивает вопросы дизайна, как следствие - вносить изменения можно без последствий, но ровно до тех пор, пока мы не отойдем от дизайна и не перейдем к архитектурным принципам, вот тут мы уже не сможем просто менять правила игры не получая штрафа в виде тех. долга и нарушений в работе проекта. Поэтому не стоит рассматривать "чистую архитектуру" в качестве хорошего примера для утверждения, что архитектура не так уж важна. Архитектура программного проекта затрагивает куда больше аспектов, чтобы сосредоточиться только на одном самом простом уровне.

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

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

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

После того как я сходил на стрим к Антону Назарову теперь вся лента забита его видосами. Ютуб не делай этого со мной! 🙏🏼

Посчитали уровень развития проекта Naris. Напомню это опенсорс проект, который мы делаем вместе с активистами, которым интересно прокачать свои навыки разработки и работы в команде. Для расчёта использовали бальный метод, о котором рассказывал в своих закрытых архитектурных стримах. Получилось, что уровень развития 53%. Это довольно мало, основная проблема в слабой инфраструктуре, в реальных боевых проектах то же резервное копирование - must have, а у нас его просто нет. Первый этап работы в Naris заканчивается в конце этого месяца, обязательно соберу обратную связь и расскажу вам.

Дима (SSV) очень активно взялся за развитие сообщества ITYouTubers - https://ityoutubers.com/all-channels и теперь у него не только сообщество, но вообще все каналы русского ютуба по АйТи собраны в одном месте. Дело очень хорошее, от меня респект и лайк 👊🏼

В пятницу хочу поговорить про то, что такое бизнес-логика почему и как с ней работать. Думаю, что разговор будет интересный. Стрим будет проходить по следующей схеме: - 40 минут рассказываю о своем понимании бизнес-логики - 30-60 минут отвечаю на вопросы (сначала донаты, потом вопросы из чата на ютубе) https://youtu.be/gFFDolTeAQw #стрим

В рамках ревью кода для Naris наткнулся на интересную ситуацию: - есть две структуры DTO с данными пользователя (login, email, password) и моделька для записи в БД (тот же login, email и password). - в DTO проставляем валидирующий гуарды для email - нужно ли проставлять валидирующие гуарды для email в модельке, ведь мы уже сделали проверки при получении DTO

Решил отказаться от поддержки чата для канала. Он не выполняет той функции, которую я хотел от него получить - ответы на уточняющие вопросы, конструктивные обсуждения. Комментарии на ютубе я читаю редко, поэтому осталось два основных канала общения: - задать вопрос на soer.pro - общение для платных подписчиков soer.pro в отдельном чате. Эмоции убирать не планирую, поэтому свое отношение по прежнему можно выразить.

Мне в комментах накинули интересный термин "булева логика", чел. который это выдал не вызвал у меня доверия, но все же хочется понять, что за зверь это такой, кто может поделиться ответами по следующим вопросам: 1. Чем "булева логика" отличается от "булевой алгебры" 2. Чем "булева логика" отличается от "логики предикатов"