По предложению сотрудников Селектела написал гостевой пост про терраформ. Уф, непросто это было, не помню когда в последний раз что-то подобное по объему писал. Потратил около 15-20 часов и еще время, которые потратили сотрудники на правку и вычитку. Спасибо Андрею Емельянову, за помощь в оформлении статьи как по целостности и стилю, так и по грамотности.

Терраформ, как вы уже заметили, сейчас мой фаворит, но как и с любым другим инструментом 5% времени нужно потратить на его изучение и 95% - на внедрение в повседневные процессы компании. У нас, я считаю, мы уже внедрили, даже провели внутреннюю мини-конферецию по использованию. Есть еще серия хитростей, как можно облегчить использование, которые я не успел раскрыть в статье, буду потихоньку рассказывать.

Пришло время говорить о самой важной вещи - личной продуктивности. Как и у любого уважаемого блоггера у меня есть свои секретики (кручусь-с как говорится ). Что изучал:

• GTD, Архангельский

Обе книги - классика. Интересно, занимательного, но очень сложно. Честно говоря я вроде и не рискнул хоть что-то попробовать. Очень, очень сложно. А, есть еще жесткая жесть - система Любищева.

• Тайм-менеджмент для системных администраторов

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

• Pomodoro Technique Illustrated

Честно купил электронную книгу и прочитал. Сама система никак не прижилась, хотя регулярные перерывы я, конечно, стараюсь делать. Запомнил оттуда бинарный тудулист. Это тудулист в котором одна задача (или ноль). Вспоминаю эту идею в минуты когда не знаю, что делать прямо сейчас.

• Максим Дорофеев - Доводить дела до конца

Честно говоря все видосы я не досмотрел до конца, хотя хотел , но мне очень понравился докладчик и три принципа (формулировки, списки, регулярные обзоры) я использую. Действительно удобно держать список крупных задач, но не разбивать их на 100 мелких сразу же, а отколоть одну задачку, потому вторую и так потихоньку двигаться.

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

Но вообще эффективно получается работать, когда нравится то, что делаешь, и неэффективно когда не нравится.

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

Чемпион по удобству засовывания - это конечно SCSS. Обожаю его. Досточно завернуть все вот это, что накопилось в какое-нибудь body.legacy5 { ... }, проставить нужный класс в лайауте или вьюхах и начать новую жизнь даже с теми же стилями.

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

И напоследок в Рейлс - очень удобно организовывать неймспейсы. Практически любой код можно аккуратно засунуть в какое-нибудь Legacy2:: и потихоньку вытеснять из проекта. Я когда-то давно даже писал пост, какая магия Рейлс создает неймспейс Foo::Bar::, если файл лежит например в app/components/foo/bar/some_file.rb.

Как известно йобибайт - это 2**80 по версии МЭК. Зебибайт, Пебибайт, Тебибайт - все это есть, в википедии написано (или более точная версия в лурке).

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

Так вот, вообще есть хинт (кто-то мне рассказал), что маленькое b - это биты, а большое B - байты. Поэтому MiB или MB - это мегабайты, а Mb, извините, уже мегабиты. А мега- или меби- уже без разницы, никогда не сталкивался с ситуацией, где бы это было важно.

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

Сейчас постараюсь пояснить, как мыслю. Представьте, что мы на оси времени находимся в точке А. Единственная объективная реальность - это тот код, который сейчас находится на продакшене (этим кстати мне нравится гитхаб-флоу, мастер - всегда в продакшене, в ветках - что хочешь то и делаешь, дело личное, точка опасности - мерж пул реквеста в мастер). Так вот в точке А, глядя на наш продакшен, мы видим проблемы кода и всегда примерно понимаем как выглядит точка B, в которой сегодняшний функционал был бы "идеально" выражен в коде.

Я уверен, что большая ошибка начинать движение в точку B (в принципе это и есть рефакторинг - изменение кодовой базой без изменения функционала). Время то движется вперед и вы оказываетесь в точке C с устаревшим кодом ("идеальным" кодом на момент A). В процессе движения выяснится, что точка B - тоже не совсем хороша. В голове - идея была хорошая, а в реализации оказалось не очень. Тогда начинаете движение в точку B', потом в B'' и так далее. Поэтому переписывание продакшен кода в моей системе ценности - в большинстве случаев ошибка, это работа на прошлое.

