Почему программисты должны писать документы в LaTeX

Хочу сразу написать, что в этом небольшом посте мне бы не хотелось рассказывать о преимуществах LaTeX в том виде, как это принято. Вы не найдете здесь похвал в адрес удобства использования, удобства редактирования, изменения оформления, набора формул, составления содержаний и списков литературы - всё это присуще LaTeX, но и упоминалось уже неприличное количество раз. Я бы хотел рассказать о тех забавных преимуществах, которые лично мне в LaTeX показались важными.
В процессе обучения в НАУ им. Н.Е. Жуковского "ХАИ" я дошел до момента, когда нужно писать бакалаврскую работу. Ничего особенного в этом нет, тема была выбрана, "исследования" проведены, программа уже написана. Осталось только написать пояснительную записку.
А это с незапамятных времен было для меня самым сложным. Еще участвуя в МАН, при написании курсовых работ и т.п. я заметил за собой жгучее нежелание писать текст. Это было скучно и неинтересно, не то что создавать программную реализацию.
Но недавно я открыл для себя LaTeX и все переменилось! Теперь я с удовольствием набираю текст, вставляю команды, "компилирую", правлю опечатки и пишу дальше. У меня даже появились "баги"(вызванные, вероятно, моим собственным недопониманием команд), которые я, ругаясь, фикшу. Написание скучного текста превратилось в увлекательнейший труд - вот вам причина, по которой программисту стоить писать документы в LaTeX!
Побочная причина - возможность хранения истории изменений в репозитории. Ведь когда пишешь документ, так и хочется закоммитить, чтобы увековечить свои изменения, а .tex файлы для этого подходят как нельзя лучше.

---

Напоследок хотелось бы дать несколько интересных ссылок

• Прекрасное "не очень короткое" введение в мир LaTeX на русском языке
• Хорошая подборка материалов

Также в качестве бесплатной рекламы - эти люди занимаются составлением руководств по верстке дипломов в LaTeX, честь им и хвала.

• 'Верстаем диплом в LaTeX.' Цикл статей
• 'Как оформить диплом в LaTeX?' Одна статья разбитая на несколько подразделов
• 'Диссертация в LaTeX.'
Одна статья, хороший блог :)

Я собираюсь выложить в общий доступ мои наработки(классы, стили) как только пояснительная записка будет написана. Надеюсь, это окажется полезным для тех, чьи alma mater предъявляют схожие к моему требования.

SciTE incremental autocompletion

I am a big fan of these "holy" editors, like vim and emacs (yes, I use both). But I am also a big fan of SciTE - simple text editor for developers. It is not so popular like vim or emacs, but I like it. So I decide to improve one of its features - autocompletion. I called the result "Incremental autcompletion". Look at this video:

Isn't it cool? I think it is :) If you like it, you can use this patchset. To use feature after applying patches and compiling, just add "autocompleteword.incremental=1" to the properties file.
I started a thread in scite-interest group. I hope, this feature will be accepted by Neil Hodgson (SciTE and Scintilla creator), because for me it is acceptable open source alternative for some of Visual Assist autocompletion features.
UPD 1. Don't forget to add all of these lines

autocompleteword.automatic=1
autocomplete.choose.single=0
autocompleteword.incremental=1

to your properties file.
UPD 2. Frank Wunderlich noticed the bug in implementation. Please use the second version of patch

О разделении труда, написании кейсов и их реализации

Прошедшая вчера встреча IT Talk натолкнула меня на интересные воспоминания. Я вспомнил предисловие к роману Джека Лондона "Сердца трёх". А точнее, заметил, что Лондон описывает в нем не только свою работу, но и современные реалии IT.
Предисловие к предисловию. Обычно процесс разработки состоит в преобразовании начальной идеи в кейсы-требования, которые потом преобразуются в код. Т.о., есть два вида работ - написание кейсов и написание кода. В последнее время существует множество мнений на тему, нужно ли написание кейсов:

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

Мнения о том, кто должен выполнять эти работы:

• Technical writers
• QA, им потом это тестировать
• Бизнес аналитик, так как его прямая обязанность - разбираться в начальной идее
• Разработчики, так как они могут представить программный продукт
• Отдельный случай - когда в команде нет особого разделения на роли и идеей проникнут каждый - тогда кейсы могут писать все.

