пятница, 28 июня 2013 г.

[prog] Маленький пример на тему Big Rewriting

В разработке ПО есть такое понятие -- Big Rewriting. Что на русский переводится как "Взять и все переписать!"

Думаю, что многие из нас сталкивались с ситуациями, когда развивать, сопровождать или просто заставлять работать большую (как правило, написанную задолго до тебя) систему уже просто не хватает сил и нервов. В такие моменты возникает соблазн взять и переписать эту систему заново, с использованием новых идей, самых последних наработок, модных языков/фреймворков и т.д. К счастью, далеко не всегда нам дают возможность осуществить такой Big Rewriting. К несчастью, далеко не все начавшиеся попытки полного переписывания заканчиваются успешно.

Об одном из таких примеров я прочитал в статье "E-TeX: Guidelines for Future TeX Extensions - revisited" при подготовке к предыдущему своему посту о LaTeX-е. Цитирую:

The NTS project (New Typesetting System) was inaugurated by DANTE (the German TeX Users Group) in 1992. Its objective was to re-implement TeX in a 100% compatible way in Java. While TeX was frozen, NTS was to remain exible and extensible. The project completed successfully in 2000, passing the trip test, and thus proving that a reimplementation of TeX in a different language was possible. As it turned out though, full compatibility with TeX resulted in code that was less modular than initially hoped for, so that adding any extensions or providing modi cations of algorithms turned out to be far more difficult than initially anticipated. For this and a number of other reasons, NTS itself wasn't developed any further.

εχTeX is a spin-off started around 2003 with the intention of developing a new Java-based system incorporating the experiences from NTS, ε-TeX, pdfTeX and Omega. The project is represented on the web [1], but as of today it hasn't left alpha stage.

Т.е. проект NTS стартовал в 1992-м и его целью было получение 100% совместимой с TeX-ом новой реализации, написанной на Java. Планировалось, что NTS, в отличии от замороженного оригинального TeX-а, будет развиваться и расширяться. Проект NTS успешно завершился в 2000-м и прошел тесты совместимости с TeX-ом, тем самым доказав, что можно создать TeX на другом языке программирования. Но оказалось, что из-за необходимости иметь 100% совместимость с TeX-ом код NTS получился совсем не таким простым и модульным, как это планировалось вначале. И внедрение в NTS новых расширений или изменение каких-либо внутренних алгоритмов выходило намного более сложным, чем предполагалось. В итоге NTS больше не развивался. На базе NTS в 2003-м стартовал проект εχTeX, который к весне 2013 года так и не вышел из alpha-версии.

четверг, 27 июня 2013 г.

[work.memories] LaTeX в качестве средства создания документации

После заметки о DSL-е для подсистемы логирования меня попросили рассказать о том, как LaTeX был выбран в качестве инструмента для написания документации. Попытаюсь нижеследующим текстом удовлетворить эту просьбу. Хотя дело это уже очень давнее, наверняка в датах буду путаться.

Вопрос о том, как и чем делать документацию для наших разработок встал перед нами в полный рост где-то лет 7-8 назад, в районе 2005-2006 годов. Поначалу, как, полагаю, и в любом другом стартапе, до своей внутренней документации руки не доходили. То, что нужно было заказчику, без каких-либо альтернатив набиралось в Word-е. И здесь ничего с тех пор не изменилось, уж очень активно бизнес-аналитики/ПМы пользуются режимом Review при совместной работе над документом. Тем не менее, со временем, особенно с ростом удаленной от центра разработки (Гомель) службы эксплуатации (Москва), необходимость написания эксплуатационной документации "для себя" созрела окончательно. Нужно было налаживать этот процесс. Чем тогда попытались заниматься, если мне не изменяет склероз, я и Слава Костин.

Задействовать для написания документации Word лично мне не очень хотелось. У меня было много своих причин не любить Word. Но это были мои личные тараканы, с которыми можно было соглашаться, а можно было и не воспринимать всерьез. Но вот в чем мы сходились, так это в неудобстве совместной работы с .doc-файлами, если они хранятся в Subversion репозитории. Если хранить в Svn текстовый файл, то во многих случаях при одновременном его редактировании несколькими людьми можно было автоматически объединять все изменения не имея конфликтов. doc-файлы же у Word-а тогда были бинарными, об слиянии изменений, сделанных в doc-файле одновременно разными людьми, не могло быть и речи. Вроде бы, существовали какие-то инструменты-плагины для Word-а, которые могли это делать, но было очевидно, что это есть облегчение проблемы, но не ее решение. Поэтому мы стали всерьез рассматривать системы документирования на основе простых текстовых файлов.

