Цель достигнута. Большое всем спасибо, особенно тем кто внёс свой вклад в виде подписки!

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

Ну что погнали https://youtu.be/hxRvfe9oczc
#стрим

Вчера на стриме говорил про свою систему донатов. Вот был по этой теме видос на канале - https://www.youtube.com/watch?v=Xpqc_k90ZGs
Думал о том, чтобы продолжать делать видео с мини-проектами. В которых делать архитектурные наброски решения. Интересен ли вам такой формат?

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

Алексей спасибо за поддержку. По ссылке пришло около 400 человек разом. )

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

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

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

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

На soer.pro опубликовал ответ на вопросы. Дублирую дорожку здесь. Ответы на другие вопросы есть на https://platform.soer.pro в разделе "Развитие / Вопрос ответ" вкладка "Все вопросы"

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

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

Эмоции убирать не планирую, поэтому свое отношение по прежнему можно выразить.

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

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

У меня только один вопрос - че это я "монологи"?

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

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

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

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

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

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

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

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

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

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