Software People

HTML5+ JS приложения для Windows 8. Что внутри + холиварные мысли

Software People Team — Thu, 02 Feb 2012 08:37:57 +0000

Автор статьи: Игорь Сычев

На Build были широко разрекламированы приложения для windows8, которые можно писать на html5. Я раньше считал, что MS взялись за html5 больше из политических-маркетинговых соображений, и не обращал внимание на маркетинговые сказки. Но после build мне стало понятно, что, судя по всему, они взялись очень серьезно, и поэтому на них стоит обратить внимание.

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

Общий вид пустого приложения.

Приложение содержит в себе css,js,html которые и есть основной контент приложений. Так же есть отдельная папка с js,css файлами в которой находятся код framework html5 приложений под win8-WINJS. Собственно мы можем внимательно изучить внутренности, но по лицензии это как .net framework, который можно скачать в исходных кодах, но нельзя по лицензии модифицировать, да и очень сомневаюсь, что кто-нибудь решится “подправить” что-то в такой большой библиотеке.

Внутри приложения есть файл манифеста, такой же как в xaml metro application, о котором я уже писал ранее

Типы страниц

Типы шаблонных страниц в html-js приложениях и xaml идентичные.

Отладка.

Я думаю, самой большой проблемой для разработчиков .net – это отладка js. Все таки мы привыкли к статически типизированным языкам, к отладке их, отлове ошибок еще на этапе компиляции. В Win8 есть новая консоль отладчика js, без которой отлаживаться на мой взгляд вообще невозможно.

Картинки

В WP7 надо было сделать картинки одних размеров, но для win8 придется сделать еще нарезочку из

150*150 logo
310*150 winw logo
30*30 small logo
56*56 storeloge
24*24 badge logo
624*304 SplashScreen

Дизайн

MS рекомендует(активно рекламирует) использовать Blend 5 версии, для создания дизайна. В нем можно и js поправить, но по назначению — это именно дизайн. Мое личное мнение, что 99% разработчиков, как и раньше, не будут использовать Expression, а по-прежнему будут верстать что xaml, что html руками. А также непонятна логика, почему надо было вставлять редактор html в blend, когда есть Expression Web, в котором редактор html уже есть. Кто-то говорит, что “НУ ЭТО ЖЕ НЕ ВЕБ”, но по мне проще переименовать в Expression HTML, чем вставлять поддержку html в другой редактор. Но все же это просто мое непонимание.

Среда исполнения для html приложений

Во время Build нам рассказали, что будет 2 версии браузер ie. Обычный Internet Explorer и IE для Metro приложений. Второй и будет средой исполнения для HTML Metro приложений.

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

Холиварные мысли

Microsoft хоронят уже столько лет, а он все жив. IE хоронят столько же наверное. .Net пытаются хоронить с самого его появления.

Сейчас с появлением возможности писать HTML приложения для Win8 я заметил новый виток холиваров на тему, что MS предала .net разработчиков и мол агитирует за html5. Мол Синофски не любит managed код и по этому появилась WinRT и типа будут двигать С++ как в старину. Мол .net разработчиков 10млн, а html 100 млн (я не верю что так много разработчиков, но важно соотношение 1:10 в которой я склонен верить) и акцент решили сделать на большинство.

Все это на мой взгляд происки заядлых холиварщиков.

По поводу кросслатформенности html5 я имею огромные сомнения. Была уже одна ПАНАЦЕЯ кроссплатформенная, которая в рекламном слогане говорила- «Пиши 1 раз и запускай везде». JAVA называется. В общем убить все остальные платформозависимые языки у нее не получилось, а теперь и о самой java слухов о том, что она умирает более чем достаточно.

Лично я считаю, что HTML5- это СТИЛЬНО, МОДНО, МОЛОДЕЖНО и маркетинг идет через это. + Я пользуюсь Win8 ctp с 20 сентября или уже 2 месяца. В ней много крутых вещей- таких как hyper-v на клиентской ОС, монтирование дисков, новый дизайн проводника, она грузится быстрее… НО это больше для продвинутых пользователей. А для совсем простых пользователей и планшетов нужны именно казуальные приложения для Tile панели. Сейчас приложений просто нет тк win8 еще в CTP. Как только Win8 выйдет, нужно очень быстро будет Market Place заполнить приложениями. Понятно, что их можно портировать с WP7.5, но приложений на html казуальных можно портировать тоже много и быстро.

А Главое- это ведь Tile приложения, никто .net с обычного desktop не выгоняет ведь.

По поводу C++, можно говорить что угодно, но думаю работа с указателями, памятью и прочее- это то, от чего большая часть разработчиков ушла как от страшного сна+ очень много уж кода написано на .net и идти обратно на C++ тяжело будет.

Вот оцените сколько кода надо написать на С++ и на C#/VB.NET чтобы сделать класс

FeedData и скажите, кто готов писать столько строк, явно не самых важных.

Ссылки:

Многоязычные модели Django для начинающих

Software People Team — Thu, 12 Jan 2012 13:47:23 +0000

