GitHub

Место-куда-я-пишу-мысли переехало на GitHub. Со временем я думаю перекинуть туда и свои старые записи с Blogger.

Я уже окончательно понял, что совершенно не переношу ни WYSIWYG, ни правку сырого HTML. GitHub сделал очень правильное дело, предоставив возможность использовать Markdown. Поэтому у меня есть ощущение, что на новом месте блог будет жить куда дольше --  и продуктивнее.

Поиск по внешним исходникам в Vim

Я давно использую ctags в Vim, и более чем доволен, но одной вещи по-прежнему сильно не хватало. Редко когда нужен поиск только по кода внутри проекта. Часто хочется заглянуть ещё и в third-party код. Только вот мешать его с рабочим (чтобы ctags мог дотянуться) нет никакого желания.

Обычно я решал эту проблему, просто держа под рукой браузер с API или исходниками требуемого класса. Либо запускал отдельное окно Vim. Но постепенно эта ситуация стала надоедать, да и обида за любимый редактор взяла - неужто он хуже той же IDEA? Неужто не умеет брать ctags из нескольких источников?

Полез в документацию - и увидел, что всё у него с этим делом обстоит прекрасно. Проблему решает одна-единственная строчка в конфиге.

Сначала подготовим необходимые библиотеки: создаём папку ~/src и выкладываем туда исходники необходимых библиотек и фреймворков. Можно просто распаковать архивы с кодом, но более труёвый способ - склонировать нужную ветку или тег из репозитория библиотеки. Проще будет обновлять версию при необходимости.

После этого прогоняем ctags для всех исходников - заходим поочерёдно в папки и запускаем ctags:

$ cd ~/src
$ for dir in $(ls); do if [ -d $dir ]; then cd $dir; ctags -R; cd ..; fi; done

После чего добавляем одну строчку к конфигу:

set tags=./tags,./TAGS,tags,TAGS,~/src/*/tags

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

Поиск по тегам, кстати, работает на удивление быстро. Быстрее, чем в любой IDE.

Just FYI: Мой конфиг Vim живёт здесь, но я периодически подумываю перенести его на github.

Useful bash macro: with

Here is a simple but quite nice bash macro that I use very often. Just added it into my ~/.bash_aliases:

function with () {
    # filter files list, leaving only files that has our key words
    xargs grep $@ | sed 's/:.*//' | uniq
}

Now my command line looks prettier:

$ cd project_dir
$ find . -name \*.java | wc -l # find all java files
over 9000
$ find . -name \*.java | with -i hitrin | wc -l # find all my java files
138

You can also use chaining:

find | with | with | ...

Exception: you can't use with with -v option of grep, because it displays rows in another format. Sad but true.

Сделать после

Сегодня задался вопросом, как можно в шелле дождаться завершения какого-то процесса, и после этого сделать что-нибудь ещё. Порой такая возможность бывает совсем не лишней.

Например, когда ВНЕЗАПНО выясняется, что из-за медленного интернета процесс установки нового пакета (и пятнадцати библиотек, от которых он зависит :) затянется на четверть часа, глупо сидеть и пялиться в экран на ползунок apt-get. Лучше переключиться на другую деятельность, а к новому пакету вернуться только тогда, когда он будет готов. Конечно, можно прервать процесс и запустить заново с добавлением & notify-send "Job done, my Master!" после команды, но это же не Ъ-way!

Мне казалось, что в богатейшем списке утилит командной строки обязательно есть какая-нибудь штукенция, которая позволит решить эту проблему с помощью одной-единственной команды, но гуглёж показал, что магического слова всё же нет, и все используют связку while & wait. Но лень - страшная вещь, и писать каждый раз (даже примитивный) цикл дико ломает.

Поэтому на основе пары источников был создан следующий опус:

% cat doafter
#!/bin/sh

delay=2
pid=$1
shift
cmd=$@
usage=0

if [ "$pid" == "" ]
then
  usage=1
  echo "PID is required"
fi

if [ "$cmd" == "" ]
then
  usage=1
  echo "COMMAND is required"
fi

