Управление сторонними библиотеками в 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 - изучить). Оглядев сложившуюся систему, я поудалял тэги, в которых было по одной записи, сократив их число ещё чуть. Таким образом, получилась довольно стройная система. Разумеется, она будет изменяться. Возможно будут появляться новые верхнеУровневые тэги.

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

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