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

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

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

Собственно, задача такова. Есть, к примеру, на форме два PictureBox'а: pictureBox1 и pictureBox2. Перерисовали pictureBox1 методом Invalidate(), pictureBox2 тоже должен перерисоваться, только перерисовавать его должен не pictureBox1, так как о существовании pictureBox2 он знать не должен, pictureBox2 должен сам заметить, что pictureBox1 перерисовался и перерисовать самого себя. PictureBox'ов на форме может быть много и все должны перерисоваться, когда перересуется клавный pictureBox1. Как это сделать?

Решил я это так. Расширил класс PictureBox, назвал его, к примеру, SubPictureBox, добавил к нему такой метод:

MainInvalidated(object sender, InvalidateEventArgs e)
{
    Invalidate();
}

Где-то в коде pictureBox1 и pictureBox2 объявлены следующим образом:

PictureBox pictureBox1;
SubPictureBox pictureBox2;

Далее к событию Invalidated компонента pictureBox1 присоединил метод из компонента pictureBox2:

pictureBox1.Invalidated += new InvalidateEventHandler(pictureBox2.MainInvalidated);

Теперь когда перерисовывается pictureBox1, все экземпляры класса SubPictureBox, подсоединённые к событию Invalidated экземпляров класса PictureBox, перерисовываются автоматически.

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

Symbian - это просто ужос! В наши дни эта операционная система работает на достаточно мощных процессорах со сравнительно большим объёмом памяти, но продолжает тянуть за собой наследие EPOC, операционной системы для мобильных устройств, разработанной в конце восьмидесятых и работающей на карманных компьютерах Psion девяностых годов прошлого столетия.

Система объектно-ориентирована и основной язык программирования для неё C++, но программисту на C++ начинающему программировать под Symbian лучше забыть всё то, что он знал ранее и начинать учиться с нуля. Потому что для программирования Symbian используется нестандартная реализация C++ и собственные приёмы, вроде файлового сервера для работы с файлами, дескрипторы для работы с памятью, отсутствие исключений, cleanup stack, из-за которого программисту приходится вручную делать то, что за него должен делать компилятор и т.д. Всё это располагается в тысяче с лишним классов, запомнить которые просто невозможно. STL естественно отсутствует.

Уже которую неделю бьюсь с этим Симбианом и тихо его ненавижу. В следующим году будет ещё хуже. Второй курс и проект по этой ОСи.

Более подробно и с примерами: http://www.codeproject.com/KB/mobil...ign_faults.aspx

А вот этим я занимаюсь в последнее время. Вот такой вот список контактов для The Mana World:



C вот такой вот иконкой в трее и с вот такими вот оповещениями:



Осталось дописать несколько фишек. Надеюсь, потеряю интерес после того, как закончу.

Написал на Питоне фотоальбом, используя mod_python. Заценить можно здесь: http://pupukarhu.info. Какое счастье не зависеть от настроек сервера хостера! Канал бы только пошире, да компьютер по-мощнее.

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

Готово! Работает! Моей радости нет предела. Сделал программно-аппаратный комплекс "сигнализация" при помощи сетевых камер Axis 207W, компьютера под управлением Linux и программного обеспечения собственной разработки. Сетевые камеры втыкаются в сеть, получают IP-адрес по DHCP и начинают слушать mDNS-запросы. Программа под Linux ищет в сети сервисы "_axis-video._tcp.local", рассылая DNS-SD запросы, на которые камеры отвечают. Программа получает доменные имена, IP-адреса, названия камер и порты, на которых сервис предоставляется. Далее программа подключается к камерам и начинает получать изображения. Изображения декодируются и сравниваются. Если замечает движение, начинает пищать. В принципе, можно научить делать что угодно: слать смски, электронную почту, звонить и т.д. Но пока только пищит. Теперь надо всё это дело запустить на плате с Blackfin-процессором под управлением uClinux и сделать систему автономной с возможностью удалённой настройки.

Wi-Fi пульт управления MPlayer'ом для Windows Mobile.

Клиент Сервер

http://mcontrol.dmitry.fi/
Открываем фильм командой mControl movie.avi, открываем клиент на КПК, выходим в сеть, в настройках вводим адрес компьютера и порт (по умолчанию 31337) и управляем, тыкая пальцем в экран или по кнопкам КПК. Протокола пока нет, но планируется. Также планируется нахождение компьютера при помощи mDNS, отображение времени проигрывания и ползунка, составление списков воспроизведения, поддержка скинов и других проигрывателей. А пока и этого хватает, чтобы каждый раз не вставать с дивана.

Простые программы интерпретирует без проблем, всё работает как надо, а вот программы побольше, например "99 бутылок", либо зацикливаются, либо делают что-то не то. Странно, вложенные циклы работают без проблем, как только не тестировал, так и не могу отловить, что же все-таки не так работает.

Upd: кое-что исправил. Доходит до 91-ой бутылки и застревает. Надо искать, чего там такого хитрого в алгоритме, что зацикливает мой интерпретатор. Не думал, что будет столько проблем с таким элементарным языком. Рекурсивный алгоритм был бы куда проще, только вот пользоваться приходится итераторами текстового буфера.

Два проекта в универе ещё далеки от завершения, но вдохновение меня покинуло. Вместо того, чтобы писать по делу, пишу Grainfuck, IDE (если хватит терпения) и интерпретатор brainfuck для GNOME. Уже что-то есть. Ещё бы возможность код трейсить, просматривая состояние памяти, и экспорт в разные языки или в бинарники. Под Windows полно сред разработки для brainfuck, под *nix не нашёл ни одной. Приходится пользоваться bfdev из-под wine, под которым, он кстати, чувствует себя замечательно. Но хочется чего-то родного. Надеюсь, что-то из этого выйдет.