[prog.flame] Антиреклама: haskell-исты ищут C#-пера!

Поскольку я любитель бросать камни в огород продавцов волшебных пилюль адептов функциональщины, то не могу пройти мимо объявления о вакансии: Нам в команду требуется программист пользовательского интерфейса на C#.

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

1. Функциональное программирование вообще и язык Haskell в частности такие все из себя серебряные пули, ну такие серебряные, что программировать пользовательский интерфейс нужно на C#.

2. Ынтылигэнтные люди о деньгах не говорят, поэтому в работе главное, чтобы ее было много, она была интересная и чтобы была возможность прикоснуться к великому поработать вместе с Зефировым и Шабановым. Поэтому в объявлении о работе вилку зарплат указывать нельзя.

Товарищи функциональные евангелисты! Вы пишите, пишите статьи, рассказывайте как в ФП все классно и насколько ФП облегчает труд программиста по сравнению с ООП и т.д. Все это очень интересно, особенно когда вы открываете вакансии для C# разработчиков.

[life.business] Вот так нас и накалывают

Если не удается понять, в чем состоит наколка, загляните под кат.

[life.humour.black] Не могу не перепостить две замечательные эпитафии

Пишу практически из-под стола, куда сполз после просмотра вот этого:

Найдено в “Блоге добрых психиатров”.

[life.flame] Иногда бывает тяжело понять написанное очень умным человеком

В ЖЖ известного хаскелиста Сергея Зефирова (aka thesz) появился призыв к написанию статей в журнал “Практика функционального программирования”. Меня в этом призыве зацепила фраза:

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

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

Однако стоит перечитать эту фразу вдумчиво. На написание статьи уходит по три-четыре часа в один выходной. Требуется три выходных. Уже три недели. Плюс “еще столько же на рецензии и столько же на корректуру”. Итого 9 недель – два месяца по календарю.

Я вынужден признать, что прочитал исходную фразу не внимательно.

Но, что же мне не нравится?

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

Чтобы пояснить то, о чем я говорю, я приведу свой вариант обсуждаемой фразы:

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

Читатели могут сами сделать вывод о том, в каком из вариантов оценка календарных сроков проще.

PS. Я специально употребил выражение “неосознанно пишут так”. Осознано это делается, например, в трюках с мелким шрифтом. Когда в рекламном объявлении или тексте контракта крупно прописывается “Вы вкладываете 2 доллара и через два месяца получаете 4 доллара”, а потом следует уточняющая приписка мелким шрифтом “Наша комиссия составляет 3 доллара”.

[life.photo] И я тоже сфотографировал кактус

Вчера Слава Костин у себя в блоге опубликовал фотографии цветущего кактуса, а сегодня и мне повезло сфотографировал кактус. С тремя цветами. Это чудо расцвело у моей мамы. Она попросила сфотографировать на память.

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

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

Более менее получились фотографии, снятые крупным планом, в основном в режиме макро:

В общем, фотограф из меня никакой. Но, как говорит мой друг – когда есть красивый пейзаж, почему бы его не снять? ;) Вот я и снял, поскольку было очень красиво.

[prog.flame] Попрограммировал на Java, делюсь впечатлениями. Часть VI. Форматирование кода и Javadoc.

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

Часть I
Часть II
Часть III
Часть IV
Часть V

Никогда больше я не слышал таких жарких споров вокруг соглашений о форматировании кода, чем у Java-программистов. Люди с пеной у рта спорят не только о том, стоит ли использовать какие-нибудь префиксы/суффиксы для полей класса, и даже не о том, стоит ли открывающую фигурную скобку переносить на новую строку. Спорят о том, сколько пробелов должно быть в табуляции и на сколько пробелов нужно делать отступ при: a) переносе длинного выражения, b) переносе параметров при вызове метода, c) при декларировании методов с большим количеством параметров и т.д.

Самое смешное, что все эти горячие споры действительно имеют смысл. Поскольку IDE настолько умные, что могут переформатировать код по своему разумению. И если ты в свою IDE загружаешь чужой код и случайно его переформатируешь, то чужой исходник оказывается полностью перекроенным. Что затем скажется на мержинге изменений из разных веток от разных программистов.

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