Автор статьи: Вадим Лопатюк (сайт автора: http://lopatyuk.com/)

Вводная

Работаю я над социальным порталом, который покорит всех от грудничков до маразматиков. И так как цели наполеоновские, нужно учесть возможность использования сервиса даже теми представителями человечества, которые не владеют великим и могучим. Знаю, что многие долго боролись с вопросом локализации именно контента (перевод отдельных полей модели на разные языки), т.к. локализация интерфейса, в пределах общепринятых, в Django решена. Суть проблемы в том, чтобы одна и та же модель (это важно! к примеру, пункты единого для всех языков каталога) имела переводы своих полей на разные языки. Те, кто давно «на игле» этого фреймворка, уже наверняка нашли для себя наиболее подходящую методу решения этой проблемы, я же хочу предложить способ решения и набросать порядок действий для начинающих, чтобы они не сбежали по рельсам на рубиновые копи.

Отмазка

Совсем недавно мне подвернулся счастливый случай начать превращение из личинки-PHP’шника в жука-Python’оида. Так что сразу не бросайтесь в критику. Эта заметка (не статья) представляет из себя HowTo для таких же начинающих.

Используемые материалы

Для локализации моделей мы будем использовать приложение для Django — django-modeltranslation. Я выбрал именно его среди прочих по следующим причинам:

работает с Django 1.3
добавляет переводимые поля для языков в ту же таблицу, т.е. не будет лишних JOIN‘ов
не требует внесения никакого кода в уже существующие модели
почти безболезненно включается и отключается
в админке локализованная модель интегрируется с другими модулями (меня волновал mptt)

Ещё понадобится South — установленный и работающий.

Собственно всё (не считая рабочего/разрабатываемого сайта на django).

HowTo

Устанавливаем modeltranslation командой pip install django-modeltranslation.

Или качаем последнюю версию django-modeltranslation. Распаковываем, заходим в распакованный каталог и устанавливаем python setup.py install. Можно сразу из распакованного каталога руками закинуть в папку для статических файлов директорию modeltranslation/static/modeltranslation.

Далее работаем уже с нашим проектом

Добавляем 'modeltranslation' в INSTALLED_APPS файла настроек
settings.py.

В тот же файл добавляем описание необходимых локализаций, язык по-умолчанию и импортируемый файл регистрации локализуемых моделей. В последнем MYPROJECT — нужно заменить на имя вашего проекта (оно же имя папки в которой он размещается), а translation — на имя самого .py файла без расширения, по умолчанию это translation.py. Этот файл один на весь проект и кладётся, соответственно, в корень проекта.

LANGUAGES = (
    ('ru', 'Russian'),
    ('en', 'English'),
)

MODELTRANSLATION_DEFAULT_LANGUAGE = 'ru'

MODELTRANSLATION_TRANSLATION_REGISTRY = 'MYPROJECT.translation'

В этом самом файле нам нужно создать классы содержащие указание какие поля (здесь это 'name' и 'description') нужно переводить и привязать эти классы к переводимым моделям (здесь это 'Modelka') Ваших приложений (здесь это 'app') сответствтенно:

# -*- coding: utf-8 -*-

from modeltranslation.translator import translator, TranslationOptions
from app.models import Modelka

class ModelkaTranslationOptions(TranslationOptions):

    """
    Класс настроек интернационализации полей модели Modelka.
    """

    fields = ('name', 'description',)

translator.register(Modelka, ModelkaTranslationOptions)

В этом месте можно сгенерировать миграцию python manage.py schemamigration app --auto.

South обнаружит новые поля для локализации и сгенерирует миграцию для их добавления. К слову если отключить приложение 'modeltranslation' — то также можно сгенерировать и миграцию для их удаления. Кроме того отдельное удобство в том, что modeltranslation привязывает язык по-умолчанию к оригинальным полям модели, т.е. это поле локализации и переводимое оригинальное поле модели будут идентичны.

Не забудьте потом применить миграцию: python manage.py migrate app.

И, наконец, настраиваем админку.

Очень важно чтобы админка описывалась в отдельном файле admin.py для каждого приложения!!! А не в файле моделей, как, признаюсь честно, по-началу пытался сделать я.

Для образца сразу приведу пример использования локализованной админки с админкой mptt:

# -*- coding: utf-8 -*-

from django.contrib import admin
from mptt.admin import MPTTModelAdmin
from modeltranslation.admin import TranslationAdmin

from models import Modelka

class ModelkaAdmin(MPTTModelAdmin, TranslationAdmin):
    """
    Настройка админки для Modelka.
    """

    list_display = ('name',)

    class Media:

        js = (
            '/static/modeltranslation/js/force_jquery.js',
            'http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.2/jquery-ui.min.js',
            '/static/modeltranslation/js/tabbed_translation_fields.js',
        )
        css = {
            'screen': ('/static/modeltranslation/css/tabbed_translation_fields.css',),
        }

    fieldsets = [
        (None, {
            'fields': [
                'name',
                'slug',
                'type',
                'description',
                'parent',
            ]
        }),
        (u'Лог', {
            'fields': [
                'author',
                'editor',
            ],
            'classes': ['collapse']
        })
    ]

admin.site.register(Modelka, ModelkaAdmin)

Обращаю Ваше внимание, что в примере сразу же включены скрипты для отображения переводов на разных вкладках. Это как раз те файлы которые я в начале предлагал скопировать в каталог для статического контента. Если Вы установили modeltranslation через pip — не забудьте собрать статические фалы командой python manage.py collectstatic (подробнее о статических файлах). Соответственно не забудьте подправить пути во вложенном Meta классе, если они у Вас отличаются.

На скриншоте видны вкладки языков для переводимых полей модели (скриншот с разрабатываемого приложения, потому языков больше чем в примере)

Работа с локализованной моделью

Собственно сама работа абсолютно прозрачна и также не затрагивает уже существующий код (наилучший язык отображения сайта может определяться как самим фреймворком, так и сторонними модулями, но это отдельная тема), если не понадобится где-то руками объявлять используемый язык через set_language. Т.е. модель будет возвращать значения полей на текущем языке приложения возвращаемом get_lang.

Что такое этот новый jQuery.Callbacks Object

Software People Team — Tue, 10 Jan 2012 21:11:31 +0000

Автор статьи: Зайцев Андрей (блог автора)

В не столь давно вышедшей версии jQuery 1.7 появился новый объект Callbacks, о котором сегодня и пойдёт речь.

В официальной документации jQuery.Callbacks описан, как многоцелевой объект, представляющий собой список функций обратного вызова (callbacks — далее просто колбэков) и мощные инструменты по управлению этим списком.

Я просматривал возможности этого объекта, когда он был ещё только в разработке, и надо сказать, что возможностей у него изначально было немного больше, чем осталось в релизной версии. Например, сейчас отсутствует возможность создания очереди (queue) колбэков, которые вызываются по одному на каждый вызов fire(). Видимо, команда jQuery, решила немного подсократить код, убрав «ненужные/редкоиспользуемые» возможности, чтобы сэкономить в весе библиотеки. Это маленький экскурс в историю Callbacks, но далее я буду описывать только доступные сейчас функции и в конце напишу небольшое возможное улучшение этого объекта.

Назначение

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

Конструктор: jQuery.Callbacks(flags)

Вызовом конструктора создаётся объект callbacks, который имеет ряд методов для управления списком колбэков.

Параметр flags необязательный и позволяет задать параметры работы объекта, возможные значения параметра мы рассмотрим ниже.

var callbacks = $.Callbacks();

К созданному объекту callbacks мы сможем теперь добавлять функции-колбэки в список, удалять их, вызывать, снова вызывать (если это не было запрещено при создании объекта), проверять статус объекта (был ли уже вызов или ещё нет) с помощью таких методов объекта, как add(), remove(), fire() и пр. Выполняются колбэки, кстати, в порядке их добавления в список.

Отмечу, что это не «настоящий» конструктор экземпляра класса, поэтому использовать оператор new при его вызове не требуется (и даже бессмысленно).

По этой причине не получится проверить, является ли объект экземпляром Callbacks, способом, стандартным для JS:

if (obj instanceof $.Callbacks) {
    obj.add(fn);
}

Выражение под if всегда возвращает false. Но можно положиться на один из известных методов этого объекта (или сразу на несколько), например, можно проверить так:

if (obj.fire) {
    obj.add(fn);
}

На самом деле, внутри этой функции создаётся обычный JS-объект с определённым набором методов, которые опираются на своё замыкание — это довольно распространённый в JavaScript способ задания приватных (private) переменных, недоступных вне этого псевдоконструктора.

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

var c = $.Callbacks(), obj = {};
obj.register = c.add;
obj.register(function() { console.log('fired'); });
c.fire();

// output: 'fired'

Флаги

Примечание: далее по тексту под словами «вызов метода fire()» понимается вызов выполнения колбэков из списка в том числе и методом fireWith().

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

once — указывает, что список колбэков может быть выполнен только единожды, второй и последующие вызовы метода fire() будут безрезультатны (как это сделано в объекте deferred), если этот флаг не указан, то можно несколько раз вызывать метод fire().

memory — указывает, что необходимо запоминать параметры последнего вызова метода fire() (и выполнения колбэков из списка) и немедленно выполнять добавляемые колбэки с соответствующими параметрами, если они добавляются уже после вызова метода fire() (как это сделано в объекте deferred).

unique — указывает, что каждый колбэк может быть добавлен в список только один раз, повторная попытка добавить колбэк в список ни к чему ни приведёт.

stopOnFalse — указывает, что нужно прекратить выполнение колбэков из списка, если какой-то из них вернул false, в пределах текущей сессии вызова fire(). Следующий вызов метода fire() начинает новую сессию выполнения списка колбэков, и они будут выполняться опять до тех пор, пока один из списка не вернёт false либо пока не закончатся.

Методы

Ниже я приведу список методов с кратким описанием, примеры есть в официальных доках и для некоторых методов в следующем разделе. В общем-то методы довольно просты и ведут себя вполне ожидаемо.

callbacks.add(callbacks) returns: callbacks — добавляет в список колбэки, можно одновременно передавать в аргументах этого метода несколько функций (несколько аргументов) или массивов функций (можно одновременно и то и другое), можно даже вложенные массивы передавать. Все аргументы (или элементы массива), не являющиеся функциями, просто игнорируются. Метод (этот и некоторые далее) возвращает контекст своего вызова, позволяя тем самым организовать цепочку вызовов нескольких методов одного объекта подряд, как это принято в jQuery.

callbacks.remove(callbacks) returns: callbacks — удаляет колбэки из списка, причем даже если колбэк был добавлен дважды, удаление его произойдёт с обеих позиций. Т.о. если вызвать метод удаления некоторого колбэка из списка, то можно быть уверенным, что его в списке больше нет, сколько бы раз его не добавляли. Можно передавать несколько функций одновременно как несколько аргументов, массивы передавать нельзя, все аргументы не функции игнорируются.

callbacks.has(callback) returns: boolean — проверяет, есть ли указанная функция в списке колбэков.

callbacks.empty() returns: callbacks — очищает список колбэков.

callbacks.disable() returns: callbacks — «отключает» объект callbacks, все действия с ним будут безрезультатны. При этом перестают работать вообще все методы: add — ни к чему не приводит, has — всегда возвращает false и пр.

callbacks.disabled() returns: boolean — проверяет, отключен ли объект callbacks, после вызова disable() будет возвращать true.

callbacks.lock() returns: callbacks — фиксирует текущее состояние объекта callbacks относительно параметров и состояния выполнения списка колбэков. Этот метод актулен при использовании флага memory и предназначен для блокирования только последующих вызовов fire(), в остальных случаях он равносилен вызову disable().

Детально этот метод работает так: если флаг memory не указан или ещё ни разу не был вызван метод fire() или последняя сессия выполнения колбэков была прервана возвратом false одним из них, то вызов lock() равносилен вызову disable() (именно он и вызывается внутри) и вызов disabled() в таком случае вернёт true, иначе будут заблокированы только последующие вызовы fire() — они не приведут ни к выполнению колбэков, ни к изменению параметров выполнения добавляемых колбэков (при наличии флага memory).

callbacks.locked() returns: boolean — проверяет, зафиксирован ли объект callbacks методом lock(), также верёт true после вызова disable().

callbacks.fireWith( [context] [, args] ) returns: callbacks — запускает выполнение всех колбэков в списке с указанным контекстом и аргументами. context — указывает контекст выполнения колбэка (объект, доступный через this внутри функции). args — массив (именно массив) аргументов, передаваемых в колбэк.

callbacks.fire( arguments ) returns: callbacks — запускает выполнение всех колбэков в списке с контекстом вызова и аргументами этого метода. arguments — список аргументов (не массив, как в методе fireWith()). Т.е. контекстом вызова и аргументами колбэков будут контекст и аргументы метода fire().

Пример, как можно эквивалентно запустить исполнение колбэков с одинаковыми параметрами и контекстом:

var callbacks = $.Callbacks(),
    context = { test: 1 };
callbacks.add(function(p, t) { console.log(this.test, p, t); });

callbacks.fireWith(context, [ 2, 3 ]);

// output: 1 2 3

context.fire = callbacks.fire;
context.fire(2, 3);
// output: 1 2 3

Обратные вызовы (callbacks) из списка выполняются в том порядке, в котором они в этот список добавлялись. После выполнения колбэков при указанном флаге once список будет очищен, а если при этом не указан флаг memory или выполнение обратных вызовов было прервано возвратом false, то объект callbacks будет отключен методом disable().

Примеры

Давайте посмотрим как работают флаги на примерах. Во всех примерах используются такие функции:

function fn1( value ){
    console.log( value );
}

function fn2( value ){

    fn1("fn2 says:" + value);
    return false;
}

$.Callbacks():

var callbacks = $.Callbacks();
callbacks.add( fn1 );
callbacks.fire( "foo" );
callbacks.add( fn2 );
callbacks.add( fn1 );
callbacks.fire( "bar" );
callbacks.remove( fn2 );
callbacks.fire( "foobar" );
console.log(callbacks.disabled());

/*
output:
foo
bar
fn2 says:bar
bar
foobar
foobar
false
*/

Никакие флаги не указали — вполне ожидаемое поведение.

$.Callbacks(’once’):

var callbacks = $.Callbacks( "once" );
callbacks.add( fn1 );
callbacks.fire( "foo" );
callbacks.add( fn2 );
callbacks.add( fn1 );
callbacks.fire( "bar" );
callbacks.remove( fn2 );
callbacks.fire( "foobar" );
console.log(callbacks.disabled());

/*
output:
foo
true
*/

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

$.Callbacks(’memory’):

var callbacks = $.Callbacks( "memory" );
callbacks.add( fn1 );
callbacks.fire( "foo" );
callbacks.add( fn2 );
callbacks.add( fn1 );
callbacks.fire( "bar" );
callbacks.remove( fn2 );
callbacks.fire( "foobar" );
console.log(callbacks.disabled());

/*
output:
foo
fn2 says:foo
foo
bar
fn2 says:bar
bar
foobar
foobar
false
*/

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

$.Callbacks(’unique’):

var callbacks = $.Callbacks( "unique" );
callbacks.add( fn1 );
callbacks.fire( "foo" );
callbacks.add( fn2 );
callbacks.add( fn1 );
callbacks.fire( "bar" );
callbacks.remove( fn2 );
callbacks.fire( "foobar" );
console.log(callbacks.disabled());

/*
output:
foo
bar
fn2 says:bar
foobar
false
*/

А в этом случае повторное добавление функции fn1 было проигнорировано.

$.Callbacks(’stopOnFalse’):

var callbacks = $.Callbacks( "stopOnFalse" );
callbacks.add( fn1 );
callbacks.fire( "foo" );
callbacks.add( fn2 );
callbacks.add( fn1 );
callbacks.fire( "bar" );
callbacks.remove( fn2 );
callbacks.fire( "foobar" );
console.log(callbacks.disabled());

/*
output:
foo
bar
fn2 says:bar
foobar
foobar
false
*/

Обратный вызов fn2 прерывает цепочку выполнения, т.к. возвращает false.

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

$.Callbacks(’once memory’):

var callbacks = $.Callbacks( "once memory" );
callbacks.add( fn1 );
callbacks.fire( "foo" );
callbacks.add( fn2 );
callbacks.add( fn1 );
callbacks.fire( "bar" );
callbacks.remove( fn2 );
callbacks.fire( "foobar" );
console.log(callbacks.disabled());

/*
output:
foo
fn2 says:foo
foo
false
*/

Видим, что сработали только первый fire() и добавление новых колбэков привело к их немедленному выполнению с параметрами первого fire().

$.Callbacks(’once memory unique’):

var callbacks = $.Callbacks( "once memory unique" );
callbacks.add( fn1 );
callbacks.fire( "foo" );
callbacks.add( fn2 );
callbacks.add( fn1 );
callbacks.fire( "bar" );
callbacks.remove( fn2 );
callbacks.fire( "foobar" );
console.log(callbacks.disabled());

/*
output:
foo
fn2 says:foo
foo
false
*/

Здесь результат тот же, несмотря на то, что мы указали флаг unique и дважды добавляем fn1, — второй раз добавление этой функции в список сработало, потому что при указанном флаге once после выполнения колбэков список очищается, а флаг memory указывает, что последующие добавления колбэков будут приводить к их немедленному выполнению без помещения в список, а так как список пуст — то добавление любой функции всегда уникально. Но этот флаг сыграет свою роль при попытке добавить за раз несколько колбэков, среди которых есть дублирующиеся, если в предыдущем коде изменить 4-ю строку как показано ниже, то fn2 всё равно выполнена будет только один раз (а без флага unique была бы выполнена три раза):

callbacks.add( fn2, fn2, fn2 );

$.Callbacks(’once memory stopOnFalse’):

var callbacks = $.Callbacks( "once memory stopOnFalse" );
callbacks.add( fn1 );
callbacks.fire( "foo" );
callbacks.add( fn2 );
callbacks.add( fn1 );
callbacks.fire( "bar" );
callbacks.remove( fn2 );
callbacks.fire( "foobar" );
console.log(callbacks.disabled());

/*
output:
foo
fn2 says:foo
true
*/

Возврат false заблокировал все дальнейшие выполнения колбэков и при наличии флага once вообще привёл к отключению объекта callbacks.

Я не буду рассматривать все возможные комбинации флагов, я постарался выбрать наиболее интересные (не совсем простые) и объяснить поведение callbacks. Остальные комбинации можно протестировать самостоятельно, например, воспользовавшись заготовкой: http://jsfiddle.net/zandroid/JXqzB/

Обещанное улучшение

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

Идея улучшения в том, чтобы опустить вызов метода fire(), а вместо этого сам объект callbacks использовать как функцию. Для этого пишем такую функцию:

(function($, undefined){
    $.FCallbacks = function(flags, fns) {

        var i = $.type(flags) === 'string' ? 1 : 0,
            callbacks = $.Callbacks(i ? flags : undefined);
        callbacks.add(Array.prototype.slice.call(arguments, i))
        return $.extend(callbacks.fire, callbacks, { fcallbacks: true });
    };
})(jQuery);

И без лишних слов посмотрим пример использования:

function fn1(p1, p2) { console.log('fn1 says:', this, p1, p2); }
function fn2(p1, p2) { console.log('fn2 says:', this, p1, p2); }

var callbacks = $.FCallbacks('once', fn1, rn2);
callbacks.add(fn2);
callbacks(2, 3);

Также ещё у нового «конструктора» появилась возможность сразу же передавать начальные колбэки в параметрах, без лишнего вызова add().

Ну и в работе: jsfiddle.net/zandroid/RAVtF/

Реальное использование

Callbacks на самом деле теперь используется очень многими пользователями jQuery 1.7+ и был сделан командой разработчиков не просто, потому что им захотелось сделать новый фичер. Смотрите, цепочка и логика этого вопроса довольно проста:

В библиотеке был реализован метод $.ajax(), который по своей природе не что иное, как надстройка над неким Deferred — разработчики улучшили код, вынесли его отдельно от основного кода $.ajax() (для возможности повторного использования и упрощения тестирования) и решили, а почему бы не опубликовать этот код (дать доступ пользователям библиотеки к нему и задокументировать его) — получился $.Deferred.

В свою очередь $.Deferred — это изначально два (done() и fail()), а теперь три (+ ещё progress()) надстройки над Callbacks, который был сделан как внутренний код $.Deferred. И снова, разработчики улучшили и отделили этот код от $.Deferred, реализовав последний через $.Callbacks (кстати, source-код $.Deferred стал при этом намного понятнее и читабельнее).

Вывод: разработчики не ставят главной целью добавление новых «никому не нужных» фичеров, они оптимизируют уже существующий внутренний код, попутно публикуя побочные, но не менее полезные от этого, результаты. И каждый раз, когда вы используете $.ajax() — знайте, вы используете $.Deferred, а значит и $.Callbacks. Это и есть пример реального использования.

Backup Time Machine своими руками

Software People Team — Mon, 09 Jan 2012 19:54:19 +0000

Автор статьи: Дорощенко Юрий (сайт автора)

Как ни крути, а в новогодние праздники, риск порчи файлов значительно возрастает. Не миновала сия беда и меня. Как не трудно догадаться, я перепутал диск при форматировании и… да-да, все, что было нажито ~~неправедным путем~~ непосильным трудом, в один момент было уничтожено.

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

Закончив с пытками гугла на тему: «сделай мне хорошо», решил поступить как истинный Unix`оид, хоть и работающий в форточках. А именно: не выпендривайся, чем проще — лучше.

Тут я вспомнил презентацию MacOS на которой демонстрировали их Time Machine. Ведь если подумать, очень удобно иметь возможность получить доступ к любому файлу за любой день. Но… Если делать полные копии в виде архивов, то никаких объемов не хватит, чтобы это все хранить. Дальше мысль зацепилась за инкрементные бекапы. То есть в первый раз вы делаете полный архив, а затем архивируете только то, что изменилось.

И… Этот вариант я тоже отбросил, как не удобный для моего случая. Во-первых, существует необходимость в возможности удалять произвольные «дни». А во-вторых, я очень часто переименовываю свои файлы и время от времени перекладываю из директории в директорию. А это, в свою очередь, к моему удивлению, срезало почти всех кандидатов в «бекаперы». То есть, софт тупо смотрел на имя файла, дату его изменения и… и все. В итоге бекап разбухал.

Итак, спасли меня две идеи:

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

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

Если кто не знает, то благодаря команде:

fsutil hardlink create <ссылка> <файл>

в windows можно получить настоящую жесткую ссылку.

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

И вот собственно сам «бекапер».


//
$dir = array();

$hah = array();
$hah_new = array();
$file = array();
$copy = 0;

$link = 0;
include 'conf.php';
$date = date('Y-m-d');

// выход если бекап на сегодня уже существует
if(is_dir($date)){
    exit("Backup already exists\n");
}

// составляем список существующих файлов
foreach(glob('*', GLOB_ONLYDIR) as $v){
    if(is_file($v.'/hah.db')){
        $hah = array_merge($hah, unserialize(file_get_contents($v.'/hah.db')));
    }
}

// создаем дерево директорий
foreach($dir as $v){
    $x = explode('/', $v);
    array_unshift($x, $date);
    $x[1] = substr($x[1], 0, 1);
    foreach($x as $k=>$v){
        $y = implode('/', array_slice($x, 0, $k+1));
        if(!is_dir($y)){
            mkdir($y);
        }
    }
}

// получаем список файлов
while($n = array_pop($dir)){
    if(!is_dir($date.'/'.substr($n, 0, 1).'/'.substr($n, 3))){
        mkdir($date.'/'.substr($n, 0, 1).'/'.substr($n, 3));
    }
    $dir = array_merge($dir, glob($n.'/*', GLOB_ONLYDIR));
    $file = array_merge($file, array_diff(glob($n.'/*'), glob($n.'/*', GLOB_ONLYDIR)));
}

// копируем новые и линкуем старые файлы
foreach($file as $k=>$v){
    $x = md5_file($v).filesize($v);
    if(!$x){
        continue;
    }
    $f = $date.'/'.substr($v, 0, 1).'/'.substr($v, 3);
    if($hah[$x]){
        exec('fsutil hardlink create "'.$f.'" "'.$hah[$x].'"');
        $hah_new[$x] = $f;
        $link++;
    }else{
        copy($v, $f);
        $hah_new[$x] = $f;
        $copy++;
    }
    print ceil($k*100/count($file))."%\r";
}

print "\nLink: ".$link."\n";
print "Copy: ".$copy."\n";

// сохраняем информацию о файлах

file_put_contents($date.'/hah.db', serialize($hah_new));
exit;

Его конфигурация:


date_default_timezone_set('Asia/Novosibirsk');

$dir[] = 'c:/scan'; // сканы
$dir[] = 'c:/web'; // корень локального сервера
$dir[] = 'c:/gohsrf'; // приказы

$dir[] = 'q:'; // флешка

Ну и BAT`ник его запускающий:

@echo off

cls

php backup.php

pause



Простая real-time коммуникация с посетителем
Software People Team — Sun, 08 Jan 2012 11:54:51 +0000
Автор статьи: Евгений Лисицкий, технический директор Sports.ru



Я давно интересуюсь вебом в реальном времени. На сегодня уже есть ряд библиотек для этого. В этой статье я хочу рассказать про недавно опробованный нами самый простой способ — использование внешнего сервиса Pusher.com.
Если сегодня асинхронно отправить сообщение на сервер проще простого, то с обратным транспортом пока не все так радужно. Сервис как раз берет на себя эту задачу.


Все работает очень просто. На страницу вставляется JavaScript пушера, он открывает подключение к серверам пушера и подписывается на сообщения по какому-нибудь каналу. Когда вы хотите отправить сообщение, вы вызываете API пушера и отправляете сообщение в канал. Все пользователи, подписавшиеся на канал, его получат.

Таким образом можно очень легко организовать массовую рассылку сообщений всем нужным пользователям в онлайне. Что позволяет очень просто создать чат — достаточно вставить пушер на страницу, скрипт на вашем сервере будет принимать сообщения POST-ом, «дергать» API Pusher`a, а тот будет рассылать их всем клиентам через веб сокеты. Аналогично можно сделать и более сложные вещи, например, совместные графические редакторы — все есть в примерах и документации.
От себя замечу — мы несколько месяцев назад перевели чат и онлайны на пушер, тем самым решили сразу несколько проблем:

 — значительно ускорили доставку сообщений

 — снизили пользователям трафик

 — уменьшили нагрузку на на наши сервера — теперь мы только принимаем сообщения, а рассылкой по пользователям занимается пушер

 — улучшили масштабируемость системы
Когда переходили, были некоторые сомнения — не столкнутся ли пользователи с проблемами. Насколько хорошо будут поддерживаться разные браузеры. Опасения были напрасными — пушер использует WebSockets, а при их недоступности (например, в древних недобраузерах ИЕ) старую добрую эмуляцию через Flash Sockets — именно то, что я использовал в своем модельном чате на вебсокетах. Практика показала, что этого достаточно. Усложнять и деградировать до Long Polling, Multi Part и прочего не требуется.
Недавно мы решили использовать его еще в одном более сложном проекте.

Если интересно, то как реализуем, подробно опишу.
Подведем итог

Плюсы:

 — очень просто поключать к сайту — есть готовые либы на PHP и Python

 — если нет готовых либ для вашего языка, то можно использовать простое API, для этого достаточно curl`a

 — снимает проблему масштабирования — пушер размещается на серверах Амазона
Минусы:

 — платный



WebSockets — полноценный асинхронный веб
Software People Team — Sat, 24 Dec 2011 19:41:33 +0000
Автор: Евгений Лисицкий, технический директор Sports.ru
Недавно разработчики Google Chromium опубликовали новость о поддержке технологии WebSocket. В айтишном буржунете новость произвела эффект разорвавшейся бомбы. В тот же день различные очень известные айтишники опробовали новинку и оставили восторженные отзывы в своих блогах. Моментально разработчики самых разных серверов/библиотек/фреймворков (в их числе Apache, EventMachine, Twisted, MochiWeb и т.д.) объявили о том, что поддержка ВебСокетов будет реализована в их продуктах в ближайшее время.

Что же такого интересного сулит нам технология? На мой взгляд, WebSocket — это самое кардинальное расширение протокола HTTP с его появления. Это не финтифлюшки, это сдвиг  парадигмы HTTP. Изначально синхронный протокол, построенный по модели «запрос — ответ», становится полностью асинхронным и симметричным. Теперь уже нет клиента и сервера с фиксированными ролями, а есть два равноправных участника обмена данными. Каждый работает сам по себе, и когда надо отправляет данные другому. Отправил — и пошел дальше, ничего ждать не надо. Вторая сторона ответит, когда захочет — может не сразу, а может и вообще не ответит. Протокол дает полную свободу в обмене данными, вам решать как это использовать.
Я считаю, что веб сокеты придутся ко двору, если вы разрабатываете:

 — веб-приложения с интенсивным обменом данными, требовательные к скорости обмена и каналу;

 — приложения, следующие стандартам;

 — «долгоиграющие» веб-приложения;

 — комплексные приложения со множеством различных асинхронных блоков на странице;

 — кросс-доменные приложения.

И как это работает?
Очень просто! Как только ваша страница решила, что она хочет открыть веб сокет на сервер, она создает специальный javascript-объект:



<script>
ws = new WebSocket(“ws://site.com/demo”);
 
// и навешивает на новый объект три колл-бека:
 
// первый вызовется, когда соединение будет установлено:
ws.onopen = function() { alert(“Connection opened…”) };
 
// второй - когда соединено закроется
ws.onclose = function() { alert(“Connection closed…”) };
 
// и, наконец, третий - каждый раз, когда браузер получает какие-то данные через веб-сокет
ws.onmessage = function(evt) { $(“#msg”).append(“”+evt.data+“
”); };
 
script>


* This source code was highlighted with Source Code Highlighter.
А что при этом происходит в сети?

Все начинается так же как в обычном HTTP-запросе. Браузер подключается по протоколу TCP на 80 порт сервера и дает немного необычный GET-запрос:

GET /demo HTTP/1.1

Upgrade: WebSocket

Connection: Upgrade

Host: site.com

Origin: http://site.com



Если сервер поддерживает ВебСокеты, то он отвечает таким образом:

HTTP/1.1 101 Web Socket Protocol Handshake

Upgrade: WebSocket

Connection: Upgrade

WebSocket-Origin: http://site.com

WebSocket-Location: ws://site.com/demo


Если браузер это устраивает, то он просто оставляет TCP-соединение открытым. Все — «рукопожатие» совершено, канал обмена данными готов.

Как только одна сторона хочет передать другой какую-то информацию, она отправляет дата-фрейм следующего вида:

0×00, <строка в кодировке UTF-8>, 0xFF 

То есть просто строка текста — последовательность байт, к которой спереди приставлен нулевой байт 0×00, а в конце — 0xFF. И все — никаких заголовков, метаданных! Что именно отправлять, разработчики полностью оставили на ваше усмотрение: хотите XML, хотите JSON, да хоть стихи Пушкина.

Каждый раз, когда браузер будет получать такое сообщение, он будет «дергать» ваш колл-бек onmessage. 
Легко понять, что КПД такого протокола стремится к 95%. Это не классический AJAX-запрос, где на каждую фитюльку приходится пересылать несколько килобайт заголовков. Разница будет особенно заметна если делать частый обмен небольшими блоками данных. Скорость обработки так же стремится к скорости чистого TCP-сокета — ведь все уже готово — соединение открыто — всего лишь байты переслать.

Лирическое отступление:

И еще одна вещь, которая меня очень радует - в качестве единственной разрешенной кодировки выбрана UTF-8! Я уже робко надеюсь, что через некоторое время мы уйдем от одного из костылей веба.


А картинку можно отправить?

С помощью WebSockets так же можно передавать и бинарные данные. Для них используется другой дата-фрейм следующего вида:

0×80, <длина - один или несколько байт>, <тело сообщения>
Что значит «один или несколько байт»? Чтобы не создавать ограничений на длину передаваемого сообщения и в тоже время не расходовать байты нерационально, разработчики использовали очень хитрый способ указания длины тела сообщения. Каждый байт в указании длины рассматривается по частям: самый старший бит указывает является ли этот байт последним (0) либо же за ним есть другие (1), а младшие 7 битов содержат собственно данные. Обрабатывать можно так: как только вы получили признак бинарного дата-фрейма 0×80, вы берете следующий байт и откладываете его в отдельную «копилку», смотрите на следующий байт — если у него установлен старший бит, то переносите и его в «копилку», и так далее, пока вам не встретится байт с 0 старшим битом. Значит это последний байт в указателе длины — его тоже переносите в «копилку». Теперь из всех байтов в «копилке» убираете старшие биты и слепляете остаток. Вот это и будет длина тела сообщения. Еще можно интерпретировать как 7-битные числа без старшего бита.
Например, самую главную картинку веб-дизайна — прозначный однопиксельный GIF размером 43 байта можно передать так:

0×80, 0×2B, <тело сообщения>

Объект размером 160 байт закодируется 2 байтами длины:

0×80, 0×81, 0×20, <байты объекта>

Не правда ли, очень элегантно?
Что это нам дает?

Скорость и эффективность

Высокую скорость и эффективность передачи обеспечивает малый размер передаваемых данных, который иногда даже будет помещаться в один TCP-пакет — здесь, конечно, же все зависит от вашей бизнес-логики. (В дата-фрейм можно засунуть и БСЭ, но для такой передачи потребуется чуть больше 1 TCP- пакета.  ).

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

Самим своим выходом WebSockets отправит на свалку истории Comet и все приблуды накрученные поверх него — Bayuex, LongPolling, MultiPart и так далее. Это все полезные технологии, но по большей части, они работают на хаках, а не стандартах. Отсюда периодески возникают проблемы: то прокся ответ «зажевала» и отдала его только накопив несколько ответов. Для «пробивания» проксей часто использовался двух-килобайтный «вантуз» — т.е. объем передаваемых данных увеличивался пробелами (или другими незначащими символами) до 2К, которые многие прокси передавали сразу, не задерживая. Периодически антивирусы выражали свое желание получить ответ полностью, проверить его, и только потом передать получателю. Конечно, сегодня все эти проблемы более-менее решены — иначе бы не было такого большого кол-ва веб-приложений. Однако, развитие в этом направлении сопряжено с появлением новых проблем — именно потому, что это попытка делать в обход стандарта.
На мой взгляд, через некоторое время останется только 2 технологии: чистый AJAX и WebSockets. Первая хороша для одно- или несколькоразовых обновлений на странице — действительно, врядли рационально для этого раскочегаривать мощную машину веб-сокетов. А все остальное, что сейчас делается кометом и коллегами, переедет на веб-сокеты, т.к. это будет проще и эффективнее. Например, вы хотите вживую мониторить цены на рынке форекс. Пожалуйста: открывайте сокет — сервер вам будет присылать все обновления. Ваша задача только повесить правильный колл-бек на событие onmessage и менять циферки на экране. Вы решили что-то прикупить, отправьте серверу асинхронное сообщение, а параллельно продолжайте получать циферки. Элегантно? По сравнению с этим LongPolling с необходимостью периодческого рестарта даже неактивного канала (чтобы его прокся или еще кто не прихлопнул) выглядит грязным хаком.
Время жизни канала

В отличие от HTTP веб-сокеты не имеют ограничений на время жизни в неактивном состоянии. Это значит, что больше не надо периодически рефрешить соединение, т.к. его не вправе «прихлопывать» всякие прокси. Значит, соединение может висеть в неактивном виде и не требовать ресурсов. Конечно, можно возразить, что на сервере будут забиваться TCP-сокеты. Для этого достаточно использовать хороший мультиплексор, и нормальный сервер легко потянет до миллиона открытых коннектов.
Комплексные веб-приложения

Как известно в HTTP предусмотрено ограничение на число одновременных октрытых сессий к одному серверу. Из-за этого если у вас много различных асинхронных блоков на странице, то вам приходилось делать не только серверный, но и клиентский мультиплексор — именно отсюда идет Bayeux Protocol. 

К счастью, это ограничение не распространяется на веб-сокеты. Открываете столько, сколько вам нужно. А сколько использовать — одно (и через него все мультиплексировать) или же наоборот — на каждый блок свое соединение — решать вам. Исходите из удобства разработки, нагрузки на сервер и клиент.
Кросс-доменные приложения

И еще один «камень в ботинке» AJAX-разработчика — проблемы с кросс-доменными приложениями. Да, и для них тоже придумана масса хаков. Помашем им ручкой и смахнем скупую слезу. WebSockets не имеет таких ограничений. Ограничения вводятся не по принципу «из-того-же-источника», а из «разрешенного-источника», и определяются не на клиенте, а на сервере. Думаю, внимательные уже заметили новый заголовок Origin. Через него передается информация откуда хотят подключиться к вашему websocket-у. Если этот адрес вас не устраивает, то вы отказываете в соединение. 

Все! Конец кросс-доменной зопяной боли!
А руками пощупать можно?

Можно!
UPDATE: Одной из открытых реализаций веб-сокетов является чат на www.mibbit.com (заметка в их блоге).
PHP-реализация сервера WebSocket также представлена модулем к асинхронному фреймворку phpDaemon, модуль называется WebSocketServer. Пример простейшего приложения, которое отвечает «pong» на фрейм (пакет) «ping» — ExampleWebSocket.

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

И когда же оно настанет? На самом деле очень скоро. Гугл в очередной раз дал «волшебного пендаля» всей веб-индустрии, и все зашевелились. Вы удивитесь, но тут же люди вспомнили, что в багзилле фаерфокса уже год(!) висит задача на эту тему. В Хроме все изменения сделаны в WebKit — а значит очень скоро появится поддержка в Safari. Скоро подтянутся и остальные браузеры.
А если нельзя, но очень хочется?

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

На мой взгляд, как только люди распробуют, эта технология получить очень широкое распространение. К весне-лету мы получим массу сайтов с ней. И как в свое время несколько лет прошло «под звездой AJAX», так и здесь год-другой мы будем слышать отзывы о внедрении WebSockets повсеместно.
…

Осторожно, двери закрываются. Не опоздайте на поезд в будущее…
Оригинал статьи размещен здесь: Введение в WebSockets — полноценный асинхронный веб



Версионная миграция структуры базы данных: основные подходы
Software People Team — Thu, 22 Dec 2011 17:04:37 +0000
Автор статьи: Дмитрий Шевченко
Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как в русскоязычном (1, 2, 3 и др.), так и в англоязычном Интернете.
В первом разделе этой статьи я рассматриваю основные проблемы, которые возникают в командах программистов при внесении любых изменений в структуру базы данных. Во втором разделе я попытался выделить основные общие подходы к тому, в каком виде изменения структуры базы данных можно хранить и поддерживать в процессе разработки.
Терминология
База данных — совокупность всех объектов БД (таблиц, процедур, триггеров и т.д.), статических данных (неизменяемых данных, хранящихся в lookup-таблицах) и пользовательских данных (которые изменяются в процессе работы с приложением).
Структура базы данных — совокупность всех объектов БД и статических данных. Пользовательские данные в понятие структуры БД не входят.
Версия базы данных — определенное состояние структуры базы данных. Обычно у версии есть номер, связанный с номером версии приложения.
Миграция, в данном контексте, — обновление структуры базы данных от одной версии до другой (обычно более новой).
В этом смысле термин миграция, похоже, используется во многих источниках (особенно этому поспособствовали миграции из gem’а Active Record, входящего в состав Ruby on Rails). Однако при использовании этого термина возникает двусмысленность: человек, который не знает контекста, скорее подумает, что речь идет о переносе базы данных с одной СУБД на другую (MySQL => Oracle), а то и вовсе о миграции процессов/данных между нодами кластера. Поэтому предлагаю в случаях, когда контекст неочевиден, использовать более точный термин: версионная миграция баз данных.
Зачем это нужно?
Разработчики, которые уже сталкивались с проблемой рассинхронизации версий БД и приложения, могут пропустить этот раздел. Здесь я напомню, почему нужно соблюдать паритет версий приложения и базы данных и какая общая проблема при этом возникает.
Версия базы данных должна соответствовать версии приложения

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

Любому программисту в процессе написания кода приложения может понадобиться изменить структуру базы данных, а также, сами данные, которые в ней хранятся. Приведу простой пример: допустим, есть необнуляемое (not nullable) строковое поле в одной из таблиц. В этом поле не всегда есть данные, и в этом случае там хранится пустая строка. В какой-то момент вы решили, что хранить пустые строки — семантически неправильно в некоторых случаях (см. 1, 2), а правильно — хранить NULL’ы. Для того, чтобы это реализовать, понадобятся следующие действия:
1. Изменить тип поля на nullable:
ALTER myTable CHANGE COLUMN myField myField VARCHAR(255) NULL DEFAULT NULL;

2. Так как в этой таблице на продакшн БД уже наверняка есть пустые строки, вы принимаете волевое решение и трактуете их как отсутствие информации. Следовательно, нужно будет заменить их на NULL:

UPDATE myTable SET myField = NULL WHERE myField = ”;
3. Изменить код приложения так, чтобы при получении из БД данных, хранящихся в этом поле, он адекватно реагировал на NULL’ы. Записывать в это поле тоже теперь нужно NULL’ы вместо пустых строк.
Из пункта 3 можно видеть, что приложение и база данных — неразрывные части одного целого. Это означает, что при поставке новой версии приложения в продакшн, нужно обязательно обновлять и версию базы данных, иначе приложение попросту не сможет правильно работать. В данном примере, если до новой версии будет обновлено только приложение, то в какой-то момент произойдет вставка NULL в необнуляемое поле, а это очевидная ошибка.
Таким образом, обновление версии приложения требует корректной версионной миграции базы данных.
Так ли это просто?

Осознав, что паритет версий БД и приложения необходим, вам нужно удостовериться, что миграции БД до нужной версии всегда будут выполняться правильно. Но в чём здесь проблема? Ведь, на первый взгляд, сложного здесь ничего нет!
Тут снова обратимся к живому примеру. Допустим, программисты в процессе разработки записывают свои изменения структуры и данных БД в отдельный файл в виде SQL-запросов (как DDL-, так и DML-запросов). А при каждом деплое последней версии приложения вы одновременно обновляете до последней версии и базу данных, выполняя запросы из того самого SQL-файла… Но погодите, с какой версии вы обновляете БД до последней версии? «С прошлой»? Но так ли хорошо вы помните, что конкретно из себя представляла прошлая версия (её выпустили 2 месяца назад)? Если нет, то как вы собрались её обновлять? Ведь без точной информации о состоянии структуры и данных выполнить корректную миграцию невозможно: если вы непредумышленно выполните запросы, которые уже когда-то выполнялись, это может привести к потере данных или нарушению их целостности.
Простой пример — замена паролей на их MD5-суммы. Если повторно выполнить такой запрос, то данные можно будет восстановить только из бэкапа. Да и вообще, любые UPDATE‘ы, DELETE‘ы, и даже INSERT‘ы, выполненные повторно, могут привести к крайне нежелательным последствиям. Не говоря уже о несвоевременных TRUNCATE‘ах и DROP‘ах (хотя такие случаи намного менее вероятны).

Кстати говоря, с этой точки зрения, недовыполнить — не меньшая опасность для работоспособности приложения, чем перевыполнить.
Таким образом, можно сделать вывод, что в процессе версионной миграции все запросы должны выполняться только один раз и, к тому же, в правильной последовательности. Последовательность важна потому, что одни изменения могут зависеть от других (как в примере с обнуляемым полем).

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

единоразовое выполнение каждого изменения (SQL-запроса);
строго предустановленный порядок изменений.

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

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


Основание миграции

Как оказалось, у большинства подходов есть общий принцип: им необходимо основание (baseline) — некоторое эталонное состояние БД, от которого можно отталкиваться. Эта концепция довольно хорошо описана в статье «Versioning Databases – The Baseline» Скотта Аллена.
Попросту говоря, основание — это дамп структуры базы данных для версии, которая принята за базовую. Имея на руках основание, впоследствии всегда можно будет создать БД с нуля. После применения к этой БД всех миграций, созданных в процессе разработки, получим БД со структурой самой последней версии.
Далее будут рассмотрены три подхода к организации версионной миграции баз данных.

Метод инкрементных изменений
Этот метод хорошо описан в статье «Versioning Databases – Change Scripts» все того же Скотта Аллена. Схожий подход также описан в статье «Managing SQL scripts and continuous integration» Майкла Бэйлона.
Структура файлов

Пример того, как в этом случае может выглядеть папка с файлами-миграциями:

Database

 |- Baseline.sql

 |- 0001.03.01.sql

 |- 0002.03.01.sql

 |- 0003.03.01.sql

 |- 0004.03.02.sql

 |- 0005.03.02.sql

 |- 0006.03.02.sql
 ‘- 0007.03.02.sql

В этом примере в папке хранятся все файлы, созданные при разработке версии 03. Впрочем, папка может быть и общей для всех версий приложения.
В любом случае, самый первый файл, который появится в такой папке, — основание (Baseline.sql). После этого любое изменение в БД сабмиттится в репозиторий в виде нового файла-миграции с именем вида [номер файла].[версия].[подверсия].sql.
Фактически, в этом примере в имени файла содержится полный номер версии БД. То есть после выполнения файла-миграции с именем 0006.03.02.sql база данных обновится с состояния, соответствующего версии 03.02.0005, до версии 03.02.0006.
Хранение истории версий

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

CREATE TABLE MigrationHistory

(

    Id INT,

    MajorVersion VARCHAR(2),

    MinorVersion VARCHAR(2),

    FileNumber VARCHAR(4),

    Comment VARCHAR(255),

    DateApplied DATETIME,
    PRIMARY KEY(Id)

)


Это всего лишь пример того, как может выглядеть таблица. При необходимости, её можно как упростить, так и дополнить.
В файле Baseline.sql в эту таблицу нужно будет добавить первую запись:

INSERT INTO 

MigrationHistory ( MajorVersion, MinorVersion, FileNumber, Comment,    DateApplied )

VALUES           ( ‘03′,         ‘01′,         ‘0000′,     ‘Baseline’, NOW() )



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


Автоматическое выполнение миграций

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

 Быстрое и удобное выполнение миграции до последней версии;

 Механизм нумерации версий. Номер текущей версии хранится прямо в БД;

 Для максимального удобства нужны средства автоматизации выполнения миграций;

 Неудобно добавлять комментарии к структуре БД. Если их добавлять в Baseline.sql, то в следующей версии они пропадут, т.к. основание будет сгенерировано с нуля вновь, в качестве дампа новой версии структуры. Вдобавок, такие комментарии будут быстро устаревать;

 Возникают проблемы в процессе параллельной разработки в нескольких ветках репозитория. Так как нумерация файлов-миграций — последовательная, то под одинаковыми номерами в разных ветках могут возникнуть файлы с разными DDL-/DML-запросами. Как следствие, при слиянии веток придется либо вручную редактировать файлы и их последовательность, либо же в новой, «слитой» ветке начинать с нового Baseline.sql, учитывающего изменения из обеих веток.
Этот метод в различных формах довольно широко распространен. К тому же, он легко поддается упрощению и модификации под нужды проекта.

В интернете можно найти готовые варианты скриптов по инкрементному выполнению миграций и встроить в свой проект.

Метод идемпотентных изменений
Этот метод описан в статье «Bulletproof Sql Change Scripts Using INFORMATION_SCHEMA Views» Фила Хэка. Описание схожего подхода также изложено в ответе на этот вопрос на StackOverflow.
Под идемпотентностью понимается свойство объекта оставаться неизменным при повторной попытке его изменить.

В тему вспоминается смешная сцена из «Друзей»  
Основная идея этого подхода — написание миграционных файлов таким образом, чтобы их можно было выполнить на базе данных больше одного раза. При первой попытке выполнить любую из SQL-команд, изменения будут применены; при всех последующих попытках ничего не произойдет.
Эту идею проще всего уяснить на примере. Допустим, вам нужно добавить в БД новую таблицу. Если вы хотите, чтобы если она уже существует, при выполнении запроса не возникло ошибки, — в MySQL для этих целей есть краткий синтаксис:

CREATE TABLE IF NOT EXISTS myTable

(

    id INT(10) NOT NULL,

    myField VARCHAR(255) NULL,

    PRIMARY KEY(id)
);

Благодаря ключевой фразе IF NOT EXISTS, MySQL попытается создать таблицу только в том случае, если таблицы с таким именем еще не существует. Однако такой синтаксис доступен не во всех СУБД; к тому же, даже в MySQL его можно использовать не для всех команд. Поэтому рассмотрим более универсальный способ:

IF NOT EXISTS

(

    SELECT *

    FROM information_schema.tables

    WHERE table_name = ‘myTable’

        AND table_schema = ‘myDb’

)

THEN

    CREATE TABLE myTable
    (

        id INT(10) NOT NULL,

        myField VARCHAR(255) NULL,

        PRIMARY KEY(id)
    );

END IF;

В последнем примере роль параметра условного выражения играет запрос, который проверяет, существует ли таблица myTable в базе данных с именем myDb. И только в том случае, если таблица отсутствует, произойдет, собственно, ее создание. Таким образом, приведенный запрос является идемпотентным.
Стоит отметить, что в MySQL по какой-то причине запрещено выполнять DDL-запросы внутри условных выражений. Но этот запрет легко обойти — достаточно включить все подобные запросы в тело хранимой процедуры:
DELIMITER $$

CREATE PROCEDURE sp_tmp() BEGIN
IF NOT EXISTS
(

    – 

    – Условие.

    – 

)

THEN

    – 

    – Запрос, изменяющий структуру БД.

    – 
END IF;
END;

$$
DELIMITER;
CALL sp_tmp();
DROP PROCEDURE sp_tmp;
Что за птица такая — information_schema?

Полную информацию о структуре базы данных можно получить из специальных системных таблиц, находящихся в базе данных с именем information_schema. Эта база данных и ее таблицы — часть стандарта SQL-92, поэтому этот способ можно использовать на любой из современных СУБД. В предыдущем примере используется таблица information_schema.tables, в которой хранятся данные о всех таблицах. Подобным образом можно проверять существование и метаданные полей таблиц, хранимых процедур, триггеров, схем, и, фактически, любых других объектов структуры базы данных.
Полный перечень таблиц с подробной информацией об их предназначении можно посмотреть в тексте стандарта. Краткий перечень можно увидеть в уже упоминавшейся выше статье Фила Хэка. Но самый простой способ, конечно же, — просто открыть эту базу данных на любом рабочем сервере БД и посмотреть, как она устроена.
Пример использования

Итак, вы знаете, как создавать идемпотентные SQL-запросы. Теперь рассмотрим, как этот подход можно использовать на практике.
Пример того, как в этом случае может выглядеть папка с sql-файлами:

Database

 |- 3.01

 |   |- Baseline.sql

 |   ’- Changes.sql

 |

 ’- 3.02

     |- Baseline.sql

     ’- Changes.sql

В этом примере для каждой минорной версии базы данных создается отдельная папка. При создании каждой новой папки генерируется основание и записывается в Baseline.sql. Затем в процессе разработки в файл Changes.sql записываются все необходимые изменения в виде идемпотентных запросов.
Предположим, в процессе разработки в разное время программистам понадобились следующие изменения в БД:

a) создать таблицу myTable;

b) добавить в нее поле newfield;

