Я уже забыл, что ноутбуки могут так сильно греться.
С другой стороны, я для игр их не использовал лет 15. Как раз с покупки моего самого первого ноута ASUS на котором мы с женой играли в Героев 3
А по ночам я залипал в DeadSpace. Ух страшно тогда было, капец. Помню, я в наушниках, а жена ночью подошла спросить не налить ли мне чаю. Дотронулась до плеча и чуть не потеряла меня. Нельзя же так пугать, когда ты идешь по помещениям планетарного потрошителя Ишимуры.
Меньше народу (файлов и зависимостей) — больше кислороду (лучше фокус, навигация, поддержка).
Уже давольно давно я активно разгружаю основной код проектов от всего того хлама, который разработчики напихивают внутрь и потом в корне проекта у них 250 файлов c настройками, 100500 зависимостей, которые используются только по праздникам, и тд и тп.
Что бы такого можно выкинуть?
— Код деплой-инструментов. Ну, этого точно в проекте держать не надо. — Докер файлы, скрипты инициализации и прочее для запуска окружения для разработки. — это все можно легко вынести в отдельный репозиторий и организовать удобную и простую в поддержке запускалку проектов любой сложности. — Любые дополнительные инструменты разработки, дебага, отладки — типа сторибука.
Так, Илья, ты что-то упоролся. Может еще и тесты предложишь вынести во вне?
Нет, а вот тесты их запускалки точно выностить из основного проекта не надо — тесты это неотьемлемая часть технологического процесса. Тесты это не опциональные элементы; Выделяя и отрывая из основного проекта опциональные и логически автономные фрагменты главное не перестараться.
Storybook, Capistrano и зоопарк прочих сопутствующих решений (Часть 2)
На примере капистраны я хотел вам продемонстрировать, что логика одного человека (меня) — вообще не совпадает с логикой экосистемы и сообщества.
Мои доводы очень простые
1) Капистрано — инструмент деплоя. Проект, команда разработчиков ничего не должны знать о том, как его деплоят. А значит — капистрано из проекта — вон! 2) Сложившиеся традиции — всего лишь устоявшиеся практики — вы сами можете формировать свои предпочтения и практики. Главное, чтобы в этом была видимая вам логика, упрощение, и (желательно) документация, которая объясняет ход ваших мыслей и подходов.
А дальше — больше. Если мы встали с вами на эту скользкую дорожку выкидывания из проекта всего ненужного барахла. Так может подумаем, чтобы там такого его выкинуть в отдельный репозиторий.
Главное преступление, на мой взгляд, которое сделали авторы капистраны — научили руби экосистему хранить код деплоилки в каталоге рельсового проекта.
Так просто кто-то придумал. Так написали в документации и все стали бездумно делать.
Капистрано как зависимость стала идти с кодом проектов. Поверх капистраны еще шли не менее уродливые плагины на капистрану под разные случаи деплоя. Все они были написаны в формате капистрановского DSL (я уже упоминал, что он явно не красивый и не удобный).
Конфиги капистраны хранились в проекте и раздували его. Да, обычно не сильно. Но все равно не приятно.
Посмотрев на эту дичь, и немного подумав, я сделал простой и очевидный вывод — Инструмент деплоя не имеет никакого отношения к проекту и находится в проекте не должен.
Так еще 15 лет назад, а то и больше, я выкидывал из проектов код деплоилки в отдельный каталог и репозиторий и жить становилось веселее всем.
1) Решения не смешивались 2) Читать код и поддерживать отдельный инструмент деплоя намного проще, когда тебе не мешают файлы основного проекта, которые находятся где-то рядом и хрен его знает где и как и что найти. 3) Команда разработчиков могла ничего не знать о капистране, и тонкостях деплоя. А им обычно и не надо об этом знать. Обычно разрабы в это нос совать не должны. 4) Я избавил окружение разработки и зависимости от лишнего мусора. Меньше кода — быстрее загрузка.
В общем одни плюсы со всех сторон. Да и при переключении на другую деплоилку не надо заботится о том, чтобы почтистить проект от капистраны. Ведь ее в проекте нет.
Есть такой хороший подход — программист пишет код, а системный администратор настраевает сервер и занимается деплоем приложения.
Сис админ, или DevOps — это не важно. Есть целая профессия, которая занимается разверткой серверов, поддержанием их рабочего состояния. Подготовкой к деплою, и доставкой кода на продакшн сервера.
У этих условных сисадминов есть свои инструменты. Терраформы, Кубернетисы, Баш скрипты, Ансиблы и Паппеты. Эти люди способны обеспечить работу и Go и PHP и Ruby и Java проектов. Они красавчики!
Повторюсь! У них свой набор инструментов. Традиций, подходов и прочего.
Но рубисты на заре своей экосистемы родили милого себе уродца и назвали его Капистрано. Капистрано занимается деплоем рельсовых приложений на сервера. Делает это примитивно. Делает это в формате своего уродвливого DSL, который явно не получился.
Никто из профессиональных девопсов никогда не работал с этой поделкой. Никому она не была интересной. Это очень нишевый инструмент деплоя.
Storybook, Capistrano и зоопарк прочих сопутствующих решений (Часть 1)
У фронтендщиков, есть такой инструмент — Storybook. Он позволяет изолированно показывать UI элементы, разрабатывать и делать документацию.
Обычно во фронтовых проектах Storybook устанавливают и хранят в самом проекте. Тем самым раздувая список зависимостей для среды разработки, раздувая проект дополнительными папками, файлами и конфигами. Да, может и не так много, но добавляется.
У руби и рельсовых разработчиков есть такой инструмент деплоя — Capistrano. По старой (идиотской, но уже сложившейся традиции) капистрано, тоже как и сторибук устанавливают и хранят в самом проекте.
А еще во многих проектах хранят Docker и Docker Compose файлы, чтобы быстро и весело запускать среду разработки на основе докера.
Это всего несколько примеров того, как инструменты разработки переплетаются с кодом самого проекта, и превращают корень проекта или конфигурационные файлы в адовое переплетение конфигов, настроек, параметров и переменных окружения.
Какой-то гениальный чувак, с помощью небольшой команды единомышленников сделал проект, чтобы на винде, за 3 команды в консоли, с помощью докера запускать Ruby on Rails приложения. Да еще и с кучей предустановленного типичного софта.
Идеальная заготовка для стартапов. Не зря проект набрал 500+ звезд на гитхабе.
Я попробовал запустить проект под виндой на новом компьютере и все получилось! Фантастика!
Особенно приятно, что проект делал я с помощью некоторых участников этого чата.
Спасибо ребята! Даже спустя год - проект работает! Отличный результат!
Последние пару лет я оставляю ноутбук дома, принимаю для себя тяжелое и очень эмоциональное решение, что, наверное, если я неделю пробуду без работы, то никто не умрет и мир не рухнет, если я не не сделаю ни одного пуша в репозиторий, не проведу ни одного интервью, консультации или коучинговой сессии.
Уже несколько таких экспериментов показывают, что и правда ничего не случается. А если и случается, то это только к лучшему. 😄
Вечер провел на берегу Босфора с моим бывшим коллегой Тимофеем Качаловым.
Тимофей просто бог Тайпскрипта. Автор популярного проекта Обфускатор. С 13.500+ звезд на гитхабе😻
Пример того, как один человек может сделать проект конкурирующий по популярности с проектами, которые разрабатываются большими командами и корпорациями.
Я всегда старался искать проекты, где работают лучшие специалисты индустрии и учиться у лучших. Тимофей один из тех на кого приятно ровняться и наблюдать за его работой. Рад, что удалось поработать с ним в одной команде и мы по прежнему поддерживаем связь, хотя и живем в разных точках планеты.
Ближайшие пару дней собираюсь посвятить изучению Telegram Mini App.
В целом ничего сложного, но, чтобы запустить комфортный процесс разработки понадобится согласовать работу нескольких частей системы. Поставить нужный софт, спроектировать передачу параметров от элменту к элементу. Подумать о том, как комфортно дебажить и смотреть за состоянием системы и в целом и в каждом отдельном элементе.
Организационной работы больше, чем программистской.
Наконец завершил обучение по коучинговой программе на русском языке.
Учился Just for fun. Чтобы познакомиться с новыми областями применения коучинга.
Наверное, на первый взгляд, коучинг это не самое обычное направление для ИТ-шника. Но за последние несколько лет коучинг, как подход, принес мне довольно прилично денег.
Коучинг полезен как в работе с клиентом, так и с коллегами.