Обо всем по-немногу. Firefox, AMR, ExtJS.

Прошу прощения у читателей/подписчиков за продолжительное отсутствие. Проекты съедают много времени. Что не съедает работа, догрызает свое дело. Свет в конце тоннеля пока не виден, поэтому учимся жить в условиях ограниченного времени.

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

Конвертация AMR и 3gp.

Я часто пользуюсь диктофоном на мобильном телефон. Во-первых, потому что не всегда есть возможность достать бумагу и ручку, а во-вторых для того, чтобы хранились логи встреч, которые потом можно послушать, если забыл что же было решено по итогам встречи ;)

Я не помню уже, чем конвертировал из amr в mp3 под Windows, но под *nix искать программу долго не пришлось. Попробовав несколько самопальных скриптов, некоторые из которых опасны для жизни файлов ;) я остановился на программе Mobile Media Converter (ссылка внизу страницы, между гуглоРекламой, долго искал =). Программа с самым банальным интерфейсом и тем очень удобна. Умеет работать с amr и 3gp, а большего мне и не нужно.

Знаменитый баг Firefox

С этим багом я столкнулся сразу же после установки Ubuntu. Это тот самый знаменитый баг, из-за которого хоткеи не работают в русской раскладке. Его уже поправили (за деньги), но исправления будут только в Firefox 3. А пока, необходимо установить маленький add-on, который всё вам поправит. И будет шастье =)

Небольшой багФикс для ExtJS

Замешивая полный винегрет из тем, упомяну ещё одну вещь. Все знают, что ExtJS можно заставить говорить по-русски в окошках/менюшках, просто подключив файл с русской локалью. Но в нем есть один неприятный и редкий баг. При работе с DateField, когда выставляется формат содержащий месяц прописью (янв, фев и пр.), мы получаем январь 1970 года и ничего кроме.

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

Date.monthNumbers = {
  Янв : 0,
  Фев : 1,
  Мар : 2,
  Апр : 3,
  Май : 4,
  Июн : 5,
  Июл : 6,
  Авг : 7,
  Сен : 8,
  Окт : 9,
  Ноя : 10,
  Дек : 11
};

На сегодня — всё. Надеюсь, что скоро станет посвободнее и я допишу туториал по ExtJS и гридам с фильтром и поиском =)

Управление сторонними библиотеками в Subversion.

В этом блоге я ни разу не постил переводы. Повода не было. Но вот в RSS пробежала статья, описывающая правильное управление внешними библиотеками в Subversion. Она мне настолько понравилась, что я решил опубликовать её вольный перевод. К сожалению, времени потестировать рецепт у меня не было, поэтому буду переводить "as is". Если заметите какие-нибудь неточности, отпишите в комментах, исправлю.

Subversion Externals

В Subversion существует удобный механизм управления внешними библиотеками, который позволяет автоматически экспортировать код из других репозиториев в рабочий проект. Это svn:externals. Этот пост создан в качестве напоминания самому себе, о том, как это реализовать. Потому что каждый раз забывая, я вынужден гуглить. А решение, к которому я прихожу каждый раз одно и то же.

Для начала, предположим, что у нас в репозитории есть папка lib/, и мы хотим положить в неё код из папок library/ и incubator/library/ проекта Zend Framework. Конечная структура папок выглядит следующим образом:

myApplication/
    lib/
        incubator/Zend/
        Zend/

Для этого необходимы следующие заклинания:

$ cd lib/
$ export SVN_EDITOR=vim
$ svn propedit svn:externals .

(Разумеется, стоит заменить vim на редактор, привычный Вам)

В запустившемся Vim'е (emacs'е, nano) необходимы следующие строки:

incubator http://framework.zend.com/svn/framework/branch/release-1.0/incubator/library
Zend http://framework.zend.com/svn/framework/branch/release-1.0/library/Zend

Стоит отметить, отметить, что release-1.0 это текущий релиз ZF, а следующий будет release-1.5. Если вам необходима текущая версия ZF 1.5, то это будет release-1.5PR

Сохраняемся, выходим из редактора и видим следующее сообщение:

Set new value for property 'svn:externals' on '.'