c) добавить в таблицу myTable какие-то данные.
Все три изменения написаны так, чтобы не выполняться повторно. В результате, в каком бы из промежуточных состояний не находилась база данных, при выполнении файла Changes.sql всегда будет выполнена миграция до самой последней версии.
К примеру, один из разработчиков создал на своей локальной копии БД таблицу myTable, записал изменение a) в хранящийся в общем репозитории кода файл Changes.sql, и на какое-то время забыл о нём. Теперь, если он выполнит этот файл на своей локальной БД, изменение a) будет проигнорировано, а изменения b) и c) будут применены.
Плюсы, минусы, выводы

 Очень удобное выполнение миграций с любой промежуточной версии до последней — нужно всего лишь выполнить на базе данных один файл (Changes.sql);

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

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

Метод уподобления структуры БД исходному коду
Отдельных статей, посвященных этому подходу, я, к сожалению, не нашел. Буду благодарен за ссылки на существующие статьи, если таковые имеются. UPD: В своей статье Absent рассказывает о своем опыте реализации схожего подхода при помощи самописной diff-утилиты.
Основная идея этого метода отражена в заголовке: структура БД — такой же исходный код, как код PHP, C# или HTML. Следовательно, вместо того, чтобы хранить в репозитории кода файлы-миграции (с запросами, изменяющими структуру БД), нужно хранить только актуальную структуру базы данных — в декларативной форме.
Пример реализации