Что я предлагаю вместо этого. Допустим мы продолжим пилить новые фичи как сегодня. То наш код шатко-валко, вместе с нами, доползет до точки C. И для этого горемыки, так же будет "идеальный" код - точка D. Естественно это не точка (как и впрочем все остальные точки - не точки), это облачко возможных хороших реализаций той системы, которая будет в момент C. Так вот я твердо уверен, что нужно менять не сегодняшний работающий код, а менять привычки, которые приведут проект в более здоровую точку D.

У меня есть такая аналогия. Допустим человек решил привести себя в форму. Можно поступить хирургически, радикально. Быстро - но много побочных эффектов, жесткий отходняк. Либо человек меняет привычки: разбирается с режимом дня, правильно питается, регулярно занимается в зале. То есть по факту он ведет себя уже, прямо сейчас, как здоровый человек, но сегодняшнее состояние пока не очень.

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

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

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

psql $db -c'SELECT pg_terminate_backend(pid) FROM pg_stat_activity
            WHERE pid <> pg_backend_pid();'
dropdb $db

Вроде работает хорошо.

Когда-то давно я настраивал винду и линукс под себя, ставил нескучные обои и делал кучу тонких настроек под себя. А потом, в какой-то момент стал наоборот любить максимально стандартные настройки. Более того где-то раз в год я переставляю OS с нуля и проверяю какими вредными привычками или лишним софтом оброс за это время. Во время облаков, смузи и тотального джаваскрипта так можно делать. Документы у меня в гугл драйв, фотошоп не нужен (да и то вроде сейчас легко по подписке ставится), настройки вима - на гитхабе, а больше ничего и не надо для счастья.

Кроме того я написал скриптец, который накатывает необходимые файлы и ключи. Текст его не буду приводить, это просто портянка на баше (не на руби, так как в момент запуска на свежей машине, руби может еще и не быть). Он берёт шифрованный архив с дропбокса и раскадывает все возможные .bash_profile, .gitconfig, vpn-ключи и прочее. Шифрование сделал по типу ансибловловского vault.key, чтобы магия сработало рядом со скриптом синхронизации нужно положить файл с ключом.

Благодаря привычке работать на стандартной конфигурации я совершенно спокойно перехожу с рабочего компьютера на домашний и обратно (главное не забывать часто комититься, чтобы файлы не зависли между небом и землей), могу работать в убунту, как живой, так и в виртуалке. На телефоне я стараюсь привыкать только к тем приложениям, которые есть и на iOS, и на андроиде.

Вообщем борюсь с вендор локом на бытовом уровне. А сколько времени вам понадобится, чтобы продолжить работу на чистом компьютере (с хорошим интернетом мне - меньше часа)?

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

Зато не люблю нравоучения и обобщения, как от других, так и от себя, поэтому большая просьба относится к моим словам именно как историям и мыслям, за жирными скобками именно моего конкретного опыта. Как я могу разбираться в разработке в целом? Или как надо что-то делать и как не надо? (или кто любой другой?) Я за 12 лет работал всего в трех компаниях. А даже если бы в двадцати? Любое мнение - субъективное (и это не ругательство, так как означает, что и означает - мнение выраженное субъектом, в мире есть всего пару объективных вещей, там типа законов Ньютона и прочего, да и то).

Так вот, еще я не люблю "так положено" или "авторитет так говорит", проверяю все на свой вкус, самые крепкие знания получаются. Вот откуда я знаю по тысяча и одно падение продакшена? Гхм. Знаю, ронял . И миграции под нагрузкой, и правку кода ручками на продакшене, и настройка iptables на удаленном сервере, много попробовал за хипстерскую юность компании и много где отхватил. Так, что могу сказать, гуру не врут (а где-то кстати и врут, мир меняется, принципы тоже, надо проверять). И опять, что одним хорошо, другим может не подойти. Везде контекст, везде конкретика.

Ансибл мне очень нравится (особенно по сравнению с ручной настройкой FreeBSD, как пришлось делать 10 лет назад для запуска первого рейлс приложения), но пару вещей сделало бы ансибл еще лучше, если бы это было возможно технически.

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

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

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

С нетерпением жду будущего.

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

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

Мда. Вот такие вещи меня смущали тогда.