Джек Лондон "Сердца Трёх", отрывки из предисловия с комментариями:

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

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

...Итак, мы работали параллельно, каждый над своим куском. Когда я писал какую-то главу, я, естественно, не мог принимать в расчет того, что происходит в следующей или через двенадцать глав, так как я этого не знал. Не знал этого и м-р Годдард. Отсюда неизбежные последствия: нельзя сказать, чтобы повествование в "Сердцах трех" отличалось особой последовательностью, хотя, оно, безусловно, не лишено логики...

Комментарий 2. И сценарист и романист работают в условиях, когда неизвестно, что будет дальше. Это нормально.

...Представьте себе мое изумление, когда я, будучи на Гавайях, вдруг получаю от м-ра Годдарда по почте из Нью-Йорка сценарий четырнадцатогоэпизода (я же в то время только еще трудился над литературной обработкой десятого эпизода) и вижу, что мой герой женат совсем не на той женщине! И в нашем распоряжении всего только один эпизод, когда можно избавиться от нее и связать моего героя узами законного брака с единственной женщиной, на которой он может и должен жениться. Как это сделано - прошу посмотреть в последней главе или пятнадцатом эпизоде. Можете не сомневаться, что м-р Годдард надоумил меня, как это сделать.

Комментарий 3. Сценарий обычно опережает роман по количеству эпизодов. Задача сценариста - стараться не допускать того, чтобы новые эпизоды влияли на старые.
Комментарий 4. К сценарию нужно относится со всей серьезностью. Если вдруг нужно что-то добавить в сценарий - нужно пытаться сделать это с минимальными изменениями в уже написанном, тогда роман тоже нужно будет минимально переписывать. Т.е., написание кейсов очень сходно с написанием кода. Вместо привычного "unit тесты -> код -> рефакторинг" при написании сценария нужно придерживаться сходного "проверка требования на удовлетворение какой-то части идеи -> написание требования -> рефакторинг"

...Дело в том, что м-р Годдард - мастер по части развития действия и гений по части быстроты. Развитие действия нимало не волнует его. "Изобразить", - спокойно указывает он в авторской ремарке киноактеру. Очевидно,актер "изображает", ибо м-р Годдард тут же начинает нагромождать однодействие на другое. "Изобразить горе!" - приказывает он, или "печаль",или "гнев", или "искреннее сочувствие", или "желание убить", или "стремление покончить жизнь самоубийством". Вот и все. Так и должно быть - иначе, когда же он завершил бы работу и написал свои тысячу триста сцен?
Но можете себе представить, каково пришлось мне, несчастному, который не мог ограничиться волшебным словом "изобразить", а должен был описать - и притом весьма подробно - все те настроения и положения, которые одним росчерком пера наметил м-р Годдард! Черт побери! Диккенсу не казалось чрезмерным излишеством потратить тысячу слов на описание и возможно более тонкую обрисовку горестных переживаний того или иного из своих героев. А вот м-р Годдард говорит: "Изобразить", - и рабы киноаппарата делают все, что нужно...

Комментарий 5. Сценарист не должен вдаваться в подробности. "Изображать" умеет романист, не надо отбирать у него хлеб.

Если в основе этой авантюры, именуемой "Сердца трех", лежит сотрудничество, я восхищен идеей сотрудничества. Но только - увы! - боюсь, что такого коллегу, как м-р Годдард, можно встретить не чаще, чем одного на миллион. Мы ни разу не перебросились даже словом, у нас не было ни одного спора, ни единой дискуссии. Но в таком случае я, должно быть, и сам - не коллега, а мечта! Разве я не позволил ему - без единого намека на жалобу или возражение - "изображать" все, что ему заблагорассудится, на протяжении 15 эпизодов сценария, 1300 сцен и 31000 футов пленки, а затем 111000 слов, составивших роман? И все-таки теперь, когда я кончил сей труд, я очень был бы рад, если бы не начинал его, - по одной простой причине: мне хотелось бы самому прочесть книгу и посмотреть, как она читается. А меня это очень интересует. Очень.

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

