Организованное программирование | Кирилл Мокевнин

В профессиональную разработку я вкатился через PHP 4 версии, который не просто был динамическим языком программирования, он даже языком то мог назвать себя с натяжкой, формально да, но это был такой продвинутый шаблонизатор. Потом был php 5, который вобрал в себя ООП модель Java, что сделало программирование очень похожим по стилю и способу организации программ. На тот момент, да и десяток лет до этого, динамические языки полностью захватили веб. Началось все с Perl, потом PHP и наконец Ruby с Python. Даже сейчас подавляющее большинство сайтов реализовано на PHP. Дешевый хостинг, огромное количество CMS и конечно же фреймворков...

Сегодня неожиданный гость с неожиданной темой. У нас в студии снова Антон Назаров, но в этот раз с темой про дебаты. Меня лично всегда впечатляло как он разбирается с оппонентами аргументируя, где надо манипулируя или провоцируя. Поэтому и появилась идея такого выпуска. Надеюсь вам зайдет как и мне :) https://www...

? В индустрии циркулирует страх, что люди перестали обсуждать код на публичных площадках, stackoverflow почти умер, что будет дальше? Хорошая новость в том, что все это есть на reddit, но дело даже не в этом. Я сегодня наткнулся документ для llm, который описывает лучшие практики, паттерны и описание команд (по сути api) для работы с редисом redis.antirez.com И вдруг меня осенило. Кажется что станет не хуже, а станет только лучше. Куча разработчиков по всему миру бросились писать скилы и гайды для иишек, в которых собирают все накопленные индустриальные знания. Прямо сейчас идет бурный рост появления таких документов...

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

Все опытные бекендеры так или иначе знают, что sql-запросы в цикле это зло. Но даже если их явно не делать, то они все равно будут появляться при использовании ORM. Например мы извлекаем какую-то связь, а затем генерируем json по этому набору данных, попутно вызывая какие-то вложенные связи: user.companies().map((company) => company.creator()). В этом примере сами компании будут извлечены одним запросом, но обращение к creator() породит цепочку запросов, по запросу на каждую компанию. В миру эта штука называется select n + 1 Кто-то скажет что фу, orm зло, потому что там есть такая проблема. Я...

Выпуск подкаста про паттерны уже доступен для просмотра https://youtu.be/tuP54QyVQVY?si=GSnCXdQnl2TsEbFu Наслаждаемся :) Альтернативные ссылки: Аудио | vk

Регулярно стал видеть подобные вопросы. Если растет производительность, то логично, что надо сокращаться? Если речь идет про избыточную разработку и цель оставаться на том же уровне производительности, то да, избыточность можно уменьшить. Но реальность и капитализм работают чуть сложнее. Начнем с избыточности. Одно дело когда у вас команда из 50 человек, где есть и фронты и бекендеры и девопсы и бог знает кто еще. Другое, когда вся команда это три человека с очень разными компетенциями. Если в команде один бекендер, то его никем не заменить. Тоже самое касается и большинства остальных ролей. Всегда...

Есть такая софтина https://www.dittofeed.com/ которая нужна для crm-макретинга (email рассылок и т.п.) Таких решений довольно много и честно говоря стоят они немало. Поэтому попрыгав по разным сервисам, мы в конце концов пришли к тому, что ладно, пусть будет меньше функций, но зато open source, который можно поставить к себе если что. Дитофид как раз оказался таким решением. Не единственным, но помимо подходящей функциональности я обращаю внимание на технологии и перспективы. В данном случае там юзаюется как по мне очень неплохой сетап на ноде (ts + drizzle + fastify)...

В этот раз мы с гостем взяли стратап-идею и разложили ее по DDD через Event Storming https://www.youtube.com/watch?v=gyaDwoDvsWY Альтернативные ссылки: Аудио | vk

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

Работать только над фичами утомляет и в течение дня иногда хочется переключиться или просто голова не особо варит, а делать полезное хочется. Куда и как можно переключиться? Вот что работает в моем случае. Для начала, какие типы задач я выделяю (в моей практике): - UX/UI. Дизайн, удобство, отзывчивость и любые фронтовые правки - Обновление зависимостей (люблю я это дело) - Типизация. Добавление типов (нам в ruby актуально), оптимизация типов и т.п. - DX. Тут и скорость работы инструментов (сборка, тесты и т.п.) и CI и разворачивание проекта - Kubernetes. Сам по себе отдельно, как инфраструктурная единица - Инфраструктура...

Чем дальше, тем больше ии интегрируется в мой процесс разработки и уже появился какой-то набор паттернов, которыми я бы хотел поделиться. В этом посте поделюсь сетапом, а в будущих уже расскажу подробнее про эффективное использование 1. chatgpt всегда остается когда надо просто поговорить. Причем сейчас он может работать в агентском режиме, к нему можно подключить репозитории и всякое другое 2. Для работы над кодом codex и copilot в терминале отдельно от редактора. 3. В редакторе автокомплит + nes (next edit suggestion). Тут есть небольшое ограничение самого nvim, которое не позволяет делать многострочные nes, но это поправят буквально в следующей версии, которую я очень жду 4...