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. Впрочем, пока существенно почти ничего не изменил. Распутываю классы нот и нотных эффектов.

140

Завёл себе твиттер: twitter.com/ahitrin

В ближайшие дни выложу перевод статьи об Х11 (надо ещё окончательно оформить).

jackd on ArchLinux

Столкнулся с проблемой запуска jackd на своём ArchLinux (x64). Вскоре после запуска сервер jack падал, а если он запускался через qjackctl, то интерфейс намертво зависал.

Сначала я гуглил по вылезавшему при падении сообщению:

cannot lock down memory for RT thread

В качестве решения предлагалось увеличить количество выделяемой на реалтайм-процессы памяти в /etc/security/limits.conf. Я увеличил значение memlock для группы @audio с 40000 (кб) до 500000 (кб), и сообщение пропало. Однако джек по прежнему падал вскоре после запуска.

Единственное, что говорило об ошибке - это следующее сообщение:

jackd watchdog: timeout - killing jackd

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

Эффективная работа с унаследованным кодом

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

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

Другая сложность - это то, что я сам пишу GUI (на wxWidgets). Пока что мне не совсем ясно, как можно эффективно заводить под юнит-тесты все эти wxDialog'и. Скорее всего, проблема решается дроблением классов на кучу мелких. Однако в ближайшее время вряд ли мне удастся посвятить этому достаточно времени. Новую функциональность ввожу через тесты, а большинство старой приходится оставлять как есть. Время сильно ограничено. Да и CppUnit (созданный, кстати, автором этой книги) не слишком удобен в использовании. Но без него всё равно работать было бы только труднее :) Вчера пришлось полностью перелопатить логику работы одного служебного класса, и только поэтапное покрытие кода тестами в сочетании с контролем версий из-под git позволили мне к концу дня уверенно сказать, что класс работает правильно.

Мелочи жизни

Недавно поставил Archlinux на новый компьютер. Дистрибутив понравился в первую очередь за обилие чёткой документации и очень неплохой менеджер пакетов. Pacman оказался очень гибким, шустрым в работе и удобным в управлении. Система PKGBUILD'ов порадовала не меньше. Как только разобрался, как с ними работать, установил себе qutIM и шрифты со сглаживанием.

Однако при очередном обновлении системы я словил проблемы как раз из-за этих самолично поставленных пакетов. Перестал запускаться Firefox, выдавая лаконичное и ни о чём не говорящее сообщение:


$ firefox
Couldn't load XPCOM.


Пришлось гуглить решение через старый добрый links. Сначала нашёл ссылки на проблемы с xulrunner и flashplugin, попробовал их переставить - не помогло. Посмотрел в зависимости firefox (pacman -Qi firefox) и увидел зависимость от библиотеки cairo. Но cairo у меня уже был заменён на cairo-cleartype (по этому мануалу). Когда я догадался попробовать провернуть обратную замену, всё тут же исправилось :)


# pacman -Rd cairo-cleartype
# pacman -S cairo
# pacman -S xulrunner firefox


После этого скачал PKGBUILD для cairo-cleartype и пересобрал его заново, поставив вместо обычного cairo.

На поиск причины неполадок ушло минут 15, а на исправление и того меньше, буквально пара минут. Этой мелкой неполадке, конечно, далеко до того эпического фэйла, который я словил примерно год назад, когда сидел ещё под FreeBSD и неудачно обновил xorg. Жил в консоли на домашней машине добрую неделю, пока не сумел починить.

P.S.: Надо будет чуть попозже повторить эксперимент с обновлением фокса. Хочу проверить, справится ли yaourt с нерепозиторными пакетами. Может быть, стоило сразу обновляться через него.

Domain specific

Сегодня я взялся за один весьма объёмный труд. Начал осваивать книгу Мартина Фаулера по DSL. Уже во вступлении встретил "скромный" пример с использованием машины состояний, для описания которой используется примерно 8 классов на джаве. Чтобы не держать все в голове (наверно, это было бы реально, только пришлось бы затратить больше времени), создал проект в Eclipse и переписал классы в нём. Испытал при этом интересное ощущение. Классы очень простые, но в них есть определённое изящество. Я на самом деле почувствовал, что это код многоопытного автора книг по рефакторингу. Подобные конструкции порой получаются и у меня, но на отшлифовку их дизайна обычно требуется довольно много времени.

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

А в целом книга, похоже, стоящая, несмотря даже на свой незавершённый статус. Я довольно хорошо представляю, где мне могли бы пригодиться DSL, поэтому более близкое знакомство с темой пойдёт на пользу.

Вступительное слово

Меня зовут Андрей Хитрин, я живу и работаю в Екатеринбурге, Россия. Как профессиональный разработчик и фанат компьютерных технологий, я постоянно сталкиваюсь с интересными вещами и явлениями. О них я и собираюсь здесь писать.

Последней соломинкой, переломившей хребет моей лени, стала вот эта статья. Спасибо Алёне :)

Полу-напоминание, полу-анонс. Темы, с которых я хочу начать: Мартин Фаулер; docbook; последний опыт работы с ArchLinux.