livedev.org

Скажу сразу: «я офигел». То, что сейчас предлагает Google для сторонних разработчиков — просто бомба. И не думайте, что App Engine это что-то новое. Да это неплохое дополнение к существуещей инфраструктуре, но самое главное внутри.

Итак, про что же я. GData — универсальный API Google для чтения, записи и поиска в его сервисах. Это очень сбалансированная смесь CRUD и Atom/RSS. Самое главное в GData — это фиды. Результаты поиска, сложные запросы, создание/обновление документов и т.п. возвращаются в формате, подобному Atom фиду. Ребята из Google практически дополнили спецификацию Atom возможностью делать запросы (выборки) и реализовали незаконченную спецификацию Atom Publishing Protocol. Другими словами гугловские сервисы видны через интерфейс GData, как фиды, которые можно читать, апдейтить, искать по каким-то параметрам и удалять. Эта модель работы с данными отлично вливается в сферу веб, что и показала практика Web2.0 (покажите популярный сайт без фида).

Какие сервисы на сегодня доступны через GData API:

• Google Docs;
• Gmail contacts;
• Notebook;
• Blogger;
• Picasa;
• Calendar;
• Base;

Полный список на сайте Google API.

Чтобы не остаться голословным хочу привести пример кода для работы с Google Docs.

import gdata.docs.service

# авторизация
gd_client = gdata.docs.service.DocsService()
gd_client.email = 'username@gmail.com' #change this
gd_client.password = '' #change this
gd_client.source = 'exampleCo-exampleApp-1'
gd_client.ProgrammaticLogin()

# запрашиваем список (фид) всех документов с сервиса
feed = gd_client.GetDocumentListFeed()
# выбираем первый документ для работы
d = feed.entry[0]
# работаем с документом
print d.title.text # выводим название документа
print d.content.src # ссылка на документ в html виде (как он хранится в google)

Для создания или изменения документа необходимо использовать python-модуль atom. Пример кода:

import atom
# устанавливаем название нового документа
document.title = atom.Title(text='my best friends')

Что еще можно добавить. Вышеприведенный код предоставлен разработчиками Google для Python. Т.е. это уже клиентская часть API. Есть также версия для Java, .NET и PHP. Так что если есть желание интегрироваться с Google, то, пожалуй, все необходимое для этого есть.

Вывод простой. Google превращается из робота индексера в датацентр для размещения информации и вычислений. На сегодняшний день — это работа с документами, почтой, контактами, блогами и фото. Все в одной среде. И новое API — это отличный вариант реализации интерфейса к фичам этого гугло-датацентра :-)

На закусь ссылка на описание протокола GData.

Сегодня, после очередного просмотра и прочтения англоязычных блогов (и фидов), обнаружил совершенно новую фичу или точнее даже формат по шарингу информации между сервисами. Интересно, что в рунете пока еще никто про это не писал. Итак, представляю oEmbed — формат для встраивания контента по URL на сторонние сайты.

Т.к. формулировка достаточно абстрактная, лучше всего приведу пример. С помощью этого формата и API я могу, имея одну лишь ссылку на страницу сайта, получить контент этой страницы в удобном для встраивания виде. От сайта-экспортера требуется поддержка формата на уровне API. Типичный пример — ссылка на YouTube ролик. Чтобы можно было при запросе на API по ссылке получить код для встраивания ролика в мою страницу.

Например, всем известный flickr поддерживает этот формат, адрес API: http://www.flickr.com/services/oembed/. Пользоваться так: http://www.flickr.com/services/oembed/?url=http://www.flickr.com/photos/dobrych/2602270116/.

Кроме flickr экспорт контента в этот формат умеют делать еще несколько сервисов. Но ничто не мешает делать свои oEmbed гейты (провайдеры) для существующих сервисов, которые еще не умеют oEmbed.

Ссылки по теме. Оригинальная новость от создателя Pownce — Leah Culver » Announcing OEmbed - An Open Standard for Embedded Content. Еще:

• приложение для django — django-oembed;
• самодельный провайдер, для сервисов, которые не поддерживают oEmbed — oohEmbed.com - your one-stop oEmbed provider.

