Просто похвастаюсь. Оценит тот, кому приходится часто управлять квотами в Селектеле вручную. У нас есть магический руби-скрипт (а настоящия магия возникает только в руби-скриптах, написанных только в виме, как мы все прекрасно знаем ), который умеет управлять квотами.

Стандартное флоу 1. Так, нам нужно еще 8 гигабайт оперативной памяти. Лезем в панель, оу, 26624 мегабайт уже есть, запускаем irb (или что у вас в роли калькулятора), вбиваем 26624 + 8*1024, ентер, копируем результат в окошечко. Повторяем для всех остальных параметров.

Стандартное флоу 2. Накручиваем квот от души, побольше-побольше, с запасом. Так как много дисков, памяти и ядер стоят дешево, если пользоваться ими не долго. После создания всех необходимых cерверов нажимаем кнопки "оптимизировать квоты", которая подгоняет все параметры под реально используемые.

Магическое флоу руби-волшеников, работающих в виме. Спец скрипт, которое через resell-api Селектела узнает сколько квот в каком регионе используется сейчас, парсит tf-файлы и выдирает значения, которые вам будут нужны после terraform apply, устанавливает большие:

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

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

Так вот, плохой, плохой Хашикорп дал вредный совет как подключать опенстек-диски. Вот он, пожалуйста, compute_instance_v2, раздел Boot From an Existing Volume, зловредная опция - delete_on_termination = true. Запомните ее. Если удалить сервера (которые на самом деле пустышки, которые можно спокойно сноcить и восстанавлить, главное прописывать IP жестко), созданные, как рекомендуется в документации c delete_on_termination = true, то диску будет тоже секир башка.

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

Питон как известно это почти, как руби, только сильно хуже, а емакс - это бледная тень вима. "Эээ, куда вы меня тащите и зачем бьете? Это же оценочное суждение!"

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

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

Итак:
руби - да, питон - нет,
вим - да, емакс - нет,
gnu screen - да, tmux - нет,
с++ - нет, java - нет (сорян, не хочу ни того, ни того ),
tsung - да, jmeter, танк - нет,
bash - да, zsh - нет.

Пока у меня нет четкой дифференциации инструмента под задачи, я пользуюсь тем, который выучил первым.

Очень не люблю слово "баг". Мне кажется, что там где баг, там и глюк, и где-то рядом "программисты - пид*расы". "Дефект" лишено негативного смысла в моем сознании. Если стол с дефектом - не обязательно это столяр ошибся, может грузчики уронили (у нас все работает, это админы не правильно окружение настроили). Баги - программисты плохо кодят, дефекты - это часть процессов, приоритеты, триаж и осмысленное управление.

"Хотелки" и "плюшки". Ыыыы. Не перевариваю. По-моему это унижение всех. Если бизнес вместо требований, подкрепленных знанием рынка, метриками, опытом и интуицией выдает "хотелки", то пусть делают их "компьютерщики", они стоят друг друга.

А вот написание по-русски и адаптация терминов ухо мне не режет, просто стараюсь приспособится кому как нравится. Ну сиквел - так сиквел, а эскюель - значит эскюель. Даже википедия говорит, что неважно как. Все равно как 15 лет назад я проносил лен-гэ-тэ-ха в голове, так и произношу, другого способа правильно написать length я не знаю.

Да пребудет с вами раби.

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

Эту силу я познал в CQG, где были очень сильные и формальные процессы, так как работа идет с большими деньгами. Если задача была чуть более сложная, чем совсем очевидная, она всегда была у простого разработчика одна. Максимум три. И когда задача всего одна, все равно нужно же как-то отчитываться, что по ней сделал. Даже если было непонятно ничего, то можно было как минимум пообщаться с постановщиком задачи, тимлидом, архитектором, человеком из матрицы компетенций, написать несколько писем и пару документов. И чудо, если сделать это даже в самой безнадежной и сложной проблеме, она сдвинется с места. И будет медленно двигаться.

Естественно обратная сторона любого формального процесса - это стоимость. Когда разработчик три недели пишет HLD - это довольно дорого, и компании стараются организовать дела так, чтобы можно было "чик, чик и в продакшен". Баланс между формализмом и процессной свободой зависит от многих факторов и мне кажется немножко является искусством. В продуктовой компании, конечно, формализма может быть меньше, если фича успешная - ТЗ и вроде как не нужно, а провальная - не поможет. В разработке на заказ начинает играть аджайл, спринты, постоянная визуализация результата.

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

