Let me know if I missed anything.

And here is screencast of demo project deployment with help of Vagrant and Fabric.

I use git for my projects, and find it very convenient to let git to provide version info instead of hardcoding it into the source code. There are several possible ways to ask git for version information, including keyword expansion – and some of them are described in this stackoverflow post. For me, git describe works best, since it doesn’t modify sources on checkout (comparing to keyword expansion) and provides version information in format that could be used in other git commands such as git diff.

Sidenote: git describe

git describe returns information about state of working tree or any particular commit. There are several command line switches to consider, but in most cases “git describe –tags –always” will work just fine for everyone. The command finds the most recent tag that is reachable from a commit, and if the commit itself is pointed at by the tag, shows the tag. Otherwise, it suffixes the tag name with the number of additional commits and the abbreviated object name of the commit.

$ git describe --tags --always
v0.1.3-16-ge1b5922

Note on performance

Keep in mind that running git every time you need version information may not be the best idea. When source code changes are rare and performance is important (e.g. production website) it is wise to get information only once, then store it for later use. In other cases, when changes are often and performance is not critical, it may be ok to query git every time.

Example: including version information in Sphinx documentation

Sphinx is a tool that makes it easy to create intelligent and beautiful documentation, and it is often used in Python world. Project version information is stored in Sphinx configuration file and is embedded auto-generated project documentation. Since Sphinx itself is written in Python, getting version info is simple. First, add the following lines to your docs/conf.py:

from subprocess import Popen, PIPE

def get_version():
  """ Returns project version as string from 'git describe' command. """
  pipe = Popen('git describe --tags --always', stdout=PIPE, shell=True)
  version = pipe.stdout.read()

if version:
  return version
else:
  return 'X.Y'

Then, replace hardcoded version and release values:

# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
version = get_version().lstrip('v')
# The full version, including alpha/beta/rc tags.
release = version

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

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

• Откройте HKLM/Software/Microsoft/Windows NT/CurrentVersion/Console/TrueTypeFont. Вы увидите несколько значений, соответствующим Lucida и Consolas.
• Создайте новый String Value. Название должно состоять из нолей и быть на один символ длиннее предыдущего подобного названия. Так, в моем случае имя ключа – “000″.
• Значение ключа – название фонта. Вообще на фонты накладываются некоторые ограничения, подробнее о них вы можете прочесть в MS Knowledge Base.
• Reboot. Без этого шрифты не подхватятся.

Все. После перезагрузки новый фонт можно настроить в качестве фонта по умолчанию и ваша консоль станет удобнее.

Хорошая альтернатива танцам с бубном вокруг реестра – open-source проект Console2. Как пишут авторы:

Console is a Windows console window enhancement. Console features include: multiple tabs, text editor-like text selection, different background types, alpha and color-key transparency, configurable font, different window styles.

Console2 недавно поднялся до второй версии, и выглядит довольно-таки неплохо, с успехом заменяя стандартные средства.

По счастью, большая часть настроек хранится на *unix-системах в простых текстовых файлах и может быть легко скопирована на новый сервер. Однако, при росте количества серверов вы неизбежно сталкиваетесь с ограничениями такого подхода. Какую версию считать основной мастер-копией? Что, если в вашем парке несколько операционных систем и настройки разнятся от одной системы к другой? Что делать, наконец, если мастер-копию настроек возможно быстро скачать не на все сервера – скажем, она лежит на вашей основной рабочей машине в офисе компании за файрволлом?

Появление distributed version control systems, таких, как git и mercurial, вкупе с возможностью хостить свои персональные репозитории в облаках позволяет значительно уменьшить эти проблемы. Я воспользовался публичным хостингом на github, однако, если вы не хотите давать доступ к вашим настройкам – есть и другие варианты (например, unfuddle предлагает бесплатный приватный хостинг git и svn репо).

Последовательность действий

