[life.comp] В России появился официальный день программиста!

Цитата с сайта Минкомсвязи РФ:

Президент России Дмитрий Медведев подписал 11 сентября указ, подготовленный Министерством связи и массовых коммуникаций Российской Федерации, который устанавливает в России новый официальный праздник – День программиста.

Согласно этому документу, День программиста будет праздноваться в России на 256-й день года – 13 сентября, а если год високосный – 12 сентября.

Вот так вот! Поздравляю российских программистов с наступающим праздником!

PS. Надеюсь, что российские программисты не бросят неофициальную традицию считать днем программиста любую пятницу 13-е ;)

[comp.prog.perfomance] Неплохая статья о подготовке к оптимизации программы

Статья The Three Stages of Preparation for Optimizing Parallel Software в Dr.Dobb. Хотя она, якобы, описывает стадии подготовки к оптимизации параллельного кода, ее рекомендации можно использовать и для оптимизации однопоточных программ.

На мой взгляд, большинство советов в ней – довольно банальные. Но некоторые весьма дельные. Как то:

Делайте подробные заметки. Записывайте все, что вы делаете с программой и зачем вы это делаете. Заметки, которые вы сделаете во время выполнения текущего проекта – это основа для базы знаний (даже если она неформальна), такая база может сделать ваш следующий проект более успешным. Эти заметки должны описывать такие открытия как, например, обнаруженные в генераторе нагрузки дефекты и способы их устранения.

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

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

PS. Хочу спросить читателей моего блога – нужно ли мне переводить англоязычные цитаты на русский язык? Сам-то я технический английский читаю довольно легко. Но может я напрасно требую этого же от своих читателей?

[comp.concurrency] Части Apple-вского GCD доступны под OpenSource лицензией

Из описания libdispatch:

The libdispatch project consists of the user space implementation of the Grand Central Dispatch API as seen in Mac OS X version 10.6 Snow Leopard. The Mac OS X kernel support for GCD may be found in the xnu project. While kernel support provides many performance optimizations on Mac OS X, it is not strictly required for portability to other platforms. However, in order to implement the full API for Grand Central Dispatch, C compiler support for blocks is required. The blocks runtime is available as part of the LLVM project.

This project is intended to be a resource for developers interested in learning more about libdispatch on Mac OS X. Contributions to this project will be continually evaluated for possible inclusion in future releases of Mac OS X. The sources are available under the terms of the Apache License, Version 2.0 in the hope that they might serve as a launching point for porting GCD to other platforms.

Подробнее об GCD я писал чуть раньше.

PS. Такое впечатление, что Apple у себя использует clang от LLVM.

[comp.internet] Голубиная почта быстрее электронной

В ЮАР провели небольшое соревнование по передаче 4Gb данных на расстояние в ~100км и почтовый голубь оказался быстрее Интернета.

PS. Не удивлюсь, если с текущими тарифами на Интернет у БелТелекома голубиная почта в Белоруссии окажется и быстрее, и дешевле Интернета. Например, мой безлимитный тариф с 256kbps в обе стороны обходится мне в 60000BYR (~675RUR). Тогда как в Москве у Стрима за 620RUR можно получить 4096kpbs входящего и 768kbps исходящего трафика.

[life.photo] Открыл для себя WSJ Pictures of the Day

Оказывается, на сайте The Wall Street Journal есть раздел Pictures of the Day, в котором публикуются потрясающие фотографии.

Вот несколько из них:

[comp] Плакат для пользователей Sun от Oracle - IBM-окапец?

Ждем-с ассиметричного ответа от IBM? ;)

[comp.prog.benchmark] Реализация chameneos-redux от Дмитрия Вьюкова порвала всех на Computer Language Benchmark Game

Вот сравнительная таблица результатов: http://shootout.alioth.debian.org/u32q/benchmark.php?test=chameneosredux&lang=all
Результат в 0.72 секунды, когда ближайший конкурент показывает 4.59 – это мощно!

А вот сама программа: http://shootout.alioth.debian.org/u32q/benchmark.php?test=chameneosredux&lang=gcc&id=5

Мои поздравления Дмитрию (aka remark)!