class Demo    {    public void    doSomeAction(          ActionContext ctx,          ActionParams actionParams,          Logger logger)       throws IllegalArgumentException       {          WorkingContext workingCtx = makeWorkingContext                ( ctx.getCurrentUser().getFullContextParams()                , logger );          doActionInsideWorkingContext                ( wokingCtx                , actionParams );       }    }

то это никого не волнует. Не соответствуют ваши предпочтения рекомендованным Sun-ом соглашениям – идете в сад и засуньте свои фантазии сами найдете куда.

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

Так же и в Java – нет у меня права расставлять пробелы и переносы так, как я привык. И это сильно напрягает.

До маразма можно дойти в любом языке и я слышал о C++ных проектах, в которых были просто-напросто драконовские Gode Style Guide – чуть ли не на 250-300 страниц. Но как раз дело в том, что в C/C++ – это эпизодические явления. Тогда как в Java, благодаря как IDE, так и самой ориентации на взаимозаменяемость программистов, ситуация доведена до крайности.

Ну и напоследок о штуке, которая меня всегда в Java раздражала. Это правила документирования параметров метода в Javadoc. В Java все параметры должны быть описаны в комментарии, предшествующем методу:

class Demo    {    /**     * Демонстрационный метод, который типа делает что-то.     *     * Данный комментарий должен продемонстрировать правила офомления     * документации для параметров методов в Javadoc.     *     * @param ctx Контекст, на котором воображаемая операция     *            должна выполняться.     * @param actionParams Параметры воображаемой операции.     * @param logger Интерфейс для журнализации выполняемых действий.     */    public void    doSomeAction(          ActionContext ctx,          ActionParams actionParams,          Logger logger)       throws IllegalArgumentException       {

Мне не нравится то, что список параметров дублируется – он есть и в Javadoc комментарии, и в декларации метода. Нафига? Мне не понятно.

В свое время, когда я выбирал средство для документирования C++ кода, я специально остановился на Doxygen, поскольку он позволял писать комментарий к параметру метода прямо перед декларацией этого параметра:

class Demo    {    /**     * Демонстрационный метод, который типа делает что-то.     *     * Данный комментарий должен продемонстрировать правила офомления     * документации для параметров методов в Doxygen.     */    public void    doSomeAction(       /// Контекст, на котором воображаемая операция должна выполняться.       ActionContext & ctx,       /// Параметры воображаемой операции.        ActionParams & actionParams,       /// Интерфейс для журнализации выполняемых действий.       Logger & logger)       {

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

Итого. Двойственные впечатления оставляет Java. С одной стороны, очень примитивный и многословный язык, в котором развернуться особо-то и не где. С другой стороны он безопасный, программировать на нем просто, изучать его просто, за время его существования его чуть подрихтовали, сделали помощнее, поприятнее местами. Плюс к нему разработали очень мощные инструменты. Что, в результате, сделало программирование на Java более приятным занятием, чем можно было ожидать.

Так что понятно, почему Java стал мейнстримом. Но лично мне по-прежнему хочется держаться от Java подальше.

[prog.bugs] Проблема с настройками proxy в kpackagekit из Kubuntu 9.04

Столкнулся с очередным неприятным глюком в Kubuntu 9.04. В последний раз я использовал kpackagekit из офиса, поэтому включал параметры прокси. Сегодня пытался воспользоваться kpackagekit из дому и настройки прокси отключил. Но kpackagekit все равно упорно лез в Инет через прокси. Заставить его перестать так делать удалось только отредактирововав файл .kde/share/config/kioslaverc – настройки прокси оказались прописанными в нем.

Решение проблемы было найдено здесь.

[prog] Ура, заработала! Нашел-таки злобную багу!

Вот как только появилось спокойное время разобраться с проблемой поведения ACE-вского реактора после рестарта SObjetizer Run-Time, так и решение нашлось :)

Ларчик, как водится, открывался просто. Для завершения реакторного цикла обработки событий нужно было вызывать метод end_reactor_event_loop. Вот я его и вызывал. А затем, при рестарте SObjectizer-а новый цикл обработки событий не стартовал из-за булевского признака, который выставлял end_reactor_event_loop. Достаточно было вызвать reset_reactor_event_loop чтобы все заработало.

Она как! Ошибка тупая и глупая, зато сколько удовольствия от ее исправления – не передать! :)))

