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

Я фотографии заливаю на свой сайт вручную, каталогизирую по событиям, а вот имена файлов переименовываю в md5-хеши автоматически. Специально для этого я написал такой вот скрипт. Он берёт список файлов в виде аргументов, запускает по ним цикл, считает md5-хеш файла и переименовывает файл в посчитанный хеш, оставляя расширение.

#!/bin/sh

for i in $*
do
   mv $i "`md5 -q $i 2>/dev/null`.`echo $i | awk -F . '{print $NF}'`" 2>/dev/null || echo "$i not found!" 1>&2
done

К примеру, выполнение команды "./md5rename IMG_8666.jpg" приводит к переименованию файла IMG_8666.jpg в 3c6616c9a4b182ea536c8890b57445a2.jpg. Если файл не существует, скрипт жалуется на его отсутсвие. Для запуска скрипта потребуется bash, который есть в любой Unix-like операционке.

P.S. вот за это я и люблю свой Mac — полноценный Unix и отсутствие геморроя как с Linux'ом.

Посмотрим, что из этого выйдет. Пока только играюсь. Да, в рабочее время, кстати. И никто мне ничего не скажет, так как libcurl мне в текущем проекте нужен, а сервера пока нет. Так почему бы фото в Twitpic не слать через их API? libcurl под ARM собрался. Прототип на PC заработал. Осталось на камере испытать и придумать этому какое-нибудь применение. Есть идеи?

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


Фильтрую, избавляюсь от помех, поворачиваю с билинейной интерполяцией, вырезаю дисплей, далее adaptive thresholding (отлично знаю, что это такое, но как это по-русски будет — понятия не имею), распознаю цифры, сохраняю в локальной базе данных на всякий случай и отсылаю куда надо, где показания складируются, а потом просматриваются через веб-интерфейс. И всё это работает на встраиваемом Линуксе внутри вот этой беспроводной сетевой камеры.


И написано всё это на чистом Си без каких-либо библиотек. Память, байты, алгоритмы... Нет, я не извращенец с нуля изобретать велосипед, я честно попытался собрать OpenCV под архитектуру ARM, которая хоть и не поддерживается официально, но собрать под неё урезанную версию можно. Только вот как оказалось, в последней прошивке камеры слишком старая uClibc, под которую OpenCV не собирается. Так что пришлось написать свой собственный Embedded Image Processing Toolkit без каких-либо зависимостей. Это вам не быдло-PHP! :)

Теперь не только предложения заканчиваю точкой с запятой, а ещё бросаю предложения на середине, дабы хорошенько их обдумать, либо исправить что-то в предыдущем параграфе. Ладно бы просто бросал, но я их почему-то пытаюсь закомментить двумя слешами, дабы незаконченное предложение не влияло на целостность всего текста! :D Доктор, это лечится?

Свершилось! Qt теперь распространяется на условиях LGPL, а не как раньше по GPL, что мешало линоковаться к тулкиту не-GPL софту, разработчикам которого оставалось только покупать коммерческую лицензию, стоимость которой измерялась в тысячах долларов США. Слава Nokia! Для них продажа лицензий — капля в море, продвижение платформы гораздо важнее. Хорошо, что они это осознают. Я был уверен, рано или поздно это произойдёт. Не зря же они порт под Symbian и Maemo затеяли. Среди мобильных платформ конкуренция гораздо жёстче и постоянно обостряется, бывшие условия лицензии Qt многих разработчиков коммерческих приложений просто бы отпугнули.

Как и отпугивает разработчиков невероятно сложная платформа Symbian с вагоном недостатков из-за своего наследия. Но под Symbian портировали STL, а затем Qt, который теперь ещё LGPL. И устройства с тачскринами наконец-то появились. Да и всю систему в опенсорс хотят отдать, так что моё мнение о платформе, которое было испорчено когда-то необходимостью под неё писать, что весьма сомнительное удовольствие, теперь меняется в лучшую сторону. Nokia N97 — довольно интересное устройство. Надо будет ещё пощупать и обзоры почитать, но я всё больше и больше склоняюсь в сторону покупки именно его.

Вот, собственно, сама новость: http://www.qtsoftware.com/about/news/lgpl-license-option-added-to-qt

Дело было вечером, делать было нечего.




Под Адвантеки, кстати, писать гораздо приятнее, чем под Фениксы, которые ещё к тому же срабатывают через раз.

Upd: кстати, у каждого канала при включении и выключении звук разной высоты. Можно попробовать мелодию какую-нибудь сыграть.

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

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

Да и список областей применения впечатляет:

• Video Decode/Encode
• Audio Decode/Encode
• JPEG/JPEG2000
• Data Compression
• Cryptography – CAVP Validated!
• Speech Coding
• Speech Recognition
• Image Processing
• Image Color Conversion
• Computer Vision
• Signal Processing
• Vector/Matrix Mathematics
• String Processing
• Data Integrity(new!)
• Ray Tracing/Rendering

Для всего этого есть все необходимые функции. Похоже, стоит всё-таки не IPP перейти. Лицензия стоит 200 баксов всего.

Решил тут посмотреть что за зверь.

