Истерика по поводу Vim (холиварненько)

Всегда испытывал иррациональное уважение к людям кодирующим только в Vim. Какая потрясающая самодостаточность, думал я. Но за последние 6 месяцев накопилось примеров от 4 совершенно разных разработчиков, которые подчеркнуто используют только Vim.

Самые типичные ошибки мэтров консоли, которые не совершают IDE-шники:

• не используемые импорты
• переменные, которые никогда не используются
• ошибочные изменения в следствии замены поиском
• очепятки (орфография)
• дублирование функций / классов
• pep8

Если вы ведете более одной кодовой базы с разными командами разработчиков, используйте IDE! Вообще, по любому другому поводу лучше используйте PyCharm для python.

Спорные моменты PEP8

Наверное больше всего споров в pep8 вызывает история с максимальной длинной строки. 79 символов - маловато для современного редактора и монитора. Альтернативный довод про структурированные мысли и читаемость, которая автоматически повышается у людей пытающихся ограничить строку 79 символами, лично я считаю не необходимым условием. Достаточным, возможно.
По статистике пакета для проверки pep8 следующее по популярности не соблюдаемое правило -  количество пустых строк (н-р определение класса или первое определение в модуле).
Исключения кодов E301, E302 и E501 встречаются в большинстве виденных мной выступлений на конференциях, в которых упоминался пакет для проверки pep8.

А какие моменты pep8 вы считаете устаревшими / надуманными / не нужными?

Jenkins скушал логами все свободное место на диске?

На VPS'ке (Digital Ocean для Continuous Integration! Gitlab + Jenkins [tutorial]) появилась проблема: за несколько часов ночью jenkins зафлудил логами все свободное место на диске. Решается добалвением в файл /etc/default/jenkins агрумента "-Dhudson.DNSMultiCast.disabled=true" в переменную JAVA_ARGS.

В моей файле JAVA_ARGS стал выглядеть так:

JAVA_ARGS="-Djava.awt.headless=true -Dhudson.DNSMultiCast.disabled=true"

Digital Ocean для Continuous Integration! Gitlab + Jenkins [tutorial].

В седые времена на настройку команды разработчиков уходило много времени и сил. Мало было просто поселить в голову отдельного разработчика идеи о TDD и его пользе. Ещё нужны были администраторы с руками растущими из правильных мест (ну это те, у которых кофта заправлена в джинсы и на лице густая борода), и нужно они были не один разок, а постоянно. Сейчас все иначе. Имея базовые знания можно, развернуть весь continuous integration (CI) не открываясь от смузи.

Итак, нам потребуется: $10 в месяц на оплату собственного VPS (на нем же можно хостить MVP вашего стартапа, и еще много всякого - например VPN-шлюз для маскировки под американскую компанию), 2 опсосных проекта и некоторое количество свободного времени.

Gitlab - это такой открытый Github у вас на сервере. Можно конечно обойтись Bitbucket'ом с закрытой группой (team), но это во первых не круто =), а во-вторых, стартап должен параноидально охранять свою супер новую уникальную социальную сеть "Водноклассников Мир".

Jenkins - инструмент непрерывной интеграции, написанный на Java. Есть много разных альтернатив, но вот что нужно запомнить про них про все (субъективно):

• если инструмент имеет продвинутый функционал - он написан на java
• если инструмент написан не на java, скорее всего из коробки он умеет очень мало, а настройка всего дополнительного - боль
• настройка любых метрик в любой CI - это тоже боль
• каждая команда имеет свой совершенно уникальный процесс разработки, нет двух одинаковых CI-процессов
• каждая команда стремится создать свой уникальный deploy-процесс, но автоматизировать нужно только то, в чем админы реально не принимают никакого участия (читай: и не несут никакой ответственности). Выкладка новой версии внутренней python-библиотеки в закрытый репозиторий компании - хороший пример такой работы
• и самое главное: невозможно один раз настроить CI и никогда больше к нему не возвращаться. Поддержание работоспособности CI - это отдельная настоящая работа, которой тоже нужно заниматься. Постоянно. Правда, всё потраченное время и силы вернутся сторицей.

Digital Ocean (DO) - очень модный продавец VPS'ок, который держит нос исключительно "по ветру". Цены у них может быть и не самые низкие, но: API, хранение и дистрибуция слепков, куча дата-центров по всему миру, и настройка в один клик - безусловно доставляют.

Теперь о том, как все это соединить без напрягов.

1. Создаем сервер с GitLab на борту при помощи one-click-install

