Весь смысл этого поста сводится к тому, что IE не умеет CSS3 и поэтому его нужно научить, а если не захочет — заставить. И поиск подобного решения сподвиг меня сделать данную подборку.

Встречайте, парад нездоровых решений

Google Chrome Frame

Всем известное решение, плагин для IE который рендерит страницы движком хрома.

Плохо оно тем, что нужно ставить плагин поверх IE. Люди которые используют IE не хотят/боятся/не могут ничего ставить.

Но сам по себе он наталкивает на мысль — «действительно, может в место IE заставить рендерить страницы что-нибудь другое». Ну разумеется, заниматься таким гиблым делом с нуля нет резона, поэтому нужно найти готовые решения и довести до нужного результата.

Нашлись очень забавные вещи, html-рендеры написанные на flash.

HTMLWrapper

HTML и CSS рендер на Actionscript с вариациями флеша, градиенты, анимация, видео и аудио…

Ну и еще парочка подобных извращений:

AS3 HTML Parser Library

DENG

Между прочим, встречал даже рендер HTML на SVG и джаваскриптовый рендер джаваскрипта

Но это все уж как-то хардкорно слишком, нужно поэлегантней.

Можно, конечно, использовать всевозможные хаки и приемы, как нам советует Smashing Magazine, но это не удобно и некрасиво.

Нужна система, и она есть, можно многими любимого зверька JQuery заставить сделать апорт.

jQuery CSS parser

Этот замечательный плагин для JQuery позволяет вместо джаваскриптового

$('.gallery a').lightbox({overlayBgColor: '#ddd'});

сделать CSSное