if [ "$usage" == "1" ]
then
  echo "Usage: doafter PID COMMAND"
  echo "where"
  echo "  PID = Process id to wait for"
  echo "  COMMAND = Command to be executed after it completes"
  exit
fi

while ps -p $pid >/dev/null; do sleep $delay; done
$cmd

Отныне, закинув этот скрипт в /usr/local/bin, я могу уведомлять сам себя о завершении длинного процесса хоть через notify-send, хоть через mpc play, хоть через что-угодно-ещё. Хотя, конечно, если бы существовала "магическая команда" для тех же целей, не пришлось бы и скриптованием заниматься.

В качестве дополнительного упражнения надо будет разобраться, как сделать так, чтобы можно было использовать автодополнение bash/zsh для завершения выполняемой команды. А то ввожу номер процесса, набиваю начало команды, жму таб - а шелл ничего не добавляет! Непорядок :(

Texlive vs. cases

При написании небольшого документа на TeX столкнулся с проблемой генерации систем из уравнений (cases). Оказалось, что установленный у меня texlive не понимает соответствующие теги LaTeX. По крайней мере, при таком наборе пакетов:

[zloddey@zlohost ~]$ yaourt -Q|grep texlive
==> Query installed packages
extra/texlive-bin 2009.5-5
extra/texlive-core 2009.16776-1 (texlive-most)
extra/texlive-langcyrillic 2009.16188-1 (texlive-lang)

Но, к счастью, в линуксе всё устроено логично, надо лишь порой немного подумать головой. Сначала я нашёл и установил пакет совместимости с LaTeX:

[zloddey@zlohost ~]$ yaourt -S texlive-latex3

Посмотрел список пакетов теха, которые шли в комплекте:

[zloddey@zlohost ~]$ yaourt -Ql texlive-latex3 |grep math
texlive-latex3 /usr/share/texmf-dist/tex/latex/mh/mathpazo.sym
texlive-latex3 /usr/share/texmf-dist/tex/latex/mh/mathptmx.sym
texlive-latex3 /usr/share/texmf-dist/tex/latex/mh/mathstyle.sty
texlive-latex3 /usr/share/texmf-dist/tex/latex/mh/mathtools.sty

И со второй попытки угадал имя правильного пакета (это уже в самом .tex-файле):

\usepackage{mathtools}

После этого cases стали рисоваться так, как им и положено.

UPD (2010-10-13): На днях пакет mathtools переехал в texlive-core, так что даже не надо ничего дополнительно ставить в пакетном менеджере. Только указать пакет в tex-файле.

Как не надо программировать

Всё ковыряюсь в коде TuxGuitar. Усиленно штурмую его внутреннюю модель данных. Она чудовищно переусложнена и хаотически запутанна. Мне уже удалось упростить периферию, но остался самый запутанный узел.

Это упрощённая схема зависимостей классов модели, из которой многое выкинуто. Стоит ещё добавить, что большинство этих классов создаётся двумя фабриками, одна из которых наследует другую и переопределяет все её методы. А установка конкретной фабрики осуществляется где-то в дали от создания объектов, через методы синглетона. И все эти объекты также знают о существовании фабрики. Двумя словами, это просто какой-то адский клубок.

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

Впрочем, всё это ещё не отбило моего интереса. Пока что только добавляет задору. Результаты задора хостятся на gitorious.org.

Интересы

Давно хочу разобраться во внутренностях TuxGuitar. В принципе неплохой редактор табов (и я его достаточно регулярно использую), но у него есть ряд заметных недостатков. Самые заметные для меня - это отсутствие нормальной нотации для ударных и проблемы с midi-бэкендами, из которых более-менее нормально работает только Gervill (а охота иметь дело с jack).

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

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

Мой план достаточно прост:
1. Покрываем код проекта юнит-тестами, желательно, поплотнее.
2. Аккуратно применяем приёмы рефакторинга для распутывания системных зависимостей.
3. Когда код становится достаточно чист, добавляем нужные фичи.

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

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

UPD: Залил проект на gitorious. Впрочем, пока существенно почти ничего не изменил. Распутываю классы нот и нотных эффектов.