Timur Batyrshin's blog

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

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

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

Исправления и указания на опечатки и ошибки, впрочем, приветствуются — для этого выделите ошибку и нажмите Ctrl-Enter.

Примерный список моих нынешних профессиональных знаний и умений можно посмотреть в профиле LinkedIn.

Связаться со мной можно написав письмо там же, либо написав на erthad@gmail.com.

Сейчас смотрел видеоматериалы курса об обучении с Coursera.

В первом модуле там говорится о существовании двух режимов мозга: focused mode и diffuse mode. Focused mode — режим в котором мы концентрируемся на какой-то задаче не отвлекаясь на посторонние раздражители. В diffuse mode мы, напротив, ни на чем не концентрируемся, расслабляя ум, и в этом режиме происходит другой характер работы над предметом.

В видеоролике, который я сегодня посмотрел, Барбара брала интервью у редактора журнала и известной (в Америке) писательницы по совместительству. Очень интересный момент, который я услышал — в режиме “focused mode” она редактирует тексты, а в режиме “diffuse mode” — пишет. Попытки заниматься деятельностью, не подходящей к режиму ни к чему хорошему не приводило — в focused mode она писала с очень большим трудом, а в diffuse mode очевидно ты пропустишь кучу стилистических, орфографических и прочих ошибок.

К чему я все это? Похожую аналогию можно провести с программированием. Нам нужно быстрая генерация идей, при этом для нас важно, чтобы они оказались рабочими — мы не можем сначала написать десять страниц кода, а потом проверить насколько они рабочие. В этом нам помогают наши любимые unit-тесты. Они работают быстро, их можно запускать часто, даже постоянно (есть даже, например, программа под названием guard для этого). Это позволяет нам творить не задумываясь над деталями реализации, и оно еще при этом будет работать. После того как наколбасили класс-другой можно посмотреть порефакторить, если кажется, что это нужно, либо закоммитить как есть. Более всего, наверное, это подходит к ruby, который идеально подходит для режима “пиши что думаешь”.

Как считаете, наблюдается ли такое?

Как мы знаем, если мы в Chef используем какой-то произвольный атрибут node.foobar, и если у нас он в этот момент неопределен мы получаем exception.

Это можно обойти несколькими способами:

• Конструкция вида node.attribute?('foobar') ? node.foobar : 'some_default' или она же завернутая в хелпер-функцию. Это по очевидным причинам довольно неудобно.
• Просто задаем умолчания (nil) в файле атрибутов для всех атрибутов, которые мы используем за исключением тех, на которых нам обязательно нужно падать. Вариант хороший, у нас всегда есть документация по всем используемым атрибутам, но он начинает работать со скрипом, когда мы дергаем атрибут из другого кукбука, который у нас в ранлисте может встречаться, а может и не встречаться. Переопределять родительский атрибут в своих атрибутах нельзя, т.к. получим неопределенное поведение, приходиться вручную заводить какие-то умолчания для нод или окружений.
• Для всех таких случаев используем конструкцию (( node.foobar rescue 'some_default' )). Именно так, с двойными скобками, иначе мы не сможем ее передавать параметром внутри определения ресурса.

1
2
3
4
5

template "/tmp/myfile" do
  source (node.template rescue "template.erb")   # так не пропустит синтаксис ruby
  mode    node.mode     rescue "0644"            # так сработает неправильно (см. ниже)
  owner ((node.owner    rescue "root"))      # <-- так правильно
end

Второй вариант кажется нормальным, но он будет выполняться как (some_other_parameter node.foobar) rescue "xi-xi", что очевидно делает совсем не то, что нам надо — значение по-умолчанию не передается внутрь LWRP в случае exception, как мы здесь ожидаем.

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

Еще есть хороший вариант, предлагаемый Evil Martians — заворачивать в LWRP все что можно, но с этим вариантом проблема такая же как со многими хорошими паттернами программирования: если ты сразу его не применил, придется в какой-то момент останавливаться и делать глобальный рефактор всего.

В интернетах существует великое множество статей на тему “что такое devops”, приводятся разнообразные версии, как-то:

• общение/сотрудничество/интеграция
• культура/автоматизация/измерение/обмен

