the blog is moved..

..here: http://highcat-en.blogspot.com

Development: rate amount of work you've done

Just have realized that I subconsciously wrongly rate amount of work I've done.

<sorry, no translation yet>

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

А вот и нет.
Сейчас пишу один проектик, в котором по сути 2 формы ввода. На одну из форм я уже потратил около 10 часов. Функционала, казалось бы, не так уж много, соответственно, и работы должно быть мало, и пользы для юзера. Но ключевой момент в том, что этой форму юзер будет пользоваться 80% времени от всей работы с программным продуктом. Следовательно, если она будет криво написана – ему будет тяжело работать. Если она написана нормально, но нет удобных подсказок, сложность выполнения самых частых операций не будет минимизирована - ему будет тяжело работать. Соответственно, мой вклад был недостаточно большим.

Следовательно, количество моей работы должно цениваться не только "в ширину" (т.е. количество фич в проекте), но одновременно и в "глубину" – проработанность одной конкретной фичи, её качество.

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

1. Сделать форму AAA: значение поля XXX проверяется по внешней системе YYY, поля XXX1 - в системе YYY1, поля XXX2 - в системе YYY2, поля XXX2 и XXX1 должны быть совместимы, поля ZZZ1, ZZZ2, ZZZ3, ZZZ4 должны быть совместимы


2. Сделать форму BBB: поле XXX должно провериться по значению AAA в базе.


3. Вывод выборки DDD: фильтр по XXX, YYY, ZZZ. Настраиваемый фильтр по DDD, EEE. Ajax-подсказки по фильтру EEE по существующим значениям

– наглядно, что на задачу 1 нужно больше времени чем на остальные, а на 2 больше чем на 1.

Пока мысль не довёл до конца, но подумаю на досуге о целесообразности такой "системы управления проектами для визуалов/сенсориков".

Dictionary for Openmoko

Few mounths ago I started to write a dictionary application specially for Openmoko/Neo Freerunner. StarDict dictionary format is it's base (few pieces of code is stolen from StarDict for dictionary pasing).

As Openmoko is full-featured Linux, there is a chance just to recompile StarDict, and get it working on the phone. I decided to write (almost) own implementation, because of the following:

1. GUI for mobile phone should differ from desktop's GUI. For example, this pdf-reader for Openmoko is actually a desktop application, just recompiled for ARM. Its GUI is not too convenient with small displays.
   


2. I like mobile dictionary to be fast and lightweight - it should start quickly - and work quickly, for example, in a foreign trip. GTK+ library is quite slow, as for me. So, I use (my favorite) FLTK2 for the interface.


3. I want special educational features: at least - word lists for remembering, later - text base, live pronunciation base, images, etc, in which you can find associations with words and phrases. Possibly - some kind of customizable language learning plan. The idea is to be able to learn languages when you have a bit of free time - in transport, subway, just by taking your FreeRunner from your pocket.


4. There is a selfish motive - to upgratde my own development level, to learn new instruments. (So, don't be scared, when you'll look at the code =) )

I've already implemented the following:

• Application skeleton (main architecture, considering all future features)


• Dictionary parsing, using a bit of StarDict code


• GUI - main panels, controls, tuning specially for small-screen, slow graphics mobile systems.




• Build for Openmoko (including FLTK2 and Boost libraries)

The app. interface based on screens, by functions. Switching between screens using buttons at bottom. The prototype looks like this:



First screen - word list (searching by first letters of fuzzy query).
Second - and main - word translation. Text can be scrolled by finger.
Third - bookmarks (your favorite word lists)
Fourth - text reader (optional)
Fith - settings. On the screnshot there is a list of loaded dictionaries, you can change translation order, switch on and off dictionaries.

Interface is finger-friendly. Side panel in lists (see bookmarks and settings) may be hidden. The button 'T' at the middle means translation of the word you selected in bookmarks or word lists, or you typed in input box at the second panel.

Feature list for the nearest releases:

• StarDict dictionaries, auto-scanning specified directories for dictionaries.


• Word searching by first letters, 'fuzzy query'.


• Clipboard-awareness, automatic clipboard translation (select word - switch to buffer - get translation)


• Pronunciation from wav-files (possibly, not in the first release)


• Word lists for remembering


• Simple text reader with word/phrase searching, tags and notes (optional).


• Complete configuration through GUI: font sizes, dictionary order, etc

Implementation: С++, Boost, FLTK2 (with few patches), some code from StarDict (requires glib and zlib).

I'm going to represent sources and binaries, when first beta version will be ready, presumably at the beginning of july. I think, i'll create also opkg-packets for available StarDict dictionaries.

I'll be glad to know your opinion:

• Do you need a dictionary for Openmoko?


• Are you interested in educational functions, or some other additional functions?


• Any suggestions about interface?

FLTK2: Win, Lin & Mac

Here are screenshots of my program, compiled for three popular platforms. The program makes amusing patterns, calculated by formula, which can be passed to application at run-time. Program is written in C++ with FLTK2 GUI library. Here is the link: www.fltk.org. FLTK (new version is FLTK2) is small in size, has good internal design, ported to different platforms. It also shows very good performance. Widget drawing is fast, because it's performing by means of native system API for each platform: - WinAPI/Xlib/Carbon.

Screenshots:

Linux:

Mac OS X:

Windows:



Second version of the library - FLTK2 - is in development state, actually. But, you can use it. Version for Mac is buggy yet (it's alpha) - you can see a button with corrupted size at screenshot. But, while moving from FLTK to FLTK2 I've discovered that most inconvenient features has been changed exactly like I desired =) So, FLTK2 is cool.

All we need is Music!

So. If we need to play music in real-time, to make your own genius software synthesizer sound using your keyboard, midi-keyboard, midi-didgeridoo, theremin, or ruler with a pick-up and ltp-port connection, we can't treat this with general tools.

We need a very small delay time, i.e. low latency.

In Linux we have Jack system for this purpose. And it's amazing. You can get something like 1.33 milliseconds with common build-in sound card. And it's simple to implement.

Those who don't like Linux, will use Windows.
And at Windows we have to use Steinberg's ASIO specification.

(We can also use PortAudio, but it seems not to support Jack fully for now.)


I've tried to build a standart sample from ASIO SDK. With GCC + MinGW. It even compiles =). And runs. But then it hangs.

GCC + MS Platform SDK. Hangs.
MSVC + MS Platform SDK. Works.

What I've found out: ASIO driver can work only with programs, built by MSVC, because it uses MSVC calls specification ("thiscall" for C++). Other compilers use their own implementation, so those binaries are incompatible.

Portaudio, which supports ASIO, uses a special workaround.
It's a wrapper, which imitates MSVC thiscalls for ASIO: http://www.audiomulch.com/~rossb/code/calliasio/. It's written mostly in asm.

I'm in doubt, if this wrapper will update in time, and if it suppors x86_64 architecture. So, better we don't deal with assembler. Better compile it with MSVC.


By the way - it's well-known issue with C++ for Win. Binary interface (ABI) for C is open, so pure C libraries can be linked with any code.

Microsoft's C++ ABI is proprietary. So, you have to compile your applications with MSVC, to link useful third-party libraries.

Multilingual blog?: initial

So, for now blogger doesn't have any convenient feature for different languages support. This blog contains messages from http://highcat-land.blogspot.com which I decided to translate to English. If you find any grammatical mistakes in it, pls tell me. ;)