Какие выводы можно сделать из моей истории про настройку нового ноутбука?

- Крупный производитель ноутбуков MSI на официальном сайте не следит за поддержанием актуальной версии драйверов. Возможно, никто не тестирует новые девайсы на совместимость.

- Крупный хардварный производитель Intel не очень то заботится о конечных клиентах и драйвера поставляет как удобно им. И ухудшает пользовательский опыт пакуя драйвера в exe файлы, которые очень завязаны на windows.

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

- После взятия в руки условно обычного windows ноутбука попадаешь лет на 15 назад. Оно пластиковое, с непонятным экраном, из него дует горячий воздух, оно гудит. Разница по деньгам между эпловым компьютером типа Air и MSI примерно ноль. Разница в дизайне — бесконечность.

Да, на виндовом компе можно играть. Согласен.

Наконец завершил обучение по коучинговой программе на русском языке.

Учился Just for fun. Чтобы познакомиться с новыми областями применения коучинга.

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

Коучинг полезен как в работе с клиентом, так и с коллегами.

Ближайшие пару дней собираюсь посвятить изучению Telegram Mini App.

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

Организационной работы больше, чем программистской.

Это можно пошарить друзьям. Это просто мем.

Копайлот! Что ты делаешь! Прекрати! Я просто перепутал раскладку клавиатуры!

Ловлю момент. 😅

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

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

Так-с. Учеба окончена. Диплом оформили. Надо это дело отметить. 🎉 Отличник учебы, между прочим. Мелочь, а приятно.

Storybook, Capistrano и зоопарк прочих сопутствующих решений (Часть 1)

У фронтендщиков, есть такой инструмент — Storybook. Он позволяет изолированно показывать UI элементы, разрабатывать и делать документацию.

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

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

А еще во многих проектах хранят Docker и Docker Compose файлы, чтобы быстро и весело запускать среду разработки на основе докера.

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

Капистрано (часть 1)

Есть такой хороший подход — программист пишет код, а системный администратор настраевает сервер и занимается деплоем приложения.

Сис админ, или DevOps — это не важно. Есть целая профессия, которая занимается разверткой серверов, поддержанием их рабочего состояния. Подготовкой к деплою, и доставкой кода на продакшн сервера.

У этих условных сисадминов есть свои инструменты. Терраформы, Кубернетисы, Баш скрипты, Ансиблы и Паппеты. Эти люди способны обеспечить работу и Go и PHP и Ruby и Java проектов. Они красавчики!

Повторюсь! У них свой набор инструментов. Традиций, подходов и прочего.

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

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

Капистрано (часть 2)

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

Так просто кто-то придумал. Так написали в документации и все стали бездумно делать.

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

Конфиги капистраны хранились в проекте и раздували его. Да, обычно не сильно. Но все равно не приятно.

Посмотрев на эту дичь, и немного подумав, я сделал простой и очевидный вывод — Инструмент деплоя не имеет никакого отношения к проекту и находится в проекте не должен.

Так еще 15 лет назад, а то и больше, я выкидывал из проектов код деплоилки в отдельный каталог и репозиторий и жить становилось веселее всем.

1) Решения не смешивались
2) Читать код и поддерживать отдельный инструмент деплоя намного проще, когда тебе не мешают файлы основного проекта, которые находятся где-то рядом и хрен его знает где и как и что найти.
3) Команда разработчиков могла ничего не знать о капистране, и тонкостях деплоя. А им обычно и не надо об этом знать. Обычно разрабы в это нос совать не должны.
4) Я избавил окружение разработки и зависимости от лишнего мусора. Меньше кода — быстрее загрузка.

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

Storybook, Capistrano и зоопарк прочих сопутствующих решений (Часть 2)

На примере капистраны я хотел вам продемонстрировать, что логика одного человека (меня) — вообще не совпадает с логикой экосистемы и сообщества.

Мои доводы очень простые

1) Капистрано — инструмент деплоя. Проект, команда разработчиков ничего не должны знать о том, как его деплоят. А значит — капистрано из проекта — вон!
2) Сложившиеся традиции — всего лишь устоявшиеся практики — вы сами можете формировать свои предпочтения и практики. Главное, чтобы в этом была видимая вам логика, упрощение, и (желательно) документация, которая объясняет ход ваших мыслей и подходов.

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

Кандидаты на выброс из проектов

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

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

Что бы такого можно выкинуть?

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

Так, Илья, ты что-то упоролся. Может еще и тесты предложишь вынести во вне?

Нет, а вот тесты их запускалки точно выностить из основного проекта не надо — тесты это неотьемлемая часть технологического процесса. Тесты это не опциональные элементы; Выделяя и отрывая из основного проекта опциональные и логически автономные фрагменты главное не перестараться.