Makefile: Заменяем документацию командами

Когда-то много лет назад, я задолбался писать длинные и составные команды, которые были нужны в разных проектах. Особенно актуальной эта проблема стала с появлением Docker и Docker Compose. Некоторые связки для запуска, апдейта и изменений, требовали прямо таки серьезных многострочников. Типа такого:

 docker run -it --rm \
  -v $(CURDIR):/runner/project \
  quay.io/ansible/ansible-runner ansible-vault edit

Выходов из этой ситуации было несколько, например, скидывать их куда-то в доку типа README.md и копировать оттуда. Частично мы так и делали, но оно все время устаревает и просто задалбывает.

Часть команд можно запихнуть во встроенный инструментарий языков, к ним относятся rake tasks, npm scripts и так далее. И это даже хорошо работает, но только до тех пор пока команды простые и скорее относятся к инструментам на этом же языке. Если ваша задача запустить подряд пяток команд Docker Compose, то большинство этих инструментов будут неудобными. Да это пытаются решить тем что создают универсальные запускалки, но ни одна из них не стала по настоящему популярной сквозь разные экосистемы. Почти все эти инструменты носят локальный характер для какого-то языка или конкретного стека.

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

Другой подход это алиасы в bash/zsh/fish. Но мне эта идея никогда не нравилась, потому что алиасы глобальны, а большая часть команд локальна для какого-то проекта. Несмотря на это алиасы все же заняли свое место в этой системе, но не рукопашные, а те что идут в коробке из ohmyzsh. Далеко не все знают, но это по сути ключевая фича этого инструмента. Вы только посмотрите, что он позволяет делать с гитом https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/git (а там есть комбо для всех популярных консольных утилит).

Ну и наконец, самый, как оказалось удобный подход. У нас есть старый добрый Make, который либо стоит уже сразу, либо крайне просто ставится в систему. У него есть команды, зависимости и возможность писать консольные команды напрямую (для большинства ситуаций). Еще году в 2015 я полностью перевел все свои проекты на Makefile, которые не просто решили проблему написания и запуска команд, но и создали некий универсальный язык, заменяющий доку. В любом моем проекте открыв Makefile можно понять все, что нужно для работы с проектом: make setup, make test, make lint, make run все эти команды универсальны независимо от стека.

include make-app.mk
include make-compose-app.mk
include make-compose.mk
include k8s/Makefile

project-setup: ansible-generate-env compose-setup

ansible-generate-env:
 docker run --rm -e RUNNER_PLAYBOOK=ansible/development.yml \
  -v $(CURDIR)/ansible/development:/runner/inventory \
  -v $(CURDIR):/runner/project \
  quay.io/ansible/ansible-runner

Прикольно то, что со временем это стали видеть многие и даже популярные проекты стали внедрять Makefile. Я помню был пост Андрея Ситника, где он рассказывал, как перевел команды для своей либы с npm scripts на Makefile и был удивлен как все упростилось.

В общем рекомендую. Мое видео на тему: https://www.youtube.com/watch?v=pK9mF5aK05Q

Ссылки: Телеграм | Youtube | VK

А нука ребята, кто сразу наметанным взглядом скажет какую типовую orm проблему мы тут наблюдаем?

Ruby, Ruby, Ruby. В этом выпуске мы поговорили с Владимиром Дементьевым, ведущим разработчиком в компании "Злые Марсиане", контрибьютором в Ruby и Ruby on Rails.
В подкасте обсудили:
- Современное состояние языка Ruby, его развитие и применение в больших проектах
- Подходы к созданию устойчивой архитектуры приложений на Ruby и опыт использования языка в open-source проектах
- Эволюцию фреймворка Ruby on Rails, включая новые возможности, такие как асинхронная обработка
- Личный опыт Владимира в разработке таких проектов, как AnyCable, и его вклад в создание инструментария для разработчиков

https://www.youtube.com/watch?v=fBJGj6sd9AQ (первый раз запустили видео как премьеру, можно там прямо в процессе обсуждать)

VK: https://vk.com/orgprog Подкасты: https://podcast.ru/1734325321

Что такое CodeBasics

Я планирую серию постов, про архитектуру нашего открытого проекта https://code-basics.com/ru, о котором сейчас немного расскажу. Где-то в 2015 году, задумал я сделать проект в стиле CodeAcademy как дополнение к Хекслету. То есть это простые курсы по основам языков с тренажером в браузере. Ключевые фишки проекта:

- Исходный код проекта открыт и выложен на гитхабе
- Курсы создаются не только нами, но и сообществом там же на Гитхабе
- Все бесплатно без исключений

Целей было несколько. Например на тот момент, рекомендовать кому-то платные курсы было зашкваром (сразу считалось рекламой), поэтому программисты тупо стеснялись говорить про Хекслет даже если хотели. Этот проект открывал такую возможность всем без риска, что тебя заклюют. И еще я оглядывался на не безызвестный сайт learn.javascript.ru, мне хотелось добиться похожей популярности по ряду языков, чтобы например когда речь шла про то где учить php, все не задумываясь отвечали, конечно на кодбейзиксе (я все еще мечтаю об этом!).