Для простоты примера будем считать, что в каждой ревизии репозитория всегда будет только один SQL-файл: CreateDatabase.sql. В скобках замечу, что в аналогии с исходным кодом можно пойти еще дальше и хранить структуру каждого объекта БД в отдельном файле. Также, структуру можно хранить в виде XML или других форматов, которые поддерживаются вашей СУБД.
В файле CreateDatabase.sql будут храниться команды CREATE TABLE, CREATE PROCEDURE, и т.д., которые создают всю базу данных с нуля. При необходимости изменений структуры таблиц, эти изменения вносятся непосредственно в существующие DDL-запросы создания таблиц. То же касается изменений в хранимых процедурах, триггерах, и т.д.
К примеру, в текущей версии репозитория уже есть таблица myTable, и в файле CreateDatabase.sql она выглядит следующим образом:
CREATE TABLE myTable

(

    id INT(10) NOT NULL,

    myField VARCHAR(255) NULL,

    PRIMARY KEY(id)

);

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

CREATE TABLE myTable

(

    id INT(10) NOT NULL,

    myField VARCHAR(255) NULL,

    newfield INT(4) NOT NULL,

    PRIMARY KEY(id)

);

После этого измененный sql-файл сабмиттится в репозиторий кода.
Выполнение миграций между версиями

