Лучше поздно, чем никогда.

Постом на который ссылался аудиослейв некоторое время назад навеяло. Расскажу про наш способ работы с svn-бранчами.

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

"Рабочий" бранч будет называться как обычно branches/$branch, а "эталонный" branches/$branch--base. В качестве названия бранча я, как правило, использую номер задачи из багтрекера, например FOOBAR-28.

создание бранча

# "базовый" бранч
svn cp $prj/{trunk,branches/$branch--base}`

# "рабочий" бранч
svn cp $prj/branches/$branch{--base,}

# чекаут нового рабочего бранча, начинаем работу
svn co $prj/branches/$branch
cd $branch

вливание бранча в транк

Следствием того, что каждая задача багтрекера - бранч, их жизнь скоротечна и вливание в транк гораздо более частая задача, чем обновление бранча из него. Эта операция проходит, как и предполагалось.

# локальная копия транка для сливания
svn co $prj/trunk $branch--merge
cd $branch--merge

svn merge $prj/branches/$branch{--base,}

# проверяем, что все работает и коммитим
svn ci

обновление бранча из транка

Эта операция чуть более сложная, но все же доступная для понимания =)

# так как мы сольемся с транком "эталонный" бранч должен стать идентичным 
# текущему транку
svn cp $prj/{trunk,$branch--new-base}

# сливаем все изменения от старого "эталонного" до нового
cd $branch
svn merge $prj/branches/$branch--{base,new-base}

# подменяем "эталонный" бранч
svn rm $prj/branches/$branch--base
svn mv $prj/branches/$branch--{new-base,base}

Я собрался с силами и сгенерировал текстовую версию доклада, который я делал на Exception #08. Про то, как я его писал можно будет написать отдельный пост =)

tell application "Terminal"
	set blaze_tab to do script "ssh blaze 'tail -f /var/log/yandex/...log' | bin/colorer"
	
	set custom title of blaze_tab to "blaze"
	set number of rows of blaze_tab to 80
	set number of columns of blaze_tab to 128
	
	set vitalize_tab to do script "ssh vitalize 'tail -f /var/log/yandex/...log' | bin/colorer"
	
	set custom title of vitalize_tab to "vitalize"
	set number of rows of vitalize_tab to 80
	set number of columns of vitalize_tab to 128
end tell

При использовании django регулярно натыкаюсь на выразительную убогость темплейтного языка.

Последнее из этой серии. Невозможно сделать следующее:

{% yausername user|nick_or_fio %}

А хотелось простого. yausername - тег который умеет приводить строку к виду elephantum, nick_or_fio фильтр, который выбирает у пользователя первый не пустой аттрибут из списка: [ник, фио, логин].

Но все оказалось не так просто. Фильтры могут применяться только в блоках подстановки переменных ({{ user|nick_or_fio }}), параметры же тегов обрабатываются as is и все ломается на невозможности найти в контексте переменную "user|nick_or_fio".

В принципе, поднатужившись, можно пропатчить джангу в этом вопросе, но стоит ли шкурка выделки?

как просто раскидать один список в несколько других по условию

In [1]: l = range(20)

In [2]: def cond(x):
   ...:         return x % 3
   ...: 

In [3]: (lambda r: dict((curkey, [item for (key, item) in r if key == curkey]) 
   ...:                 for curkey in dict(r).keys())
   ...:  )([(cond(i), i) for i in l])

Out[3]: 
{0: [0, 3, 6, 9, 12, 15, 18],
 1: [1, 4, 7, 10, 13, 16, 19],
 2: [2, 5, 8, 11, 14, 17]}

>>> class History:
...     def __init__(self, data=[]):
...             self.data = data
...     def append(self, val):
...             self.data.append(val)
...     def __iter__(self):
...             return iter(self.data)
... 
>>> h1 = History()
>>> h1.append(1)
>>> list(h1)
[1]
>>> h2 = History()
>>> h2.append(2)
>>> h2.append(3)
>>> list(h2)
[1, 2, 3]

очень меня беспокоит, что современное программирование больше походит процесс молекулярной сборки, мой идеал - конструкторы lego

disclaimer: да, я понимаю, что все упирается в сложность системы, однако мне кажется, что в массе случаев эта сложность преувеличивается

Силился я найти простой и приятный мне фреймворк для разработки веб-приложений для взаимодействий класса "программа-программа" (отличается от класса "программа-пользователь" тем, что отсутствует тяжелый слой верстки) REST-стиля.

Самым вероятным кандидатом был web.py, однако я не могу смириться с основными концепциями этой библиотеки. Видимо, я слишком много программировал на хаскелле, это вредно. Сейчас я считаю, что у каждой функции все выходы должны быть точечными и начинаться со слова return. Предложение генерировать выходные данные последовательностью self.send_response(...), self.send_header(...), print - меня убивает. Если действительно необходимо сделать не атомарный вывод, как, например, при server-push механизме, то просто нужно возвращать генератор атомарных элементов.