От себя еще добавлю, что эту технологию классно использовать в так называемых tumblog-ах. Что в принципе и активно делает Pownce.

PS: если это все таки «баян», дайте знать, где еще есть инфа по теме — оч интересно.

Свежая новость про новый сервис от Гугла. Я не удивлен — Гугл предлагает хостинг приложений. Вполне логичное развитие. Я в принципе давно этого ждал. Что хорошего и что плохого? Много писать не буду.

Хорошее — мощнейшая инфраструктура для хостинга и конечно поддержка приложений на Python ;-)

Плохое — такими темпами скоро «Интернет» == «Google». Я имею довольно приличный опыт в телекоме и хорошо понимаю, что бояться нужно совсем не того что Google индексирует все на свете и типа приватности скоро кирдык. А бояться нужно того, что Гугл сосредоточит большое кол-во интернет-траффика на себе и в результате сможет диктовать свои условия провайдерам. И скорее всего мы получим большое кол-во шаровых вещей в обмен на бесконечный поток контекстной рекламы... Так обычно Гугл и делает. Но не будем о грустном, время покажет.

Подробнее смотрите на страницах Гугла:

• Google App Engine - Google Code
• Google App Engine Blog: Introducing Google App Engine + our new blog
• Running Django on Google App Engine - Google App Engine - Google Code

Хочу поделиться своими впечатлениями о работе в моем текущем проекте глазами разработчика, так сказать изнутри.

А если точнее то своим впечатлением от управления проектом по методологии agile. На сегодня слово agile уже набило оскому, не смотря на то, что точного перевода этого английского слова (в отношении к разработке) я еще не встречал. Поэтому все так и пишут — в оригинале. Как же эта красивая теория приживается на практике, в злободневной рутине?..

Лично мне до сих пор не понятно, почему именно разработчики в таком восторге от очередной новой теории управления проектами или методологии разработки. Ведь если разобраться, то любая из них направлена на то, чтобы выжать из команды максимум возможного результата (читай «заставить работать на полную катушку»). Что в принципе вполне оправдано со стороны начальства и заказчика, но в итоге не всегда легко решается самими разработчиками. Я не пишу, что agile — это зло или просто очередной «гемор» для разработчика, но он им может стать…

Итак, главная фишка agile методологии разработки — это непосредственное общение внутри команды, с минимумом спецификаций и других технических документов и с максимумом реального общения. Т.е. когда заказчик (или бизнес-представитель) сидит рядом с разработчиками и рассказывает что, как и где должно работать (очень упрощенное объяснение). Наиболее распространенный вариант agile-разработки — scrum еще подразумевает ежедневные встречи команды для кратких отчетов кто над чем работает и что собирается делать в ближайшие рабочие часы. Плюс процесс самой разработки делится на итерации (иногда так называемые «спринты») — временные отрезки с набором задач. В конце каждой итерации, понятное дело, подбивается итог и по общей успеваемости разработчиков можно рисовать картину успеваемости самого проекта.

Про преимущества agile, scrum и остального зоопарка по управлению проектами вы найдете кучу статей, а вот про недостатки я расскажу далее. На самом деле в самих теориях управления проектами как правило все гладко, но мы то знаем, что теория не стопроцентно ложится на рабочую действительность. Итак, типичные проблемы, которые появляются в работе agile-команд:

• команда распределена регионально (в смысле люди сидят в разных зданиях); сильно ухудшает коммуникацию; на самом деле при таком раскладе нормальный agile почти невозможен;
• бизнес/заказчик все таки пишет подробные спеки; в этом случае пролеты гарантированы, т.к. скорее всего спеки нормально писать в agile темпе никто не сможет;
• командой управляет не технический менеджер или менеджер который не может прочитать/подправить код; это просто беда, такой менеджер скорее всего будет стопорить работу лишними вопросами и пустыми разговорами;