В этом методе процедура обновления базы данных до более новой версии не так прямолинейна, как в других методах. Поскольку для каждой версии хранится только декларативное описание структуры, для каждой миграции придется генерировать разницу в виде ALTER-, DROP — и CREATE-запросов. В этом вам помогут автоматические diff-утилиты, такие, как Schema Synchronization Tool, входящая в состав SQLyog, TOAD, доступный для многих СУБД, Dklab_pgmigrator для PostgreSQL от DmitryKoterov, а также, SQL Comparison SDK от RedGate.
Чтобы выполнить миграцию с одной версии БД до другой, вам придется восстановить на двух временных БД структуру исходной и конечной версий, и затем сгенерировать миграционный скрипт. Впрочем, эта процедура может быть автоматизирована и много времени занимать не должна.
Как быть с изменениями данных?

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

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


Плюсы, минусы, выводы

 Удобно наблюдать изменения в структуре между версиями при помощи средств системы контроля версий;

 Как и любой исходный код, структуру БД удобно комментировать;

 Для того, чтобы с нуля создать чистую базу данных последней версии, нужно выполнить всего лишь один файл;

 Скрипты-миграции более надежны, чем в других методах, так как генерируются автоматически;
 Мигрировать с новых версий на старые почти так же просто, как со старых на новые (проблемы могут возникнуть только с пресловутыми изменениями данных);

 В случае слияния двух веток репозитория, merge структуры БД осуществляется проще, чем при использовании других подходов;

 Изменения данных придется хранить отдельно, и затем вручную вставлять в сгенерированные скрипты-миграции;

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