Вот и всё! Не забываем закоммититься и теперь для поддержания ZF в состоянии актуальности не забываем запускать svn up.

ExtJs. Многостраничный грид с фильтром и поиском. Часть 1.

Просматривая статистику поискового трафика, любезно предоставленную мне feedburner'ом, я замечаю, что основная масса трафика идет на тему ExtJS. Мне не совсем понятен этот момент ;) Обычно, когда мне что-то надо узнать по ExtJs, я двигаю на их форум. Потому что именно там собрана вся информация, которая вообще может пригодиться (после документации, конечно). В гугле я ищу только конкретные ошибки, которые выдает мне FireBug. Потому что поисковая система форума далека от идеала.

Но, в свете того, что я чуть подправил вектор своего блога и ориентируюсь на пользователей больше, чем раньше, я начну серию статей, посвященных ExtJS. А точнее одному удобному виджету, который может быть применен во множестве ситуаций. Речь идет о многостраничном гриде с поиском и фильтром.

Работая с ещё с ExtJS 1.1, я нашел замечательный топик, в котором рассказывалось о подобном гриде. И приводился замечательный пример. В этом примере всё отлично. Но он написан на первой версии и использует в качестве бэк-энда python. В этой серии туториалов я опишу создание такого же грида, с использованием ExtJS 2.0, php5 и Oracle (для MySQL будут приведены примеры запросов, не сильно отличающиеся от ораклинских).

В этой заметке я лишь опишу примерную структуру будущего виджета, а в дальнейшем приведу код с комментариями и пояснениями.

Итак. Наш грид будет состоять из:

• grid.html - html-файл, содержащий разметку страницы
• grid_data.php - файл, обслуживающий запросы к БД со стороны грида
• grid.js - js-файл, содержащий основной код приложения

Архитектура будет банальной. Наш грид посредством AJAX-запросов, будет обращаться к php-файлику и тот будет передавать ему данные в формате JSON. Запросы к БД будут всего двух типов:

• Запрос очередной страницы с данными
• Поисковый запрос

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

На сегодня всё. Stay on line.

О синхронизации Google Calendar с телефоном.

С тех пор, как я последний раз поднимал эту тему, прошло немного времени, однако любезный Dragonhorse отписал в комментариях ссылку на вторую версию GCalSync'а. Напомню, что это маленькая JavaMe программка, которая устанавливается на телефон и синхронизирует календарь на телефоне с Google Calendar. В качестве ее недостатка можно было выделить лёгкую "глюкавость" и невозможность синхронизировать несколько гугло-календарей.

В связи с этим я спокойно пользовался goosync'ом в его бесплатном исполнении. Однако, во второй версии программы, был доработан интерфейс, убрана "глюкавость" (каких-то багов ещё добавили, конечно =) и, самое главное, была реализована возможность синхронизации с двумя и более гугло-календарей.

Таким образом, не вижу смысла более пользоваться GooSync и перехожу на неё. Ещё раз спасибо, Dragonhorse.

Для обладателей Motorola A1200 (и каких-нибудь ещё), привожу рецепт по преданию программе работоспособности, потому что без рецепта телефон запрещал ей читать календарь.

1. Качаем .jar файл с программой
2. Устанавливаем программу на флешку
3. Подключаем телефон к компу и ищем на флешке файл .system/java/DownloadApps/MIDletxxx/registry.txt
4. Меняем Domain: untrusted на Domain: Manufacturer
5. Меняем Is-Trusted: 0 на Is-Trusted: 1
6. Меняем DRM-Mode: Forbidden на DRM-Mode: Allowed

После этих манипуляций, телефон начнет доверять программе и они подружатся. А мы получим двухстороннюю синхронизацию мобильного телефона и google calendar. Что не может не радовать =)

del.icio.us, как хранилище информации в системе GTD.

С тех пор, как я прочел книгу Дэвида Аллена "Getting things done", прошло уже достаточно времени. Я прикипел к ThinkingRock со всеми его фишечками и прикрученным календарем, поэтому на другие GTD-системы я смотрю, сравнивая их с тем, что есть в ThinkingRock. Единственное, с чем я не до конца определился — это хранилище информации.