Update: Дмитрий подготовил подробное описание того, что именно он сделал в своей реализации этого теста.

[comp.history.my] ViM, Ruby, Mxx_ru – пять лет в пути! Часть вторая: ViM

Продолжение. Первую часть см.здесь.

Итак, для перехода под HP NonStop мне довелось сменить Mxx4 на Mxx_ru. Но это была самая легкая смена инструмента. Гораздо сложнее оказалось сменить текстовый редактор. Ведь работать с NonStop-ом приходилось удаленно, через ssh, по медленному каналу, в текстовом режиме, без каких-либо X-ов. Так что выбор был небольшим – либо встроенный в Midnight Commander редактор (годный разве что для самых простых операций), либо ViM, либо Emacs. Но начинать лучше издалека :)

Где-то до 1995-го года все было довольно просто. Сначала я пользовался Turbo Pascal-ем, затем Turbo C, затем Borland C++ 2.0. Потом довольно быстро перебрался под Multi-Edit (кажется, тогда 5-й версии). И так под ним и оставался, пока программировал в основном под DOS.

Но где-то с 95-го года ситуация сильно изменилась. На одной своей работе я программировал под OS/2 и продолжал пользоваться MultiEdit-ом. А на второй – работал под Windows и MultiEdit оказался не у дел, поскольку под DOS-ом кодировка была CP866, а нам нужна была Windows-1251. И под Windows я пользовался то слегка допиленным Notepad-ом, то редактором Far-а, то Visual Studio 4.2 (в VS был самый удобный редактор).

Потом, где-то в 2000-м, баловство с Windows и OS/2 отошло на второй план, а работать пришлось в OS-9000 в специально заточенном под нее варианте Emacs-а (кажется, это был uEmacs). Ну а с 2001-го года моей основной средой разработки опять стала Windows и выбор рабочего редактора продолжился с новой силой.

Пробовал я новый MultiEdit, кажется 10-й версии, уже полностью графический. Мне не понравилось. Показалось, что разработчики его просто убили, переведя в графику. Пробовал SourceInsight (который на меня произвел такое же сильное впечатление, как когда-то MultiEdit), TextPad, UltraEdit, ConTEXT, CrimsonEditor и еще какие-то редакторы, названия которых сейчас даже не вспомню. Дольше всего пользовался TextPad-ом и CrimsonEditor-ом.

Параллельно всей этой истории был Unix/Linux. Поскольку и сам пытался разбираться с программированием под Unix, и проекты под Unix приходилось выполнять. Но большого объема редактирования у меня в Unix-е не было. В основном, набирал тексты я под Windows, а под Unix-ом компилировался, тестировался, исправлял что-то по мелочи. Из редакторов использовал встроенный в Midnight Commander, его автономную (слегка мной допиленную) версию CoolEd и Kate (если была возможность работать в KDE). Пытался несколько раз осваивать Vi и Emacs, но надолго меня не хватало.

И вот мне, привыкшему к TextPad/CrimsonEditor/Kate предстоит что-то редактировать на фиг знает где стоящей машине, через ssh, по убитому каналу… В таких условиях даже встроенный в Midnight Commander редактор не помогал. Поэтому я решил сделать волевое усилие и освоить таки ViM или Emacs. Причем, чтобы получить нужный эффект, сделать это “по бразильской системе” – т.е. перейдя только на этот редактор даже под Windows.

По началу мне больше нравился Emacs – все-таки нет разных режимов работы редактора, да и опыт из uEmacs-а был. Но если под Unix-ами Emacs ставился без проблем, прямо из дистрибутива, то вот под Windows начались проблемы. Пробовал несколько разных портов Emacs-а для Windows и ни один из них у меня толком не заработал. Да и впечатления от обучения Emacs-у были неважные. Во-первых, болели пальцы рук от жутких клавиатурных сочетаний. Во-вторых, все эти клавиатурные сочетания никак не укладывались в моей голове в какую-то стройную и логичную схему.

Поэтому я собрался с духом и попробовал таки ViM. Кстати, совет для тех, кто начинает его изучать – сначала выучите, как из ViM выходить (ESC+:q или ESC+:qa!).