1. Зарегистрируйтесь на github.
2. Создайте новый персональный репо для ваших настроек.
3. Склонируйте его на ваш компьютер (git clone <url>).
4. Отредактируйте ваши ~/.bashrc, ~/.vimrc и прочие файлы персональных настроек, вынеся оттуда универсальные aliases, функции и прочие общие настройки в отдельные файлы в вашем клоне репо.
5. Включите универсальные настройки в ~/.bashrc (source ~/path/to/aliases.sh)
6. git add && git commit
7. Клонируйте настройки на другие сервера и отредактируйте соответствующие .bashrc (как указано в пункте 6).

В качестве примера приведу репо с моими настройками, алиасы в aliases.sh, функции, как несложно догадаться, в functions.sh.

alias md='mkdir -p'
alias h='history'
alias j='jobs -l'
alias which='type -a'
...

А вот как выглядит ~/.bashrc на моих серверах. Клон репо находится в ~/etc/bash-ext.

# Include gloablly defined aliases and functions
source ~/etc/bash-ext/aliases.sh
source ~/etc/bash-ext/functions.sh

__define_colors
__set_prompt
...

Плюсы и минусы такого подхода

Плюсы

• Копия настроек на каждой системе поднимается за минуты
• Возможность иметь историю изменений на каждой системе без необходимости доступа к центральному серверу (если вы используете dvcs – git, hg, etc.)
• Возможность иметь кастомные версии настроек, скажем, для разных ОС или целей (git branch freebsd && git checkout freebsd…)
• Возможность иметь универсальные настроки для команды или рабочей группы

Минусы

• Вам понадобится git (hg, svn, bazaar..) клиент на каждой машине. Впрочем, установка нужного пакета – дело нескольких минут.

Одним из преимуществ git являются дешевые бранчи. Поскольку бранч – это просто файл в .git/refs/heads, который содержит id последнего коммита в этом бранче, создание нового бранча выполняется за очень небольшое время. При таких возможностях разумно использовать бранчи, что называется, “на все деньги”, что большинство программистов и делает.

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

Установка git bash completion

В состав git включены несколько полезных скриптов, среди которых – git-completion.bash. После его подключения в списке completion для bash добавляются команды git, имена локальных и remote брачей, теги и многое другое. Кроме этого, скрипт определяет несколько полезных функций, которые можно использовать для получения информации об окружении.

$ git <tab><tab>
add                 citool              gc                  notes               shortlog
am                  clean               get-tar-commit-id   pull                show
annotate            clone               grep                push                show-branch
apply               co                  gui                 rebase              st
archive             commit              help                reflog              stage
bisect              config              imap-send           relink              stash
blame               describe            init                remote              status
br                  diff                instaweb            repack              submodule
branch              difftool            last                replace             tag
bundle              fetch               log                 request-pull        whatchanged
checkout            filter-branch       merge               reset
cherry              flow                mergetool           revert
cherry-pick         format-patch        mv                  rm
ci                  fsck                name-rev            send-email

Если вы пользуетесь MacPorts, убедитесь, что git-core установлен с вариантом +bash_completion

$ sudo port install git-core +bash_completion
--->  Computing dependencies for git-core
--->  Cleaning git-core

Если вы установили git из исходников, поищите – скрипт должен лежать где-то в системе.

$ locate git-completion
/opt/local/share/doc/git-core/contrib/completion/git-completion.bash

Настройка bash prompt

Добавьте следующие строчки в ~/.bashrc

source /path/to/git-completion.bash

function __set_prompt
{
    # Configure Colors:
    WHITE='\033[1;37m'
    LIGHTGRAY='033[0;37m'
    GRAY='\033[1;30m'
    BLACK='\033[0;30m'
    RED='\033[0;31m'
    LIGHTRED='\033[1;31m'
    GREEN='\033[0;32m'
    LIGHTGREEN='\033[1;32m'
    BROWN='\033[0;33m'
    YELLOW='\033[1;33m'
    BLUE='\033[0;34m'
    LIGHTBLUE='\033[1;34m'
    PURPLE='\033[0;35m'
    PINK='\033[1;35m'
    CYAN='\033[0;36m'
    LIGHTCYAN='\033[1;36m'
    DEFAULT='\033[0m'

    export PS1="\[${GREEN}\]\u.\h\[${LIGHTBLUE}\]"' $(__git_ps1 "(%s) ")'"\[${BROWN}\]\w \[${DEFAULT}\]\\$ "
}
__set_prompt