.gallery a {
-jquery-lightbox: {overlayBgColor: ‘#ddd’};
}

А плагинов, эмулирующих CSS3 у JQuery полно:

border-radius

jQuery Canvas Rounded Corners
jQuery Corners

border-image

borderImage

Multiple Backgrounds

Background Layers

Ну и так далее…

Однако, большинство из этих эмуляций кривые, почти все убогие и хорошо работают только на демо-версиях своих родных сайтов. Те же которые работают хорошо, превращают страницу в кашу при сочетании друг с другом, попробуйте, например, border-radius и Multiple Backgrounds сделать на один блок.

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

P.S. Я прекрасно понимаю, что IE будет притормаживать иногда, но считаю это плюсом, пользователи Internet Explorer должны страдать…

Взгляд в будущее

В последнее время всякие социальные сети и вообще сервисы-лидеры интернета по посещаемости и количеству аккаунтов завели очень неплохую, на мой взгляд, привычку — предоставление уникальных OpenID-идентификаторов для пользователей, дабы с их использованием можно было зайти на сторонний сайт. Кроме того, параллельно развивается очень похожая, но все-таки не совсем производная технология OAuth, которая появилась на свет благодаря стараниям создателей небезызвестного Twitter и, цитируя википедию, «позволяет предоставить третьей стороне доступ к защищенным ресурсам пользователя, без необходимости передавать ей (третьей стороне) логин и пароль».
Лично меня такая тенденция очень радует и, более того, я почти уверен, что за подобной технологией будущее. В частности, в будущем обязательно появятся новые мэшапы для агрегирования информации с кучи сайтов (в частности, хочется вспомнить очень хороший, но несправедливо забытый сервис Yahoo Pipes, который так и не смог покорить сердца и умы просто потому, что его время тогда еще не пришло. Возможно, все еще впереди), а именно такой «форм-фактор» требует логина на кучу сервисов сразу.
Петь дифирамбы подобным технологиям можно очень долго, но лично меня, например, всегда напрягали сайты, на которых надо с нуля регистрироваться, чтобы что-нибудь скачать. Ведь все мы неизменно сталкивались с тем, что когда ищешь, где скачать тот или иной материал — он зачастую оказывается на каком-то совершенно левом и непонятном сайте с названием в духе allbooksmusicwarezzz.omg.su, который ко всему прочему еще и регистрацию требует. Да нет, дело не в пиратстве, дело в том, что сайтов со всяким барахлом, сделанных на коленке, уйма. А вот человеческая память на логины-пароли ограничена, и тут уж ничего не сделаешь. Но приятный момент здесь еще и в том, что многие OpenID-провайдеры кроме информации, непосредственно служащей для авторизации, могут по запросу предоставить еще и базовую информацию о пользователе — e-mail, полное имя, предпочтительный язык и т.п. Причем на многих подобных сервисах можно управлять тем, что отдавать, а что сохранить в секрете. Например, разве пользователю не будет приятно, когда он, зайдя на очередной сайт, увидит приветливую надпись «Добро пожаловать, Вася!» на чистом русском языке, да еще и профиль уже готов к употреблению, вместе с аватаром, привычками и кличкой нежно любимого кота?

Делаем дело и работаем работу

Довольно лирики, думаю, кому оно надо как разработчику — он и так все вышенаписанное уже знает, а простым пользователям дальнейший материал вряд ли будет интересен. Еще больше хвалебных речей и рассуждений легко найти в блоге Ивана Сагалаева, а мы давайте попробуем сделать свою систему авторизации через OpenID (например, для блога) на Python, с преферансом и пианистками.
Для своего блога, который сейчас находится в разработке у меня в папочке Projects, я решил вообще отказаться от системы регистрации и авторизации через логин-пароль, а оставить только OpenID. В качестве фреймворка был выбран Pylons, а для прикручивания OpenID к Django-проектам существует и развивается проект с простым и понятным названием django-openid. Для Pylons, в общем-то, тоже существует решение под названием AuthKit, однако с ним у меня отношения как-то не очень сложились, а все, что я нашел в сети — это несколько сниппетов, в которых и пришлось разбираться.
Для начала надо установить модуль python-openid, чтобы обеспечить поддержку технологии, а потом создаем контроллер (обработчик запроса по URL, ближайшая ассоциация — джанговский views.py) и начинаем колдовать.

$ paster controller auth

Сразу оговорюсь, что код рабочий ровно до той степени, которая обеспечивает непосредственно аутентификацию, что делать дальше и как это все оформлять — решать только вам, господа творцы. Начало довольно стандартное:

from openid.consumer.consumer import Consumer, SUCCESS, FAILURE, DiscoveryFailure
from openid.store import filestore

from openid import sreg
from datetime import datetime
from hashlib import md5

class AuthController(BaseController):
    def __before__(self):
        self.openid_session = session.get(“openid_session”, {}) # проверяем, не существует ли openid-сессии

    def index(self):
        return render(‘/accounts/enter.html’)

    @rest.dispatch_on(POST=“signin_POST”) # разделяем GET- и POST-запросы по разным обработчикам для удобства

    def signin(self):
        if c.user: # проверяем, не попытался ли уже залогиненый юзер зайти еще раз

            session['message'] = ‘Already signed in.’
            session.save()
            redirect(url(action=‘index’)) # и если да, то не пущаем

        session.clear()
        return render(‘/index.html’)

Теперь подходим к самому интересному:

def signin_POST(self):
        problem_msg = ‘A problem ocurred comunicating to your OpenID server. Please try again.’


        g.openid_store = filestore.FileOpenIDStore(‘.’) # создаем временное хранилище для хранения OpenID-данных, g здесь-массив глобальных переменных Pylons

self.consumer = Consumer(self.openid_session, g.openid_store) # ага, вот и наш клиент
        openid = request.params.get(‘openid’, None) # достаем из запроса строку с OpenID - идентификатором

Ага, а вот тут немного магии. SReg — это то самое расширение, которое позволяет нам запросить у сервера дополнительные данные о пользователе. Поля, значение которых хотелось бы узнать, перечисляем в списке optional, а дополнительные данные, если что, всегда можно запросить у пользователя потом. Если же какая-то дополнительная информация требуется прямо кровь из носу, то можно запросить ее в required, но если сервер ее не отдаст — будет ошибка.

...
        sreg_request = sreg.SRegRequest(
            #required=['email'],
            optional=['fullname', 'timezone', 'language', 'email', 'nickname']

        )
 
        if openid is None:
            session['message'] = problem_msg
            session.save()
            return render(‘/index.html’)

...

Здесь я позволил себе схалявить и написал этот код только для того, чтобы объяснить разницу между простым OpenID и кросс-логином с гугловского аккаунта. Дело в том, что гугл не представляет пользователям OpenID-идентификатора вида https://vasya_pupkin.google.com/, а все куда проще и веселее. URL идентификации у всех пользователей гугла выглядит абсолютно одинаково — https://www.google.com/accounts/o8/id. Любопытно то, что при запросе на этот URL гугл отдает готовый XRDS (XML-подобного вида документ, возвращаемый сервером по стандарту OpenID 2.0), который уже содержит все необходимое для авторизации, а вам как пользователю присваивается уникальный ID, который и является, по сути, идентификатором OpenID.

if openid == ‘google’:

    openid = ‘https://www.google.com/accounts/o8/id’

    authrequest = self.consumer.begin(openid) # панеслася

except DiscoveryFailure, e: # а вдруг ошибка в адресе или такой провайдер существует только в твоем воображении?
    session['message'] = problem_msg
    session.save()
    return redirect(url(controller=‘auth’, action=’signin’))
 
authrequest.addExtension(sreg_request) # подключаем SReg, дабы извлечь требуемые поля для профиля

redirecturl = authrequest.redirectURL(h.url_for(‘/’, qualified=True),
    return_to=h.url_for(action=‘verified’, qualified=True),
    immediate=False
) # после всего, что у нас было с сервером, надо как-то жить дальше

session['openid_session'] = self.openid_session
session.save()
return redirect(url(redirecturl))

Ну, теперь можно поговорить с сервером, останемся ли мы друзьями.

...
    def verified(self):
        problem_msg = ‘A problem ocurred comunicating to your OpenID server. Please try again.’

        self.consumer = Consumer(self.openid_session, g.openid_store)
        info = self.consumer.complete(request.params, (h.url_for(controller=‘auth’,
                                                 action=‘verified’,
                                                 qualified=True)))

        if info.status == SUCCESS: # все пучком
 
            sreg_response = sreg.SRegResponse.fromSuccessResponse(info) # извлекаем затребованные в SReg поля

            user = User(by_openid=info.identity_url) # ищем юзера по идентификатору в базе
 
            if not user.exist: # а вот тут можно делать что угодно. Например, внести юзера в базу

                newuser = User()
                try:
                    email = sreg_response.get(‘email’, u”),
                except:
                    email = u”

                newuser.create(
                    openid = unicode(info.identity_url),
                    email = email,
                    password = unicode(md5(info.identity_url).hexdigest()),
                    ip = request.environ['REMOTE_ADDR']

Вот, собственно, и все. Что делать с полученными данными — засовывать в куки, продолжать регистрацию и просить у пользователя дополнительную информацию — решать только вам. Да, и еще, данный код не работает с OpenID от Yahoo. Если охота по завещанию Козьмы Пруткова позрить в корень — есть информация все в том же блоге Ивана Сагалаева. Буду рад услышать любую критику, уточнения, предложения. Постараюсь в дальнейшем разобраться с OAuth и организовать интересующимся немного кода по кросслогину из твиттера.

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

Однако, в некоторых организациях, он же применяется и для управления работами сотрудников. Часто такое бывает, когда многие сотрудники работают по контрактам.

И вот тогда, когда вы не только выставляете “внешний интерфейс” в виде ГОСТ-19, но и сами выдаете задания по его правилам - становится понятна вся его сила и весь смысл.

Это очень простой, чрезвычайно эффективный, и, вероятно, наиболее недооцениваемый стиль из существующих. И этот стиль по-настоящему крут. Сейчас разберем его отличительные особенности по практике его применения. Без шелухи и формализма - только суть и дух. То, про что я расскажу - базовые принципы, общие для всех ГОСТ, посвященных организации работ. Однако, если вам хочется определенности - думайте, что я говорю про ГОСТ-19.

Значит, первое, и главное. Единицей планирования в ГОСТ является ТЗ. Техническое задание. Вокруг предназначения и сути этого документа много непонимания. Многие путают его с Requirements Specification.

Так вот, это НЕ Requirement Specification. Начать можно с того, что правильно составленное ТЗ обычно гораздо короче, и в секции “технические требования” содержит в основном ключевые требования, определяющие успех всей работы. Почему? Потому, что эта секция - только одна из секций документа, который суть “Задание”, а не требования.

Вторая главная секция - поэтапный план работ. Это простая таблица - последовательность этапов выполнения работы. В ГОСТ есть список стадий и этапов, но этот список носит рекомендательный характер. На практике у вас есть полная свобода в определении количества этапов, их названий, и состава работ.

Итак, что такое “этап”? Этап имеет срок окончания, название, описание результатов этапа, и (наименее важная, информационная составляющая) - перечень видов работ-активностей, которые выполняются в рамках этапа. Если оплата работ сдельная - в этой же таблице стоят суммы за каждый этап, и ТЗ - является приложением к договору подряда.

Почему активности - наименее важная составляющая? Потому, что ГОСТ не содержит никаких инструментов контроля, выполняются на самом деле эти активности, или нет. Этап проверяется по результатам. Точка. А активности - указываются для того, чтобы заказчику было понятно, чем люди заниматься будут, и почему у этапа такие сумма и сроки.

Итак, что такое ТЗ? ТЗ, это комбинация ключевых требований, определяющих успех работ, и поэтапного плана данных работ. ТЗ - это единица планирования. Это не “требования”. Это - задание.

ТЗ определяет, что должно быть сделано (ключевые признаки успеха проекта), в какие сроки, каковы промежуточные этапы (точки контроля). И кроме этого - он определяет требования к проведению работ (дополнительные ограничения на выполнение), к обеспечению работ и испытаний (что необходимо для выполнения работ и для проведения приемки - это обязан предоставить выдающий задание), а также - к проведению испытаний (обычно, там дается ссылка на документ “программа и методика испытаний”).

Ближайшим аналогом ТЗ является Project Charter, если угодно.

А еще в ТЗ есть очень короткая секция, в самом начале, с которой у большинства есть огромные проблемы. Но - в которой состоит весь дзен ТЗ. Называется “Цели и задачи работы”.

В чем состоят проблемы? В неумении людей отличать цели от задач. Типичное содержимое - “целью работы является разработка системы Х. Задачами работы, э-э-э… Чорт! Что здесь писать? являются проектирование, кодирование, и отладка системы Х”.

Надо ли говорить, что разработка (т.е. процесс) не может являться целью работ? По опыту знаю - не только надо, но надо еще и пояснить. Смотрите:

“Задача - достать денег в партийную кассу, предотвратив тем самым закрытие типографии” - таковы цели и задачи Грина в одном из эпизодов “Статского Советника” Акунина.

“Задача - достать денег, с целью хорошо отдохнуть в Европе” - казалось бы, другая цель, но какая разница, если выполнять надо одну задачу - достать денег? А разница очень большая.

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

Хорошо отдохнуть в Европе - цель не срочная, сильно рисковать ради ее достижения глупо, ибо отдыхать будет некому. Понятно? Понимание цели дает исполнителю возможность додумать детали и расставить приоритеты.

И в конце концов, раз у вас затруднение с формулировкой цели работ, и она дублирует задачи - может быть, работу вообще не стоит выдавать? Ну, раз выдающий задание не в состоянии внятно объяснить, зачем нужен результат работ? То, может, и работа не нужна?

Ок, переходим на конкретику. Задача работы - получить работоспособную реализацию аудиокодека Dolby Digital. А вот с какой целью? Проще выражаясь - зачем он нам нужен, ради чего вообще эта работа затеяна, для решения какой проблемы? Плевать, что вам это очевидно - это необходимо довести до исполнителей.

Если с целью испытаний архитектурного прототипа медиаплеера - это одно. Берем GPL-реализацию, и допиливаем. Главное в данной работе - архитектуру проверить как можно быстрее, а не ковыряться с одним из десятка кодеков.

Если же с целью использования в конечном продукте - тут уже совершенно другое дело. Абсолютно другие требования к качеству, и GPL лицензия не подойдет.

Цель работ, т.е. решаемая работой проблема, rationale, стоящее за задачей - обязательно должны быть обозначены явно. Для этого, в принципе, допустимо ввести отдельную “главу” в ТЗ - она называется как-то вроде “характеристика предметной области” (забыл, как она точно называется, см. ГОСТы в сети), где простым человеческим образом описать проблему. Можно это сделать в той же самой секции “цели и задачи”.

Здесь многие знатоки ЕСПД-ЕСКД со мной не согласятся. Ибо - общая практика такова, что к данной секции относятся наплевательски - лень мозги включать. Не без греха и автор этих строк - бывало, что писал в эту часть полную хрень. Но я скажу - вне всякого сомнения, “цели и задачи работы”, вкупе с описанием решаемой проблемы - самая важная секция ТЗ. И умение отделять цели от задач - ключевое в составлении ТЗ и менеджменте вообще.

Теперь два фокуса.
1) Вас могут не устраивать фиксированные даты окончания этапов. Пишете в соответствующей графе: “в соответствии с ведомостью исполнения”. И все ок.
2) Вас может волновать отсутствие детально расписанных требований в документе ТЗ. Волноваться не надо - у вас есть “программа и методика испытаний”.