Дэвид Аллен рекомендует использовать шкаф с папками. Создавать по папке на каждую тему, упорядочить их по алфавиту и хранить в шкафу. В такой системе меня не устраивает пара моментов:

• Громоздкость
• "Оффлайновость"

В силу того, что большая часть моей работы проходит через комп, и большая часть информации идет в цифровом виде, мне необходимо цифровое хранилище информации. Блуждая по зарубежным ресурсам (тут можно привести длинный список), я наткнулся на очередное эссе на тему "Моё ГТД", в котором упоминается макосовский софт DEVONthink, который я попробовать не смог в силу его макосОвости и небесплтатности. Но судя по заверениям создателей и личным впечатлениям автора эссе (а он, судя по всему, завсегдатай известного макОсно-ГТДшного блога 43Folders, т.е. ему верить можно ;) софт достойный.

Убедившись в очередной раз, что надо либо ставить MacOSX на PC (фи), либо покупать Mac (о, да), и поняв, что отдавать деньги в очередной раз не хочется, я решил подумать ещё раз =)

Вторая дума (по мотивам того же эссе) занесла меня на backPack. Опять же, основываясь на заверениях автора эссе и создателей сервиса, пришел к мысли, что сервис хороший. Только, он платный. Точнее есть бесплатный вариант, но настолько урезанный, что способен только заманить на платный аккаунт. А жить на нем невозможно. Это понимаешь только после бесплатной регистрации. Но попробовать его стоит. Может кому сильно понравится, и он останется там жить ;)

После нескольких часов поиска, я вспомнил про del.icio.us, который я использовал как временное пристанище для ссылок и периодический источник полезных линков. И его тэги показались мне вполне удачной идеей.

Не мудрствуя лукаво, я решил сотворить из него information storage для он-лайн статей. Есть, конечно, вероятность, что статьи канут в лету, но кэш гугла останется с нами. И, имея нормальное название статьи и линк на неё, можно у гугла будет попросить показать последнее, что он об этой странице запомнил ;)

Помня, что лучший "упорядочиватель" — это время, я решил не слишком углубляться в создание сложной структуры тэгов. Я пробежался по всем закладкам, благо их было около сотни, стер те, что были устаревшими или более не полезными, и "заТэгил" те, что остались. В процессе "тэганья", я выделил несколько основных направлений, по которым я буду (предположительно) складировать информацию и вывел их наверх (@development, @nix и пр.). Далее, я создал пару тэгов ещё повыше ;) (@@print - распечатать и @@parse - изучить). Оглядев сложившуюся систему, я поудалял тэги, в которых было по одной записи, сократив их число ещё чуть. Таким образом, получилась довольно стройная система. Разумеется, она будет изменяться. Возможно будут появляться новые верхнеУровневые тэги.

Результатом я остался доволен. По-крайней мере часть хранилища у меня есть. Если найду более универсальный способ - обязательно расскажу

Что касается хранилища оффЛайн-информации, то в субботу поеду за папками и файлами и наклейками =) Посмотрим, что из этого получится. Главное купить побольше, чтобы можно было беспроблемно выкидывать ;)

ThinkingRock и pocketMod.

К программке thinkingRock я уже привязался, и привык запускать её каждое утро, чтобы сориентироваться "на местности". И периодически запускать в течение дня, чтобы понять правильно ли я двигаюсь ;)

Но моя радость была бы не полной, если бы программка не позволяла делать отчеты, которые можно печатать на бумаге. И носить с собой. Учитывая стоимость одного листа бумаги, даже с тонером, можно предположить, что решение довольно оправдано. Но самым неожиданным для меня было то, что программка умеет делать pocketMod. Т.е. маленькие такие книжечки. Которые удобно таскать с собой. Правда настройка не очень тонкая, но жить можно. Всё самое важно можно вытащить.

Для тех, кого решительно не устраивает половинчатый подход к делу, есть ещё одна возможность. Помимо pocketMod, программа позволяет создавать отчеты в PDF. На листах формата A4. Здесь уже возможностей настройки больше. Но таскать с собой A4 не с руки. Можно было бы напечатать их по 4-8 на листе, резать, клеить. Но это уже не 2 минуты =) Здесь нас выручит программка PDF2PocketMod, которая умеет создавать pocketMod-блокнотики из любого документа. Лишь бы страниц было много. Правда она в альфа-версии и вообще. Но она работает ;) А больше и не надо