Большую часть курсов я написал на бейзиксе сам, но часть была написана ребятами из нашего сообщества. И это очень круто, потому что это позволило появиться на сайте курсам по лиспам и элексиру. Самая интересная история была, когда один парень нам нафигачил курс по python, а потом мы взяли его на работу (привет Леша!). На гитхабе проекта созданы репы под все языки, так что если вам интересно, то велкам, можно просто прийти и начать коммитить.

У проекта есть несколько интересных вещей с архитектурной точки зрения, о которых хочется рассказать. Например то, как мы переложили работу с контентом на гитхаб, решив множество задач без кодинга (права, версионирование итп). Про то как устроена база данных, так чтобы иметь версионирование уроков и не ломать людям все сразу при обновлении курсов. Про то как мы его написали на phoenix/elixir, а потом переписали на rails. В общем там реально много интересных концепций. А прямо сейчас я его еще переписываю на инерацию, так что будет что рассказать про фронтендовые примочки в новой реальности.

Короче не проект, а сказка. А на днях мы вышли с ним https://productradar.ru/ это типа нашего продуктханта. Эту неделю идет голосование за лучший проект и мы там вчера вышли на первое место с 104 голосами. Но прямо в спину нам дышит другой проект, который видимо тоже пытается поднажать. В общем, вы знаете что надо делать :)

В этом выпуске мы с Дмитрием Коваленко, опытным разработчиком и контрибьютором таких проектов, как Material-UI, Cypress и FFmpeg. Затронули тему низкоуровневого программирования, обсудили работу с ассемблером и оптимизацию производительности на уровне процессора.
Эпизод получился насыщенным: мы подробно обсудили технологии, архитектуру и программирование на уровне железа.

Альтернативные площадки: ВК Видео | Подкаст

https://youtu.be/BsNgohFW6rM

Про менеджеры версий

Когда надо сменить версию языка под проект, то для этого обычно используют либо докер, либо менеджеры версий. Под каждый язык есть как минимум один такой, а то и пачка: nvm, gvm, rvm, rbenv и так далее. Десятки их. В общем задолбаешься если постоянно надо между языками переключаться. Поэтому кто-то догадался написать универсальный менеджер.

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

Начать можно отсюда: https://asdf-vm.com/guide/getting-started.html

// Вариант установки для brew

// Ставим asdf и зависимости
brew install asdf

// Ставим плагин для ноды
asdf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git
// И его зависимости
brew install gpg gawk

// Устанавливаем последнюю версию nodejs и делаем ее доступной глобально
asdf global nodejs latest

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

p.s. А какой менеджер версий используете вы?

Ссылки: Телеграм | Youtube | VK

В этом выпуске мы снова встретились с Дмитрием Коваленко, чтобы разобраться, почему Rust заслужил столько внимания в сообществе разработчиков. Получился содержательный и насыщенный разговор, полезный и начинающим, и опытным специалистам.
Присоединяйтесь, чтобы узнать, чем Rust может усилить ваш tech stack и как писать надёжный, эффективный код!

https://www.youtube.com/watch?v=bKyxOaP-mDg

Альтернативные площадки ВК Видео | Аудио

Идеальное решение

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

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

Может быть и так, но если исходить сразу из ограничений, то мы никогда не придем туда, куда надо идти, с точки зрения смыслов, что может нас сильно замедлить и ослабить по отношению к конкурентам. Вместо выставления границ, лучше поступить по другому. Сначала мы можем представить, что нет никаких ограничений и мы можем сделать все что хотим моментально. Каким бы тогда выглядело наше решение? Идеальное решение. Что в него входит:

* Система выполняет функцию с минимальным количеством ресурсов
* Противоречия устраняются максимально элегантно

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

Как пример, у нас есть задача создать систему управления баннерами на сайте. Формулировка задачи на первом этапе производится на примере лучших известных решений на рынке с учетом наших хотелок. Затем на эту систему начинают накладываться ограничения реальной системы и ресурсов.

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

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

Ссылки: Телеграм | Youtube | VK

У меня пропал сон

Где-то лет в 35 со мной что-то случилось. Я стал просыпаться в 6 независимо от того во сколько я уснул. Что самое страшное у меня пропала способность “доспать” если я не выспался. Вообще никаких шансов, проснулся - вставай, потому что иначе будешь тупо лежать, но не уснешь. Всегда раньше удивлялся бабушкам и дедушкам, которые так в 4 вставали. А теперь сам такой стал. У вас есть такой эффект?

В сегодняшнем выпуске мы поговорили с Юрием Жлобой — разработчиком из Wargaming. Почему Erlang стал революцией для телеком-индустрии, а Elixir сделал функциональное программирование удобным для бизнеса? Этот выпуск — глубокий разбор технологий, которые обеспечивают стабильность и масштабируемость в самых требовательных системах.

Альтернативные ссылки ВК Видео | Аудио

https://www.youtube.com/watch?v=lpmZJ2xnsaE