Этот документ - именно, что программа (то есть, тест-план), и методика (общие принципы построения тест-плана и организации тестирования). Этот документ - фиксирует требования в конструктивной форме. Хреначьте в него свои юз-кейсы и юзер-стори. И включайте наличие первой версии этого документа в результат первого этапа.

Далее - вы сможете отслеживать прогресс работ по количеству проходящих пунктов этого “документа”. Вот и весь фокус.

Вкратце - все. Но к самому интересному моменту мы только подошли. Вы видите - ТЗ это очень укрупненный план. Вот у вас есть ТЗ на весь проект. Что же делать дальше? Составлять WBS? Рисовать задачи?

Черта с два. Единственная “задача” - это ТЗ. Правильный ответ - выделять частные, более мелкие ТЗ, на более мелкие работы. И так - до самого мелкого уровня. Две главных секции - я показал. Это технические требования плюс поэтапный план.

Вот в этом и состоит второе важное отличие схемы ГОСТ от классической. План работ - это совокупность заданий, на каждое из которых выписано ТЗ. Результат каждого задания - конкретный и проверяемый. Проходит обязательную приемку. Задание может иметь промежуточные этапы - каждый из которых также проходит приемку.

То есть, в отличии от классики, ГОСТ:
1) Объединяет планирование и управление требованиями в единую технику.
2) Явно фокусируется на результате работ, а не на процессах и активностях.
3) Опирается на одну и ту же технику при управлении программой и проектом. Он предполагает, что вы вместо выдачи “заданий”, будете дробить крупные “проекты” на “подпроекты”, концентрируясь на результатах каждой задачи и этапа.
4) Не предполагает отдельной роли “менеджера”. Все, кто завязан в процесс - в той или иной степени инженеры. Задание-то “техническое”, как ни крути.
5) Совместим со стилем управления Auftragstaktik, про который я много писал.

Когда вы понимаете принцип, стоящий за ГОСТ (а ГОСТ были изначально разработаны для управления большими программами, вроде разработки комплексов ПВО), все становится очень просто и симпатично.

Настолько - что вы можете даже не писать документов-ТЗ. Честно. Смотрите: Берете Redmine.
1) Иерархия ТЗ - это иерархия проектов и подпроектов.
2) Этапы - это “версии” для каждого проекта.
3) Технические требования - можете в вики писать, а можете задавать тикетами. Это уж как душе угодно.

Вот вам и все управление. Просто, симпатично, и, самое главное - отлично работает.

Я даже скажу так. Это - одна из немногих техник, которая действительно работает на практике.

Я расскажу о нюансах использования тега <audio> в разных браузерах при разработке игр, о проблемах, с которыми я столкнулся и о том, как их решить. Объяснение будет идти параллельно с написанием обертки для удобной работы.

Элемент Audio имеет очень красивый интерфейс, но нам его надо расширить, потому напишем обертку:

var LibCanvasAudio = function (file) {
this.audio = new Audio;
this.audio.src = file;
};
LibCanvasAudio.prototype = {};

.ogg vs .mp3

Для начала — муть с поддерживаемыми кодеками. Большинство браузеров поддерживает ogg vorbis(для Оперы в Линуксе не забудьте установить gstreamer base и good плагины), но, например, Apple решил выебнуться. Давайте для вменяемых браузеров будем отдавать в .ogg, всем остальным — в .mp3. Все звездочки в имени файла будем заменять на ogg или mp3 соответственно:

var LibCanvasAudio = function (file) {
this.audio = new Audio;
this.src(file);
};
LibCanvasAudio.prototype = {
src : function (file) {
var codec = this.getSupport();
if (!codec) throw ‘AudioNotSupported’;
this.audio.src = file.replace(/\*/g, this.getSupport());
this.audio.load();
return this;
},
getSupport : function () {
return !this.audio.canPlayType ? false :
this.audio.canPlayType(’audio/ogg;’) ? ‘ogg’ :
this.audio.canPlayType(’audio/mpeg;’) ? ‘mp3′ : false;
}
}


Схема Гатлинга

Мы подошли к главной теме. Допустим, мы разрабатываем экшн. У нас огромное количество взрывов, выстрелов, етс. Допустим, один взрыв с эхо длится 5 секунд, а интервал между взрывами может быть 0.5 секунд. Если просто запускать файл сначала, то предыдущий взрыв резко оборвется. Мы могли бы клонировать элемент Audio каждый раз перед запуском, но так мы будем плодить кучу DOM-элементов. Приблизительно через 5 минут игры все браузеры сходят с ума. Потому предлагаю воспользоваться схемой Гатлинга. Заносим определенное количество элементов в массив и вызываем их по очереди. Пока сыграет последний элемент первый успеет закончиться. Главное — выставить достаточно количество «стволов» для каждого из звуков.

LibCanvasAudio.prototype = {
// …
cloneAudio : function () {
audioClone = this.audio.cloneNode(true);
audioClone.load();
return audioClone;
},
gatling : function (count) {
this.barrels = [];
this.gatIndex = 0;
while (count–) {
this.barrels.push(this.cloneAudio());
}
return this;
},
getNext : function () {
var elem = this.barrels[this.gatIndex];
++this.gatIndex >= this.barrels.length && (this.gatIndex = 0);
return elem;
},
playNext : function () {
var elem = this.getNext();
elem.pause();
elem.currentTime = 0;
elem.play();
return this;
}
};

Интерфейс у нас получается приблизительно такой:

var shotSound = new LibCanvasAudio('explosion.*').gatling(6);
window.addEventListener(’keydown’, function (e) {
(e.keyCode == keys.SPACE) && shotSound.playNext();
}, false);

Облом в Опере

В Опере нас ждёт облом. Детально изучив этот вопрос нашел баг, который я зарепортил с кодом DSK-309302. Клонированный элемент Аудио в Опере не работает:

// var audioOrig = document.createElement('audio'); // аналогично с:
var audioOrig = new Audio();
audioOrig.src = ’shot.ogg’;
audioOrig.controls = ‘controls’;
var audioClone = audioOrig.cloneNode(true);
function appendToBody (node) {
document.getElementsByTagName(’body’)[0].appendChild(node);
}
audioOrig.play(); // работает
audioClone.play(); // не работает в Опере
appendToBody(audioOrig); // работает
appendToBody(audioClone); // не работает в Опере

Напишем небольшой фикс для Оперы:

LibCanvasAudio.prototype = {
// ..
cloneAudio : function () {
if (window.opera) { // Reported Opera bug DSK-309302
var audioClone = new Audio;
audioClone.src = this.audio.src;
} else {
audioClone = this.audio.cloneNode(true);
}
audioClone.load();
return audioClone;
},
// ..
};

Баг в Фоксе

Другой баг мы можем наблюдать в firefox 3.5 (в 3.6 и 4 уже нету) — при повторном воспроизведении аудиотрека первая секунда± — дублируется. Судя по всему, не только у меня: «the second time you hit the button it plays the “badumm” twice in Firefox». (видео с записью бага). Добавим небольшой фикс — будем отматывать аудио не в начало, а на 25 миллисекунду (минимальное значение установлено экспериментально и равно приблизительно 0.021-0.022 секунды). При желании можно добавить проверку версии и всех кроме 3.5 фокса возвращать в начало (но разница между 25 миллисекундой и нулевой не ощущается, в крайнем случае, зная про этот нюанс можно всё аудио отодвинуть в любимом аудиоредакторе на 25 миллисекунд влево):

LibCanvasAudio.prototype = {
// ..
playNext : function () {
var elem = this.getNext();
elem.pause();
elem.currentTime = 0.025;
elem.play();
return this;
}
};

Бонус

В IE9 preview 4 не работает new Audio(), но это очень просто решить, заменив его на document.createElement('audio');

Исходник, получившийся в результате: pastebin.com/xG4mhX3w

Что такое CouchDB для вас? Вероятно любой, кто хоть немного интересуется популярной нынче темой NoSQL, прекрасно знает общие детали: это такая симпатичная игрушка с map/reduce-запросами, которые пишутся на Javascript, с которой можно работать, гоняя JSON по HTTP-протоколу, а также не исключено, что слышали, что она fault-tolerant, то бишь не ломается вообще. Дальше этого обычно дело не идёт, в результате CouchDB отправляется в delicious в общую кучу со всякими MongoDB, Cassandra, Hadoop и т.п.

Примерно такого мнения придерживался и я вплоть до недавнего времени, пока не возникла острая необходимость переосмыслить архитектуру текущего проекта (упёршегося лбом в свою реляционную БД) и пересесть на документную базу данных, которая бы умела map/reduce. После того, как более пристально взглянул на CouchDB, я понял, что он уникален в своём классе, его не следует ставить в один ряд с упомянутыми продуктами. Идеи, которые заложены в CouchDB, настолько концептуальны, что способны в корне перевернуть представление о разработке веб-приложений.

Сразу хочу сказать, что если вы уже имеете определённый опыт использования CouchDB, то, вероятно, что вы уже и сами «с усами» и эта статья не для вас. А вот что касается остальных, то может после прочтения появится желание и возможность прилечь на такой вот красный диван и расслабиться, как и рекомендуют разработчики CouchDB.

Следует сказать, что шумиха вокруг CouchDB вплоть до последнего времени несколько поутихла, хотя за последний месяц твиттер буквально взорвался новостями о релизе CouchDB 1.0 и о выходе Cloudant из фазы закрытого Beta-тестирования (о чём я расскажу чуть подробнее ниже). Это событие толком не было освещено. Такую несправедливость надо исправлять, так как, если вы помните CouchDB как сырую альфу с медленными insert-ами и бешеным потреблением памяти и процессора, то забудьте — это всё уже в далёком прошлом. На сегодняшний день это production-ready система с доступной коммерческой поддержкой и реальными примерами использования в production такими компаниями как BBC, например.

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

map/reduce

Казалось бы, что здесь сложно кого-то чем-то удивить. Многие NoSQL базы данных используют именно эту парадигму доступа к данным, которые не имеют строго определённой схемы. Плюс ещё настораживает использования Javascript для описания map/reduce-функций. Первое впечатление — это же должно быть страшно медленно, ведь как минимум map() необходимо выполнять для каждого документа в базе данных. Плюс ещё и движок-то SpiderMonkey — далеко не V8 по быстродействию. В чём же подвох?