---

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

Об отношении к вышестоящим

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

Произносим числа словами, альтернатива SayNumber в Asterisk

Казалось бы, совсем детская задачка - имея на входе число, например, 42, получить на выходе строку символов - "сорок два". Вот и в Asterisk(программная АТС с открытым исходным кодом) есть встроенная функция SayNumber, которая "произносит"(проигрывает) число в канал. На самом деле, это ничем не отличается от простого преобразования числа в последовательность слов - Asterisk просто проигрывает звуковые файлы, которые имеют соответствующие словам названия.
Asterisk предоставляет простейшую функциональность по локализации звуковых файлов - вместо стандартной озвучки можно подставить свою, например русскую. И тогда 42 будет произноситься не как "fourty two", а как "сорок два". Однако, такая локализация не полная - при ближайшем рассмотрении можно заметить, что в русском языке числа произносятся совсем не так, как в английском. Например, 201 произносится как "двести один", а не как "два сотня один". Более того, в русском языке есть еще падежи, единственное/множественное число, мужской/женский/средний род. И когда нужно произнести что-то вроде "одна тысяча четыреста один рубль" или "две тысячи сорок пять рублей", встроенные средства совсем не подходят.
На voip-info.org даже есть ссылка на альтернативную реализацию SayNumber, которая настраивается через конфигурационные файлы(на voip-info.org неправильная ссылка, правильная на данный момент - альтернатива SayNumber от www.beronet.com ). Однако она реализована на С, в виде модуля, так что слабо портируема между версиями Asterisk: я не смог использовать ее в Asterisk 1.4.x. И тогда мне пришла в голову мысль написать свою альтернативную реализацию. В качестве требований выступили:

• Возможность гибкой настройки(решение: использовать конфигурационные файлы)


• Переносимость между версиями, удобство установки и использования(решение: использовать механизм AGI)


• Элегантность (решение: использовать Python :) )

Не затягивая долго, покажу, что в итоге получилось: Исходный код.
Или без подсветки: Plain text.
Я старался комментировать и документировать код, чтобы он был прост и понятен. Также надеюсь, что он оказался достаточно элегантен (любые замечания или исправления приветствуются). Осталось только показать, как его использовать:

exten => _X.,n,AGI(pysaynumber.agi|42r|ru.conf)

, где pysaynumber.agi - название скрипта, 42r - что надо произнести, ru.conf - название конфигурационного файла.
Конфигурационный/ные файлы нужно положить рядом с pysaynumber.agi в agi-bin (его местоположение разнится в зависимости от места установки Asterisk)
Пример конфигурационного файла: здесь
Формат конфигурационного файла. Частично позаимствован из наработок www.beronet.com. Каждая строка состоит из двух частей, разделенных ":". Первая часть - регулярное выражение, без начального "^" и конечного "$"(они подставляются автоматически). Вторая часть - список действий, разделенных ";". Алгоритм прост - идем подряд по всем правилам и если находим match с номером, который мы желаем "произнести", то выполняем подряд все действия по соответствующему списку. Видов действий три. Если строка действия представляет собой конечное "слово" (например, rublei, 40), то мы просто "произносим" его. Если строка действия начинается с number, то это второй тип действия. Параметры указываются в скобках, вот так - (индекс|суффикс). При выполнении этого действия "произносится" конечное "слово", составленное из символа, который находится в исходном номере по индексу и суффикса. Третье действие - recursive. Параметры - (индекс[,индекс...]|суффикс). Запускает весь алгоритм рекурсивно, но уже для номера составленного из символов, которые берутся из исходного номера по индексам, и суффикса.
Приведенный мной код может использоваться не только для Asterisk(проверялось на Asterisk 1.4.18.1), а и для других нужд. Также для того, чтобы ускорить работу скрипта можно использовать FastAGI, тогда можно будет хранить таблицу уже проинициализированной и не запускать интерпретатор каждый раз заново.
UPD. Используйте FastAGI. По непонятной причине подобным образом написанные скрипты приводят к подвисанию Asterisk со 100% загрузкой процессора. С применением FastAGI таких проблем не наблюдалось.