Собеседования: Истории и раздражающие практики

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

Ссылки: Телеграм | Youtube | VK

Написал мощную статью на хабр про то как на самом деле надо собеседовать разработчиков. Вложил туда так сказать весь опыт с 2009 года, когда я начал впервые собеседовать и с тех пор провел более 1000 собесов! https://habr.com/ru/articles/879902/ не забудьте поделиться с друзьями ;)

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

Альтернативные площадки ВК Видео | Аудио
https://www.youtube.com/watch?v=Lbq_NwIKUrI

slim => inertiajs + react + vite в code-basics

Саммари по переезду с серверной шаблонизации на slim в code-basics на инерацию с реактом. Если кто пропустил напомню, концепция инерации в том, что она соединяет бек и фронт в классическом стиле для бекенд фреймворков. В экшенах контроллера передаются данные во вьюху, а вместо обычной серверной вьюхи, используется какой-либо фронтенд фреймворк, в моем случае реакт. Инерция концептуально работает как nest.js, но в качестве бека может выступать любой бекенд фреймворк для которого есть адаптер. Ключевые моменты:

* Используется серверный роутинг
* На фронтенде нет стора. Данные идут в пропсы
* По причине описанной выше, нет никакого API

Для меня это уже второе приложение в таком стиле. Сначала была приемка документов для колледжа, в разработке которой я участвовал три месяца. Теперь вот code-basics. В отдаленной перспективе, я планирую переводить на эту схему сам Хекслет.

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

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

Либа для ресурсов (DTO), как и полагается в современном мире, умеет генерировать типы для TS, что очень помогает не дублировать и не описывать все ручками.

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

Рельса предоставляет много удобных механизмов для серверных шаблонов, например офигенные формы, которые умеют работать с моделями. Это автоматизирует кучу вещей, от правильной обработки ошибок, интеграцию с i18n и многое другое. В новой схеме все это пришлось заводить руками. Инерция поставляется с хуками для обработки форм, но им далеко до рельсовых интеграций, поэтому пришлось напилить файл с формами. Для хранения строк я взял i18next, но сделал хитро. Я не стал дублировать и переносить переводы из бека, а заюзал либу, которая автоматом собирает все в json для фронта. Поэтому сами тексты описываются как обычно, но “магически” оказываются на фронтенде.

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

А что по внешнему виду? Тут многие знают что я предпочитаю бутстрап, но честно говоря, у меня была попытка найти что-то такое же высокоуровневое. В итоге из более менее подходящего оказался только https://primereact.org/, который можно подстраивать под свои стили. Сейчас в проекте часть компонентов взята из react-bootstrap, часть из primereact, например автокомплит или грид в админке.

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

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

Ссылки: Телеграм | Youtube | VK

В сегодняшнем подкасте мы поговорили с Владимиром Ивановым, Senior Engineering менеджером в Bolt, о системном дизайне и его роли в создании крупных сервисов. В выпуске много живых кейсов и инсайтов из реальных проектов
https://youtu.be/5A7ncMHfB1g

ВК Видео | Подкаст
https://youtu.be/5A7ncMHfB1g

Выход из крысиных бегов

А что вас останавливает от старта своего бизнеса? Недостаток идей? Страхи? Что-то еще? Поделитесь плс в комментариях. Пора уже и про стартапы начинать движуху 🙂

Готов ли я рисковать?

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

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

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

Кто-то в комментариях написал, что закрываются 9 из 10 бизнесов. Ха, все еще интереснее. Конкретно каждый предприниматель вам скажет что он 10 лет пытался и закрыл 10 бизнесов перед тем как у него что-то получилось. Другой вопрос, что в историях успеха про это не особо упоминают. Еще писали что “деньги буду получать только через год”. Вот тоже не факт, что через год у вас будут какие-то деньги. Гарантий никаких вообще. Нормально я мотивировать умею да? 🙂

Ну и я на всякий спросил у ChatGPT: “степень риска на которую готов пойти человек в своей жизни в разных аспектах определяется его воспитанием или это врожденная штука?”. Он неплохо расписал, можете сами попробовать. Вывод там такой: “Склонность к риску – это не что-то одно, а сочетание генетики и воспитания. Но важный момент: человек может сознательно менять свою стратегию риска, обучаясь анализировать риски и управлять ими.”

Пока достаточно) Вот примерный план публикаций:

* Предпринимательское мышление (жилка).
* Чем вообще можно заниматься если у меня нет денег и я не секу в маркетинге.
* Как оценить идею и размер рынка.
* С чего надо начать: продукт, маркетинг, продажи. Какой такой customer development?
* AAARRR. CJM и Воронки
* Лидопад и сломанные процессы. Почему владелец бизнеса обречен.
* Как работает маркетинг. Обзор всех направлений. Сквозная аналитика.

Что скажете? Не будете отписываться? 🙂

Ссылки: Телеграм | Youtube | VK

p.s. В твиттере прошлый пост то же бахнул сильно, там более 100 комментов: https://x.com/mokevnin/status/1891542982349758856