Выбор был невелик и пристально рассматривалось всего два варианта: DocBook и LaTeX. Помнится, я еще смотрел в сторону Doxygen-а: там можно было посредством т.н. \page-секций делать весьма большие описания, но все-таки это инструмент для построения справочников по API, а не для полноценных руководств по эксплуатации программных комплексов.

Если я помню правильно, то нам со Славой толком договорится по единому инструменту так и не удалось. Он больше склонялся к DocBook-у, как к стандарту, который поддерживается разными инструментами. Я же был сторонником LaTeX-а. После ряда экспериментов и с тем, и с другим, я тихо начал использовать LaTeX для документирования разработок, за которые я отвечал. А потом заставлял осваивать LaTeX своих подчиненных. В итоге мое небольшое подразделение, получившее впоследствии название транспортного цеха отдела разработки в области транспортных систем, всю документацию по своим продуктам писала сама в LaTeX-е. Эксперименты с DocBook-ом в других командах, насколько я помню, заглохли. Да и вообще дела с документацией после отъезда занимавшейся этим направлением Ирины Агеенко шли ни шатко, ни валко. Специализированный же отдел эксплуатационной документации, организованный осенью 2012-го, стал одним из моих немногих реальных достижений на должности начальника управления. Впрочем это уже другая совсем другая история.

Возможно, я был необъективен по отношению к DocBook-у. Но меня сильно смущали несколько вещей. Во-первых, формат XML. Как-то не сложилось у меня с XML-ем. Когда он используется для автоматического парсинга или генерации, это еще куда ни шло. Но вот создавать его ручками -- это то еще удовольствие. Отсюда вытекало и во-вторых: необходимость использования специализированных редакторов. Кои были, но лучшие из них, помнится, были платными. Да и насколько просто было мержить сгенерированные этими редакторами XML-файлы при одновременных правках -- это был вопрос без внятного ответа. В-третьих, на тот момент не было каких-то удобных инструментов для генерации из DocBook-овских файлов чего-то читабельного. И если преобразовалки из DocBook XML в HTML еще находились и худо-бедно работали, то сгенерировать PDF-ку оказывалось не просто. Нужно было качать что-то написанное на Java, как-то с этим шаманить, и только после этого получать как-то слепленную PDF-ку. Лично у меня это не получалось, хотя Диме Косточко это удалось. С LaTeX-ом мне было намного проще.

Здесь нужно сказать, что к тому моменту с LaTeX-ом я сталкивался уже не в первый раз. Более того, для своих личных нужд я его уже применял. Но обо всем по порядку :)

Сначала я о нем услышал учась в аспирантуре на математическом факультете. Поскольку кандидатские диссертации там люди готовили с большим количеством формул, то в качестве инструментов для верстки текста диссертаций использовался либо такой интересный DOS-овский редактор, как ChiWriter (кстати говоря, один из первых редакторов написанный с использованием принципов ООП), либо же кое-как портированный под DOS вариант LaTeX-а. Мощные компьютеры, на которых можно было пускать 6-й Word были тогда доступны далеко не всем, вот люди и пользовались инструментами, которые нормально работали на старых 286/386-х (а некоторые и на совсем-совсем старых 86-х). Я тогда подрабатывал в университете в лаборатории, где был в наличии принтер, и некоторые диссертанты пользовались им для печати своих материалов. От них я и слышал отзывы и о ChiWriter-е, и о LaTeX-е. LaTeX при этом хвалили больше, объясняя мне на пальцах принципы работы с ним. Хотя я тогда не понимал, как может быть удобен инструмент для верстки, не работающий в режиме WYSIWYG.

Первое же знакомство с LaTeX-ом у меня состоялось где-то в 1999-м, когда пришло время набирать текст своей диссертации, хотя формул там вообще не было :) Для этих целей я приобрел старенький, но очень удобный лаптоп Toshiba 5100/100, на котором стоял MS-DOS и был 7-й MultiEdit. И хотя я изучил взятую в университете методичку по использованию LaTeX-а, прихваченный оттуда же на дискетах дистрибутив LaTeX-а на этом лаптопе не пошел. Но какие-то представления о том, что можно делать в LaTeX-е у меня сформировались.

