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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вчера Михаил Фленов провел ламповый стрим - https://www.youtube.com/watch?v=y21Eqwp9BVM

Ну что "Золотая печенька" готова и осталось выбрать того, кто активнее других участвовал в проектах, которые я анонсировал в этом году

Вот ресурс где можно измерить свою скорость печати и точность. У меня получилось, что скорость печати на английском 50-55 WPM, это около 250-260 символов в минуту, а точность в районе 88 процентов. https://monkeytype.com/

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

Настоящие спецы 10-пальцевой печати могут выдавать по 500 символов в минуту. Правда, особой разницы в работе я не замечал. Те кто печатают быстро, не успевают делать кратно больше, чем те, кто печатает со средней скоростью. Куда сильнее играет умение организовывать свою работу. А скорость печати - это очень странная метрика.

В рамках расширения кругозора попробовал связку vim + tmux + ssh. Tmux позволяет легко сделать attach к удалённой сессии и работает в режиме совместного редактирования. Поэтому когда по ssh подключаешься к удалённой машине, то легко можешь подключиться к запущенной сессии tmux. Получается очень простое легковесное решение для совместной работы.
В таком режиме использовать vim в качестве ide - оправдано. Правда, чтобы настроить, а потом ещё и привыкнуть к vim нужно иметь сильную мотивацию.
Я очень люблю консоль, часто использую vim для редактирования конфигов, но все равно не могу приловчиться писать код в vim-е.
Хотя опыт и интересный, но на уровне ощущений дискомфортно.

При этом для примеров в видео vim подходит идеально - нет ничего лишнего и работает очень шустро

Сейчас очень много разговоров про лопнувший айти пузырь. Мне кажется, что проблемы в мировом айти пока ещё нельзя считать полноценным кризисом, но если так продолжится, то кризис доткомов 2.0 мы увидим в ближайшие несколько лет.
И тут интересная ситуация с АйТи в России, потому что по факту находясь под большим давлением сейчас, у нас уже принимаются антикризисные меры и тем самым возможности нашего локального рынка найма будет сохраняться примерно в текущих реалиях.

Для оптимизации вычислений на больших объемах данных чаще всего используется один из трех вариантов: потоки, SIMD-инструкции для ASM и GPU (обычно через CUDA). Многие считают, что эти возможности оптимально можно использовать только на низком уровне. На самом деле работы по преобразованию кода, написанного на высоком уровне, в низкоуровневый код стараются вынести на специальные компиляторы. Примером такого компилятора для Python является Numbda - это OpenSource JIT компилятор написанный для NumPy. Он позволяет значительно повысить скорость работы с NumPy массивами.
Если интересуетесь обработкой данный на питоне, то посмотрите официальный сайт проекта, там куча примеров использования - https://numba.pydata.org/

Иногда ребята не из айти выдают офигенные перлы, один из последних "ты что не знал, что opensource ушёл из России?".
Всем спокойно, я попросил и opensource остался!

Итоги года и награда S0ER DEVS https://youtu.be/4nlX2y4m0Gc

На soer.pro выпустил 30-ый архитектурный стрим это третья часть из четырех по "Чистой архитектуре". Речь шла о бизнес-правилах и их влиянии на модель архитектуры.

Новый год широкой поступью идет по стране, кому-то уже стучится в дверь. В эти минуты хочу поздравить всех с новым 2023 годом и отметить людей, которые помогали кто советом, кто добрым делом или словом.
В первую очередь спасибо Дену (ака WestwindGaleaf) мы очень сдружились в этом году, огромное спасибо и персонально - С новым годом!!!.
Специальное спасибо Алексею ( канал Диджитализируй), Насте (miracl6), Максу (Pylounge) за поддержку и тоже С новым годом!!!
Так же хочу поздравить с новым годом Диму (seniorsoftwarevlogger), Антона Назарова с которыми весело потусили на стриме.
Всех ребят из ютуберс, особо Антона Павленко и Михаила Фленова - С новым годом вас, парни!
А так же всех с кем весело зажигали в Питере и Сочи - С новым годом!!!

И конечно же всех подписчиков и патронов, которых уже невозможно перечислить - с новым 2023 годом вас, друзья!!!