Так вот, попробовал я ViM. И мне понравилось! Сначала мне понравилось, что в нем можно комфортно работать по дохлому ssh каналу. И в этом как раз здорово помогает разделение на командный и прочие режимы. Затем, мне стало казаться, что в системе команд ViM есть какая-то логика (если заучить, что передвижение по тексту выполняется посредством клавиш hjkl). Потом мне стало нравиться, что набор текста напоминает программирование. Т.е. ты не столько пишешь программу, сколько программируешь ее написание. Потом я стал осваивать крутые возможности ViM-а по поиску/замене, по записи и воспроизведению действий, по запуску программ из ViM-а…

А потом, месяцев через 6-7 ежедневной работы в ViM-е, я случайно узнал, что ViM может держать в памяти сразу несколько файлов! :))) Ну тут уж жизнь уж окончательно наладилась.

В результате, вот уже пять лет я ежедневно использую ViM в качестве основного редактора для набора текстов программ и документации (в ReST и LaTeX форматах). И стараюсь больше пользоваться именно ViM-ом, поскольку в других редакторах (в Opera, в Windows Live Write/Zoundry Raven) мне очень не хватает привычных возможностей ViM-а.

Вот так я и стал Vim-ером. Пока не сильно продвинутым, т.к. лень заниматься его более подробным изучением и затачиванием под себя. А изучать есть чего. См.например, Best of VIM Tips – их автор говорит про себя: 15 Years of Vi + 7 years of Vim and still learning. Ну а я пока 5 years of Vim and still learning… Чего и вам желаю ;)

Happy Vimming!

[comp.history.my] ViM, Ruby, Mxx_ru – пять лет в пути! Часть первая: Mxx_ru

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

Итак, пять лет назад, в конце лета 2004 нам представилась возможность портировать часть своих программ на платформу HP NonStop. Чем мы решили воспользоваться. Но для этого мне пришлось пересмотреть несколько своих привычек и сменить несколько инструментов.

В первую очередь это затронуло систему сборки наших C++ проектов. До этого мы использовали мою систему сборки Mxx4 – проектные файлы записывались в виде небольших программ на своем собственном примитивном языке программирования. Mxx4 появился в 2001-м и к 2004-му я уже хотел заменить его на что-нибудь более мощное. И переход на NonStop как раз подтолкнул меня к этому. Я решил отказаться от собственного языка программирования в пользу какого-то готового скриптового языка и рассматривал Python, Perl, Tcl, c-smile и Ruby. В результате остановился на Ruby, т.к. его блоки кода были как раз очень удачной штукой для моих целей (и они используются в полный рост в проектных файлах Mxx_ru). В итоге, в августе-сентябре 2004 я написал Mxx_ru.

Первые пару лет Mxx_ru использовался только внутри нашей компании. Но в 2006-м произошло важное событие – со мной связался Михаил Лёсин и предложил свою помощь в развитии и продвижении Mxx_ru в виде OpenSource проекта. Так Mxx_ru появился на RubyForge. Пользуясь случаем, еще раз скажу Мише огромное спасибо за неоценимую помощь в переводе Mxx_ru и документации на английский язык, а так же за поддержку развития Mxx_ru. Благодаря Мишиной рекламе Mxx_ru используется в проекте CGRU, в следствии чего при помощи Тимура Хайрулина удалось портировать Mxx_ru под MacOS X.

Сейчас Mxx_ru продолжает активно использоваться у нас. Так же, судя по статистике RubyForge, некоторый интерес к Mxx_ru существует и вне нашей компании, а количество скачиваний постоянно растет. Совсем недавно я обрадовался тому, что было загружено 1400 копий Mxx_ru, не прошло немного времени – и сегодня статистика говорит о 1557 скачиваниях. Хотя я и не знаю, кто и для чего использует Mxx_ru, но все равно спасибо! :)

Пока отмечу проекты, которые точно используют Mxx_ru:
SObjectizer
CGRU
FatRat