Зоркий глаз узреет, что вобще-то в CouchDB используется не map/reduce чистом виде, а т.н. incremental map/reduce. Вся идея заключается в том, что CouchDB не расчитывает свои представления (так называемые views — результаты выполнения функций вроде map() и reduce()) каждый раз. Это делается только при первом обращении к новому представлению, после чего результат спокойно индексируется и ID документов спокойно попадают в B+-дерево по нужному нам ключу с дополнительной информацией в узлах (а также результатами промежуточных редьюсов). Далее всё просто: когда в базу попадает новый документ (или изменяется старый) для него один раз вызывается map() после чего он кладётся в дерево индекса. Т.е. нет необходимости перерасчитывать индекс целиком, дерево просто инкрементно достраивается.

Когда нам нужны результаты, Couch просто отдаёт нам то, что уже посчитано заранее, нет необходимости заново обходить документы, выполняя map(). В отличие от того, чтобы проиндексировать несколько отдельных колонок для ускорения поиска, как делает большинство баз данных, мы проиндексировали все результаты запроса одним махом. Представьте себе MySQL, которому вообще не нужно «выполнять» запрос — он может сразу достать все его результаты из одного единственного индекса.

Единственный аналог, который приходит в голову — это материализованные представления данных (materialized views) из «больших» РСУБД вроде Oracle, но только намного более легковесный. Не забывайте, что хранится только индекс результатов и только нужные вам значения — избыточность не такая уж большая по сравнению с обычными базами данных с кучей индексов, ведь индексируются только результаты map/reduce — те данные, которые вам нужны в контексте данного запроса, а не все колонки. Да и винты нынче дешёвые относительного того потенциала, который сулит этот метод.

I need more power©

Тот факт, что map() по сути выполняется один единственный раз для каждого нового/изменённого узла, очень интересен. Это позволяет выполнять довольно тяжёлые операции над новым документом, все равно это делается единожды. И если вам кажется, что со встроенным Javascript рантаймом особо не разгонешься, то тут всплывает ещё одна интересная особенность CouchDB — на самом деле он не завязан ни на какой конкретный язык, а использует абстракцию в виде View-сервера. Т.е. вы просто подключаете view-сервер для вашего любимого языка программирования и пишите map() и reduce() например на Python, пользуясь его его богатой стандартной библиотекой.

По большому счёту никто не мешает вам при добавлении нового документа прямо из map() осуществить геокодинг адреса вашего добавляемого в базу клиента с помощью внешнего сервиса (Google Maps API например) и посчитать для него геоиндекс другой внешней библиотекой. Или просто взять и проиндексировать ваш документ с помощью Sphinx, получив ещё и супербыстрый полнотекстовый индекс вашей БД (если недостаточно хорошей интеграции с Apache Lucene). В общем? простор для творчества ограничен только фантазией.

Если нужно больше скорости, то все ваши view-функции можно переписать на C, воспользовавшись тем фактом, что интерфейс view-сервера прост как лопата, а view в CouchDB — это точно такой же документ, а точнее design-документ со специальным ID. Поэтому ему совсем не обязательно содержать непосредственно код функций — можно положить туда в том числе любой идентификатор, который будет понятен вашему view-серверу. В общем заметно, что вот это идейное единство данных и инструкций по их обработке в виде точно таких же данных сродни идеологии Lisp.

Пусть говорят, что map/reduce парадигма не обеспечивает такой мощи как SQL-запросы, но на практике просто нужно научиться мыслить её категориями. Так например заблуждение, что JOIN нельзя сделать без SQL, т.к. джойны не масштабируются и так далее. Это всё не лишено смысла, тем не менее заявление слишком общее. Во-первых документ можно содержать не только пары ключ-значение, но и коллекции, другие объекты и всё остальное, что можно описать пользуясь JSON, ну а во-вторых даже более сложные join-ы можно реализовывать, зная основные паттерны — реализация map/reduce в CouchDB очень мощная и в то же время понятная и логичная.

Веб как он есть

В отличие от большинства альтернатив, CouchDB разрабатывался в первую очередь как база данных для нужд веб-приложений. Отсюда корни такого нетривиального решения как доступ к базе через REST-интерфейс. Да, у HTTP в чистом виде, есть оверхед, но он полностью компенсируется тем, насколько элегантным является это решение. Во-первых вам не нужно искать драйвер для любимого языка программирования — любой HTTP-клиент справится (все примеры — это чаще всего curl прямо из командной строки). Более того, таким клиентом может быть веб-браузер. Можно написать веб-приложение вобще не используя какой-либо middleware на сервере — с базой можно работать при помощи Javascript через Ajax (например CouchApp — фреймворк на базе jQuery от создателей CouchDB).

После старта Couch ведёт себя словно обычный HTTP-сервер, вы можете зайти на него с помощью вашего браузера и выполнять GET-запросы просто используя строку адреса вашего браузера, получая JSON в качестве результата. А также сразу будет доступен Futon — административный интерфейс CouchDB-инстанса. Кстати он реализован полностью на Javascript без серверного middleware, расширяем и умеет много всего интересного несмотря на свою простоту.

Едва ли стоит говорить о том, что HTTP-протокол реализован правильно, поддерживается кеширование и Couch знает когда отдать 304. Аналогично документ может содержать бинарные вложения (attachments — эквивалент (B)LOB), которые Couch хранит нативными файлами и отдаёт просто как статический контент. Design-документы могут также содержать show() и list(), которые позволяют преобразовывать возвращаемые результаты как угодно, например в HTML-страницы и отдавать их непосредственно браузеру. И если ранее вы придерживались мнения, что хранить аватары пользователей и картинки от товаров вашего Интернет-магазина прямо в вашей [реляционной] БД плохо, то с CouchDB всё обстоит по-другому — иногда даже данные без жесткой схемы могут оказаться в определённых случаях более структурированными и целостными.

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

Масштабирование

О CouchDB раньше обычно говорили, что он не масштабируется. Действительно не так давно это было правдой, но только на половину. Обо всём по порядку.

Одна из ключевых и самых интересных особенностей CouchDB — его репликации. Читатель возможно удивится, как репликации могут быть интересными в принципе, воспринимая их как своего рода костыль. В Couch-е всё не так, его репликации проектировались изначально при создании БД. Во-первых они умеют master-to-master, что позволяет вам делать все инстансы одинаково функциональными, а не делить их на master/slave. Проблемой такой репликации в «обычных» базах данных являются потенциальные конфликты. Поэтому Couch (обладающий свойством MVCC), при возникновении конфликта сохраняет все конфликтующие версии и умеет эти конфликты разрешать, по сконфигурированным правилам (либо отдать это дело в руки вашего приложения — как вы захотите этим воспользоваться, зависит только от вашей фантазии). Сама по себе репликация сводится к дёрганию URL из REST-ового API CouchDB (или воспользовавшись Futon, можно просто ввести URL другой базы и нажать кнопку) вот так вот это всё сложно.