Затем было активное использование Doxygen-а, который во многом напоминал не только Javadoc, но и LaTeX. Так что, психологически, к работе с LaTeX-ом я был готов. И когда в конце 2003-го мне потребовалось написать что-то вроде учебника по SObjectizer-4, я начал с Doxygen-а, но довольно быстро перебрался под LaTeX.

В качестве дистрибутива я сначала использовал пакет TeX Live, который брал с CTAN (тогда дистрибутив сразу для Windows и Linux помещался на один CD, потом они перешли на DVD). Впоследствии, с чьей-то подсказки (не помню, был ли это Михаил Лёсин, Игорь Мирончик или Дима Косточко) я перешел на MikTeX, о чем совершенно не жалею и рекомендую для Windows-пользователей.

Для изучения LaTeX-а мне потребовалась всего одна дока: где-то в дебрях каталога doc в TeX Live был файлик под именем, похожим на lshort-russian.pdf. Это оказался очень толковый документ, страниц на 60, в котором расписывались все основные моменты использования LaTeX для простых и не очень простых целей. Найти этот документ в Интернете можно и сейчас по названию "Не очень краткое введение в LaTeX" (только с того времени он стал объемнее). Повторюсь, для начала полноценного использования LaTeX-а его оказалось вполне достаточно.

Спустя несколько лет мне попалась замечательная книга Котельникова и Чеботарева "LaTeX по-русски". Именно ей я и пользовался, если мне нужно было разобраться в каком-либо вопросе. В частности то, как вставлять картинки в текст документа я осваивал с помощью этой книги. Очень ее рекомендую.

В общем, к 2005-му у меня уже был собственный опыт создания больших документов в LaTeX. Результаты меня вполне устраивали, пользоваться LaTeX-ом было удобно. И этот опыт хотелось использовать при создании документации для интервэйловских продуктов.

Но прежде, чем предлагать LaTeX в качестве инструмента для документирования я посмотрел и на других похожих зверей вокруг. Для непосвященных нужно сказать, что ядром всех что-то-над-TeX-ов является система TeX, разработанная тем самым Дональдом Кнутом. Автором знаменитого многотомника "Искусство программирования", для верстки которого он и написал METAFONT и TeX (попутно еще познакомив мир с "литературным программированием").

Так вот, ядром системы компьютерной верстки является TeX. Но непосредственно TeX-ом мало кто пользуется, уж больно низкоуровневый это инструмент. Поэтому на его основе разработаны макропакеты для разных целей. LaTeX один из них, очень раскрученный и популярный. Тем не менее, в качестве инструмента для написания документации LaTeX представлялся слишком мощным, хотелось найти что-нибудь попроще. Вроде бы более простым показался ConTeXt, но на тот момент в нем были проблемы с поддержкой русского языка. Смотрел я так же и на LyX, который вполне мог бы использоваться в качестве альтернативы Word-у для технических писателей, но в те времена под Windows в готовом виде он был доступен только в составе cygwin и работал там не очень устойчиво. В конце-концов поиски альтернативного макропакета для TeX-а я забросил и остановился на LaTeX-е.

Вначале мы генерировали два типа результирующего представления из tex-файлов. В первую очередь это были PDF-документы. Которые аттачились в соответствующие разделы нашей корпоративной wiki-системы. По просьбе службы эксплуатации делали и HTML-представления. Этот вариант был удобен для использования на КПК (Palm-ы и PocketPC). Но затем мы перешли исключительно на PDF-ки. Благо теперь смартфоны и планшеты совершенно спокойно переваривают PDF-ы. В любом случае получить то или иное представление документа можно было всего одной командой, без шаманства, как с DocBook-ом ;)

В качестве редактора LaTeX-овских документов я использовал ViM. Хотя есть и специально заточенные под LaTeX редакторы, которыми некоторые мои подчиненные пользовались. Но я предпочитал все делать в ViM-е, и специальных плагинов для LaTeX-а не ставил, хватало того, что ViM умеет "из коробки".

Из-за того, что я пользовался ViM-ом, вопрос автоматической проверки орфографии в документации я не решил. Впрочем, и не решал :) Обычно я сам вычитываю то, что пишу в документации, по нескольку раз. И часть опечаток нахожу сам. Если же была возможность, то отдавал документацию коллегам на корректуру. И таким образом выявлялось много больше ошибок, в том числе и те, которые автоматической проверкой не обнаруживались (например, я часто пишу правильные слова но не в согласованных падежах, что пропускается автоматическими проверяльщиками, но замечается людьми).

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

В целом, я уверен, выбор LaTeX-а себя оправдал.

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

