Программирование

Сегодня меня порадовали, дескать подписка на комментарии в твоем блоге не работает.

Действительно, на ряде записей ссылка "подписаться на комментарии к этой записи по RSS" была битая, вела на несуществующий фид.

Разбирательство показало, что:

• Это касается только записей, где последняя буква (буквы) в title - непечатная (мягкий-твердый знак или знаки препинания). Эти символы дирифицируются в подчеркивание.
• Сами такие записи имели URL вида date/bla_bla_.html (фиды: bla_bla_.xml).
• Ссылки из списков записей (по месяцам, по рубрикам) были правильными.
• А вот ссылки, сформированные через <$MTEntryBaseName$> вели на bla_bla.html.

Засучив рукава, я полез читать исходники MovableType и мне открылось страшное.

К MT3 был отдельный плагин nofollow, который приписывал атрибут rel=nofollow ко всем ссылкам в комментариях.

В четвертой версии эта функциональность есть прямо в самом движке. Ее несколько расширили, в частности в комментарях от доверенных комментаторов можно такую функциональность выключить (и тем их поощрить).

Естественно, о российских реалиях и теге <noindex> в SixApart не знают. Прилагаемый

патч

решает эту проблему. На глаз - работает.

P.S. Если вы не знаете что такое "патч", то он вам не нужен

Голосом зануды:
MovableType 4.x. Казалось бы, давно имеем систему Widget Set, можно собрать сайдбар из этих самых виджетов мышкой и разместить в блоге. Прекрасная штука, была еще в 3-й версии.
Однако в 4-й версии про них явно забыли и включаемые элементы настраиваются переменными (по сути, дефайнами) в шапке страницы. Как-то так:

<MTSetVar name="sidebar" value="1">
<MTSetVar name="module_recent_entries" value="1">
<MTSetVar name="module_category_archives" value="1">

Ну скажите пожалуйста, если widget set - это плохо, то нафига для них отдельный пункт меню завели ? При этом, естественно, набор переменных новых темплейтов в документации не описан, несмотря на то, что одно из ключевых Release Notes у четверки озвучено как Kick-ass documentation. Впрочем, если kick-ass переводить буквально, то ощущение от документации сходится. Попробуйте там найти что-нибудь действительно нетривиальное....

MT-Colorer. Кажется прекрасной заменой для кривого, косого и т.п MTCodeBeautifier-а (который, извините уже непонятно как скачать, хорошо что в заначке был).
Но он тянет за собой ports/devel/colorer, который в свою очередь хочет принести все известные ему библиотеки и компиляторы java, после чего все ломается. Видите-ли JDK 1.4 не собирается GCC 4.2, а у меня это, пардон, системный компилятор (FreeBSD-current) и другого тут не носят.

Эх, хорошо что я незлобивый. Другой бы давно всех убил, один бы остался. (С) Успенский, близко к тексту.

После десятка экспериментов на кошках, была отработана (и проделана на данном блоге) процедура апгрейда на Movable Type 4.x с третьей версии. В общих чертах она совпадает с рекомендованой авторами MT4, хотя имеются, конечно, и всякие локальные отклонения.

В пошаговом виде процедура выглядит так: После десятка экспериментов на кошках, была отработана (и проделана на данном блоге) процедура апгрейда на Movable Type 4.x с третьей версии. В общих чертах она совпадает с рекомендованой авторами MT4, хотя имеются, конечно, и всякие локальные отклонения.

В пошаговом виде процедура выглядит так:

Разработчики MovableType, судя по всему, предполагают, что вся работа с темплейтами должна происходить внутри интерфейса системы. В ряде сортов колбасы потребности, очевидно, нет. В частности, нет способов сделать:

• backup/restore только темплейтов;
• использование темплейтов одного блога для другого;
• редактирование внешним редактором, а не встроенным уебибожеством.

Понятно, что разработчики плагинов в стороне не остались и Mark Carey предлагает готовое решение в виде плагинов Template Exporter и Template Installer. Есть правда одна закавыка, Installer бесплатен для некоммерческого использования, а вот за Exporter автор хочет $97.

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

Это, естественно, для инсталляции MT на PostgreSQL. C MySQL я практически не знаком, но уверен что средства побэкапить-поресторить табличку есть и там. Для переноса Archive Mapping нужно таскать табличку mt_templatemap. Конечно, мы неявно предполагаем что:

• blog_id на двух инсталляциях совпадает
• нужно перенести все темплейты всех блогов.

Естественно, для чуть более сложной задачи: экспортировать не все, а только для одного блога, экспортировать в файлы (и импортировать из них) придется попрограммировать. На первый взгляд, экспорт в формате, пригодном для импорта через Template Installer должен уложиться строчек в 20.

Вердикт после попытки пару часов поработать: глюкало. Пусть сначала 4.2 выпустят, потом поговорим

Посмотрел на 4-й Movable Type с точки зрения "апгрейдиться или нет".
Впечатления двойственные:

• Очень красивая новая панель управления, кнопочки, все мигает и переливается.
• Появился бэкап (как я понимаю, полный), а не только экспорт.
• Переделана система темплейтов, явно учли мои замечания :).
• Есть готовый плагин для кросспоста в ЖЖ, не такой уродский, как используемый мной MTLJpost. Немножко недоделаный, имя аккаунта не видно где должно, но пользоваться можно.
• Preview - настоящие. Наконец то!
• апгрейд на тестовой площадке прошел на ура.

Попробовал проапгрейдить тестовую площадку....

В University of Illinois at Urbana, куда я чуть было не уехал заниматься геологией 15 лет назад, в настоящее время читается курс ECE 498 AL : Programming Massively Parallel Microprocessors.

Опуская обычные охи "ну почему этому не учат на ВМК" - все в наших руках и я думаю, что через пару лет такие курсы будут и у нас, тема вкусная - хочу обратить внимание на слайды и транскрипты лекций, доступные вот тут. Читают приглашенные лекторы из NVidia, поэтому основное внимание уделено, сюрприз, NVidia 8800. Курс включает в себя лабы, которые сделаны очень интересно: есть готовая рыба, делающая подготовительную работу (I/O, печать результаты) и студент должен только написать несколько десятков-сотен строк изучаемой функциональности. Что, конечно, экономит кучу непроизводительного времени (смотреть тут)

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

Нравится, как практику, подробный разбор аппаратуры. Вылезает множество подробностей, которые нигде не опубликованы.

Вот о подробностях - ниже.

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

Из общих соображений, понятно что самая медленная часть суперкомпьютера - память. С одной стороны, теоретическая пропускная способность (bandwidth) составляет 900MHz * 384 бита * 2 (DDR) = 86.4 GB/sec. С другой стороны, раздел 6.1.1.3 руководства говорит о 200-300 циклах memory latency (при, по всей видимости,случайном доступе).

К счастью, проблема легко изучается: если взять достаточно много данных (скажем, полгигабайта) и, например, сложить все 4-байтовые значения (как float), то основные затраты времени будут именно на чтение из памяти, а всей прочей арифметикой можно пренебречь (или подсчитать ее отдельно).

Экспериментально выяснилось, что содержимое shared memory не сохраняется между запусками кода на G80. Всякий раз оно инициализировано, причем значения разные, то 10 (float), то 125.

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