Теперь нужно найти время и выкатить очередной патч для SObjectizer 4.4.0-b6…

PS. Кстати это ошибка из разряда тех, которые элементарно отлавливаются пошаговой отладкой.

[prog.flame] Попрограммировал на Java, делюсь впечатлениями. Часть V. IDE

Нашлось время для очередной заметки о впечатлениях после программирования на Java. Предыдущие части здесь:

Часть I
Часть II
Часть III
Часть IV

Сегодня речь пойдет о впечатлениях о работе в IDE. Сразу скажу, я использовал NetBeans 6.8. Как говорят, это не самая продвинутая Java IDE, поэтому в ней невозможно прочувствовать “всю мощу” современных IDE для Java. Пусть и так. Насколько я могу предполагать, более умная IDE вызвала бы у меня еще большее неприятие.

Первое впечатление. IDE для Java действительно сильно упрощают программирование на Java. Слишком уж Java тупой и многословный язык, чтобы писать все вручную. Здесь помощь от IDE очень в тему. Так что если есть нужда писать именно на Java, то нужно иметь очень серьезные доводы, чтобы не пользоваться IDE.

Второе впечатление. IDE для Java превращает процесс программирования в диалог с компьютером. Начал писать вызов метода, спросил у IDE его точное имя – компьютер тебе его подсказал (либо вообще сделал это без твоей просьбы). Сделал вызов – компьютер тебе подсказывает, что не все исключения из этого метода ты обрабатываешь. И тут же сам у тебя спрашивает – добавить ли эти исключения в секцию throws или обернуть вызов try-catch-ем?

Так что, в какой-то степени, работа в Java IDE напоминает парное программирование. Только общаться нужно не с коллегой, а с IDE.

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

Например, поскольку у меня уже есть код методов и я знаю, что и как делает каждый метод, то хотел бы написать Javadoc комментарий сразу. Но тут выясняется, что продвинутая Java IDE ничего не может предложить мне в помощь. Поскольку она расчитана на то, что Javadoc строится по уже написанному методу. Поэтому приходится либо все самому делать внутри нового комментария, либо же сначала сделать рыбу метода, затем попросить IDE сгенерировать Javadoc, затем его подправить, а потом вернуться к написанию кода.

Имхо, когда Javadoc пишется после кода метода – это неправильный в принципе подход. Комментарии должны писаться перед кодом. Не можешь написать комментарий – значит ты еще не готов написать код.

Еще одна штука, которая сильно тормозила набор кода – автоматическая подстановка параметров при вызове методов. Т.е. если в текущем контексте есть одна переменна a типа int, и переменная b типа String, и вызывается метод add(int key, string value), то после набора имени add и открытия скобочки IDE само напишет add(a,b). В ряде случаев это именно то, что нужно. Но, как оказалось, далеко не всегда. И когда случаются эти не всегда, то приходится править нагенерированный без моего ведома код. Плохо не столько то, что процесс набора текста программы прерывается. А то, что не всегда эту неправильность сразу замечаешь. Хорошо, что Unit-тесты выявляют такие ошибки.

Еще от набора текста отвлекают возникающие предупреждения (в виде загорающихся красным значков вокруг кода). Иногда они полезны – при опечатках или простых синтаксических ошибках. Иногда они бесполезны – я сам знаю, что еще нет метода с именем addIfNotExists, я напишу его буквально через 10 минут. Но мне уже предлагают определить данный метод.

Но самая главная причина замедления набора кода по бумажке – это мое собственное ожидание подсказок со стороны IDE. Т.е. быстро привыкаешь к тому, что IDE делает автодополнение. И ждешь его. А IDE ничего не делает. Поскольку код написан на бумаге и IDE не в состоянии подсмотреть туда и узнать, что метод addIfNotExists у меня есть. И что можно сделать автодополнение для него. :) Собственно, IDE здесь не причем – это исключительно моя заморочка. Но дело в том, что когда я пользуюсь gVim-ом, таких заморочек у меня нет.