и прочие подобные вариации и это все действительно вдохновляет.

Тут же рядом движутся движения ChatOps и MonitoringLove (ex-MonitoringSucks), ворох технологических решений (управление конфигурацией, виртуализация, контейнеризация, и еще вагон и маленькая тележка) и технологических практик (унификация dev/prod окружений, immutable servers, continuos delivery/deployment).

Часто приводят параллели с Agile, и довольно часто пытаются (чаще всего на LinkedIn и, по-моему, не очень успешно) как-то стыковать его с ITIL.

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

Для devops это будет “управление общей технологической основой организационных процессов”.

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

ITIL делает это за счет их формализации, документирования.
Agile делает это за счет того, что принуждает людей больше общаться, обмениваться информацией, делиться опытом.
Devops создает технологическое пространство, в котором организационные процессы происходят — задает контекст, создает (простой!) протокол и средства общения, которые одновременно являются документированием, логированием, средствами управления и разработки — технологической основой организационных процессов.

Сюда замечательно ложится все вышеперечисленное:

• “общение/сотрудничество/интеграция” — в общем, то же самое, но довольно поверхностно и крайне размыто, на грани понимания
• “культура/автоматизация/измерение/обмен” — то же самое, но в терминах более-менее понятных процессов
• управление конфигурацией — протокол работы с серверами, одновременно является документацией, а также основой для почти всего остального
• унификация dev/prod окружений и immutable servers — контекст технологического общения разработчиков, тестеров и админов
• виртуализация, контейнеризация — немного сбоку, но без них вряд ли возможно что-то из перечисленного
• continuos delivery/deployment — делаем наш процесс непрерывным, вовлекаем в него людей
• ChatOps — протокол, логирование, средство управления, коммуникация с командой
• MonitoringLove — то же самое, что у ChatOps, но практически однонаправленное (поэтому ChatOps во многом на нем основан)

Естественно, как и Agile с ITIL, Devops в частности — это каталог, набор практик, приемов, технологий, инструментов для осуществления задачи, которую он перед собой ставит. Каждая из его частей делает какой-то вклад, но не является обязательной. Вполне нормально применять один-два приема, или же применять все, что получается — вопрос лишь в том, что мы хотим получить и какой ценой.

Devops — это “управление общей технологической основой организационных процессов”, именно так.

Переименовал учетку github в более короткую. Теперь я timurb (был timurbatyrshin).

Если увидите, что где-то что-то отвалилось из-за этого, просьба сообщать.

Как я уже писал, после обновления Ubuntu до версии 14.04 в Google Chrome поломалось отображение китайского языка, причем, только в Chrome/Chromium — в Mozilla Firefox, как и в других местах системы, все отображалось нормально.

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

Обновление Ubuntu до версии 14.04 прошло на удивление без косяков — ничего из основных устройств и приложений не отвалилось. Мелкие косяки все же есть — отвалился принтер Samsung ML-2010 и поддержка китайского языка в Chrome.

Принтер системой определялся, но не печатал. Наконец-то нашел пару часов и установил драйвера для принтера. Делается это примерно так:

Качаем и распаковываем универсальный драйвер принтера: http://downloadcenter.samsung.com/content/DR/200902/20090225163328453/UnifiedLinuxDriver.tar.gz

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

Берем нужный PPD из cdroot/Linux/noarch/at_opt/share/ppd и подсовываем его принтеру, который у нас Ubuntu нашла сама. Он требует фильтр /usr/lib/cups/filter/rastertosamsungspl. Кладем его из этого же архива к себе в систему.

Чтобы не искать их потом еще раз, я положил их сюда:

• ML-2010spl2.ppd
• rastertosamsungspl

Периодически сталкиваюсь с задачей: как сравнить две версии вида X1.Y1.Z1 на шелле. Очень часто это делают при помощи разнообразных врапперов.

Настроил Zapier для трансляции блога в твиттер. Эта запись будет проверкой связи.

Как всем известно, последние несколько лет очень популярно слово “Devops”. Про это пишут большое количество статей, кто-то говорит про культуру, кто-то про задачи бизнеса, кто-то про автоматизацию, сравнивают с Agile, но ясности это не прибавляет. Внесу и я свои пять копеек на этот счет.