Чернышевский. Кто виноват? И что делать?

- Что делать?
- Ааа?..
- Я говорю, что делать? Я закончил популение фуфырчиков через неполное замыкание. Теперь этот кусок работает гораздо быстрее.
- Эээ... Ага. Насколько быстрее? Сколько теперь занимает?
- 29 фарфоровых слоников на два небольших кошачьих хвоста. Было 60.
- Ага, отлично. Слушай, но 29 слоников все равно много... А?..
- Нуу... много...
- Надо бы, наверное, еще копнуть сюда. А какие там еще части есть медленные?
- Не знаю. Надо померить.
- Ага, померяй, тогда поймем что делать дальше...
...
- Слушай, я померил. Там при популении еще подвязывание пупов тормозит.
- А что там тормозит?
- Посмотреть под профайлером?
- Ага.
- На какой среде?
- Ну... В ближнем болотце...
- В ближнем болотце нельзя, там много травы по берегам стало.
- Ну... Скосить немного придется...
...
- Нашел. Там у фуфырчиков нос закладывает. Похоже, в болотце сыро, вот пупы и тормозят.
- Угу, а что сделать можем?
- Ну, наверное, осушить болотце. А если бы кто-то давным-давно вместо болотца построил бы олимпийский бассейн 50-метровый, то было бы сейчас гораздо удобнее. Можно было бы вообще наливать воду и откачивать в момент!
- Угу... Отлично... А чтобы носы не хлюпали у фуфычиков нельзя сделать?
- Нну... Я посмотрю...

- * -

- Слушай, ну я сейчас закончил с подвязыванием крыльев жирафу. Вроде нормально стало. Теперь крылья не ломаются, а аккуратно волочатся по земле, заметая следы. Так что жираф теперь еще и от львов лучше прячется :-)
- Слушай, отлично. А крылья шелковой лентой подвязывал или хлопчатобумажной?
- Там пришлось тонкий канат заюзать. Шелк пачкался быстро - некрасиво.
- ОК. Что думаешь дальше?
- Я вот думаю или ужу уши увеличить, или коту усы. А еще есть 15 мышей - их подковать надо.
- Ага, а ужу потенциально уши насколько увеличить можно?
- Да он ими вообще тогда сможет от дождя укрываться.
- Дождя?.. Да, нормально. Это на сколько по времени?
- Ну примерно полтора дня.
- Ок. Давай начнем с ужа, а потом мышей. Уточни у Э.У., нет ли у него проблем, перед тем как к мышам приступать.
- ОК.

REST архитектура (II)

Одним из свойств REST-архитектуры является манипулирование объектами средствами ограниченного числа операций. В рамках HTTP это GET, POST, DELETE, PUT.

До этого мой API был построен в стиле:

GProjectEstimates getProjectEstimates(String projectName);

GProjectEstimates fixInitialEstimate(String projectName);

GActiveProject createProject(String name);

void deleteProjects(Set projectNames);

Т.е. определен некоторый интерфейс в терминах действий, предоставляющий доступ к методам по работе с данными. Для REST я переформулировал его в терминах объектов-ресурсов:

/{user}/time - Ресурс «Затраты времени пользователя»

/{user}/projects - Ресурс «Проекты пользователя»

/project/{projectNumber} - Ресурс «Проект»

/project/{projectNumber}/initial - Ресурс «Начальное планирование проекта»

/project/{projectNumber}/current - Ресурс «Текущее состояние проекта»

Для каждого из ресурсов задан URI. Важным моментом является то, что представление одного и того же ресурса (т.е. ресурса имеющего один и тот же URI) для разных пользователей не должны различаться. Если представления различны, то по сути это разные ресурсы и должны иметь различные URI. Поэтому ресурс «Затраты времени пользователя» включает в свой URI имя пользователя {user}.

Над каждым ресурсов определены действия:

Ресурс «Проекты пользователя»
/{user}/projects

GET - Возвращает коллекцию ссылок на проекты с названиям вида.
PUT - ничего
DELETE - ничего
POST - Создает новый проект, добавляет в коллекцию и возвращает его URI в Location. Может быть указано имя проекта, иначе создается самостоятельно.

GET, очевидно, получает представление ресурса с сервера.
PUT помещает на сервер по указанному URI новый ресурс или заменяет имеющийся.
DELETE удаляет ресурс.
POST позволяет выполнять модификации или создание нового ресурса. Естественно действие может быть различным в зависимости от переданного в POST содержимого.

GET может возвращать несколько разное содержимое в зависимости от запрошенного клиентом типа результата.