Готовые решения для версионной миграции БД
Описанные выше методы могут использоваться без сторонних решений, однако существуют и готовые к использованию продукты, каждый со своей идеологией и оригинальным подходом, достойные отдельной статьи. При выборе решения версионной миграции, обязательно рассмотрите и такие продукты.
Некоторые из них рассмотрены в недавней статье «Подходы для версионирования баз данных» Дениса Гладких.
Ниже перечислена лишь малая часть готовых к использованию систем версионной миграции:

Migrator.NET;
ECM7.Migrator — форк Migrator.NET за авторством dima117. Его статья на Хабре;
Active Record Migrations, входящие в Ruby on Rails;
SQL Source Control от RedGate;
DotNetMigrations;
Fluent Migrator. Статья на Хабре за авторством tabushi, создавшего форк проекта;
DbDeploy.NET;
Tarantino;
Mygrate;
DBUpdater;
Wizardby за авторством ostapbender. Его статья на Хабре

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



SWP-дайджест №61
Software People Team — Thu, 22 Dec 2011 08:17:14 +0000
Статья Сергея Симоненко «Малоизвестные особенности Java» познакомит с возможностями этого популярного языка программирования, не так часто используемыми и потому нуждающимися в особом внимании. Статья будет полезна всем, кто собирается освежить в памяти синтаксис этого языка, а может быть, открыть что-то новое для себя. Сегодня мы публикуем первую часть статьи.
Статья Владимира Попова «Пишем модульное приложение на .Net Framework» посвящена проблемам проектирования систем, создаваемых на основе .Net Framework. В статье рассматриваются основные этапы проектирования. Статья будет полезна системным архитекторам и ведущим программистам, специализирующимся на создании масштабируемых приложений на этой платформе.
Статья Сергея Теплякова «Проблемы передачи списка перечислений или Почему абстракции „текут“» также посвящена архитектурным проблемам. В продолжение темы о «дырявых» абстракциях, начатой Джоэлем Спольски, Сергей пишет о проблемах, возникающих в том случае, когда нам нужно знать не только нам нужно знать не только видимое поведение (абстракцию), но и понимать внутреннее устройство (реализацию) описываемого объекта.



Расширяем C# с помощью Roslyn. Безопасные вызовы
Software People Team — Wed, 21 Dec 2011 13:31:51 +0000
Автор статьи: Дмитрий Ейбоженко (сайт автора: eibozhenko.ru) 
У вас никогда не возникало ощущения, что в языке X, на котором вы в данный момент программируете чего-то не хватает? Какой-нибудь небольшой, но приятной плюшки, которая может и не сделала бы вашу жизнь абсолютно счастливой, но определенно добавила бы немало радостных моментов. И вот вы с черной завистью посматриваете на язык Y, в котором эта штуковина есть, грустно вздыхаете и тайком льете по ночам слезы бессилия в любимую подушку. Бывало?
Пожалуй, C# дает своим адептам и меньше поводов для такой зависти, в сравнении с многими другими, поскольку динамично развивается, добавляя все новые и новые упрощающие жизнь фичи. И все же, нет предела совершенству, причем для каждого из нас — своего.
Сразу отмечу, что приоритетом в данной работе для меня было желание попробовать на зуб Roslyn, а сама идея, которую я дальше опишу, была скорее поводом и тестовым примером для испытаний этой библиотеки. Однако в процессе изучения и реализации я выяснил, что хоть и с некоторыми бубноплясками, но результат действительно можно использовать на практике для реального расширения синтаксиса языка. Как это сделать, кратко опишу в самом конце. А пока приступим.
Безопасные вызовы и монада Maybe