Standard C/C++ developers get access to Open C++ (STL, IOStreams, and Boost libraries) as standard platform features.

Свершилось! Nokia наконец-то поняла, что недружелюбность платформы для разработчиков и нестандартный диалект C++ всё-таки большой минус для платформы, как бы ни лояльны к ней не были пользователи за счёт популярности устройств на ней работающих, разработчиков чем-то всё-таки надо привлекать, а не отпугивать 1,5 тысячами скудно документированных классов и очень сложным устройством операционной системы. С портом недавно купленной Qt, я думаю, писать под платформу станет ещё проще.

Ещё бы пересмотрели политику лицензирования Qt для коммерческих приложений.

Оказывается, виндовый сервис перезапустить сам себя не может. Он может себя остановить, но без посторонней помощи запуститься уже не сможет. Начал копать и искать обходные пути. Докопался до динамической компиляции кода в память при помощи CSharpCodeProvider и исполнения этого кода из памяти. Только вот код исполняется из того же процесса (на сколько я понял), что не есть хорошо, так как ни чем мне в этом случае не помогает. Начал копать дальше и искать аналог *nix-ового fork(). Докопался до CreateProcess() и тут ко мне пришло озарение. Написал отдельный исполняемый файл в несколько строчек, в котором инициализирую контроллер сервиса, потом его останавливаю, жду остановки и запускаю. Из самого же сервиса запускаю исполняемый файл отдельным процессом при помощи класса Process. Всё работает замечательно.

Продолжаю тихо ненавидить Symbain за

- глючный эмулятор, который работает через раз
- SDK, который в проекте прописывает абсолютные пути
- скудную документацию с краткими описаниями классов
- за совершенно странное и порой нелогичное поведение ОС
- за наследие EPOC и устаревший взгляд на многие вещи
- за нестандартный диалект C++

Вся система тянет за собой наследие операционной системы для устройств начала 90-х. Буквально всё в ней нацелено на производительность на маломощном железе неимоверно усложняя жизнь разработчика под это платформу. И что я вижу на конечных девайсах? Тормоза! Дикие тормоза! Windows Mobile так не тормозит порой, который, кстати, урезанная версия настольной винды с тем же WinAPI.

Дедлайн 30-ого. Нифига не успеваю.

Типограф обзавёлся предпросмотром и сохранением настроек в конфигурационной базе GConf.

Брать здесь, если кому-то кроме меня ещё нужен: http://dmitry.fi/code/typograph/typograph-0.2.tar.gz.

Искал способ поиска доступных remoting-сервисов в сети, ничего толкового не нашёл. Посмотрел на майкрософтовский UPnP, потом на эппловский Bonjour. С первым разбираться лень, со вторым опыт есть, когда я ещё в лабе работал, отлавливал сетевые камеры в сети при помощи кода, основанного на Avahi. Но то было под ucLinux, а сейчас я, к сожалению, пишу под Винду, портировать под которую Avahi тоже не вариант. Посмотрел на SSDP и по его подобию придумал RSDP, Remoting Service Discovery Protocol и реализовал его в виде библиотеки. Задействовал мультикастинг по такому же принципу как и SSDP, все сервера подписываются на сообщения по определённому адресу, а клиенты по этому адресу высылают запросы, только поиск ведётся по типам, точнее по их уникальным идентификаторам. Сервер, на котором данный объект доступен, отправляет клиенту его URL (к примеру, tcp:\\server42:8189\RemotableObject.rem), по которому клиент может получить прокси на удалённый объект и работать с ним как с локальным. Таким образом адреса других серверов, клиентов и прочих членов распределённой системы могут быть заранее им неизвестны, кому кто нужен, те найдутся.

Когда-нибудь, я напишу подробные статьи про все свои разработки. Наверное, после диплома, так как всё это и так будет его частью.

Поковырялся в Mono и Gtk#, наваял клиента для арт.лебедевского типографа дабы упростить и ускорить процесс типографирования текста перед публикацией. Тарбол взять можно здесь: http://dmitry.fi/code/typograph/typograph-0.1.tar.gz. Устанавливается он следующим образом:

wget http://dmitry.fi/code/typograph/typograph-0.1.tar.gz
tar xvf typograph-0.1.tar.gz
cd typograph-0.1
./configure
make
sudo make install

После чего ярлык «Типографа» появляется в меню в разделе «Интернет»:


Можно пользоваться.

Выглядят не очень симпатично в отличии от Gtk#-приложений, которые от нативных ничем не отличаются, зато работают. Все компоненты проверять не стал, но разработчики утверждают, что Mono 2.0 их все полностью поддерживает. Поддержка тем пока ещё в разработке.

Вот-вот только что, 6-ое же уже наступило. Нигде пока ни слова, случайно наткнулся на новые исходники. В release notes пишут о полной поддержки виндовых форм. Если нет вызовов виндового API, то любое .Net-приложение должно работать под Mono без проблем. Попробую. Исходники уже качаются.

