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

YouTube | RuTube | VK

Эх, вот так всегда:

1. Железячники говорят, путаешь наносекунды с микросекундами, неправильно называю развертку и делитель напряжения, гребенкой называю осцилограмму, и вообще все не то и все не так;
2. Сетьевики говорят, что я не помню на зубок 7-ми уровневую модель OSI, не помню структуру пакета IP, не различаю ACK от SYN и FIN, да и вообще все не так и все не то;
3. Системные разрабы говорят что я плохо дизассемблирую код, неверно называю инструкции, плохо знаю теорию компиляции, неправильно называю биты и байты, и вообще все не так и все не то;
4. Бэкендеры говорят, что я плохо знаю java и php, не умею пользоваться Maven  и композером, не шарю в фреймворках и вообще все не так и все не то;
5. Веб-программисты говорят, что я плохо знаю React, не умею в каррирование и монады, не помню наизусть http протокол, не пишу на WebAssembly да и в целом все не то и все не так;

А архитекторы вообще со мной не разговаривают...

Куда податься бедному Соеру? Чужой среди своих, чужой среди чужих...

На что вы долго смотрите, то вам и нравится или почему споры о том, что лучше бессмысленны.

Обычно люди уверены, что они выбирают лучшее на основе объективного сравнения всех конкурентов. На самом деле выбор сделан ещё до осознания потребности, а во многом даже возникновение "потребности" это не ваш выбор. Если интересно немного подорвать свои устои, то поищите в сети исследования на тему свободы выбора.

Для нас же важно то, что весь маркетинг построен на узнаваемости бренда, которая сводится к тупому повторению во всех утюгах, что бренд А хороший.

Как только понимаешь, что выбором каждого человека уже давно и успешно манипулируют, становится проще понимать людей.

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

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

Если кому-то нравится смотреть на зарплату, софтскилы, тусовки, и лидеров мнения, то во многом нам будет трудно понять другу друга.

Напишите в комментариях на что смотрите вы?

P.s. и да, если вам кажется, что где-то там лучше чёс здесь, то это скорее всего значит, что вы больше смотрите куда-то туда, а не сюда.

Приятно, когда сотрудники ведущих компаний приходят к тем же выводам, что и ты. У меня есть отличный стрим по тех. долгу (конспект вот тут), а полное видео только для подписчиков на платформе

У меня фокус на конкретном описании способа оценки тех. долга (бальный метод, экспертная оценка) в статье от Google можно прочитать почему такой подход и есть "самый правильный"

CORS замечательная идея и боль в продакшене

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

CORS - обозначает "совместное использование ресурсов из разных источников" (Cross-Origin Resource Sharing). Идея сама по себе очень классная, особенно в мире, где веб вытесняет все другие способы взаимодействия. Удобно, например, когда у тебя есть один общий сервис, который используется из множества одностраничных приложений, это позволяет сделать separation of concerns (разделение ответственности), упростить сопровождение системы, наращивая и разделяя мощности.

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

А третьи лица это знаю и внедряют всякие зловреды, которые в тихую делают XSS атаки, сливая все ценное и не очень злоумышленникам.

В итоге для борьбы с проблемой используется старый добрый дедовский способ - запреты. Например, в preflight запросах (которые, кстати, тоже появились из-за требований безопасности) можно запретить отдавать cookie, а на сами эти запросы наложить жесткую политику ограничений, которая позволит точно определить кому и что можно сливать.

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

#CORS

Monitoring as code

Последние тренды АйТи перевести описание всей инфраструктуры в "код". Под кодом понимается не обязательно программный код, часто это YAML или JSON файлы, которые можно формировать полуавтоматическими или полностью автоматическими методами.

Такие файлы удобно генерировать "на лету". Это, вместе с облачными технологиями и виртуализацией, позволяет генерировать инфраструктуру под любые задачи, при этом делать это быстро.

Создание инфраструктуры через код получило название "Infrustructure as code" (IaC). Скорость создания и запуска в работу новых узлов составляет от нескольких секунд до десятка минут. Инфраструктура может расти как грибы после дождя, главное успевать накидывать ресурсы.

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

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

Чтобы быстро вносить изменения в конфигурацию системы мониторинга одной автоматизации недостаточно, нужен способ аналогичный созданию инфраструктуры - накатывать изменения через "код". Поэтому разработчики активно внедряют возможности управления средствами мониторинга через "код", это называется "Monitoring as code".

В итоге конфигурирование мониторинга становится частью процесса развертывания новой инфраструктуры и средства мониторинга отслеживают изменения сразу после их внесения.

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

Вывод из всей этой истории следующий - Айти не помогает ошибаться меньше, вместо этого оно помогает ошибаться быстрее. Подходы "as code" как раз и служат для повышения скорости развертывания систем, но не повышению стабильности работы систем.