Идея безопасных вызовов заключается в том, чтобы избавиться от надоедающих проверок любых классов на null, которые являясь необходимостью, в то же время значительно засоряют код и ухудшают его читабельность. В то же время, нет никакого желания находиться под постоянной угрозой выпадения NullReferenceException.
Данная проблема решена в функциональных языках программирования с помощью монады Maybe, суть которой заключается в том, что после boxing’а использующийся в конвеерных вычислениях тип может содержать некоторое значение, либо значение Nothing. В случае, если предыдущее вычисление в конвеере дало некоторый результат, то производится следующее вычисление, если же оно вернуло Nothing, то вместо следующего вычисления вновь возвращается Nothing. 
В С# созданы все условия для реализации данной монады — вместо Nothing используется null, для структурных типов могут использоваться их Nullable версии. В принципе, идея уже витает в воздухе, и было несколько статей, в которых реализовывалась данная монада в C# с помощью LINQ. Одна из них принадлежит Дмитрию Нестеруку, есть еще и другая. 
Но нельзя не отметить, что при всей заманчивости такого подхода, результирующий код с использованием монады выглядит весьма туманно, из-за необходимости использовать вместо прямых вызовов обертки из лямбда-функций и LINQ. Однако без синтаксических средств языка реализовать ее более элегантно вряд ли представляется возможным. 
Достаточно элегантный, как мне показалось, способ реализации данной идеи я обнаружил в спецификации еще пока не созданного языка Kotlin для JDK от ребят из горячо мною любимой компании JetBrains (Null-safety). Как оказалось, такой есть уже в Groovy, возможно и еще где-то.
Итак, что же это за оператор безопасного вызова? Предположим, у нас есть выражение:
string text = SomeObject.ToString();

В случае, если SomeObject является null, мы неминуемо, как уже говорилось, получим NullReferenceException. Чтобы этого избежать, определим в дополнение к оператору прямого вызова ‘.’ еще и оператор безопасного вызова ‘?.’ который выглядит следующим образом:
string text = SomeObject?.ToString();

и представляет собой на самом деле выражение: 
string text = SomeObject != null ? SomeObject.ToString() : null;

В случае, если безопасно вызываемый метод или свойство возвращает структурный тип, необходимо чтобы присваиваемая переменная имела тип Nullable. 
int? count = SomeList?.Count;

Как и обычные вызовы, такие безопасные вызовы можно использовать цепочками, например:
int? length = SomeObject?.ToString()?.Length;

который преобразуется в выражение:
int? length = SomeObject != null ? SomeObject.ToString() != null ? SomeObject.ToString().Length : null : null;

Здесь скрывается некоторый недостаток предлагаемого мной преобразования, поскольку оно порождает дополнительные вызовы функций. На самом деле желательно было бы преобразовывать его, например, к виду:
var temp = SomeObject;
string text = null;
if (temp != null)
    text = temp.ToString();

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

Как вы может уже слышали, совсем недавно была выпущена CTP версия проекта Roslyn, в рамках которого разработчиками языков C# и VB были полностью переписаны компиляторы языков с использованием managed кода, и открыт доступ к этим компиляторам в виде API. С его помощью разработчики могут делать много полезных вещей, например очень удобно и просто анализировать, оптимизировать, генерировать код, писать экстеншны и код фиксы для студии, а возможно и собственные DSL. Выйдет она, правда, еще не скоро, аж через одну версию Visual Studio, но пощупать хочется уже сейчас.
Перейдем к решению нашей задачи и прежде всего представим, как бы нам хотелось видеть использование данного расширения языка в действии? Очевидно: мы пишем код, как обычно, в любимой IDE, используем где надо операторы безопасного вызова, жмем Build, во время компиляции написанная нами с помощью Project Roslyn утилита преобразует все это в синтаксически верный C#-код и вуа-ля, все скомпилировано. Спешу вас разочаровать — Roslyn не позволяет вмешиваться в процесс работы текущего компилятора csc.exe, что в принципе довольно объяснимо. Вполне вероятно, если в той самой vNext студии компилятор заменят на его Managed аналог, то такая возможность появится. Но пока ее нет.
В то же время, существует аж два обходных пути:

Можно создать свой собственный компилятор взамен нынешнему csc.exe с использованием все того же Roslyn API, и изменить свою build-систему, заменив csc.exe на свой аналог, включив в него помимо дефолтной компиляции (довольно, кстати, просто программирующейся) свои предварительные преобразования кода.
Вы можете использовать свою консольную программу в качестве Pre-Build задачи, которая преобразует файлы исходного кода и сохраняет полученные новые исходники в папку Obj. Очень похожим образом осуществляется в данный момент компиляция WPF, когда xaml файлы в фазе pre-build преобразуются в .g.cs файлы. 

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

Конечно, все написанное ниже лишь пример, страдает от множества пороков и не может использоваться в реальности без существенных доработок, однако показывает, что такие вещи сделать в принципе можно.

Перейдем к реализации. Для того, чтобы написать программу, нам прежде всего надо установить Roslyn SDK, который скачивается по ссылке, также предварительно придется поставить Service Pack 1 для Visual Studio 2010, и Visual Studio 2010 SDK SP1. 

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

Для примера будем использовать следующий «исходный код»:
public class Example
{
    public const string CODE =
    @"using System;
    using System.Linq;
    using System.Windows;

    namespace HelloWorld
    {
        public class TestClass
        {
            public string TestField;
            public string TestProperty { get; set; }
            public string TestMethod() { return null; }
            public string TestMethod2(int k, string p) { return null; }
            public TestClass ChainTest;
        }

        public class OtherClass
        {

            public void Test()
            {
                TestClass test;
                string testStr1;
                testStr1 = test?.TestField;
                string testStr3 = test?.TestProperty;
                string testStr4 = test?.TestMethod();
                string testStr5 = test?.TestMethod2(100, testStr3);
                var test3 = test?.ChainTest?.TestField;
            }
        }
    }";
}

Данный исходный код за исключением операторов безопасного вызова являются не только синтаксически правильным, но и компилируемым, хотя для нашего преобразования это и не обязательно.
Прежде всего, необходимо по файлу с исходным кодом построить абстрактное синтаксическое дерево. Делается это в два счета:
SyntaxTree tree = SyntaxTree.ParseCompilationUnit(Example.CODE);
SyntaxNode root = tree.Root;

Синтаксическое дерево задается классом SyntaxTree и представляет собой, как ни странно, дерево узлов, наследуемых от базового типа SyntaxNode, каждый из которых представляет некоторое выражение — бинарные выражения, условные выражения, выражения вызова методов, определения свойств и переменных. Естественно, абсолютно любая конструкция C# может быть отображена некоторым экзмепляром класса-наследника SyntaxNode. Кроме того, класс SyntaxTree содержит в себе наборы SyntaxToken, определяющих разбор исходного кода на уровне минимальных синтаксических блоков — ключевых слов, литералов, идентификаторов и пунктуации (фигурные и круглые скобки, запятые, точки с запятыми). Наконец, SyntaxTree в содержит в себе элементы SyntaxTrivia — те, которые по большому счету не важны для понимания кода — пробелы и табуляции, комментарии, директивы препроцессора и.т.д. 
Тут следует знать одну небольшую деталь — Roslyn является очень толерантным к синтаксическому разбору файлов. То есть, хотя по-хорошему, ему для разбора надо подавать синтаксически корректный исходный код, на самом деле он абсолютно любой текст пытается некоторым образом преобразовать в некоторое AST. В том числе и наш синтаксически неверный код. Этим фактом мы и воспользуемся. Попробуем построить синтаксическое дерево, и выяснить, каким же образом Roslyn отображает в дереве наш оператор безопасного вызова. 
Оказывается все просто: с точки зрения Roslyn выражение test?.TestField является тернарным оператором с условием — «test», выражением «когда верно» — “.TestField”, и пустым выражением «когда неверно». Вооружившись этой информацией, будем преобразовывать наше дерево. Тут натыкаемся еще на одну особенность Roslyn — строимое им синтаксическое дерево является неизменяемым, т. е. поправить что-либо прямо в имеющейся структуре не получится. Но не беда. Roslyn предлагает для такой операции использовать класс SyntaxRewriter, который наследует класс SyntaxVisitor, который, как следует из названия, имплментирует небезызвестный паттерн Visitor. Он содержит в себе множество виртуальных методов, обрабатывающих посещение узла каждого конкретного типа (например VisitFieldDeclaration, VisitEnumMemberDeclaration,… всего их порядка 180 штук).
Нам необходимо создать своего наследника класса SyntaxRewriter и переопределить метод VisitConditionalExpression, который вызывается, когда визитор обходит выражение, являющееся тернарным оператором. Далее я приведу целиком код имплементации, тем более, что он невелик, и добавлю лишь некоторые пояснения:
// Находит в синтаксическом дереве операторы безопасного вызова и заменяет их на тернарные операторы
public class SafeCallRewriter : SyntaxRewriter
{
    //Был ли в данный проход заменен хотя бы один оператор ?.
    public bool IsSafeCallRewrited { get; set; }

    protected override SyntaxNode VisitConditionalExpression(ConditionalExpressionSyntax node)
    {
        if (IsSafeCallExpression(node))
        {
            //Строим expression для объекта, проверяемого на null

            string identTxt = node.Condition.GetText();
            ExpressionSyntax ident = Syntax.ParseExpression(identTxt);

            //Строим expression для кода, вызываемого при успешной проверка на != null
            string exprTxt = node.WhenTrue.GetText();
            exprTxt = exprTxt.Substring(1, exprTxt.Length - 1);//убираем точку из записи выражения
            exprTxt = identTxt + '.' + exprTxt;
            ExpressionSyntax expr = Syntax.ParseExpression(exprTxt);

            ExpressionSyntax synt =
                Syntax.ConditionalExpression(//тернарный оператор

                condition: Syntax.BinaryExpression(//проверяемое условие ident != null
                    SyntaxKind.NotEqualsExpression,
                    left: ident, //левый операнд - проверяемый объект
                    right: Syntax.LiteralExpression(SyntaxKind.NullLiteralExpression)), //литерал null
                whenTrue: expr,
                whenFalse: Syntax.LiteralExpression(SyntaxKind.NullLiteralExpression));
            IsSafeCallRewrited = true;
            return synt;

        }
        return base.VisitConditionalExpression(node);
    }

    //Является ли тернарный оператор на самом деле оператором безопасного вызова

    private bool IsSafeCallExpression(ConditionalExpressionSyntax node)
    {
        return node.WhenTrue.GetText()[0] == '.';
    }
}

