S0ER

Если хотите разобраться в подробностях как происходит сборка программы и линковка библиотек на С, то гляньте вот это мое видео - 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. Чем "булева логика" отличается от "логики предикатов"

Всем, кто интересуется сферой применения нейронок, рекомендую посмотреть вот эту статью https://habr.com/ru/company/recognitor/blog/524980/ Лучше, конечно, посмотреть более свежий обзор инструментария, поэтому если есть что-то полезное, то киньте в комментариях

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

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

К вопросу о том "кто такой архитектор". Я уже снимал видео про архитектора решений. Поэтому просто дам ещё раз ссылку. На многие вопросы, которые задают, я уже отвечал давным давно на канале. Поэтому чтобы не повторяться буду давать ссылки на старые видео https://youtu.be/bYd9FavRQfI