#IaC #Monitoring #code #мысли

Вчера на стриме спрашивали какой nvim конфиг я использую. Я использую nvchad у него есть стартовый конфиг который для typescript

Я уже кидал ссылку на этот сетап ранее, но продублировать нетрудно. )

Кто не успел посмотреть вчерашний стрим в реале, может посмотреть его в записи

Какой язык программирования учить

Мне кажется, что самый верный способ выбрать язык - это посмотреть на рейтинг языков от компании, которой доверяешь. Мне нравится команда RedMonk, которые регулярно выпускают свой рейтинг уже много лет.

Пятерка лидеров почти не меняется и выглядит так: JavaScript, Python, Java, PHP, C#

Сам рейтинг смотрите вот здесь

Для платных подписчиков на платформе вышла вторая часть стрим с разбором примера анемичной модели DDD.

- Для просмотра нужно иметь подписку "Stream", которая стоит 350р.

- Чтобы быстро найти последние стримы есть вкладка latest на главной странице https://platform.soer.pro/#!/pages/overview/latest

Хотел сходить на митап Сбера в Сочи, нашёл регистрацию, прочитал вот "это" (см. скрин) решил, что даже для меня это кринж. Вот так захочешь рассказать про Сберовские митапы, а тут тебе "коммерческая тайна".

Понятно, что они может какую типовую форму регистрации дёрнули, но, блин, это же просто митап!

Определенно Кандинский моя самая любимая генеративная сетка, вот пример для промпта "обложка для подкаста "программисты решают проблемы мироздания"

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

Внимание! Топик будет жестко модерироваться, так что только прикольные картинки.

Когнитивные измерения

Если отказаться от мысли, что программирование - ремесло, то расширять свой кругозор можно бесконечно. Одно из интереснейших направлений для изучения - это оценка качества кода. Здесь есть такая штука как "когнитивные измерения".

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

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

Исследовательское проектирование - это ситуация при которой разработчик понимает куда нужно двигаться для получения результата, но не может определить насколько долго нужно двигаться в этом направлении, чтобы получить требуемый результат. Т.е. классическая задача исследования - познать непознанное.

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

Обычно такой разработкой занимаются R&D подразделения, для них важно писать невязкий код, который хорошо декомпозирован и спроектирован. Когнитивные измерения в таком случае помогают сохранить темп и вектор развития кода.

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

Последние 10% задачи стоят первых 90% или проблема приближения к цели.

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

В случае с созданием новых фич работает примерно так же, позади уже 90% работы, есть небольшая усталость, но хочется доделать, сделав "рывок".

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

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

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

Закрывать фичу всегда на свежую голову, еще раз окинув взглядом сделанное.

И тогда все будет хорошо, без рывков и выгораний.

Стрима сегодня не будет. Неделя выдалась насыщенная, закрыл кучу задач и на последней немного надорвался. Хочу взять паузу и немного отдохнуть.

Заметил, что в пятницу мало активности и в кружочках. Видимо, не я один такой "уставший". Так что всех у кого была продуктивная неделя - "С пятницей!". Отдыхаем, восстанавливаем силы для новых свершений.

Что предпочтет настоящий соер в качестве отдыха? Конечно же лучший способ расслабиться и отдохнуть - это непринужденное чтиво перед сном. Очень хорошо подходят мануалы и спецификации.

Я, например, читаю спеку на EcmaScript - это очень расслабляет и гарантирует глубокий, спокойный сон.

Фрагментация времени

Я в последнее время постоянно пытаюсь придумать как дефрагментировать свое свободное время. Получается так, что у меня то тут, то там есть по 15-20 минут свободного времени, в течение дня это может быть пара часов, которые можно было бы использовать для чего-то осмысленного.

Меня постоянно успокаивают, что мол это нормально, ты не робот, используй эти минуты чтобы просто расслабиться и не о чем не думать. А мне вот наоборот хочется использовать это время с пользой для себя.

Чего скажите, утопия или все же планирование может помочь?

Сэкономленные деньги !== заработанные

Ради фана посчитали сколько денег потребуется компании на свободном рынке, чтобы построить продукт уровня Naris.

В качестве целевых показателей взяли:
- процесс разработки;
- архитектура;
- разработка и сопровождение.

Получилось, что на сегодняшний день Naris стоит примерно 20 млн. рублей.

Основная статья затрат - заработная плата. Если ты сам являешься человеком-оркестром, то можно сильно сэкономить.

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

В такие моменты остается лишь сожалеть, что нельзя сэкономленные деньги взять налом.

Внеочередной стрим https://youtube.com/live/Uf2s7kDWM38?feature=share