По совету коллеги изучил СoncourseCI, CI нового поколения. Идея - просто бомба, пайплайны, которые собираются в модных yaml-файлах (кстати у ямл-файлов второе рождение, в рейлс они помню были очень давно, потом все захватил JSON и вот снова ямл, который на самом деле включает в себя JSON) и позволяют делать потенциально любые операции с вашими исходниками: релизить, версионировать, деплоить, выкладывать на S3 и все остальное, что может пригодится для CI/CD.

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

СoncourseCI, уверен, - будущее, и поиграть с ним точно стоит, освежает мышление. С внедрением спешить не будут, подожду более простую реализацию или попробую еще раз попозднее.

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

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

Такие мягкие правила невозможно нарушить, поэтому мы 100%-процессная команда. А степень мягкости можно уже варьировать по обстоятельствам. Живой продакшен - вообще не надо ломать, а внутренние поддерживаются по принципу "что упало у студента, то упало на газетку".

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

Есть фраза, что "информация самое ценное, что есть" или как-то так. Мне кажется по-крайней мере в разработке это уже не совсем так. Информации сейчас очень много, самой разной. И часто более ценно - уметь с этой информацией работать и своевременно использовать. Я как вспомню, как мало было книг по C++ 10 лет назад, не было StackOverflow, ужас. Сейчас конечно с информацией полный порядок.

Недавно понял, что мы живем не только в постинформационном обществе, но и в постпрограммистическом. Сейчас на самом деле совершенно не важно, какой софт или архитектуру использовать прямо сейчас (ну-ка, что круче Scala, Ruby, Go или Elixir? Давайте решим прямо сейчас ), важна способность к изменениям.

Единственный параметр, который меня тревожит больше всего, это некий коэффициент готовности меняться. Я не знаю как выразить его явно, это вопрос ощущений, но он включает в себя и величину легаси, и вопросы CI/CD, количество и возраст компонент, гибкость команды - фактическую и психологическую, скорость разворачивания приложений, степерь централизации управления, готовность к масштабированию и многое другое.

В постпрограммистическом обществе важно, не то где ты находишься сейчас, а как умеешь передвигаться.

Одна из проблем терраформа, как я писал, заключается в том, что вы работаете с тремя сущностями:

• tf-скрипты — это то, что вы хотите видеть;
• файл состояния — это то, как выглядит инфраструктура по мнению Terraform;
• реальное состояние дел — как на самом деле выглядит инфраструктура.

Как небесной механике задача трех тел в аналитическом виде не решается, так и терраформ со своими тремя сущностями оставляет повод для беспокойства, а что если кто-то ручками заведет сервер или dns-запись? Не со злобы, а просто так вышло. Этот сервер или эта запись не попадет в состояния терраформа. Раздражает.

Чтобы вернуть себе полное чувство контроля над инфра, я ввел в систему четвертую сущность - написал специальный руби-скрипт (99% проблем в жизни решается специальным руби-скриптом кстати ), который запускаю ручками время от времени. Этот скрипт скачивает все DNS-записи, полную структуру опенстека (сети, диски, сервера) и сравнивает результат с файлами состояния. Если различий нет, то значит, каждый объект управляется терраформом и соответственно лежит в красивом виде в репозитарии as a code. Это очень приятно осознавать.

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

Так вот, в рейлс many-to-many в принципе принято делать через доп-таблицу. Но если вы отважный хакер, без стыда и совести, то можно сделать так:

create_table "products" do |t|
  t.integer  "owner_ids",    default: [], array: true
end

В модели:

def owners
  @owners ||= User.where(id: owner_ids).to_a
end

Во вьюхе формы:

= bootstrap_form_for(@user) do |f|
  = f.select :owner_ids, User.all, {}, {class: "select2", multiple: true}

Честно скажу, я не вижу ничего особо криминального так делать даже в серьезном продакшене (если джойны не нужны и таблицы маленькие). Но у меня уже большая деформация, так как рейлс-фич уже давно не писал, а разобраться могу, если жизнь заставит, практически в любом коде. В вопросах стиля себе уже не доверяю. Но написать такой many-to-many в режиме хакантона имхо проще классического (у нас давно работает в одной утилитке). Прокатит это или нет - 50 на 50.