Так что вот едете вы в транспорте, пописываете что-то там во всякие твиттеры с вашего Nexus One (я разве не упомянул, что CouchDB полностью функционален на телефонах с Android, а также Maemo/MeeGo?), и тут въезжаете в туннель — коннект теряется. Вы можете спокойно продолжать пользоваться приложением, которое по возвращению коннекта сможет слить новые сообщения и залить то, что вы написали одним API-вызовом, не изобретая велосипедов. Например, если вы пользуетесь Ubuntu One, то вы уже используете CouchDB именно таким образом.

Но не будем отвлекаться от темы. Такие репликации — это конечно хорошо (особенно в свете HTTP-природы CouchDB: можно поставить перед кластером Couch-ей обычный балансер и не переживать), но это не является «настоящим» масштабированием. Репликациями и реляционные БД умеют масштабироваться (хоть и далеко не так элегантно), а что насчёт шардинга? Ведь все хотят размазать данные по кластеру и просто путём добавления нода увеличить объём доступного дискового пространства, максимальную нагрузку, пиковое количество пользователей и так далее, не теряя при этом в скорости. CouchDB делать этого из коробки не умеет. Пока. Но это лишь вопрос времени.

А вот Cloudant умеет. Cloudant — это новый сервис, который буквально пару дней назад завершил Beta-тестирование и теперь доступен каждому. Это хостинг вашей CouchDB-базы данных (на облаке от Amazon), а то и всего приложения, учитывая, что CouchDB может служить не только БД, но и middleware. Ребята воспользовались заложенным в CouchDB потенциалом, и развивают свой fork (который в скором времени имеет шансы стать частью trunk-а), который неограниченно масштабируется шардингом, в который в любой момент можно добавить новый node, также он обеспечивает избыточность — каждый документ хранится в трёх экземплярах на разных node-ах на тот случай, если один из node-ов отвалится. Более того, помимо полной поддержки стандартного API, Cloudant позволяет осуществлять map/reduce по результатам другого map/reduce и имеет ещё много интересных особенностей.

Весь код открыт, так что можете поднять и использовать Cloudant на приватном облаке. А ещё можно зарегистрировать бесплатный аккаунт (до 250 мегабайт дискового пространства без учёта старых ревизий документов) и попробовать CouchDB вживую — все основные возможности доступны, в т.ч. Futon.

Сегодня

CouchDB в июле дорос до версии 1.0, чем разработчики подчёркивают его стабильность и готовность к production-использованию. Также релиз Cloudant является знаковым для всего CouchDB-комьюнити. Если вы ещё не пробовали Couch, потратьте полчаса вашего времени — можете сэкономить намного больше времени в итоге, хотя это, конечно же, будет зависит от специфики вашего конкретного проекта. Продукт делает именно то, для чего он создавался, но не более. Так что не ждите чуда, но надеюсь, что после прочтения, кто-нибудь расслабится, как рекомендуют разработчики (особенно, если есть красный диван).

UML – язык, давно нашедший свое уникальное место в процессе проектирования IT-систем. Он облегчает рутинную работу и улучшает понимание между различными членами проектной команды – от системных аналитиков до архитекторов и разработчиков. Первый вопрос, с которым сталкиваются те, кто решил использовать моделирование на UML в своей работе – это какой инструмент выбрать. Обзор существующих инструментов приводится в статье Александра Краковецкого «Инструменты для рисования UML-диаграмм»
Читать статью

Проблемам управления рисками посвящены две статьи в этом выпуске: статья Владислава Балина «Инженерная деятельность, ошибки и риски», которая является вступлением к его докладу об управлении рисками в софтверных и инженерных проектах, и статья Константина Кондратюка «Риски, паникеры и негодяи». Первая дает целостный взгляд на проблему управления рисками в проектах, относящихся к IT-индустрии, а вторая представляет различные подходы к управлению рисками и рассказывает о результатах их применения.
Читать статью «Инженерная деятельность, ошибки и риски»

Читать статью «Риски, паникеры и негодяи»

События:

7-8 октября в Москве состоится самое грандиозное в России событие в области юзабилити – User Experience Russia 2010, которая пройдет в этом году в четвертый раз и будет посвящена вопросам юзабилити, проектированию и взаимодействию с пользователем услуг в интернете.
В этом году конференция пройдет при поддержке европейской ассоциации юзабилистов UPA Europe.

В программе конференции ожидается 40 докладов ведущих экспертов области, а также множество подарков и сюрпризов! К примеру, американская компания Розенфельд Медиа выступила спонсором конференции и проведет розыгрыш книг от Розенфельд Медиа. Также каждый участник получит 20%-скидку на всю продукцию компании.

Торопитесь зарегистрироваться на User Experience 2010! Стоимость участия при оплате до 1 сентября составляет 10 000 руб., при оплате до 7 октября – 12 500 руб.

Новость от Спанч Боба

Как программисту рассказать о том, чем он занимается? Можно уныло перечислять свои заслуги, а можно подойти к решению проблемы творчески. Например, так:

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

5 августа 2010 г. вышла третья альфа-версия Убунту 10.10 — Maverick Meerkat Alpha 3, — вобравшая в себя функциональность, подготавливаемую для следующей стабильной версии системы, которая выйдет 10 октября этого года (10.10.10).

Обновление с Ubuntu 10.04 LTS

Обновиться до третьей альфы с Ubuntu 10.04 LTS на десктопной версии можно с помощью команды:
update-manager -d

Запустившийся Update Manager сообщит о наличии новой версии 10.10. Нажмите «Обновить» и следуйте указаниям программы.

Чтобы обновить серверную Ubuntu 10.04 LTS, необходимо:

1. Установить пакет update-manager-core (если он ещё не установлен);
2. Отредактировать /etc/update-manager/release-upgrades и установить Prompt=normal;
3. Запустить менеджер обновлений командой sudo do-release-upgrade -d;
4. Следовать указаниям программы.

Что нового в Maverick Meerkat

Началась разработка функциональности для Maverick, подробности доступны в спецификациях Maverick.

Среди прочего, она содержит глобальное меню приложения (здесь есть много скриншотов Unity, а также видео).

Индикатор даты/времени теперь предоставляет настоящий виджет календаря:

Просьба тестировать релиз и сообщать о багах.

Обновления пакетов

Как обычно бывает при подготовке новой версии, пакеты (приложения и прочее ПО) обновляются очень часто. Многие из этих пакетов поступают автоматически при синхронизации с веткой Debian Unstable. В данный момент период автоматической синхронизации окончен, поэтому теперь изменений будет не так много.

Список пакетов, принятых для 10.10 Maverick Meerkat, вы можете получить, подписавшись на maverick-changes.

Ubuntu

GNOME обновлён до текущей версии 2.31. Она, в частности, включает API dconf и gsettings. Evolution обновлена до версии 2.30, и работает теперь намного быстрее по сравнению с версией, вошедшей в Ubuntu 10.04 LTS.

Ubuntu Netbook Edition

По умолчанию оболочкой в нетбучной редакции Убунту теперь является Unity.

Также стоит отметить и редизайн меню регулятора громкости, впервые появившийся в прошлой альфе:

В качестве стандартного менеджера фотографий теперь используется Shotwell.

Kubuntu

