среда, 9 мая 2012 г.
понедельник, 3 января 2011 г.
Разработка: оценка проделанной работы
Только сейчас допёрло, оказывается я подсознательно неверно оцениваю результаты своей работы как разработчика.
До этого момента я (подсознательно) думал что чем больше функционала я навернул, тем больше полезной работы (измеряемой в человеко-часах, или в тысячах рублей) я проделал.
А вот и нет.
Сейчас пишу один проектик, в котором по сути 2 формы ввода. На одну из форм я уже потратил около 10 часов. Функционала, казалось бы, не так уж много, соответственно, и работы должно быть мало, и пользы для юзера. Но ключевой момент в том, что этой форму юзер будет пользоваться 80% времени от всей работы с программным продуктом. Следовательно, если она будет криво написана – ему будет тяжело работать. Если она написана нормально, но нет удобных подсказок, сложность выполнения самых частых операций не будет минимизирована - ему будет тяжело работать. Соответственно, мой вклад был недостаточно большим.
Следовательно, количество работы должно оцениваться не только "в ширину" (т.е. количество фич в проекте), но одновременно и в "глубину" – проработанность одной конкретной фичи, её качество.
В связи с этим мысль:
как правило, работая над проектом, я держу перед глазами список тикетов (читай – фич), которые нужно выполнить. Возможно, вместо этого (или параллельно) стоит держать перед глазами аналогичный список use-кейсов? Так будет понятнее, какие моменты больше прорабатывать, а какие – меньше. Ещё заметил, что глядя на список подсознательно оцениваешь объём работ по количеству тикетов, а не по объёму каждого. Возможно, стоит попробовать систему списков, состоящую не просто из заголовков, а из кратких описаний тикета, где объём каждого описания визуально будет соответствовать объёму работы, которую нужно проделать. Можно организовать такое описание из множества заметок, например грубо вот так:
– наглядно, что на задачу 1 нужно больше времени чем на остальные, а на 2 больше чем на 1.
Пока мысль не довёл до конца, но подумаю на досуге о целесообразности такой "системы управления проектами для визуалов/сенсориков".
До этого момента я (подсознательно) думал что чем больше функционала я навернул, тем больше полезной работы (измеряемой в человеко-часах, или в тысячах рублей) я проделал.
А вот и нет.
Сейчас пишу один проектик, в котором по сути 2 формы ввода. На одну из форм я уже потратил около 10 часов. Функционала, казалось бы, не так уж много, соответственно, и работы должно быть мало, и пользы для юзера. Но ключевой момент в том, что этой форму юзер будет пользоваться 80% времени от всей работы с программным продуктом. Следовательно, если она будет криво написана – ему будет тяжело работать. Если она написана нормально, но нет удобных подсказок, сложность выполнения самых частых операций не будет минимизирована - ему будет тяжело работать. Соответственно, мой вклад был недостаточно большим.
Следовательно, количество работы должно оцениваться не только "в ширину" (т.е. количество фич в проекте), но одновременно и в "глубину" – проработанность одной конкретной фичи, её качество.
В связи с этим мысль:
как правило, работая над проектом, я держу перед глазами список тикетов (читай – фич), которые нужно выполнить. Возможно, вместо этого (или параллельно) стоит держать перед глазами аналогичный список use-кейсов? Так будет понятнее, какие моменты больше прорабатывать, а какие – меньше. Ещё заметил, что глядя на список подсознательно оцениваешь объём работ по количеству тикетов, а не по объёму каждого. Возможно, стоит попробовать систему списков, состоящую не просто из заголовков, а из кратких описаний тикета, где объём каждого описания визуально будет соответствовать объёму работы, которую нужно проделать. Можно организовать такое описание из множества заметок, например грубо вот так:
- Сделать форму AAA: значение поля XXX проверяется по внешней системе YYY, поля XXX1 - в системе YYY1, поля XXX2 - в системе YYY2, поля XXX2 и XXX1 должны быть совместимы, поля ZZZ1, ZZZ2, ZZZ3, ZZZ4 должны быть совместимы
- Сделать форму BBB: поле XXX должно провериться по значению AAA в базе.
- Вывод выборки DDD: фильтр по XXX, YYY, ZZZ. Настраиваемый фильтр по DDD, EEE. Ajax-подсказки по фильтру EEE по существующим значениям
– наглядно, что на задачу 1 нужно больше времени чем на остальные, а на 2 больше чем на 1.
Пока мысль не довёл до конца, но подумаю на досуге о целесообразности такой "системы управления проектами для визуалов/сенсориков".
четверг, 21 мая 2009 г.
Словарик для Openmoko
Уже несколько месяцев между делом пишу словарик для Openmoko/Neo Freerunner. За основу выбран формат словарей StarDict, оттуда же позаимствована часть кода для разбора словарей.
Так как Openmoko - это полноценный линукс, можно было бы просто перекомпилировать StarDict под него, и получить всю функциональность. Однако, я решил написать свою реализацию, потому что:
Я уже реализовал следующие вещи:
То есть уже можно запустить словарик на телефоне, скормить ему словари StarDict, попробовать перевести слово (вывод перевода - пока в виде простого текста).
Интерфейс - основан на экранах, разбитых по функциям. Переключаться можно кнопками снизу.
Пока это выглядит так:
Первый экран - список слов (поиск по первым буквам или fuzzy query).
Второй, он же главный - перевод слова. Окошко скроллируется пальцем.
Третий - букмарки (списки слов).
Четвертый - читалка текста (пока существование под вопросом).
Пятый - настройки. На скриншоте - список загруженных словарей, можно менять порядок, включать/отключать словари.
Кнопки сделаны под размер пальцев, все списки скроллируются. Боковую панель в списках (в букмарках и настройках) можно скрыть. Кнопка 'T' по середине - перевод слова, т.е. того, которое выделенно в букмарках и списках слов, или введено в поле на второй панели.
Cписок фич, которые планируется сделать:
Реализация: C++, Boost, FLTK2 (с патчами), немного кода из StarDict (требует glib и zlib).
Выкладывать пакеты и исходники буду когда проект достигнет более-менее рабочей стадии, предположительно к началу июля. Думаю, буду собирать opkg-пакеты для доступных StarDict-словариков.
Интересно мнение будущих пользователей:
Пишите!
Так как Openmoko - это полноценный линукс, можно было бы просто перекомпилировать StarDict под него, и получить всю функциональность. Однако, я решил написать свою реализацию, потому что:
- GUI приложения для телефона или коммуникатора должен быть другим, чем для десктопа. Например, pdf-ридером под Openmoko не очень удобно пользоваться, т.к. это десктопное приложение, просто перекомпилированное под ARM, GUI не рассчитан на маленький экран.
- Словарь для мобильного устройства должно быть быстрым и легковесным - быстро включаться и выключаться, например, если вы пользуетесь им в заграничной поездке. Интерфейсы на основе GTK+ (оригинальный StarDict), на мой взгляд, получаются тяжеловатыми, хочется сделать пошустрее. Для GUI я решил использовать свой любимый FLTK2.
- Хочу добавить в словарик специальные функции для обучения языкам: как минимум - списки слов для запоминания, как максимум - база текстов, записей произношения, картинок, ассоциированных со словами и фразами, напоминалки, возможность выстроить программу обучения. Фунции обучения будет удобно использовать между делом, например в транспорте, просто достав телефон из кармана.
- Есть цель повысить собственный девелоперский уровень, освоить новые инструменты. =)
Я уже реализовал следующие вещи:
- Архитектурный скелет приложения
- Прикрутил парсер словарей, взятый из StarDict
- GUI - основные панельки, элементы управления, мелкий тюнинг специально под мобильные девайсы.
- Рабочую сборка под Openmoko (включая FLTK, Boost)
То есть уже можно запустить словарик на телефоне, скормить ему словари StarDict, попробовать перевести слово (вывод перевода - пока в виде простого текста).
Интерфейс - основан на экранах, разбитых по функциям. Переключаться можно кнопками снизу.
Пока это выглядит так:
Первый экран - список слов (поиск по первым буквам или fuzzy query).
Второй, он же главный - перевод слова. Окошко скроллируется пальцем.
Третий - букмарки (списки слов).
Четвертый - читалка текста (пока существование под вопросом).
Пятый - настройки. На скриншоте - список загруженных словарей, можно менять порядок, включать/отключать словари.
Кнопки сделаны под размер пальцев, все списки скроллируются. Боковую панель в списках (в букмарках и настройках) можно скрыть. Кнопка 'T' по середине - перевод слова, т.е. того, которое выделенно в букмарках и списках слов, или введено в поле на второй панели.
Cписок фич, которые планируется сделать:
- Словарики формата StarDict, авто-сканирование директории со словарями
- Поиск по началу слова, fuzzy query
- Захват слова из буфера обмена (выделил - переключился в словарик - получил перевод)
- Произношение из звуковых файлов (вероятно, в первую версию не войдёт)
- Списки слов для запоминания
- Читалка простых текстов, с поиском слов по ним, тегами/заметками
- Подробная конфигурация через GUI: размер шрифтов, порядок использования словариков, etc
Реализация: C++, Boost, FLTK2 (с патчами), немного кода из StarDict (требует glib и zlib).
Выкладывать пакеты и исходники буду когда проект достигнет более-менее рабочей стадии, предположительно к началу июля. Думаю, буду собирать opkg-пакеты для доступных StarDict-словариков.
Интересно мнение будущих пользователей:
- Нужен ли вам словарик под Openmoko?
- Интересуют ли функции обучения, или ещё какие-то дополнительные функции словарика?
- Есть ли предложения по интерфейсу?
Пишите!
воскресенье, 28 сентября 2008 г.
Статья: NeoFreerunner overview
Недавно привезли NeoFreerunner - opensource/openhardware-смартфон. По этому поводу решил написать небольшой обзор по этому устройству. Вот он: http://highcat.by.ru/freerunner_overview/freerunner.html
вторник, 12 февраля 2008 г.
FLTK2: Win, Lin & Mac
Выкладываю скриншоты одной своей программы, скомпилированной под 3 популярные платформы. Программа рисует забавные узоры по формуле, которую можно вписать во время выполнения. Написана с использованием GUI библиотеки FLTK2: www.fltk.org. FLTK (новая версия FLTK2) отличается небольшим размером, хорошим дизайном, кроссплатформенностью и высокой производительностью. Виджеты рисуются нативными средствами каждой платформы - WinAPI/Xlib/Carbon, то есть скорость перерисовки максимальна.
Вот такие получились скриншоты:
Linux:
Mac OS X:
Windows:
Вторая версия библиотеки - FLTK2 - фактически ещё в стадии разработки. Однако, ей уже вполне можно пользоваться. Версия под Мак отстаёт от остальных - на на картинке можно увидеть баг - неправильный размер кнопки. Лично я при переходе на вторую версию обнаружил, что многие моменты, которые мне казались неудобными, были переделаны как раз так, как мне хотелось =)
Вот такие получились скриншоты:
Linux:
Mac OS X:
Windows:
Вторая версия библиотеки - FLTK2 - фактически ещё в стадии разработки. Однако, ей уже вполне можно пользоваться. Версия под Мак отстаёт от остальных - на на картинке можно увидеть баг - неправильный размер кнопки. Лично я при переходе на вторую версию обнаружил, что многие моменты, которые мне казались неудобными, были переделаны как раз так, как мне хотелось =)
четверг, 10 января 2008 г.
понедельник, 7 января 2008 г.
ASIO: All we need is Music!
Итак. Если мы хотим получить музыку в реальном времени, чтобы заставить играть собственноручно написанный гениальный программный синтезатор от клавиатуры, midi-клавиатуры, midi-диджериду, терменвокса или линейки со звукоснимателем, подключенным к lpt-порту, - простыми средствами нам не обойтись. Нужно быстрое время отклика, т.е. низкая латентность.
Под Lin у нас есть Jack. And it's amazing. 1.33 милисекунды задержки на встроенной звуковой карте получаются без проблем.
У кого нет Lin, придётся использовать Win.Под Win нам придётся использовать ASIO. На Portaudio пока забъём. (по определённым причинам)
.. Пытался скомпилировать стандартный пример из ASIO SDK. Хм. С помощью GCC + MinGW.
Хм. =). Даже собрался. Даже запускается. И виснет.
GCC + MS Platform SDK. Виснет.
MSVC + MS Platform SDK. Работает.
Оказывается, ASIO работает только с программами-клиентами, собранными MSVC, т.к. используется только MSVC'шная схема вызовов (т.н. thiscall в C++). Другие компиляторы пытаются выполнить вызовы по своей схеме, и в результате приложение падает/виснет.
В Portaudio, которая поддерживает ASIO, эту проблему решили с помощью специальной обёртки: http://www.audiomulch.com/~rossb/code/calliasio/ - вручную эмулируются вызовы MSVC, ассемблерными вставками.
Xм, я в сомнениях, будет ли эта обёртка обновляться постоянно, и будет ли работать под x86_64. Не будем связываться с ассемблером. Будем компилировать MSVC.
Ах да. Это же известная проблема с C++ под Win. Бинарный интерфейс (ABI) для C открыт, С-шные библиотеки собранные MSVC можно слинковать с любым кодом. Для C++ - закрыт (проприетарен). Поэтому из-за чужих бинарных C++-библиотек приходится собирать свой проект компилятором от Майкрософт.
Под Lin у нас есть Jack. And it's amazing. 1.33 милисекунды задержки на встроенной звуковой карте получаются без проблем.
У кого нет Lin, придётся использовать Win.Под Win нам придётся использовать ASIO. На Portaudio пока забъём. (по определённым причинам)
.. Пытался скомпилировать стандартный пример из ASIO SDK. Хм. С помощью GCC + MinGW.
Хм. =). Даже собрался. Даже запускается. И виснет.
GCC + MS Platform SDK. Виснет.
MSVC + MS Platform SDK. Работает.
Оказывается, ASIO работает только с программами-клиентами, собранными MSVC, т.к. используется только MSVC'шная схема вызовов (т.н. thiscall в C++). Другие компиляторы пытаются выполнить вызовы по своей схеме, и в результате приложение падает/виснет.
В Portaudio, которая поддерживает ASIO, эту проблему решили с помощью специальной обёртки: http://www.audiomulch.com/~rossb/code/calliasio/ - вручную эмулируются вызовы MSVC, ассемблерными вставками.
Xм, я в сомнениях, будет ли эта обёртка обновляться постоянно, и будет ли работать под x86_64. Не будем связываться с ассемблером. Будем компилировать MSVC.
Ах да. Это же известная проблема с C++ под Win. Бинарный интерфейс (ABI) для C открыт, С-шные библиотеки собранные MSVC можно слинковать с любым кодом. Для C++ - закрыт (проприетарен). Поэтому из-за чужих бинарных C++-библиотек приходится собирать свой проект компилятором от Майкрософт.
Подписаться на:
Сообщения (Atom)