Могу сказать еще, что работать по правилам agile действительно интересно и приятно в небольшой команде матерых профи. Но в проектах с большим количеством разработчиков, agile надо как-то адаптировать. Как вариант — делить команду на более мелкие группы по более узким направлениям. Еще могу привести пример, что agile вполне успешно приживается даже в распределенных командах, но с учетом того, что команда маленькая. Тот-же джаббер чат и скайп достаточно эффективно решает вопрос командной коммуникации.

Итак простой вывод для читателей-разработчиков: если на собеседовании на новую работу/проект вы услышали волшебное слово agile, не спешите радоваться :-) позадавайте побольше общих вопросов о команде, менеджерах и заказчиках.

Хотел поделиться списком django-проектов, которые могут быть очень полезны при старте любого нового проекта. Чтобы, как говориться, «не изобретать велосипед».

Из того, что пробывал лично я, советую:

• sorl-thumbnail – для генерации thumbnail картинок для ImageField, очень удобно, может делать crop, изменение качества для jpg, подробнее смотрите на сайте проекта (все параметры задаются прямо через темплейттаг, так что верстальщики не будут задалбывать каждый раз когда нужно поменять размер картинки на фронтенде);
• django-registration – для автоматизации регистрации юзеров (проверка имейла итд), скорее всего будете затачивать под себя, так что годиться но с напильником;
• django-tagging – неплохая реализация тегирования для джанги, но требует доработки в плане оптимизации запросов к базе;
• django-template-utils – можно выцепить полезный код или использовать «как есть» при работе с темплейтами, полезные темплейттаги;

Из того, что не пробывал, но советую пробывать читателям:

• django-voting – система рейтинга для контента (работает для юбой модели);
• django-evolution – новый проект для тракинга изменений схемы базы (моделей); сам не тестил, но отзывы хорошие;
• django-atompub – для генерации atom-фидов (feeds), намного гибче стандартного джанговского, очень хорошие отзывы;
• django-rest-interface – для создания ReST API, возможно для работы с ajax;
• typogrify – для обработки вводимого/выводимого текста (правильные кавычки, тире итд); актуально только для англоязычных проектов, наша типографика отличается (читайте Лебедева);
• django-localdates – для корректной локализации дат; интересно как работает с русскими датами, кто может протестировать?

Отдельно. Готовые к бою приложения:

• ByteFlow – блогодвижок, разработка моего товарища, оч советую (есть скрипт миграции с wordpress).
• feedjack – приложение, feed агрегатор на джанге. Полезно для коммунити-сайтов.
• webthumb-api – генерация превьюшек реальных сайтов (передаешь ссылку получаешь картинку).
• django-diario – блогодвижок, не смотрел код, кто пробывал или попробует – напишите комментарий о своем впечатлении.
• django-photologue – фотогалерея, тоже сам не пробывал, но судя по описанию довольно «продвинутое» приложение (кто попробывал – отпишитесь).
• snapboard – готовый движок форума, опять же не пробывал, если есть впечатления – напишите.

Последнее время стал увлекаться подкастами. К сожалению русскоязычных качественных очень мало. А на тему веб-разработок вообще нет (поправьте если ошибаюсь).

Хочу привести свою подборку англоязычных подкастов, которые слушаю.

1. Начну с наиболее интересного для меня—Hivelogic Radio. В этом подкасте автор концентрируется на веб-разработке, как на дизайне так и на программировании. Очень интересные интервью с интересными людьми. В разработке есть акцент на Ruby on Rails. Со стороны аудио, подкаст сделан очень качественно. Приятно слушать.
2. Следующий подкаст я слушаю не так давно, но у него довольно большой авторитет—FOO Casts: Podcasts from O’Reilly & Friends В нем освящается много технических вопросов, необязательно связанных с вебом, но все равно полезных для любого гика и разработчика. Качества звука тоже на высоте.
3. Inside Silicon Valley—Подкаст, состоящий в основном из интервью с монстрами и просто успешными людьми из Силиконовой Долины. Качество хорошее, слушать интересно.
4. Python411 Podcast—для фанов Python. Качество звука не впечатляет, но темы и интервью довольно интересные. Так что подкаст пожалуй действительно для фанатов Python. Освящаются вопросы не только веб-разработки, но и других специализаций в программировании.
5. WebDevRadio—Действительно настоящий подкаст именно для веб-разработчика. Обсуждение новых технологий в вебе, интервью, относительно часты обновления. Советую.
6. The Mac Attack—Подкаст про Mac, MacOSX и все что с ним связано. Как известно многие современные веб-разработчики и дизайнеры выбирают платформу Apple в качестве рабочей станции. Так что думаю будет просто интересно, а некоторым и полезно.