KDE обновлена до 4.5 release candidate. Веб-браузер по умолчанию теперь Rekonq, основанный на Webkit. Qt обновлена до текущей версии 4.7 beta.

Xubuntu

Xfce4 обновлена до текущей версии 4.6.2, в которой исправлено множество багов и обновлены многие программы, использующиеся в Xubuntu. Новые программы по умолчанию: медиаплеер Parole вместо Totem Movie Player, программа для записи дисков Xfburn вместо Brasero, менеджер процессов xfce4-taskmanager вместо Gnome-Task-Manager.

Edubuntu

Edubuntu наследует все изменения из Ubuntu. Пакет edubuntu-artwork был разделён на несколько меньших пакетов, чтобы упростить установку обновлений и уменьшить размеры загружаемых файлов.

Software-Center

На стартовой странице software-center появились разделы «Лучшее» («Featured») и «Новое» («What’s New»). Приложение стало работать быстрее, интерфейс стал отзывчивее, добавлена функция «История» («History»), где представлен список того, что было установлено, удалено и обновлено. Добавлена поддержка расширений (плагинов), по умолчанию специфические технические записи не отображаются.

Ядро 2.6.35

Alpha 3 поставляется с ядром 2.6.35-14.19, основанным на финальной версии 2.6.35.
Это ядро содержит ряд улучшений, связанных с безопасностью. Одно из самых важных нововведений изменяет стандартное поведение PTRACE, используемого gdb, strace, ltrace и т. д. Начиная с Убунту 10.10, только дочерние процессы могут быть оттрассированы, что обусловлено исходным значением 1 в /proc/sys/kernel/ptrace_scope. В некоторых системах такое значение может вызывать проблемы, например, в системах, используемых для разработки, и серверах, где имеются только администраторские учётные записи. Если использование sudo для PTRACE нежелательно, необходимо установить это значение в 0.

Образы Ubuntu Server Cloud

cloud-init, настраиваемый процесс инициализации облака Ubuntu Server, приобрёл новые вохможности ещё в Maverick Alpha 2, среди которых pluggable hooks, ebsmount, поддержка ext4 и новые параметры в формате cloud-config.
Начиная с Alpha 3, экземпляры облака могут управлять собственным ядром, включая обновление ядра с помощью apt. Это делается с помощью предоставляемой Амазоном утилиты pv-grub.

Установка

Теперь при установке можно использовать новую файловую систему btrfs (при ручном разбиении), если раздел /boot поместить на другой системе.

Загрузка Alpha 3

Налетай, пока не остыло! ISO-образы и торренты доступны:

Ubuntu Desktop, Server и Netbook
Ubuntu Server для UEC и EC2
Kubuntu Desktop и Netbook
Xubuntu
Edubuntu DVD
Ubuntu Studio

Ubuntu ARM

Известные проблемы

На данной стадии подготовки к релизу является закономерным наличие некоторых известных проблем, с которыми пользователи могут столкнуться в Maverick Alpha 3. Здесь собраны описания таких проблем, а также возможные исправления их, чтобы вы не теряли времени, вновь сообщая об этих багах.

• Установка в режиме OEM завершается неудачно при отсутствии подключения к Интернету вследствие неудачной установки пакета oem-config из установочного образа. Если вам это требуется для тестирования, обеспечьте постоянное подключение к Сети в течение всей установки (613008)
• Установщик для Windows Wubi завершается со сбоем. Проводится изучение проблемы (600578, 613288).
• Ubuntu Netbook Edition с оболочкой Unity в настоящее время не предоставляет обходной возможности для систем с видеодрайвером, не поддерживающим 3D-ускорения, как, например, NVidia (600567).
• В системах с малым количеством памяти (256 МБ или меньше), ureadahead вызывает ошибки недостатка памяти, что может привести к невозможности загрузки (600359).
• Приложения, использующие sqlite3, сталкиваются с множеством проблем, связанных с производительностью и правильностью выполнения запросов, например, banshee (612370).
• Пререлизная версия Eucalyptus 2.0 включена в состав Alpha 3, хотя в ней до сих пор имеется ряд проблем. Например, регистрация после установки работает ненадёжно (609112), сложные топологии (такие, например, как отделяющие CLC от Walrus) пока не поддерживаются (613033). При установке узловой («node») системы будьте готовы получить две проблемы с grub, которые могут быть проигнорированы без последствий (613463).
• KDM выдаёт таймаут при загрузке с образа Kubuntu Live, после чего запуск отказоустойчивой X-сессии должен быть возможен (613574).

Сообщения об ошибках

Не следует сильно удивляться также, что в альфа-версии Maverick Meerkat могут присутствовать прочие ошибки. Ваши комментарии, отчёты об ошибках, патчи и предложения помогут внести необходимые исправления и улучшить будущие версии. Чтобы сообщить об ошибке, воспользуйтесь стандартными средствами.

Если же вы хотите помочь в исправлении ошибок, то вам надо в Bug Squad, где всегда рады новым силам.

Помощь Убунту

Если вы хотите внести свой вклад в будущее Убунту, ознакомьтесь со списком возможных способов участия в её судьбе.

Прочая информация

Вы можете найти дополнительную информацию об Убунту на веб-сайте и в Ubuntu wiki.

Можно также подписаться на рассылку для разработчиков Убунту (Ubuntu’s development announcement list).

Недавно (весной этого года) Твитер перепроектировал процесс регистрации, чтобы увеличить количество новых пользователей. И хотя в новой версии в регистрацию добавилась ещё одна страница, то есть дополнительный шаг, конверсия всё равно выросла на 29%. Почему это произошло? Благодаря постепенному вовлечению.

Постепенное вовлечение — это процесс перемещения пользователя по приложению или сайту, фактически “пробуя” его и видя все его преимущества. В обычном процессе регистрации пользователю показывают форму, которую необходимо заполнить. Здесь наоборот, регистрация или отложена на потом, или происходит в фоне, а первый опыт пользователя сфокусирован на том, чтобы показать, как использовать сервис и зачем он вообще нужен.

Перевод статьи

Правильное постепенное вовлечение рассказывает пользователю об основной сущности сервиса путём простых взаимодействий. Если вы при этом осчастливите человека — даже лучше. Уилл Райт, создатель Sims & Spore, верит, что игры должны позволять человеку выигрывать в течении первых 5 секунд. Это хорошая философия, чтобы добиться постепенного вовлечения. На самом деле вы можете позволить людям за одно-два простых взаимодействия сделать то, в чём смысл вашего сервиса. Это наилучший вариант.

Термин «gradual engagement» я перевожу как «постепенное вовлечение». По-моему он точно отражает суть, но вы можете указать в комментариях свой вариант.

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

Вот как выглядела регистрация в Твитере до изменений

Она не попала в цель. Если человек решал зарегистрироваться, то его приветствовала форма, где он:

1. должен был создать акаунт,
2. мог найти друзей через свой почтовый акаунт,
3. просмотреть список самых популярных твитерян, которых мог зафоловить, и
4. наконец, если не смог ничего найти или пропустил предыдущие два шага, то видел пустую страницу с вопросом «что вы делаете».