Нет совершенно никаких проблем с совместным редактированием находящихся под контролем Svn tex-файлов. Это же обычный текст, который мержится не хуже каких-либо других исходников. В самом начале серьезного внедрения LaTeX-а мы совместно с Димой Косточкой работали над одним объемным документом, состоящим из нескольких больших tex-файлов. Тогда часто бывало, что Дима дописывает что-то в конец очередного tex-файла, а я при этом делаю правки в начале этого же файла. По сравнении с Word-ом это были совсем другие ощущения.

Есть, конечно, и свои сложности. Например, если нужно оформить LaTeX-овский документ так же, как какой-нибудь Word-овский. Тут потребуются более серьезные знания тонкостей LaTeX-а, его настроек и дополнительных пакетов. Не так просто вставляются в текст растровые картинки. Большие таблички требуют большего геморроя, чем в Word-е. С другой стороны, есть и свои плюшки. В первую очередь это возможность задавать свои макрокоманды. Например, захотел я, чтобы теги конфигурационных файлов (которые у нас задаются в фигурных скобках), выделялись в тексте курсивом, определил макрокоманду \CfgTagInBrackets. После чего в тексте имена всех тегов указывал посредством этой команды. Если со временем вместо курсива нужно было бы сделать полужирный шрифт, то текст перелопачивать бы не пришлось, нужно было бы всего лишь изменить определение макрокоманды \CfgTagInBrackets в прологе документа. В этот же список плюшек идет и поддержка списка литературы. А так же наличие дополнительных пакетов, например, таких, как listings, который позволяет красиво форматировать фрагменты исходного кода.

В LaTeX-е я набрал много документации. Думаю, что не ошибусь, если скажу, что счет давно перевалил за тысячу страниц, а может и не одну. Из публично доступных образцов моего "литературного творчества" могу упомянуть учебник по SObjectizer-4 (плюс не законченное описание построенных над ним фреймворков) и первый, еще русскоязычный вариант описания Mxx_ru (который затем был любезно переведен на английский язык Михаилом Лёсиным). Да и самую лучшую свою статью, Ruby-новые грани, для RSDN-а я так же писал изначально в LaTeX-е. Но намного больше моего текста осталось в документации внутри Интервэйла.

Подводя итог могу сказать, что если нет жесткой любви к WYSIWYG и автоматической проверки орфографии, то LaTeX может стать отличным инструментом для написания документации. Связываться же с DocBook-ом сейчас вообще вряд ли есть смысл, имхо, интерес к нему уже совсем не такой, как лет 10 назад. Так что стой я сейчас перед выбором системы для написания документации, то с большой вероятностью вновь выбрал бы LaTeX (или ConTeXt).

PS. Кстати, для написания совсем маленьких статеек с последующей конвертацией в HTML можно воспользоваться такой штукой, как reStructuredText (который относится к категории легковесных языков разметки текста). Я им пользовался, действительно удобно. Для маленьких текстов :)

[work.idiotic] У какого специалиста может быть такой список навыков?

Наиболее привлекшие мое внимание:

AJAX, Translation, SQL, JIRA, Electronic Payments, Project Management, Localization, Subversion, Software Development, Payment Systems, Android, Mobile Commerce, Requirements Analysis, Software Project Management

Итак, специалист в какой области деятельности указал эти термины в списке своих навыков? Ответ под катом.

среда, 26 июня 2013 г.

[prog.flame] И снова gandjustas! :) На это раз про оптимизацию программ и кластеры

Впервые за довольно долгое время заглянул в RSDN-овский форум "Философия программирования". Оказывается, народ еще активно срется на тему C++ vs Managed (JVM, .NET + все остальное). Надо же, ничего не меняется :) Попробовал почитать. Вначале было забавно, немного поностальгировал. Но быстро надоело, появилась досада на бессмысленно убиваемое время. Но тут в списке авторов ответов промелькнуло имя gandjustas... С надеждой щелкнул на первое сообщение начатой им ветки обсуждения и не разочаровался, gandjustas все еще торт!

Кластер нужен как минимум для отказоустойчивости. Надежность в серверных приложениях нужна гораздо больше оптимальности. Дешевле добавить память, диск, процессор, чем оптимизировать программу. Для примера представь что серверу для работы на всю компанию нужно 16гб оперативки. Есть всего восемь. Вариант — оптимизировать приложение, два месяца работы, два месяца исправления багов, при ЗП в 100к — 400к + упущенная выгода + административные расходы. Добавить 8гб памяти — 5к + день работы.

