Про планирование и самоорганизацию

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

Про Ubuntu и клиническую смерь панголина

Про убунту

Убунта (хотя, пожалуй, это свойственно почти всем дистрибутивам) похожа на лоскутное одеяло, состоит из кучи софта, разрабатываемого разными людьми. Стандарты? ЛолШТО? Есть, конечно, FHS, но всем плевать. Без интернетов под рукой восстановить систему после нетривиального падения не реально. Куча файлов со своим уникальным именованием, куча ключиков и параметров.

Самый эпичный момент был при обновлении до 12.04: из-за проблем с оборудованием, Космонавты выпилили режим гибернации из-за проблем с некоторыми версиями материнок. Включается он эпичнейше: не переключателем (как сделали бы разумные люди), не раскомментированием строк в каком-нибудь конфиге (как сделали бы разумные, но ленивые люди), а воссозданием конфига. Когда я это прочитал, единственная мысль была: НО? КАК? БЛЯДЬ? Я должен был бы его воспроизвести без интернета???

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

Статистика владения кодом

Давно была идея визуализировать impact человека на продукт. Мощные визуализаторы типа codeswarm (активность и совместная работа) и gource (процесс работы) показывали не совсем то, что хотелось - текущее состояние. При помощи hg log -u username -p | grep "^+" | wc -l  можно посчитать добавления и удаления, но опять же в динамике не увидеть. Хотелось увидеть как росла доля пришедшего человека, насколько быстро она затухала с уходом и какое наследие осталось.

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

Полез курить Mercurial API, заодно накидал ссылок в вики-статью и скачал бесплатный PyCharm. На проект не тянет, поэтому сохранил в gist (derived work требует назначить лицензию GPL). Программа последовательно в каждой ревизии аннотирует текстовые файлы и считает, количество строк для каждого коммитера. Тестировал на маленьком репозитории, и не заметил нескольких улучшений. Пока работал на нашем основном - успел внести несколько правок.

Процесс запуска

1. Запускаем первый раз python participation.py - у нас появится шаблон конфига

2. Отключаем подсчет calculate=false и прописываем репозиторий repo=~/path/to/repo

3. Запускам еще раз и получаем на выходе пользователей

4. Прописываем им алиасы в разделе [Alias] - часто один пользователь попадает под разными именами, а мы не хотим портить статистику
5. Наконец включаем подсчет и запускаем
6. Ждем результат, открываем в Excel и рисуем график

Статистика

На серьезных репозиториях работает ОЧЕНЬ долго.
Проанализировано 164.564.370 строк в 1135 коммитах (только ветка default) за 8 часов на Atom N550, потребление памяти в пике 75мб, диск был SSD, но IO был неизмеримо мал.

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

Hgext.markdown for Windows

Python eggs

Main problem with this extension on Windows OS was external dependency Markdown and unlike on Ubuntu you cannot execute apt-get python-markdown in your shell. TortoiseHG has bundled python and you cannot simply add egg inside dist-packages. I look at source and find out, that original way for Windows user was uncomment and edit line sys.path.append("c:/python27/Lib/site-packages/markdown-2.2.0-py2.7.egg") but nothing was in documentation about it.

So I decide to rewrite this mechanism in fallback style: first we try to load markdown package and if failed, lookup using path from config (python can transparently lookup files in zip archives):
try:
    from markdown import Markdown 
except ImportError:
    dir = os.path.dirname(os.path.realpath(__file__))
    md = ui.config("web", "markdown.egg", "Markdown-2.3.1")
    ui.debug("Markdown not found search for egg in local dir %s for %s.zip\n" % (dir, md))
    sys.path.append(os.path.join(dir, "%s.zip\%s" % (md, md)))
    try:
        from markdown import Markdown
    except ImportError:
        ui.error("Unable to locate markdown in path %s" % sys.path)
global Markdown

this is final version corrected by Chris Eldredge. Now you can download markdown package and put it in extension folder.

Relative paths

Rendering comparison
BitBucket vs hgext.markdown