Update: цвета в PS1 нужно заключать в \[\], иначе bash будет некорректно рассчитывать длину приглашения и в терминале перевод строки будет обрабатываться некорректно:

123amiurg ~ $ 1234567890

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

Но сначала – спасибо всем, кто принимал участие. Ребята, с вами было интересно общаться и работать над идеями и кодом, я с удовольствием приму участие и в следующих “забегах”. И, конечно, отдельное большое спасибо организаторам (и в первую очередь Тимофею Евграшину).

Угнать за 80 секунд

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

Все вышло как нельзя лучше, и в качестве бонуса мы получили массу удовольствия от самого процесса. Но обо всем по порядку.

Атмосфера

Представьте себе 25-30 программистов, которые видят друг друга в первый раз, но уже горят желанием создать что-то этакое, потом прикрутить еще что-то вот такое, повесить бантик и покрасить в малиновый, чтобы вышло ОГОГО. Представили? Теперь равномерно накрошите программистов по залу, обеспечьте wifi, раскидайте десяток-другой bean bag chairs, пару бильярдных столов, литров 50 кофе, полцентнера шоколадок и.. знаете, лучше идите-ка спать домой, потому что поспать здесь у вас точно не получится.

“Он добавил картошки, лука, посолил и поставил аквариум на огонь” (народное творчество)

Программист и PR-щик – братья навек

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

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

- (Галя) Ти хто?

- (Я) Э-э-э.. с утра был программистом..

- То чого сюди приперся? Іди програмуй!

- Да я это.. да мне бы.. я так, хожу-думаю..

- Думати? Думати можна. Думай.

Старт

В 10 утра субботы мы запустили на большом экране обратный отсчет и время пошло. Представиться и рассказать о себе и своих скиллах несложно, чуть сложнее ясно описать идею своего приложения (сервиса, программы) в паре фраз. С другой стороны, если идею приложения сложно объяснить – возможно, оно будет понятно и интересно только узкому кругу людей? За 10 минут stand-up обсуждения идей мы набросали штук 15, потом разбились их на команды и принялись за работу.

Если кто-то не знает – будучи предоставленными самим себе, разработчики быстро запрягают и не менее быстро едут. Представление, знакомство, обсуждение и выбор идей, формирования команд и согласование инструментов и правил разработки заняло немного времени, и в 12:14 наша команда уже чекинила первые строчки. Поневоле вспоминаются некоторые компании, в которых 3 менеджера на 1 работника.

ххх: думаю, очень показательно, что из всех факультетов именно у нас, менеджмента, не получилось организовать вечеринку в честь получения дипломов… (bash.org.ru)

Bare essentials

Несколько советов тем, кто будет участвовать в подобных проектах. В условиях ограниченного времени на первое место выходит четкая постановка целей, хорошее распределение работы и, конечно, умение быстро писать код. А еще – умение отсекать ненужное. Кстати, все эти моменты хорошо описаны в книге Getting Real от известной студии 37signals.

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

Во-вторых, release early, release often. Чем раньше вы получите работающий скелет приложения, чем раньше вы попробуете его в деле, тем скорее определите, что имеет значение для пользователя, а что – лишь красивые, но бесполезные плюшки. В конце концов, как говорят в Одессе – “вам шашечки или ехать”?

И, наконец, научитесь делить работу. Не толкайтесь локтями на одном участке проекта. Скажем, один человек занимается UI, другой ядром, третий рисует графику. Или один работает над базой, второй тестирует, третий спит. В крайнем случае пишет код один, остальные варят ему кофе и делают массаж. Главное – не нужно всей толпой набрасываться на один кусок, и уж тем более не нужно добавлять людей в надежде сделать работу быстрее.

Assigning more programmers to a project running behind schedule will make it even later, because of the time required for the new programmers to learn about the project, as well as the increased communication overhead. (The mystical man-month)

Продолжение следует

На сегодня закончу на этом. Следующая часть через несколько дней.