В новой версии после создания акаунта пользователь видит список тем, которые могут его заинтересовать. Темы разбиты по самым популярным категориям (музыка, развлечения, мода, искусство и дизайн), а также включают текущие события, заполненные редакторами твитера.

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

Новая версия регистрации в Твитере

И хотя новый процесс регистрации состоит из 4 шагов вместо 3-х и занимает больше времени, его полностью завершают на 29% больше людей, которые становятся гораздо более вовлечёнными в Твитер, чем раньше.

Лично мне (переводчику тоже) очень любопытно посмотреть, что произошло бы, если бы создание акаунта происходило после того, как люди начали фоловить интересующие их темы и друзей. Сейчас оно идёт до того, как люди получат личные выгоды от Твитера. Как я заметил ранее, настоящее постепенное вовлечение отложит создание акаунта на потом или проведёт его в фоне.

Ещё несколько мыслей

Заставлять людей заполнять формы — это один из способов получить информацию. На сайтах это стандарт де-факто. Но так быть не должно. Вместо того, чтобы каждый раз показывать людям формы, лучше обратиться к принципам постепенного вовлечения.

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

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

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

Для начала опишу требования к инструменту, которые у меня на тот момент были.

• Минимум зависимостей — желательно только PHP (без дополнительных расширений) и MySQL.
• Возможность производить произвольные изменения схемы непосредственно, используя для этого любой доступный клиент (mysql или PHPMyAdmin, например)
• Полностью автоматизированная генерация миграций.
• Возможность использовать инструмент в скриптах или в cron.

В идеале сценарий таков: После экспериментов со структурой БД разработчик запускает генератор миграций, который создает некоторый миграционный файл (миграцию), затем этот файл добавляется под контроль версий. Когда тестовый сервер получает обновление по крону, он также запускает процесс миграции на последнюю версию структуры БД.

Итак, претендент первый: Doctrine 1.2

Это ORM (Object-relational mapping или Объектно-реляционное отображение), написанный на PHP, но тянет за собой достаточно большую библиотеку классов, и требует установленного PDO. Инструмент этот не попадает под первое же требование, но я решил, что можно использовать и его.

Что же предлагает разработчику Doctrine? Для начала нужно сгенерировать конфигурационный файл схемы — это будет описание схемы БД в YAML-формате. Менять схему придется там же, а значит придется ознакомиться с документацией на формат описания схемы.

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

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

Итог: инструмент меня не устроил. Я считаю этот инструмент подходит только для тех проектов, где используется Doctrine. Позже работая с Symfony + Doctrine я нашел еще пару неприятных моментов использования Doctrine Migration, но статья не об этом.

Претендент второй: MySQL Workbench

Это инструмент от Sun(Oracle) с графическим пользовательским интерфейсом. Он позволяет соединиться с базой и построить на ее основе диаграмму таблиц и их связей. В эту диаграмму мы можем вносить любые изменения, при помощи графического интерфейса. Когда изменения внесены мы можем снова соединиться с БД и опубликовать сделанные изменения. Очень удобный инструмент, когда разработка ведется на одной машине и не очень опытным программистом.

Мне же этот инструмент не подошел по причине слишком большого количества ручного труда.

Да и в процессе использования возникали вопросы:

А что если тестовых серверов несколько?

Как наладить обмен ALTER-TABLE-скриптами внутри команды разработчиков?

Еще один вариант:

К этому моменту обмен изменениями БД уже был кое-как налажен. Был написан скрипт ( http://www.antonoff.info/phps/db_migration_tool ) который исполнял только новые *.sql файлы, появляющиеся в определенной папке проекта. Новизну он определял сравнивая дату в имени файла с датой последнего обновления, хранящегося в БД. SQL-скрипты разработчики писали и именовали вручную. Файлы писались уже после того, как изменения внесены в БД на локальной машине разработчика, а потому здесь снова большую роль играл человеческий фактор: забыли написать файл, забыли добавить в файл некоторые жизненно необходимые изменения, наделали синтаксических ошибок и т. п.

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

С этого момента поиски мои шли только в направлении полностью автоматизированного процесса.

Следующим претендентом стал проект, найденный на Google Code:

Mysql PHP Migrations

http://code.google.com/p/mysql-php-migrations/wiki/Installation

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

Ruby on Rails

Перед тем как начать разработку я решил еще проверить как обстоят дела в Ruby on Rails. Там ситуация оказалась такой же печальной: Нужно запустить генератор, чтобы получить на выходе пустой класс миграции, в который опять же стоит добавить код для миграции вперед и назад. К тому же код на ruby, а его в моей команде никто не знал.

Теперь о моей разработке:

http://www.antonoff.info/development/mysql-migration-with-php-project

http://bitbucket.org/idler/mmp

Вот требования которые были предъявлены к ней на старте:

• Минимум зависимостей — желательно только PHP (без дополнительных расширений) и MySQL.
• Возможность производить произвольные изменения схемы непосредственно, используя для этого любой доступный клиент (mysql или PHPMyAdmin например)
• Полностью автоматизированная генерация миграций.
• Возможность использовать инструмент в скриптах или в cron.
• Возможность мигрировать на произвольную версию схемы
• Возможность произвольно именовать таблицу, хранящую версию схемы ( в Doctrine и в MPM имя этой таблицы жестко прошито в коде)
• Возможность вывести список доступных миграций с датами
• Возможность изменять имя каталога в котором хранятся файлы миграций.
• Читабельность кода, который будет создан при генерации класса миграции
• Command Line-интерфейс (другого мне и не нужно)
• Возможность легко добавлять под-команды утилиты (плагины? - Скорее отдельные классы как плагины)

Что мы умеем?

• Создать начальную миграцию.
• Накатить начальную миграцию, т. е. инициализировать первую версию БД
• Создать миграцию, самостоятельно сгенерив весь SQL-код.
• Показать список миграций, пометив текущую звездочкой.
• Мигрировать на указанную дату-время.

Дата-время на которые будет произведена миграция указываются в формате, понимаемом PHP-функцией strtotime.

Как это работает?

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

Зависимости:

Консольная версия PHP >= 5.3.0

Расширение MySQLi (обычно статически слинковано в PHP)

MySQL >= 5.0 (возможно будет работать и на 4.1)

Как использовать?

Три раза в день, по чайной ложке после еды — до полного просветления

Поместите папку с MMP внутрь проекта.

Создайте внутри нее файл config.ini (описание конфига: http://www.antonoff.info/development/mysql-migration-with-php-project )

Создайте начальную миграцию ( ./migration.php schema )

В других установках вашего проекта накатите начальную миграцию ( ./migration.php init )

Изменяйте БД, и создавайте новые миграции ( ./migration.php create )

Чтобы мигрировать на последнюю версию, при получении новых миграций выполните (./migration.php migrate)

Просматривайте список доступных миграций (./migration.php list)

Мигрируйте на произвольную версию ( ./migration.php migrate 2 August 2010 )