Маленькая просьба. Если вы используете Mxx_ru, то дайте мне знать – я включу название вашего проекта в свой список. А если у вас есть и аккаунт на Ohloh, то не сочтите за труд – включите себя в список пользователей Mxx_ru.

Но вернемся к 2004 году. Про Ruby тогда мало кто знал. Хотя язык был уже довольно распространенный. Впервые его название я увидел в FreeBSD 4.5 – там, помнится, какие-то управляющие штуки были на нем написаны. И, что самое важное, Ruby 1.6 уже был портирован на NonStop (а это не хухры-мухры, поскольку платформа уж очень специфическая и вся из себя Ынтырпрайзная). Разработка Ruby-On-Rails тогда только-только начиналась и шума вокруг Ruby не было вообще никакого. Помнится, на RSDN я был чуть ли не единственным человеком, который что-то рассказывал про Ruby.

Помимо того, что Ruby стал базой для Mxx_ru, сам язык Ruby прочно вошел в набор моих постоянно используемых инструментов. Построение отчетов и статистики, обработка log-файлов, различные утилиты для настройки и обслуживания программ на серверах, генерация C++ исходников из специализированных описаний, мелкие программки “на выброс” и тесты – все это отлично живет и работает на Ruby. Сейчас я даже не знаю, как мне удавалось без него обходится раньше. Так что – рекомендую! (Не нравится Ruby – можно взять Python. Ну или на крайний случай Perl или Tcl. Все равно все это одного поля ягоды).

Вот так вот. Партия сказала “Есть контакт!”, я начал есть контакт работать с NonStop-ом и получил в свое распоряжение два отличных инструмента – Ruby и Mxx_ru. Но это еще не все, т.к. обязательно нужно рассказать о подсаживании на иглу ViM-а. Так что продолжение следует…

PS. Если кому-то интересно, то я мог бы обновить историю возникновения и развития семейства Make++, к которому и принадлежит Mxx_ru.

[comp.prop] Просмотрел презентацию "Multicore Programming in Haskell Now!"

Просмотрел презентацию "Multicore Programming in Haskell Now!"...

Хотел бы сказать, что много думал, но не скажу :) Не с чего было много думать, поскольку Haskell-ем не владею, а общие замечания о распараллеливании и так понятны.

В начале улыбнула фраза: "Mature: 20 year code base, long term industrial use, massive library system". Ну тут либо я слишком недружелюбно настроен, либо Haskell-исты выдают желаемое за действительное. Но, сугубо имхо, промышленным использованием Haskell-я до сих пор не пахнет. Поскольку промышленное, в моем понимании -- это масштабы. Большие программы, большие коллективы, большое количество разработок. И, главное, ориентация на программистов-винтиков, которых можно быстро обучить и легко заменить. Есть все это для Haskell-я? Для C++ есть, для Java есть, для C#, даже для Python/Perl/Ruby и старого (не)доброго C это все есть.

Ну и в очередной раз убедился, что у математиков (а с Haskell-ем, по-моему, возятся в первую очередь сильные математики) своеобразное чувство прекрасного. Например, оператор для параллельного выполнения нужно обозвать не как-нибудь, а `par` (именно в кавычках). Обязательно нужно придумать новый синтаксис для data parallelism: [: e :], ну и функции для параллельной обработки данных нужно обозвать именно mapP, sumP, zipP, foldP (поскольку parallel_map, parallel_sum и т.д. -- это оскорбляет их тонкое эстетическое чувство). Да, и в примере нужно было объявить функцию sumsq. Видимо, это специальный IQ-тест на отсеивание нежелательных читателей. С Haskell-ем должны работать только те, кто сразу поймут, что это название обозначает сумму квадратов. А такие чайники, как я, которые ожидают увидеть название вида sumSquares, из-за скудоумия не должны к Haskell-ю допускаться под страхом смертной казни. Ибо сказано "Avoid Success At Any Cost!"

PS. Давно уже пришел к выводу, что математики могут писать либо очень понятные и простые, либо очень непонятные и запутанные программы. Среднего не дано. Причем, по моим субъективным наблюдениям, пишущих нечитабельные программы математиков гораздо больше...

[comp.prog] Проектирование – моя самая нелюбимая часть разработки ПО