Итого. Я не могу оценить, насколько IDE помогает при работе с большими проектами (например, насколько полезен браузер классов). Я не могу оценить, насколько IDE помогает при работе с какими-нибудь мейнстримовыми фреймворками (вроде автогенерации каких-нибудь описаний для Hibernate или Struts) – не знаю, далек от этого. Но из того, с чем сам столкнулся, я думаю, что тормоза придумали трусы умные IDE и пошаговые отладчики убивают качество программ. Имхо, чем больше программисту приходится делать самому, тем меньше он будет делать (а больше думать – по-идее, должно быть так). Следовательно, тем качественнее будет то, что он делает.

Но, думаю, отговаривать сейчас людей от использования IDE (тем более при программировании на Java) – это как мочиться плевать против ветра. Глобально ничего не изменится, а сам обоссаным оплеванным окажешься :)

[life.video] Как я конвертировал mkv (avc+dts) в avi (divx+ac3)

Есть у нас дома маленький старенький медиацентр от Sony. Кроме DVD он еще может проигрывать avi-файлы, записанные на DVD/CD болванках. Но, к сожалению, в avi-шках поддерживается только DivX для видео и MP3, AC-3 для аудио. Поэтому видеофайлы для воспроизведения на этом комбайне приходится перегонять в DivX.

Раньше я пользовался двумя программами: VirtualDub (когда нужно было из XviD-а в DivX перегонять) и Auto Gordian Knot (для преобразования DVD в DivX). Пробовал еще много всякой всячены, но добавил к себе в список инструментов только одну программулину под скромным названием SUPER. Последней я пользовался когда нужно было mkv файлы в avi преобразовывать.

Нужно сказать, что со временем SUPER стала основным инструментом. Как я понимаю, в ней используется два разных тулкита: ffmpeg и mencoder. При декодировании можно выбирать любой из них. Первый, как мне кажется, работает шустрее но временами ломается. Второй стабильнее, медленнее, но качественнее. По крайней мере mkv в avi с помощью mencoder-а пережимаются без проблем чаще, чем в ffmpeg-ом.

Так вот, потребовалось пережать большой mkv файл в avi. Желательно с максимальным качеством и с сохранением звука 5+1. С перепаковкой видео из AVC в DivX SUPER (посредством mencoder-а) справился без проблем. А вот со звуком, который был в DTS-е, возникли проблемы. Ни mencoder, ни ffmpeg сделать это нормально не смогли (либо процесс конвертации вообще не запускался, либо же звук оказывался записанным в avi-шку неправильно).

Пришлось искать решение. Что заняло некоторое время, поскольку в видео/аудио я полный дилетант и знаю разве что названия кодеков/форматов, но не более.

Для начала я нашел интересный обзор инструментов для конвертации видео/аудио. Попробовал iWisoft Free Video Converter, FormatFactory и Any Video Converter. Но не получилось. Либо программы не поддерживали конвертацию в DivX, либо же не позволяли для DivX-овой avi-шки задавать звук в AC-3, либо же ограничивали количество каналов для AC-3 всего двумя.

Кстати говоря, из всего этого набора больше всего мне понравился FormatFactory.

Попробовал так же AviDemux. Он так же не позволял конвертировать видео в DivX, а с преобразованием DTS в AC-3 не справлялся.

Вообще, у меня сложилось впечатление, что все эти бесплатные программы используют одни и те же сторонние наработки. Соответственно, если в какой-нибудь свободной AC-3 библиотеке есть баг, то он проявляется сразу во всех бесплатных перекодировщиках.

В общем, бесплатного GUI-инструмента для преобразования mkv (avc+dts) в avi (divx+ac3) несколькими кликами мышки я не нашел (вполне возможно, что таковые и есть, просто мне не попались в нужный момент). Пришлось искать иные способы. Коих сразу нашлось два и оба они построены на том, что звуковая дорожка в DTS-формате вырезается из файла, затем преобразуется в AC-3, и новая дорожка помещается в результирующий avi-файл.

Первый способ основывается на использовании transcode. Вроде бы нужно натравить transcode на DTS, получить 6 wav-файлов (по одному на каждую дорожку), затем через внешние утилиты (к примеру BeSweet/BeHappy) эти wav-файлы собираются в один AC-3 файл. Мне этот способ показался слишком муторным, поэтому я воспользовался вторым.

А второй способ заключается в использовании утилиты eac3to. Он оказался очень простым. Я запустил из командной строки “eac3to my.dts my.ac3” и все – утилитка сама проанализировала dts-файл, сделала два прохода по нему и создала нормальный ac3-файл на выходе. Как говорится, без шума и пыли.