События в дотнете — задумка хорошая, довольно упрощает реализацию шаблона «наблюдатель», но в ремоутинге реализованы они через одно место. Оповещения рассылаются по очереди, что уже не есть хорошо, но что гораздо хуже, так это то, что из-за умершего и не отписавшегося клиента возникает исключение где-то во внутренностях фреймворка, которые так тщательно скрываются от пользователя, из-за чего все последующие подписчики оповещения о событии не получат. Если же событие пометить атрибутом «OneWay», то ответ клиента будет проигнорирован, но умерший клиент никогда не будет удалён из списка получателей, что равнозначно утечки памяти.

MSDN считает делегаты и события небезопасными и рекомендует использовать их только при общении между процессами по каналу IPC с аутентификацией. Единственный верный способ — обратный вызов подписавшихся клиентов, но стандартных средств для упрощения данного процесса нет. Начал искать решение и наткнулся на статью на CodeProject про события и ремоутинг. Решение в статье работает, но использует оно не стандартные каналы, а Genuine Channels из одноимённой библиотеки, которую автор предлагает у него купить. Купить, конечно, было бы проще всего, тем более у этих каналов нет многих недостатков стандартных каналов ремоутинга, но весь проект использует именно их, да и нафиг надо за стопесят баксов за лицензию.

Написал свой диспетчер событий для .Net Remoting. Клиент подписывается на события сервера, сервер добавляет клиента в список получателей и при возникновении события на сервере при помощи трэд пула рассылает события по списку всем клиентам одновременно. Умершие клиенты из списка удаляются. Клиент получает сообщение о событии на сервере и вызывает соответствующее локальное событие. Пытался вызывать метод у клиента асинхронно, но как оказалось, асинхронно метод вызывается только в случае если клиент жив. Если клиент мёртв, вызывающий трэд всё равно блокируется на время таймаута (говорят, в версии 3.0 пофиксили, но я пишу под 2.0) и последующие клиенты получают событие с задержкой. Задействовал трэд пул и синхронный вызов, благо этот паттерн в дотнете реализуется тоже элементарно, всё как по маслу. Надо бы статью на CodeProject.com написать.

Если захостить remotable-объект в виндовом сервисе, сделать его singleton'ом, в интерфейсе объявить два OneWay-метода, вызвать их один за другим из клиента, то второй метод на сервере просто не вызовется, если есть другие методы, вызываемые синхронно. Непонятно почему. Даже если другие методы вынести в отдельный интерфейс и в отдельный remotable-объект, то всё равно не помогает. Если между вызовами методов вставить небольшую задержку, милисекунд так 10, то второй иногда вызывается, а иногда нет. Если сделать задержку больше, то второй вызывается. Если вызывать синхронно, то второй вызывается. Даже если не обращаться ко второму объекту, то всё равно не вызывается, а если его закомментить полностью на стороне сервера и в интерфейсе, то вызывается. Асинхронно один за другим вызывать не хочется, да и нет смысла, так как методы ничего не возвращают и OneWay для них самое то. SingleCall тоже не вариант, так как читать конфиг и коннектиться к базе данных при каждом вызове метода нет смысла, да и состояние необходимо хранить в классе.

Очень странно .Net себя ведёт порой. Может быть, я что-то не понимаю? Может, кто-нибудь знает, в чём проблема?

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

Надоело постоянное копирования и ручное отслеживание версий. Команда небольшая, но с ростом проекта и постоянным дроблением его на более мелкие части сетевыми папками уже не обойтись. Начал искать решение. Team Foundation Server от Microsoft стоит 2799 баксов + лицензии по 499 баксов за клиентов. Пошли они нафиг, обойдёмся опенсорсом. Из мира опенсорса первыми кандидатами стали Subversion и Trac, их и поставил. Мне бы сервак полноценный в руки, но пока только сисадминю на домашней машине и на виртуальном сервере на работе. Поставил не него Федору в самом минимальном её варианте, с CentOS не захотелось связываться, хоть он и больше для энетерпрайзов подходит, но времени разбираться особо нет.

Поставил на неё SVN, Apache, Python, mod_python и на всё это Trac, инструмент управления проектами и отслеживания ошибок в программном обеспечении. Нашёл плагин для интеграции его в Visual Studio, будем теперь раздавать друг другу тикеты. Ещё бы SVN как-нибудь бесплатно интегрировать в Visual Studio, а то за VisualSVN денег просят. Хотя, я думаю, TortoiseSVN, расширением оболочки Windows, обойдёмся. Ещё в Trac есть Wiki, из которой можно ссылаться на тикеты, майлстоны и на все остальные фичи, так что буду пробовать приучать народ писать в ней внутреннюю документацию, тем более при помощи плагина это можно делать из самой Visual Studio.

Общая библиотека интерфейсов, XML-конфигурационный файл и две строчки кода. Всё, распределённая система готова, с объектами можно обращаться как с локальными даже не задумываясь о том, что на самом деле общаешься с прозрачным прокси. Да простят меня сторонники опен сорса и ненавистники Microsoft, но более удобной имплементации RPC я не встречал.

Upd: да возрадуются сторонники опен сорса, Mono вроде поддерживает Remoting. Сам не проверял, но пишут, что работает.

Пока не появились Они... Баги! Кто угадает что за вещество на картинке?