На досуге немного поигрался с django + python, вспомнил молодость. Получился своего рода полный цикл разработки веб-приложения, со скетчами, с несколькими итерациями кода, системой контроля версий (svn) и, в финале, выкатка рабочей версии на “production” хостинг.

pinfont text generator v0.1 | images by garnenka.

Далее о выборе svn-клиента, Mac OS и удобстве пользователя.

Version, Cornerstone и usability в мелочах

В процессе работы узнал, какие svn-клиенты существуют под Mac OS (помимо, конечно, командной строки). Соцсоревнование между Versions и Cornerstone последний выиграл с небольшим отрывом за более удобный интерфейс и предупредительное отношение к пользователю.

Хорошее сравнение Versions vs. Cornerstone (равно, как и некоторых других клиентов) можно найти у Jade Ohlhauser. Теме выбора клиента также посвящено обсуждение на Stackoverflow и даже статья Comparison of Subversion clients на Wikipedia.

Лирическое отступление. Хочу отметить, что удобству в мелочах уделяют внимание многие хорошие программы под Mac OS. В упомянутом уже Cornerstone, например, диалог подключения к новому репозиторию бережно распарсил скопированный мной в клипборд url репозитория:

Зачем?

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

Поиск в сети даст достаточно подробностей, здесь же я хочу привести краткую сводку фактов.

Методы подсчета можно условно разделить на три области – shifting, algebraic logic и table lookup.

Shifting

С первыми, в принципе, все понятно – они занимаются посчетом битов в числе, постепенно сдвигая его вправо. Небольшие вариации (обнуление самого правого единичного бита вместо сдвига всего числа) могут дать выигрыш в скорости, если заранее известно, что в данных преобладают “0″ или, наоборот, “1″. В целом, это самая медленная группа методов подсчета.

Algebraic logic

Методы этой группы основаны различных математических операциях, например, на группировке битов внутри числа в несколько проходов. Так, один из методов сначала разбивает биты в числе попарно, переводя кол-во единиц в каждой паре в бинарное представление (00 -> 00, 01 -> 01, 10 -> 01, 11 -> 10), потом по 4 бита, 8 и так далее. Группа методов работает в среднем в несколько (у меня – порядка 4) раз быстрее, чем итеративный подсчет.

Table lookup

Наконец, последняя группа методов сначала строит таблицы вида [число]->[количество выставленных в "1" битов] и потом пользуется ими для быстрого получения значения. Варьируется  в основном только размер таблиц (8-16-… бит). Эти методы самые быстрые, особенно на больших объемах данных, когда потери времени на расчет таблиц незначительны по сравнению со временем самого подсчета.

Сравнение производительности

Вот конкретные результаты прогона различных алгоритмов на моей машине (Darwin Kernel Version 10.3.0, Intel Core 2 Duo 2.26 GHz). Собрано с оптимизацией под скорость (-O3 и еще куча опций). Исходники - https://github.com/dreamiurg/bitcount.

8-bit lookup table calculation took 0.32 ms
16-bit lookup table calculation took 2.34 ms

---> Shitfing methods
Iterated        4.646 sec   21.524 Mcps
Sparse          3.475 sec   28.775 Mcps
Dense           3.670 sec   27.251 Mcps

---> Algebraic methods
Parallel        1.172 sec   85.328 Mcps
Nifty           1.204 sec   83.083 Mcps
Hakmem          1.217 sec   82.193 Mcps

---> Table lookup methods
Precomp 8       0.732 sec  136.684 Mcps
Precomp 16      0.688 sec  145.268 Mcps

Как видим, самый медленный метод отличается от самого быстрого практически в 7 раз, при этом потери на создание таблиц минимальны и измеряются миллисекундами.

Дальнейшее чтение

Конкретные алгоритмы легко найти в сети. Среди хороших ресурсов для начала – статья “Puzzle: Fast Bit Counting“, к ней и отсылаю к ней за деталями. Кроме того, обратите внимание на статью “Bit Twiddling Hacks“, которая содержит море полезной информации по различным операциям над битами и битовыми массивами.