Отмечу, что первая моя реализация пыталась работать только с логической структурой AST, брезгуя работой с текстовым представлением выражений, но сложность ее очень скоро стала превышать все мыслимые пределы. Одних только функций для определения безопасного вызова и его типа было три штуки: для полей и свойств, для вызова методов, для цепочек безопасных вызовов, ибо все это представлялось разными наследниками класса SyntaxNode, и еще множество функций для преобразования различных типов безопасных операторов. Совершенно выдохнувшись, я выбросил первый вариант в мусорку и во второй раз я воспользовался удобными функциями GetText и ParseExpression, которые предоставляет Roslyn и некоторыми грязными хаками на уровне строк :).
Также советую обратить внимание на процесс создания синтаксического узла (в данном случае ConditionalExpression) и приятность использования в этом случае такой фишки C#, как именованные параметры. Ручаюсь, если бы ее не было, в процессе построения синтаксических узлов можно было бы сойти с ума.
Приведем теперь код основной процедуры:
static void Main(string[] args)
{
    //Строим синтаксическое дерево
    SyntaxTree tree = SyntaxTree.ParseCompilationUnit(Example.CODE);
    SyntaxNode root = tree.Root;
    SafeCallRewriter rewriter = new SafeCallRewriter();
    do

    {
        rewriter.IsSafeCallRewrited = false;
        //Обходим дерево, производя заданные операции в различных типах узлов и переписывая дерево
        root = rewriter.Visit(root);
    } while (rewriter.IsSafeCallRewrited);//за предыдущий проход был найден и преобразован хоть 1 maybe-оператор

    root = root.Format();//программный Ctrl+K, Ctrl+D

    Console.WriteLine(root.ToString());
}

Поясню, что несколько перезаписей дерева необходимо для того, чтобы обработать цепочки вызовов. Конечно это можно было сделать рекурсией, но пожалуй в данном случае это только затуманило бы код. Также обратите внимание на чудесную функцию Format. Она программно делает заданное стилистическое форматирование кода, т.е. добавляет в AST все необходимые SyntaxTrivia.
В результате имеем следующий код:
using System;
using System.Linq;
using System.Windows;

namespace HelloWorld
{
    public class TestClass
    {
        public string TestField;
        public string TestProperty
        {
            get;
            set;
        }

        public string TestMethod()
        {
            return null;
        }

        public string TestMethod2(int k, string p)
        {
            return null;
        }

        public TestClass ChainTest;
    }

    public class OtherClass
    {
        public void Test()
        {
            TestClass test;
            string testStr1;
            testStr1 = test != null ? test.TestField : null;
            string testStr3 = test != null ? test.TestProperty : null;
            string testStr4 = test != null ? test.TestMethod() : null;
            string testStr5 = test != null ? test.TestMethod2(100, testStr3) : null;
            var test3 = test != null ? test.ChainTest != null ? test.ChainTest.TestField : null : null;
        }
    }
}

Итак, первое знакомство с Roslyn прошло успешно, и перспективы его в целом, не обязательно для написания языковых расширений, видятся очень неплохие. Возможно, если есть энтузиасты, этим можно было бы заняться глубже и серьезнее. В C# же есть еще много, чего нам не хватает.  
P. S. Еще один пример подобного использования Roslyn, который мне значительно помог, приведен здесь. 



Миграции баз данных — интеграция с вашим приложением
Software People Team — Thu, 15 Dec 2011 14:45:09 +0000
Автор статьи: Демишев Игорь, CTO Picrand
Данная статья посвящена практическому использованию библиотеки Migraton, появившейся в обновлении CodeIgniter версии 2.1.0. Настоятельно рекомендую вам перед ознакомлением с данным материалом прочесть первую часть статьи, в которой говорится непосредственно о создании миграций.


Постановка задачи и ее решение

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

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

В проекте, для которого я делал интеграцию миграций, все контроллеры также наследуют не базовый CI_Controller, а расширенный  MY_Controller, который содержит в своем конструкторе некие служебные действия, в том числе и с базой данных. Поэтому для файла %site_path%/application/core/MY_Controller.php нам будет необходимо добавить несколько строчек:
 if ( ! defined('BASEPATH')) exit('No direct script access allowed');

class MY_Controller extends CI_Controller {
    protected $db_update = FALSE; // it's TRUE if site's database  needs update, FALSE otherwise

    public function __construct() {
        parent::__construct();
        $is_admin_page = is_a($this, 'Admin');
        $this->db_update = $this->migration->get_fs_version()!=$this->migration->get_db_version();
        if ($this->db_update) {
            if (!$is_admin_page)
                show_error('Пожалуйста, попробуйте перезайти через несколько минут', 503, 'Простите, на сайте в настоящее время проходят технические работы');
            else return TRUE;
        }
        ### Your super overpowered code goes here..

    }
}


Примечание: как и в прошлой статье, все файлы с исходным кодом приведены в конце статьи
Я думаю, что код в целом понятен, стоит лишь заметить, что ошибку мы будем показывать везде, кроме страницы админки (контроллер Admin, который унаследует MY_Controller). Но для админки не будем выполнять конструктор дальше, т.к. он может содержать в себе обращения к базе данных, которая имеет устаревшую структуру. Кстати, как вы видите, сначала в конструкторе вызывается код родительского конструктора, что реализует паттерн Decorator.
Создаем скрипт обновления через админку 

В моем случае вся админка находилась в одном контроллере Admin, так что и мы для простоты примера возьмем такой же случай.

Этот контроллер админки содержит несколько разноплановых методов, которые позволяют управлять содержимым сайта. Не очень хорошее и элегантное решение, если честно — все же настоятельно советую разносить это по разным контроллерам или даже использовать HMVC-плагин для CodeIgniter (на хабре уже был неплохой пример его использования).
Итак, у нас есть задача сделать так, чтобы можно было авторизироваться в админке, и на любой из страниц выводилось предложение обновить базу данных. Для этого отлично подойдет волшебный метод _remap, который будет вызываться при обращении к любому из методов контроллера, и принимать решение, передать управление запрашиваемому методу или показать кукиш сделать какое-либо другое действие:
    public function _remap($method, $params = array()) {
        if (!$this->m_user->authorised() && $method != 'index') {
            header('Location:/admin/'); //If user isn't autorised, redirect him to the login form

        }
        if (!$this->db_update || (!$this->m_user->authorised() && $method== 'index') || $method=='logout' || $method=='update_db') {
            return call_user_func_array(array($this, $method), $params); // Calls requested method if it is ok to do so

        }
        else {
            $this->data['body'] = 'Внимание!
                Необходимо обновить базу данных'; // Show update database link

            $this->load->view('admin/default.phtml', $this->data);
        }
    }


Тут стоит пояснить, что m_user — модель, которая содержит в себе все методы для работы с пользователями админки (предлагаю вам реализовать самостоятельно), метод index умеет показывать форму входа для незалогиненных пользователей, ну а logout понятно что делает.
Кроме того, создадим там же метод для обновления базы:
    public function update_db() {
        $this->data['body'] = 'Обновление базы данных успешно завершено
';
        if ( ! $this->migration->current()) {
            show_error($this->migration->error_string());
        }
        $this->load->view('admin/default.phtml', $this->data);
    }


Правим конфиг и тестируем

Наконец, осталось поправить конфиг, и мы сможем воспользоваться всем тем, что написали для нашего проекта. Для этого добавим в автозагрузку класс Migration. Теперь строка с авто инициализацией библиотек в моем случае выглядит следующим образом (файл %site_path%/application/config/autoload.php):
    $autoload['libraries'] = array('database', 'session', 'migration');



Еще нам необходимо проверить в файле %site_path%/application/config/migration.php, ключены ли миграции, посмотреть правильно ли указаны к ним путь и версия базы данных, требуемой для корректной работы нашего кода (все точно так же, как и в прошлой статье):
    $config['migration_enabled'] = TRUE;
    $config['migration_version'] = 1;
    $config['migration_path'] = APPPATH . 'migrations/';



Обратите внимание, что я указал 1-ю версию, что подразумевает, что мы уже сделали функционал рассылок, миграцию для которого мы писали в предыдущем туториале.
Теперь вы можете перейти на любую страницу вашего сайта, не относящуюся к админке и должны будете увидеть сообщение об ошибке, т.к. версия базы данных у нас сейчас нулевая (при первой инициализации библиотека Migration создала в вашей базе табличку migrations и указала там версию 0), а версия кода в конфиге указана первая. Перейдя же в админку и пройдя авторизацию, вы увидите предложение обновить базу данных, и нажав на ссылку получите свежее приложение, без необходимости выполнять все запросы вручную!
Бонус — скрипт обновления через CLI

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

К счастью, CodeIgniter в своих последних версиях имеет возможность запускаться из командной строки, что называется из коробки. Поэтому для начала создадим контроллер %site_path%/application/controllers/cli.php с private переменной $args, которая будет содержать все аргументы, с которыми был вызван скрипт, кроме названия контроллера и его метода (отсечем их в конструкторе):
 if ( ! defined('BASEPATH')) exit('No direct script access allowed');

class Cli extends MY_Controller {
    private $args = array(); // Contains CLI arguments, except controller name and its method

    public function __construct() {
        parent::__construct();
        if(!$this->input->is_cli_request()) {
            show_404();
        }
        $this->output->enable_profiler(FALSE);
        $this->args = array_slice($_SERVER['argv'], 3);

    }
    // Other code goes here..

}


Кстати говоря, советую еще обратить внимание на место в конструкторе, где проверяется, пришел ли запрос через CLI. Мы же не хотим чтобы через сайт можно было выполнить служебные методы! Как видите, я еще и профайлер отключил тут, т.к. на тестовых серверах он у меня по умолчанию везде включен, а в CLI он явно был бы лишним.
Наконец, напишем метод для миграций:
public function migration() {
    if ( !is_array($this->args) || empty($this->args)) {
        print ( "Usage: php index.php cli migration [OPTIONS]\n\n" );
        print ( "Options are:\n" );
        print ( "-l, --last\t\tupdate database to the latest version\n" );
        print ( "-c, --current\t\t show current versions of database and code\n" );
        exit;
    }
    for ( $i=0; $i$this->args); $i++ ) {
        $arg = $this->args[$i];
        if ( $arg=="-l" || $arg=="--last" ) {
            print "Updating your database to the latest version..\n";
            if (!$this->migration->current()) {
                print $this->migration->error_string().'\n';
                exit;
            }
            else print "Update complete!\n";
        }
        elseif ( $arg=="-c" || $arg=="--current" ) {
            print 'Current code version is:\t'. $this->migration->get_fs_version().'\n';
            print 'Current database version is:\t'.$this->migration->get_db_version().'\n';
        }
    }
}



Для его вызова нужно всего лишь набрать в командной строке “php /%index_dir%/index.php cli migration” без дополнительных атрибутов, и скрипт вам любезно подскажет доступные для использования опции. Ну а если набрать “php /%index_dir%/index.php cli migration -l“, то метод попытается обновить вашу бд, и выдаст вам результат.

Конечно, этот кусок кода всего-лишь пример, который выполняет лишь сами основы, но общее представление о использовании CLI и миграций он даёт, и вам не составит труда добавить, например, опцию ‘-r ‘ для апдейта базы до указанной ревизии (что кстати будет простеньким домашним заданием для вас).

Заключение

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