Миграции и новое партнерство (часть 1)

1) В Ruby on Rails есть так называемые миграции. Файлы такие с определенным функционалом. В проекте в котором я сейчас работаю за 12 лет накопилось их очень много. Я решил разгрести этот бардак.

Первая идея смертельно простая — сгруппировать миграции по каталогам по годам. Делается это 3-я строчками Bash скрипта. Вместо 1000 файлов получается 12 каталогов в которые эти файлы просто переносятся. Ничего по сути не меняется и не ломается.

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

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

Миграции и новое партнерство (часть 2)

2) В очередной раз я сломал людям мозги и таки заставил их придерживаться системного подхода в их работе. А что делать. Не я такой — ну кто-то же должен ласково объяснить чего и как хочет заказчик.

В итоге нашел 2 художников-кандидатов с которыми есть шанс продуктивно поработать над небольшим проектом.

Созрела идея сделать из них команду и попробовать запустить совместную деятельность.

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

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

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

В общем попробуем

TDD как стиль работы

И вот вчера мне прилетает задача. Надо модифицировать существующий функционал в приложении.

Функционал скрыт в сервис-классе.

Сервис класс элементарно протестирован. Хотя может и хорошо протестирован. Я пока не погрузился. Но тесты работают.

Первое что я делаю — начинаю менять код сервисного класса. Прогоняю тесты постоянно. Упрощаю код. Делю его на меньшие блоки, на методы;

При этом ничего не ломается — я точно знаю, что код как работал, так и работает. Тестами же покрыт!

Из приложения этот сервисный класс вызвать не реально — надо слишком много процессов эмулировать руками. Тесты — единственный шанс менять сервис и не потратить при этом неделю на воспроизведение кейсов.

параллельно согласую с коллегой мой стиль кода и подход к упрощению — коллега хвалит — получается хорошо; Это важно — тестировать не только код но и подход.

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

Докер

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

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

Приходилось либо ситуативно лечить и смиряться, что теперь система черт знает в каком состоянии, либо начинать все заново. И тратить тонну времени.

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

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

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

Что думаете?

Докер на Apple ARM

По моим ощущениям эту проблему не решило 90% разработчиков в мире, кто с ней сталкивался.

Докер собирает под каждую систему (архитектуру) свой образ. Например i386 и arm64 или amd64. Это влияет на скорость работы итоговой сборки.

Иногда случается фигня. Все собрано под arm64, а находится какая-то нужная и важная утилита, которая рассчитана только на i386. И все. Трындец.

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

В Debian можно сделать так dpkg --add-architecture i386 && apt-get update Это подскажет операционке источники программ для нужной архитектуры.

Потом apt-file search FILE_NAME поможет найти нужный файл в библиотеках. Их можно будет поставить с постфиксом :i386

Если разложить нужные файлы по нужным местам — в итоге нужная утилита заработает.

Да чтоб тебя! 2024 год. А все какая-то дичь в этом мире программирования.

Что то на фруктово-витаминном

Докеризация крупного проекта

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

На рабочих машинах еще никому не удавалось запустить это все и сразу. Разработчики часть проекта запускают локально со связью с dev серверами. Иногда части запускают по отдельности.

Чувствительная точка — это приложение единого логина.

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

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

Я нашел вариант близкий к хорошему.

Запускать все проекты в единой сети. И использовать настройку extra_hosts. Как оказалось она умеет автоматически расширять /etc/hosts внутри контейнеров. Я не проверял еще, но кажется к контейнерам можно будет обращаться по именованным адресам, а не по IP; В голове сложилось

Докеризация крупного проекта (2)

Общий ход решения задачи.

1. Нарисовать все отдельные проекты на листке и раздать им фиксированные IP адреса. Для наглядности.

2. Поместить в единую сеть. Найти как в докере задать сеть с такими параметрами.

3. Настроить приложения, чтобы они умели обрабатывать запросы, которые идут к ним через именованные адреса (типа vasya1.dev)

4. Настроить в docker compose там где надо extra_hosts. Прописать там нужные именованные адреса и связать их с нужными приложениями внутри сети.

5. Да, блин. Придется прописать руками нужные адреса в хозяйском /etc/hosts. Эту хрень кажется не автоматизируешь.

Что получится.

App 1 дает запрос на App 2 в браузере. Резолвится все через хозяйский /etc/hosts. App 2 дает ответ App 1 и App 1 уже подает закрытый запрос на App 2.

Тут уже работает сетевой уровень в докере, хотя все участники те же. Тут уже сработают /etc/hosts контейнеров, которые мы настроили через extra_hosts.

Ну и там оно начнет само плясать. План надежный. Как швейцарские часы.