Когда-то, давным-давно, меня просветили, что есть два типа масштабирования приложений:

  • вертикальное, когда повышение производительности приложения достигается путем обновления железа: добавление памяти, установка более мощного процессора, более быстрых жестких дисков и т.д.;
  • горизонтальное, когда повышение производительности приложение достигается путем добавления новых машин в кластер, на котором развернуто приложение *.

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

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

Прошу простить мне мой сарказм, но я себе слабо представляю, как можно решать проблемы масштабирования, не занимаясь на этапе проектирования приложения вопросами разделения работы между вычислительными ресурсами и контролем их загруженности. Да и вопросы отказоустойчивости, в зависимости от предметной области, могут требовать выбора тех или иных подходов на самых ранних этапах проектирования, как, например, обеспечение отказоустойчивости платежного приложения, выполняющего списание финансовых средств. И тут уже расчеты будут совсем другие, нежели "5k RUR + день работы" **.

BTW, high performance cluster вовсе не обязательно дает хоть какую-то отказоустойчивость (см. HPC хотя бы в Wikipedia). А high availability cluster вовсе не обязан обеспечивать высокую производительность (см. HA cluster там же). Но это уже совсем-совсем другая тема для разговора, в которой и я сам не чувствую себя достаточно компетентным.


* В принципе, для некластерных (например, десктопных) приложений так же может быть возможно горизонтальное масштабирование посредством замены процессора, если новый процессор имеет больше вычислительных ядер и приложение умеет эти ядра загружать, разделяя свою работу между ними. Это относится не только процессору, но и к другим типам ресурсов: жестким дискам, сетевым картам, подключенным к машине внешним устройствам (вроде GSM-модемов, PC/SC-ридеров, HSM-модулей и пр.) Т.е. в более широком смысле горизонтальное масштабирование для приложения -- это умение приложения разделять свою работу между всеми поступающими в его распоряжение ресурсами и, за счет этого, возможность увеличения производительности приложения за счет предоставления ему дополнительных ресурсов.

** Хотя эффективные менеджеры могут все.

вторник, 25 июня 2013 г.

[life.photo] Фото с соревнований по спортивному лову рыбы фидером

В комментариях к посту "Рыбалка и рыбаки в самом центре Гомеля" Екатерина Суднеко подсказала, что в Гомеле 21-23 июня 2013 проходят соревнования по рыбной ловле. Оказалось, что это соревнования по спортивному лову рыбы фидером "Кубок Гомеля". В воскресенье, 23-го июня, наведался туда с фотоаппаратом. Было очень интересно. Отснял почти 700 кадров, оставил порядка 170. Часть из них, с небольшими комментариями можно увидеть под катом. Для самых же нетерпеливых вот слайдшоу из альбома с фотографиями:

понедельник, 24 июня 2013 г.

[life.photo] Рыбнадзор

Вчера, по наводке Екатерины Суднеко, посмотрел на соревнования по спортивной рыбной ловле. Внушаить :) Фотографий сделал много, на их обработку потребуется время. А пока одна карточка в тему "надзора" над рыбаками:


80-200/2.8D 200mm, ISO 200, f=8, 1/1600

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

[work] Обновил свое резюме на LinkedIn

В статусе безработного есть свои положительные стороны, конечно, но сам по себе этот статус постоянно намекает на то, что от него нужно избавиться. И осознавая, что рано или поздно новую работу искать все равно придется, кое-как собрался с мыслями и обновил свое резюме на LinkedIn: http://www.linkedin.com/in/eao197.

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

Теперь передо мной стоит самая серьезная проблема: определиться с тем, на какую должность/роль я сам себя позиционирую.

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

В общем, опыт экстремальный. И, как мне кажется, совершенно неподходящий для поиска руководящих должностей в крупных ИТ-шных компаниях (вроде крупных аутсорсеров вроде ЕПАма или iTransition). Там у разных типов руководителей есть своя специализация, своя "школа", свои жестко ограниченные рамки возможностей и ответственности. А это именно то, с чем я очень редко имел дело. И в КБСП, и в Интервэйле нужно было быть "мастером на все руки" и в этом я хорош. Но большим компаниям, с уже сложившейся и эффективно работающей организационной структурой, нужны классные специалисты узкого профиля, желательно с соответствующим опытом.

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

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

PS. Кстати, может кому-нибудь нужен руководитель разработки нового программного продукта? ;)