Обновление моего блога.

На днях обновил свой блог на движке typo, до весрии 4.1

Впечатления пока что только приятные. Сразу бросается в глаза подчищенная админка. Большой плюс еще, что блог движок работает на rails 1.2 и заметный прогресс в том, что есть встроенная возможность локализации.

Процесс переезда прошел прозрачно, почти без бубна и плясок :-) Итак пошагово, для тех, кто будет повторять:

1. Бекапим базу в двух вариантах—SQL-дамп и сериализованный YAML вариант. Первое делается через mysqldump или phpmyadmin, а второй вариант командой rails-backup в директории с rails-проектом блога.
2. Обновляем rails и typo. Т.к. у меня все работает через rubygem, я просто запустил sudo gem update. После чего получил последние стабильные gems.
3. Останавливаем текущий процесс typo. Переименовываем директорию проекта и создаем заново проект с typo—typo install my_typo_dir
4. Переносим конфиги из старой в новую директорию (обычно это database.yml и mongrel_cluster.yml). И обновляем базу rake db:migrate.
5. После чего запускаем проект (у меня он работает через mongrel cluster), логинимся в админку и первым делом нам предлагается поменять контент в базе на новый лад. Нужно просто согласиться и блог готов к работе.

Если появились трудности при апдейте—пишите, чем смогу помогу.

PS: В рассылке видел, что у одного человека возникли проблемы при переезде с базой. У него полечилось через rails-backup и rails-restore

activeCollab—достаточно молодая, но успевшая нашуметь система ведения проектов.

А нашумела она тем, что была достаточно подробно “слизана” с Basecamp. Занимательный шум подняли на digg сам топик звучит просто замечательно Amazing clone of Basecamp, 100% free. И хорошее сравнение Basecamp vs. activeCollab написал Slacker Manager.

Что могу сказать от себя… Я оказался очень доволен тулзой, basecamp я не пользовал, поэтому сам сравнивать не буду. Для моей небольшой команды по веб-разработке этой тулзы с головой хватает. Единственными нюансом при установке и запуске есть обязательное наличие PHP5, на 4-ом работать не хочет. Заглянув немного в код могу сказать, что все сделано на объектах, причем с очень похожей на Rails структурой.

Из фич, нужных мне имеется:

• четкое разделение сущностей (проект, задача, milestone, сообщение, файл)
• все крутится вокруг проекта (все связи в смысле)
• отдельно остановлюсь на задачах и сообщениях:
  • с помощью сообщений можно вести неплохую переписку у всех навиду (думаю можно сравнить с мейллистом)
  • задачи группируются в списки—в принципе удобно и практично
• неплохая навигация и юзабилити

Чего не хватает для полного счастья:

• синхронизацию с iCal в обоих направлениях :-)
• улучшить работу с компаниями, возможно как-то выделить менеджер контактов
• систему документирования внутреннюю неплохо было бы (аля вики)

На закуску скриншотик

Давно хотел сделать подобный обзор, но не было времени нормально покапаться. Главное начать, вот и делаю первый выпуск. По мере нахождения новых интересных проектов буду писать еще.

1. mnemosyne – свежее, недавно нашел. На сайте написано что это персональная Wiki с версией beta, но я её хочу попробовать для одного проекта документации. Отдельно поделюсь впечатлением.
2. Diamanda Wiki and Forum – интегрированный форум и Wiki. Живой сайт, работающий на этом софте есть у самого автора Riklaunim’s TechBlog. Страница на SF.
3. Feedjack – агрегатор новостей (feed) в формате atom или rss. Подобный своему брату Planet. Из преимуществ перед Planet стоит выделить умение работать с категориями и тегами, а также хранить полную историю ленты (feed).

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