Не вижу никакого смысла повторять или переводить туториал написанный DO: How To Use the GitLab One-Click Install Image to Manage Git Repositories.
DO не рекомендует устанавливать Gitlab на дроплет за 5 долларов - слишком уж мало там памяти. $10 - будет вполне достаточно. Но если очень хочется сэкономить, можно просто увеличить swap - для машинки с такими утилитарными задачами LA не критичен, как по мне. При заходе на one-click install с регистрации вам не дадут использовать $5 дроплет для gitlab, но если зарегистрироваться и уже из кабинета начать создавать дроплет (точно так, как описано в tutorial выше), то такого ограничения нет.

2. Устанавливаем Jenkins.

Для этого случая, что не удивительно, у Digital Ocean Community тоже уже есть tutorial: https://www.digitalocean.com/community/tutorials/how-to-install-and-use-jenkins-on-ubuntu-12-04. От версии ubuntu в этом руководстве вообще ничего не зависит, так что смело используйте и для 14ой убунту. Заходите на VPS по ssh и далее все как в tutorial.

По умолчанию Jenkins попытается использовать порт 8080, который уже занял gitlab. Нужно в файле /etc/default/jenkins заменить этот порт на какой-нибудь другой. Например, 9090.

Далее, наверняка захочется настроить для jenkins какое-нибудь приятное доменное имя, например ci.v-odnoklassnikov-moi-mir.ru. Для этого нам вполне хватит nginx, который установился вместе с gitlab. Его настройки лежат в каталоге /var/opt/gitlab/nginx/conf/.

Создадим файл /var/opt/gitlab/nginx/conf/jenkins.conf с содержимым из туториала jenkins: Jenkins behind an NGinX reverse proxy. Обратите внимание, что в нашем случае proxy_pass смотрит на "http://localhost:9090/;".

Только что написанный конфиг нужно "подцепить" в nginx GitLab'а. Данный процесс описан тут. Суть статьи по ссылке: нужно в файле /etc/gitlab/gitlab.rb, добавить строку:

nginx['custom_nginx_config'] = "include /var/opt/gitlab/nginx/conf/jenkins.conf;"

Не уверен, что файл  /var/opt/gitlab/nginx/conf/jenkins.conf не похерится во время обновления gitlab. Будем посмотреть...

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

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

P. S. В комментах к посту помимо "<все не так>" и "<я тоже умный>" прошу написать: что еще по теме поста интересно лично тебе, мой дорогой подписчик?

P. P. S. Лучшей благодарностью будет зарегистрироваться в Digital Ocean по моей реферальной ссылке https://www.digitalocean.com/?refcode=e16041a7fe90. Вам не сложно, а мне приятно.

Django-jenkins и COVERAGE_EXCLUDES_FOLDERS

Возился минут 10 пытаясь подобрать правильный способ прописать каталоги исключенные из coverage отчета для jenkins, залез в код и выяснил, что правильно определять полный путь до каталога, а не как в обсуждении на stackoverflow. Пора бы уже привыкнуть лезть в код раньше, чем на стэк =).
Вот кусок конфига для django + django-jenkins с покрытием:

import os


BASE_DIR = os.path.dirname(os.path.dirname(__file__))

# ...

PROJECT_APPS = ('myapp', )

JENKINS_TASKS = (
    'django_jenkins.tasks.run_pylint',
    'django_jenkins.tasks.run_pep8',
    'django_jenkins.tasks.run_pyflakes',
)

COVERAGE_EXCLUDES_FOLDERS = [
    os.path.join(BASE_DIR, 'myapp', 'tests')
]

Запускаются такие тесты так:

python manage.py jenkins --enable-coverage

Moscow Django MeetUp

Не мало воды утекло с тех пор, как я посещал последний раз это мероприятие. С удовольствием констатирую, что качество докладов сильно выросло: Moscow Django MeetUp № 26.

Интересный способ привлечь внимание пользователей bitbucket

Сегодня ночью мне пришло письмо от bitbucket, о том что не знакомый мне человек дает мне грант на запись в репозиторий. В названии репозитория доменное имя, по которому замещен интернет-магазин.
Грант, очевидно, был отозван сразу. Мне естественно, стало интересно посмотреть что там на сайте. Тему этого сайта для себя считаю закрытой, но какая-то более специализированная история, могла бы меня заинтересовать. Например, так можно раскручивать сервис непрерывной интеграции или аутсорс тестирования.
Для того что бы выдать грант пользователю достаточно знать его ФИ или username. Такие данные не сложно получить с помощью API bitbucket'а http://restbrowser.bitbucket.org/.