Итого, что мне потребовалось:

• SUPER;
• eac3to;
• AviDemux.

Происходило все так:

1. С помощью SUPER я перегнал mkv-файл в avi-файл с преобразованием AVC в DivX и с сохранением исходной звуковой дорожки. Получился my-tmp.avi в котором лежали divx+dts.
2. С помощью AviDemux вырезал звуковую дорожку из my-tmp.avi и сохранил ее в my-tmp.dts.
3. С помощью eac3to преобразовал my-tmp.dts в my-tmp.ac3.
4. С помощью AviDemux создал из my-tmp.avi результирующий my-file.avi. Для этого я указал копировать видео поток из my-tmp.avi, а звуковой поток брать из внешнего файла my-tmp.ac3.

Вот и все.

Примечание. Вместо AviDemux здесь можно было бы использовать и VirtualDub. По крайней мере вырезать аудио поток из avi-шки VirtualDub может точно, я это проделывал. А вот может ли он вклеить AC-3 поток в avi-файл я не проверял.

Ну и раз уж пошла такая пьянка еще до кучи:

• В AviDemux есть интересная фича – он автоматом режет результирующий avi-файл на фрагменты ограниченного размера. Например, если на выходе я ожидал 7Gb avi, то получил два avi – первый на 4Gb, второй на 3Gb. Самое плохое в этом то, что AviDemux их странно обзывает: первый получается my-file.avi, а второй my-file.avi01, третий –my-file.avi02 и т.д. Приходится их затем вручную переименовывать.
• Есть такой мега-монстро-комбайн MediaCoder. Ставил его себе несколько раз, пробовал разные его версии. Но все время плевался и сносил нафиг. Какой-то он глючный, падает то и дело. Да и в настройках его хрен разберешься. В общем, когда я нашел SUPER, про MediaCoder я больше не вспоминал, хотя его часто упоминают как очень хороший перекодировщик.
• Насколько я смог понять, DTS в двухканальный AC-3 можно перегнать в foobar2000. Шестиканальный AC-3 у меня сделать не получилось, а вот 6-ти канальный wav-файл из DTS-а foobar2000 строит.
• Забавный эффект был в SUPER, когда я с помощью ffmpeg-а пытался конвертировать DTS в AC-3: началась конвертация довольно шустро, а вот затем… :) Затем работа шла, похоже, по принципу маляра Шлемиля – чем дальше ffmpeg уходил от начала файла, тем медленнее шла конвертация. И, когда я его прервал через сутки непрерывной работы, результирующий AC-3 поток оказался неправильным.

[life.photo] Фотографии Земли со спутников DigitalGlobe

Сегодня в рубрике “Знакомство с фотомастером” будут необычные фотографии – их снимал не конкретный фотограф, а спутники компании DigitalGlobe. Всю коллекцию доступных под лицензией Creative Commons фотографий можно увидеть на Flickr. Я же приведу у себя те, которые мне больше всего понравились.

Для начала несколько снимков, не связанных общей тематикой.

Myrtleford, Australia. Это последствия пожаров в Австралии. Красный цвет – это живые растения. А вот зеленый – выжженные участки.

Musudan-ri, North Korea. Запуск северокорейской ракеты.

Space Shuttle Endeavour on the launchpad - July 15, 2009. Шаттл на стартовой площадке.

Теперь несколько плотин:

Tucurui Dam, Brazil

Krasnoyarsk Hydroelectric Dam, Divnogorsk, Russia

Hoover Dam, Las Vegas, Nevada

Теперь городские пейзажи из космоса:

Piazza San Pietro, Vatican City, Rome, Italy

Octavio Frias de Okiveria Bridge, Sao Paulo, Brazil

Ferrari World, Abu Dhabi, UAE

SAN FRANCISCO, CALIFORNIA

TOKYO, JAPAN

SHANGHAI WORLD FINANCIAL CENTER, SHANGHAI, CHINA

А на закуску и в продолжение городских пейзажей – башни:

Eiffel Tower, Paris, France

Burj Khalifa Tower, Dubai, UAE

TAIPEI 101, TAIPEI, TAIWAN-MAY 30, 2009

Oriental Pearl Tower Shanghai, China - May 11 2009 QuickBird