В поисках "серебряной пули" для GTD. Часть 2.

Синхронизация с большой буквы Си

В первой части этой серии статей, посвященных поиску инструментов для внедрения GTD я рассказал про замечательную программу ThinkingRock. До сих пор я в ней не разочаровался и пока всё идет по плану ;).

В этой части я расскажу о синхронизации ThinkingRock с Google Calendar. Для создания этой связки есть две причины:

1. Доступ запланированным мероприятиям из любой точки при наличии интернета
2. Удобная синхронизация с мобильным телефоном (об этом в следующей части)

Для осуществления синхронизации, я буду использовать следующие программы:

1. SunBird (в качестве альтернативы м.б. использован ThunderBird с plug-in'ом, Evolution, Rainlendar и вообще любые календари, которые воспринимают формат .ics)
2. GCalDaemon - программа-демон, осуществляющая синхронизацию
3. Сам Google Calendar =)

Настраиваем ThinkingRock

Предположим, что вы начали использовать ThinkingRock (или начнете =). Одной из его опций является ведение файла в формате .ics, в который он пишет все запланированные события и ToDo-лист. Для включения этой опции надо прогуляться в меню "Tools->Options", далее на вкладку "Miscellaneous", где открыть пункт "Calendar" и поставить там "галочку" "Publish iCalendar file". Далее необходимо задать путь до папки, где ThinkingRock будет держать наш файл. Если ThinkingRock установлен на флешке, то и файл с календарем стоит держать там же.

Как вы помните ThinkingRock кроссплатформенное приложение, написанное на Java. И из одной копии может грузиться и под *nix и под Win, и настройки у него для ОС разные. Поэтому если вы работаете и там, и там, необходимо будет проделать вышеописанную процедуру два раза. Из-под Win и из-под *nix. Ну или, для эстетов, из-под MacOSX =)

Теперь в указанном месте у нас будет жить файлик gtd.ics, который ThinkingRock будет обновлять по мере сохранения или изменения событий.

Настраиваем календарь

Я буду приводить пример настройки SunBird, но ту же процедуру можно выполнить в любом календаре, способном подхватывать ics-файлы.

Открываем SunBird, открываем "Файл->Подписаться на удаленный календарь..." В открывшемся мастере выбираем "В сети" (Далее) "Формате iCalendar" и в качестве адреса прописываем путь к нашему файлу "file:///E:/thinkingRock/gtd.ics" В результате наших манипуляций, должен подгрузиться новый календарь.

Надо заметить, что ThinkingRock'у абсолютно фиолетово что там происходит с файлом. Он просто его переписывает. Поэтому, если вы внесли правки в календарь на стороне SunBird, при следующем акте сохранения ThinkingRock, это изменения будут удалены. Это в принципе и неплохо. Мне больше нравятся централизованные инструменты.

Достаем клей

Теперь надо приклеить нашу связку к Google Calendar. Для этого скачиваем GCalDaemon для нужной нам платформы. Он тоже на Java и тоже ацке кроссплатформенный =) Теперь, в принципе, можно прекращать читать нудный текст, а двигать на сайт и осваивать там процесс установки в картинках.

Когда зарябит в глазах от всевозможностей этой программы и она заработала у вас как демон (служба Win) или просто заработала (хотя демон предпочтительней), можно обратиться к настройкам. Путем длительных махинаций с конфигурацией и календариками, было выяснено, что удобнее всего выставлять file-based synchronization (пример, правда для Rainlendar, но смысл от этого не меняется) и начинать считать, что у нас модем (file.offline.enabled=true). Тогда GCalDaemon работает практически безошибочно и не перетирает гуглом локальный файл в случае изменения. Все настройки удобнее всего править через Config Editor.

В результате, мы имеем:

1. ГуглКалендар, доступный нам откуда угодно
2. Файлик ics, погружаемы куда угодно
3. StandAlone-календарь, если, вдруг, надоел web-interface
4. Оно всё одинаковое и синхронизируется =)

С чем нас и поздравляем. Продолжение следует...