Second big improvement is relative paths in markdown files. We massively use crossreferences in the docs we store in our repository, and quickly find out some problems with relative links in which used parent (..) directory and hash (#). I fixed this and update demo page with picture and relative navigation. Unfortunately BitBucket incorrectly render this markdown because of the bug.

Preview

Also now you can navigate to preview of uncommited files with one click in menu. Not a big deal but usability improvement.

Summary

Chris already merged this patches to his repo. So if you want to see beautiful doc instead of raw markdown, even on Windows it is good time to install or update extension.

Как я патчил Jetty

Постановка задачи

Freeswitch умеет при помощи mod_curl забирать с определенного урла диалпланы и пользователей. Это очень чуствительная информация, поэтому очень захотелось ограничить доступ к служебным урлам только с localhost.

Дерзкая саламандра

trollface.jpg
Что, раскладка
не переключается?

Обновился на Saucy Salamander. С Maverick Meerkat это самый скучный релиз, обновилось 2000 пакетов, но абсолютно ничего нового. Обновили линзы, которые у меня отключены, интерфейс наутилуса, которому я предпочитаю mc.

Даже на LOR-е какой-то скучный забег без огонка, без задора. Уже какой день, а даже нет десяти страниц. Традиционно, уже который релиз подряд, ломают переключало раскладки. На космодроме выяснил, что можно забиндить переключение на ctrl+space.

Пока больше проблем не заметил. Итог: смысла обновляться нет, спокойно можно ждать Trusty Tahr LTS.

P.S. Interpid Ibex 08.10 -  был моим вторым релизом убунты. Так вот Ibex подвид Tahr, или наоборот, или вообще одно и то же. Короче, Шаттлворт мог бы быть чуточку по-оригинальнее.

Безысходность черного ящика

Давно уже ничего не писал, зато, наконец, собрался с силами и заслал пачку пуллреквестов, которые не давли мне покоя последние пол года. Как заапрувят - расскажу подробнее.

Виды систем

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

Markdown в репозитории и оформление веб-интерфейса Mercurial

В мае появилась задача подумать над хранением документации. Где мы только не пытались хранить документацию: и в Dropbox, и в Google Docs. Последнее, где мы остановились, это - Confluence. Совершенно наркоманская система редактирования, потребовалось ставить отдельный плагин, чтобы можно было редактировать чистый HTML. Главная проблема всех этих подходов - рассинхронизация. Документация не соответсвует коду. На втором месте - невозможность автоматической генерации документации в процессе сборки проекта. От системы документации не требуется многого: вставка изображений и кросс-ссылки - более чем достаточно. 

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

Mercurial + Markdown

Хотя README встречались и раньше, а wiki хранилась в репозитории еще на Google Code, но именно с приходом GitHub README.md стало обязательным требованием. Краткое описание проекта, в wiki-стайл разметке markdown. После знакомства с возможностями этой системы на github.io любые сомнения в возможностях разметки пропадают. Приятным бонусом является плагин для IntelliJ IDEA.

Очень хотелось получить это на локальном репозитории. Поиск вывел на относительно молодой проект (не первый раз ищу) hgext.markdown от Chris Eldredge. Плагин для mercurial, покрывающий требования к встроенной системе документации на 100%. Когда я его поставил, выснилось, что разметка применяется только к readme, плагин не умеет работать с кодировками (пришлось вспомнить эпичнейший доклад про кодировки), с картинками (необходимое требование), ну и несколько проблем шаблонами вообще и с разметкой в частности.

Pull request or GTFO

В общем все это я пофиксил и заслал Крису толстенный пуллреквест, пару дней назад он принял его. Линуксоиды могут спокойно качать плагин, виндузятники в пролёте, поскольку требуется библиотека а у mercurial встроенный python, и как подсунуть одно в другое, еще не разбирался. Как выкурю - зашлю еще один пуллреквест с инструкцией.

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

Темы для mercurial

В процессе ковыряния плагина набрел на встроенную систему шаблонов и тем для hgweb. Внутри крайне разухабистый движок, с доступом ко внутреннему API, позволяющий изобразить решительно всё. Заскриншотил каждую тему и добавил на страницу со списком, чтобы было понятно как каждая выглядит. Кстати, сам mercurial размазан по файловой системе: бинарники лежат в /usr/share/mercurial/templates, а основной код в /usr/lib/python2.7/dist-packages/mercurial.

Пять стандартных тем и Markdown, идущий в комплекте с плагином

Топологическая сортировка репозитория

Abstract

В систему контроля версий mercurial версии 2.6 [1] был добавлен новый алгоритм сортировки closesort в команду convert, позволяющий оптимизировать расположение коммитов, в которых закрываются ветки. В отличие от алгоритма datesort, который might well increase the size of the destination repo by 10-20 times [2], closesort незначительно меняет размер репозитория. Данный алгоритм может быть интересен для workflow в которых активно ведется работа с ветвями, причем все открытые ветви закрываются.

Rationale

Fig. 1 Визуальный мусор

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

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

Methods

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

Попытка 1

Поиск готовых или похожих решений натолкнул на обсуждение [3] проблемы оптимизации чрезвычайно больших репозиториев, вылившихся в итоге в расширение shrink-revlog [4]. Данное расширение как раз занималось топологической сортировкой и достаточно было написать собственную функцию сортировки к двум имеющимся. Алгоритм был написан, при этом потребовалось прокинуть внутрь функции сортировки объект репозитория.

Но первый же запуск на реальном репозитории привел к ошибке выхода за пределы массива. Выяснилось, что в репозитории используется два файла changelog и manifest [5]. В первом хранится информация о коммитах, а во втором информация о файлах [6], при этом, если в коммите не было изменений в файлах, то появится расхождение в нумерации между этими двумя файлами. Сортировка же changelog была запрещена, поскольку это повредит репозиторий.

Попытка 2

В качестве "Плана Б" можно было встроиться в стандартное расширение convert. В нем уже присутствовали branchsort, datesort и sourcesort. Необходимый алгоритм отличался от sourcesort одним условием:

        def makesourcesorter():
            """Source specific sort."""
            keyfn = lambda n: self.commitcache[n].sortkey
            def picknext(nodes):
                return sorted(nodes, key=keyfn)[0]
            return picknext

        def makeclosesorter():
            """Close order sort."""
            keyfn = lambda n: ('close' not in self.commitcache[n].extra,
                               self.commitcache[n].sortkey)
            def picknext(nodes):
                return sorted(nodes, key=keyfn)[0]
            return picknext 

И успешно решал поставленную задачу.

Pull request

Я сразу пошел в IRC разработчиков с целью обсудить данное решение, но особого интереса там не проявили и отправили в мейллист. После этого, Kevin предложил попробовать branchsort [7]. Данный алгоритм упорядочивал только самые простые случаи, но не справлялся со сложными. На IRC мне посоветовали засылать патч, раз никто не возразил. Патч был заслан и запушен Bryan [8]. В этот раз на всё-про-всё, от идеи до аппрува, ушел всего лишь месяц, а не пол года, как в прошлый раз [9].

Results

Максимальная ширина

На реальном рабочем репозитории с 5528 коммитов, максимальная ширина графа составляла 60 параллельных веток. После конвертации, ширина максимальная ширина репозитория уменьшилась до 26.

Средняя ширина

Подсчет средней ширины графа производился командой hg log -G | awk '/changeset/ {cnt++; width += (index($0,"changeset")-2)/2} END {print width / cnt}'. Данная подсчет не учитывает некоторых особых случаев, но подойдет для примерной оценки. До конвертации 21.16 и после 6.08.

Discussion

Алгоритм успешно, в разы сокращаяет ширину графа избавляя от визуального мусора. Из главных минусов можно указать то, что рассчет хэша у ревизии изменился между версиями 1.7 и 2.6, что приведет к несоответствию историй. Но, поскольку repository surgery можно проводить очень редко, это не является большой проблемой.

Нетерпеливый кольцехвост

Заобновился вчера на новую убунту. Для этого пришлось выкачать больше гига обновлений. Когда уже все скачалось, примерно на середине обновления, я забыл, что  обновляюсь и закрыл крышку. Пришлось восстанавливать установку через sudo dpkg --configure -a, потому что стандартное средство обновления ругалось, но никакого эффекта от нажатия кнопок не было. Вроде всё прошло гладко.

Версионирование схемы БД

1 часть. Ораклява

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

Freeswitch book

Итак, спустя почти 15 месяцев работы с FreeSWITCH у меня, наконец, дошли руки прочитать матчасть, чему я несказанно рад. Эта книга висела тяжким бременем на моей совести.

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

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

Как я мигрировал систему

На десктопе семерка стояла на IDE, причем рядом имелся SATA жесткий диск с достаточным количеством свободного места. Неудавшаяся миграция никак не давала мне покоя, и вооружившись жестким диском для бекапа всего нажитого, я таки решил осуществить этот процесс.

Linux magic

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

Yaml

Я таки смог убедить разработчиков, что сообщения об ошибках не информативны.

А вообще, создателям YAMLа посылаю лучи поноса, плюс, отдельных пожеланий гореть в аду заслуживают те, кто называет JSON подмножеством первого.

Педантичный ящер

Что-то как-то тухло. Из нового, пожалуй, только ядро 3.2. PPA для новых ядер не нашел (ведь в сурикате она точно была), а самому конпелировать ведро жутко лениво: видимо, таки придется обновиться.
https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview/Beta1#New_features_in_Precise 

The hardest piece of code I ever wrote

Наконец то можно рассказать кулстори, как я патчил mercurial.