Оба метода PUT и POST могут использоваться для создания ресурсов, но есть различие. Для использования PUT необходимо знать URI вновь создаваемого объекта, в то время как POST может сам создать объект и вернуть URI созданного объекта клиенту. Такая схема использована выше, когда выполнение POST на ресурсе "проекты пользователя" приводит к созданию нового проекта и возврату URI вновь созданного объекта.

Интересно, что наличие метода PUT само собой подвигает к программированию в стиле - загрузка объекта и передача на клиента - изменение Detached-объекта на клиентской стороне - возврат его на сервер для сохранения изменений, в противоположность специальным API часто характерным для RPC.

REST архитектура

В процессе размышлений о системном стеке решил попробовать использовать принципы REST-архитектуры. Несколько предлагаемых принципов:

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

Если следовать этим принципам, то открываются интересные возможности для системы, не имеющей серверного контекста:

• она отлично скалируется горизонтально
  
• исчезает необходимость синхронизации данных сессии
  
• упрощается выведение серверов на поддержку
  
• если результат исполнение запроса не зависит от пользовательской сессии, а зависит лишь от адреса, по которому произошло обращение, то ответ сервера может быть эффективно закэширован
  

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

В общем, я, кажется, купил :)

Kanban vs Scrum -- видимый процесс и видимый результат

Есть одна интересная особенность Kanban в отличие от Scrum. Kanban - отражает процесс от начала и до конца. Scrum отражает процесс работы команды. Обычно процесс работы Scrum-команды видится как разработка potentially shippable feature set и ограничен итерацией. Процесс работы Kanban - это процесс поставки продукта в жизнь. Т.е. он естественно охватывает более широкий период и может использоваться, например, для отслеживания того, сколько всего готово к установке в лайв и реально установлено.

Средством визуализации процесса в обоих случаях используют доску. Для мотивации к внедрению задач в жизнь против накопления сделанного, но не сданного, в Kanban можно ввести такую доску:
backlog, todo, development (in progress, done), live и установить суммарный лимит WIP на блок development (work in progress + done). Тогда накопление задач в done не позволит взять больше в in progress и приведет к сосредоточению на переводе сделанной функциональности в Live.
Очень красиво.

Инфраструктура разработки на основе бесплатного ПО

Ранее писал о JIRA Stidio - это hosted service предоставляемый Atlassian на основе ее ПО - svn, JIRA, Confluence, Greenhopper, Bamboo builds. Но мы пока что используем как альтернативу этому аренду small сервера Amazon AWS - это примерно 65 долларов в месяц. Взяли версию с предустановленным SVN и Trac. Сделали проброс через https - все работает.

В сравнении с JIRA Studio - в два раза дешевле, правда у Studio сервисов побольше и все поинтегрированней. Плюс - собранное таким образом гораздо гибче, но настройка всего потребует времени.

По производительности должно еще и систему постоянной интеграции потянуть. Остался вопрос - какую систему постоянной интеграции выбрать?


Еще немного полезной информации к размышлению об организации инфраструктуры:
Сайтик для выбора svn-хостинга

Если смотреть варианты svn + trac, то
- Assembla
- ProjectLocker
- mysvn.ru
- CodeSpaces

Чистый svn-репозиторий http://www.subversion.ru/ или http://www.svnrepository.com/

JIRA Studio: hosted development suite

Прикидываю сейчас сервера и необходимый софт для создания удобного рабочего окружения. Минимум:
- система контроля версий
- багтрекер
- система сборки
- возможно простая система планирования

Хотелось бы получить вариант наиболее простой и дешевый с точки зрения поддержки и развертывания. Первый вариант был: арендовать сервер, например, на Амазоне и поставить туда соответствующее бесплатное ПО. В процессе подбора ПО наткнулся на интересное предложение от Atlassian - это JIRA Studio. Предлагают hosted-сервис, т.е. размещение на их серверах следующего набора интегрированных сервисов:
- Subversion
- JIRA - багтрекер
- Greenhopper - систему планирования карточек a la Agile
- Confluence - wiki
- Bamboo - система continuous integration
- Crucible - ревью кода
- FishEye - поиск по коду

Смотрится ммм.... вкусно :) Практически полностью создает всю необходимую инфраструктуру без покупки единого сервера! От Svn, JIRA, Greenhopper'а у меня осталось самое приятное впечатление. В дополнение к этому есть бесплатный плагин для IDEA, позволяющий управлять всей этой радостью.

Стоимость месячной подписки на 5 разработчиков $125 (~3800 рублей в месяц) на 10 пользователей - $250. Полный список вариантов - здесь. Т.е. для моего количества примерно 25-30 долларов на человека в месяц.

Очень интересный вариант.