Точно знаю, что у многих программистов самая нелюбимая часть разработки – это написание документации. А вот у меня самая нелюбимая стадия – проектирование (хотя я знаю, по крайней мере одного человека, для которого проектирование является самой любимой частью разработки). Почему так?

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

Бывает, идем с ней приводить в порядок ее комнату перед сном – а там последствия двух Мировых Войн вместе взятых! Книги, карандаши, фломастеры, обрезки бумаги, краски, куклы, ленточки, резиночки, ниточки, тряпочки… И все это повсюду, вперемешку, в самых невообразимых сочетаниях…

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

Вот так же и с проектированием. Нужно написать вот такую программу. Какую именно? А вот такую. Ага, а вот с этим что делать? А вот с этим? А вот тогда что должно быть? Так, ладно, с требованиями типа понятно… Типа понятно… Да, я уже, вроде понял… Но вот тут что должно быть? Да уж, скромненький такой набор пожеланий собирается… Ну ладно, а как их воплотить? Что если так? А можно и вот так! Можно, только что лучше? Вот так, наверное… А почему? Ну хорошо, пусть будет так… А ведь еще можно вот так. Да, так даже лучше! Бля! Блин! Если так, то вот здесь не связывается… Лады, тогда здесь пусть будет вот так, а вот здесь мы поступим вот так… ПиздеОпаньки, опять засада… Нужно думать… Думай! Думай… Что? Как работа идет? Да нормально идет, проектированием занимаюсь. Да, через неделю, наверное, будет какой-то более-менее реалистичный макет… Думай! Думай!… Блин, послезавтра я обещался макет (долбоегений, однако, кто тебя за язык тянул!)… А может вот так? А потом вот так. А здесь вот так. О, вроде сходится. Да, точно сходится! ОхуеПошла, пошла родимая! Так, теперь вот это… Потом вот это… Сейчас вот это… Может пора уже начать писать? Нет, нужно еще вот это решить. Решаю… Решаю… Решаю… Вроде получилось. Может начинаем писать? Можно, наверное, но нужно еще вот это продумать… Думаю… Что-то придумал, можно сделать вот так. Да, так и сделаем! Ну что можно начинать писать? Дай прикинуть: это есть, это есть, это связали, это утрясли, это впихнули… Ну вроде можно начинать… Или нет? А если вот так? Вроде покрасивше будет. Да, так будет лучше, но нужно будет вот это чуть изменить. И вот это… Ага, и здесь чуть подправить… Или лучше так? БляБлин, перфекционист хуехренов! Хватит уже думать – месяц уже каракули на бумажках корябаешь, хватит! Трясти пора! Ладно, вот это выкидываем и вот так делаем. Погнали!

И все это для того, чтобы через пару недель и несколько тысяч строк отлаженного кода воскликнуть: “Ёптыть! АрхитЭктор, мать, мать, мать! А вот здесь нам что делать прикажете? Как же можно было об этом не подумать!”

PS. Если говорить серьезно, то я убедился на своем опыте, что чем больше сил вложено в проектирование, тем быстрее и проще идет процесс программирования (и даже отладки). И, наверное, я больше склонен к использованию “водопадной модели”, чем “экстремального программирования”, хотя без фанатизма. Но в любом случае, стадия проектирования тяжела тем, что из хаотичного множества совершенно разных мыслей и идей нужно выстроить жизнеспособную строгую модель, которая должна будет пройти суровую проверку. И вот эта необходимость упорядочения, помноженная на ответственность, делает проектирование моей самой нелюбимой частью разработки.

PPS. Заметка написана под впечатлением от выброшенного накануне очередного варианта проекта программы.

[life.wow] Груши в форме будды и домик из Lego

Квадратные арбузы уже дело привычное, но вот груши-будды – это что-то:

(отсюда, там же есть и другие удивительной формы фрукты-овощи).

Говорят, что самое страшное, что может произойти с человеком – это исполнение его заветной мечты. Вот, товарищ собирается таки построить себе настоящий дом из конструктора Lego:

Остается пожелать ему удачи :)

[life.rest] BuckyBalls - красота в умелых руках