Меньше ветвлений!

Одно из правил Таранцова гласит: в программе не должно быть большого редко исполняющегося куска кода.

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

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

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

1. Увеличиваются затраты на автоматизированные тесты и на QA.

2. Рано или поздно вкрадется бага, не отловленная тестами и не пойманная вашим QA-процессом. (Например, всё рушится только под Windows Vista x64, установленной на FAT32-раздел.)

3. Продукт с этой багой вы можете поставить заказчикам и не узнаете о ней, пока заказчик с ноутбуком под Windows Vista x64 на FAT32 не запустит ваш продукт вдали от Интернета.

Сравним с вариантом Б. Исключение всегда сначала записывается, потом устанавливается таймер, он срабатывает, исключение считывается и отправляется. Нормальную (частую) и ненормальную (редкую) ситуации обрабатывает один и тот же код; если он не работает, пользователи закричат об этом сразу же.

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

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

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

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

CrashKit

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

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

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

В ближайшее время мы введем в строй поддержку целой кучи языков, так что на чем бы вы ни писали, смело шагайте на crashkitapp.appspot.com, оставляйте свой e-mail, и мы в течение месяца пригласим вас участвовать в бета-тестировании.

(Если вам интересно, CrashKit написан на Google App Engine. Он уже некоторое время используется в приложениях, которые мы поставляем клиентам. Хорошо работает поддержка Java/OSGi, в разработке поддержка Java/Servlets и Python/Django, после них будет Ruby on Rails и что-нибудь еще, чего захотят пользователи.)

ProjectSync 1.2

Мы опубликовали ProjectSync — Eclipse-плагин, который синхронизирует папки на диске с Working Set'ами в Eclipse'е. Он автоматически импортирует недостающие проекты, а также автоматически перемещает вновь созданные проекты в нужную директорию (согласно их Working Set'у).

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

ProjectSync ничего не делает за вашей спиной и не тормозит Eclipse; синхронизация активируется пунктом в меню Project.

Последнюю версию 1.2.1 можно взять со странички www.yoursway.com/free/ProjectSync/. Проверен на Eclipse 3.4 и Eclipse 3.5 M5. На Eclipse 3.3, скорее всего, тоже работает.

Там же есть ссылки на сорцы, баг-трекер, лицензию (EPL) и способы получения техподдержки.

Совместимость

Название этой операционной системы, созданной маленькой компанией в конце 80-х и установленной сегодня на 8% компьютеров мира, программисты под Mac и iPhone регулярно вспоминают, набирая префикс NS у названий системных классов.

Nextstep 1.0 появилась в 1989 году после трех лет разработки, имела полностью объектно-ориентированное API с архитектурой model-view-controller, имела ядро Mach и была Unix’ом. Теперь она называется Mac OS X. За прошедшие 20 лет дизайн её API, теперь именующимся Cocoa, мало изменился: всё те же NSApplication, NSView, NSDocument успешно лежат в основе сегодняшних красивых анимированных Mac-приложений. Исходники GNUstep, реализующего Nextstep API 1993 года, можно в наши дни читать вместо (недоступных) исходников Cocoa.

Пользовательский интерфейс Nextstep включал богатый drag’n’drop между приложениями, Dock, инспекторы, общесистемные сервисы, позволяющие приложениям пользоваться услугами друг друга, и «бандлы» — директории, выглядящие как файлы для пользователя и содержащие приложение со всеми зависимостями, которое достаточно просто скопировать на жесткий диск для установки. Всё это знают и любят сегодняшие пользователи маков.

Как относятся в Apple к совместимости? Плохо. Первую революцию они сделали в 2001 году с выходом Mac OS X: старые приложения теперь могли запускаться только в приложенной виртуальной машине, эмулирующей Mac OS 9 (при этом, естественно, выглядели неприглядно и медленно работали). В 2005 году эмулятор почил с выходом OS X 10.4 (итого: 4 года на портирование старых приложений).

Для портирования людям был дан Carbon — C API, почти повторяющее API старой Mac OS 9. Carbon-приложения всегда оставались нежеланными гостями на компьютере: look’n’feel интерфейса OS X, как истинно объектно-ориентированной ОС, реализован в коде Cocoa (да, там можно изменить поведение стандартных элементов управления, просто унаследовавшись от них). Carbon представлял собой еще одну реализацию примерно того же самого интерфейса.

Вторую революцию Apple сделала в 2007 году: Carbon объявлен устаревшим и не будет поддерживать 64-битные приложения. Кадр года: Adobe переписывает Photoshop на Objective C. Называется, а вам слабо такое устроить?

Что приобретено взамен совместимости? Общий уровень приложений платформы: они все обновляются и соответствуют современным стандартам. Это работает по спирали: от более высокого качества приложений увеличиваются ожидания пользователей («никто не запустит программу без большой красивой иконки»), от высокого уровня ожиданий растет качество приложений. Apple создала платформу, в которой качество является более значимым (по сравнению с другими платформами) конкурентным преимуществом, и от этого создатели приложений больше инвестируют в качество.

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

Зато NeXT/Apple серьезно относятся к преемственности навыков пользователя. Метафора пользовательского интерфейса Nextstep/OS X не меняется уже 20 лет. Внешний вид окон OS X не меняется 8 лет. Интерфейс приложений развивается эволюционно; Photoshop переписали, но выглядит и работает он так же; вышла новая версия iWork, но она только местами отличается от старой.

Что происходило всё это время в параллельном мире? 1989 год — релиз Nextstep 1.0 — вышла Windows 2.0 без перекрывающихся окон. 1995 год — вышла Windows 95, прощай, все старые навыки. 2001 год — вышла Window XP, теперь вы не узнаете свою панель управления. 2002 год — Microsoft выпускает .NET Framework 1.0, Desktop-приложения на котором до сих пор никто не пишет. Кстати, писать Desktop-приложения вообще не на чем: MFC — поганое уродство, всё остальное до жути низкоуровневое (Win32 API отличается от Cocoa как ассемблер от Питона).

2007 год — вышла Windows Vista, прощайте, привычки, теперь всё в новом месте. Зато спиздили еще чуть-чуть гуйни мака, сделали мигающий экраном костыль для безопасности приложений (на маке privilege elevation в приложениях к этому моменту уже много лет как нормально ненавязчиво работало). Вышел Office 2007, его нужно изучать заново. 2009 год — Microsoft в Windows 7 меняет Taskbar на Dock и хвалится этим достижением в блоге. Кстати, Office 2007 Ribbon Bar будет доступна всем приложениям, теперь вам придется заново изучать не только офис.

Зато вы всё еще можете запускать DOS-приложения на Windows Vista. Реймонд Чен в своём блоге высоко воспевает культуру совместимости в Microsoft. Но стоит ли она выпуска инвалидских продуктов? Всё дело в крупно-корпоративном рынке, которому его старые приложения ценнее качества ОС. Возможно, во времена Windows 95 совместимость была необходима и для пользователей: графические интерфейсы стали массовыми именно после Windows 95, и имей она проблемы, этого могло просто не произойти.

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

Мораль два: нет так быстро всё меняется в ай-ти; команды под руководством великих людей создают технологии, живущие десятилетиями.

Мораль три: культура качества — ценнейшая штука для любой платформы; без неё корпорации не способны выпускать хорошие продукты, даже если на рынке есть образцы для подражания.

NSCoderNight(Nsk)

Если вы живете в Академгородке Новосибирска и интересуетесь программированием под мак (или вы интересуетесь теми, кто интересуется программированием под мак), присоединяйтесь к хакатону NSCoder Night по вторникам в 19:00 в кофейне на ВЦ.

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

Зачинщик события в Новосибирске — сооснователь нашей компании Михаил Калугин. Я буду тоже. О других местах, где проводится NSCoder Night, читайте на nscodernight.com.

Наконец, посты про NSCoder Night(Nsk) просьба помечать тегом nscodernsk, чтобы их можно было найти в блогосфере.

Лирика или музыка?

Пять альбомов в истории Pink Floyd наполнены глубоким смыслом и эмоциями, переданными потрясающей лирикой и выдающейся музыкой. Это Dark Side Of The Moon, Wish You Were Here, Animals, The Wall и The Final Cut.

Появились они благодаря гениальности человека по имени Roger Waters, создавшего их замысел и написавшего к ним лирику. Человека такого же уровня доброты и ума, как Джон Леннон. Человека, которого можно было бы считать великим русским писателем, будь он русским писателем.

Pink Floyd распалась потому, что их музыка держалась на великом гитаристе по имени David Gilmour, идеи Waters'а которому были чужды. Gilmour хотел играть просто красивую мощную музыку в стиле светлых лет Pink Floyd, а Waters всё больше подчинял музыку своей всё более немузыкальной лирике.

The Final Cut — последний альбом Pink Floyd, созданный Waters'ом. Он даже не совсем принадлежит группе; его полное название читается «The Final Cut: A Requiem for the Post-War Dream by Roger Waters, performed by Pink Floyd».

Альбом начал свою жизнь легким завершением The Wall и должен был включать песни из его экранизации, а также некоторые песни, задумывавшиеся для, но не попавшие в «Стенку». Но после войны между Англией и Аргентиной 1982 года альбом стал тем, чем он есть — сложным тематическим завершением The Wall, использующим похожую эмоциональную структуру, но создающим реалистично-светлые чувства к концу.

The Wall — весьма попсовый альбом в смысле сложности его восприятия: он столь пропитан эмоциями, что его сложно не понять. Мелодическая структура Dark Side Of The Moon тоньше, Animals и Wish You Were Here значительно более спокойные. The Final Cut еще более некричащий, и его прослушивание требует примерно столь же развитого вкуса и умения слушать, как классическая музыка.

Тем временем, без Waters'а David Gilmour создал альбом The Devision Bell, название которому придумал Douglas Adams, а мусором который обозвал Waters. The Devision Bell нравится многим, что неудивительно: в нём наблюдается возврат к попсовому — легко воспринимаемому — звучанию. К сожалению, нет и глубокой лирики.

The Devision Bell мне напоминает культ самолётопоклонников, описанный Фейнманом. Красивая музыка, странные слова, всё сделали как надо — почему же получилось не так, как раньше? (Что мне не мешает иногда его слушать, конечно. Гилмор великий гитарист.)

«Music, when combined with a pleasurable idea, is poetry. Music without the idea is simply music.» (Edgar Allan Poe).

Все выдающиеся исполнители, взрослея, уходят от легко воспринимаемого звучания независимо от того, становится ли их музыка более простой или более сложной по структуре. Сравните ранних Beatles, поздних Beatles и сольные записи Леннона. Сравните ранних и поздних Deep Purple, и то, что они сейчас играют на концертах. Наконец, сравните раннего и позднего Waters'а. Что интересно, взросление лирики куда как менее заметно, чем взросление музыки. Быть может, потому, что писать взрослую лирику проще, чем писать немассовую музыку.

Мораль? Breathe, breathe in the air. Don't be afraid to care. Look around, choose your own ground. Long you live and high you fly, and smiles you'll give and tears you'll cry, and all you touch and all you see is all your life will ever be.

Всё, что нужно знать про Git

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

Часть первая из трёх: объекты

Git-репозиторий состоит из набора объектов, лежащих в папке .git/objects. Каждый объект хранится в файле, названном в честь SHA-1 хеша его содержимого. Например, объект 55f6209f867f37598cfb56832adf74bee2921c3f лежит в файле .git/objects/55/f6209f867f37598cfb56832adf74bee2921c3f.

Есть четыре вида объектов (blob, tree, commit и tag), о которых мы сейчас поговорим.

1. Все файлы вашего проекта — это blob'ы. Возьмём каждый файл, припишем к нему в начало тип "blob" и размер, посчитаем SHA-1 и запишем это в репозиторий. (Имя файла в blob не входит, так что одинаковые по содержимому файлы окажутся записанными только один раз.)

2. Каждая директория проекта — это объект tree. Он ссылается на другие деревья и blob'ы, а также указывает их имена и атрибуты. Вот пример содержимого объекта tree:

100644 blob 6fccfdcbd0a1cdbf3bf2a5960e601b369c0a921c    .gitignore
040000 tree 824b4bd4a0df733b5b5106b1b55c3630566759dc    com.yoursway.sadr.core
040000 tree 2406b80d9623067f92db7f60d6eeabfed6966a9f    com.yoursway.sadr.engine
040000 tree d1bae2405388774e484cfd3779adf7e1eda1f5d9    com.yoursway.sadr.python.core
040000 tree f3d282a4b963183fefdca6ff99a5995953a9c33e    com.yoursway.sadr.python.idioms.core
100755 blob 14cf98b8521eb27ae556d9b707290e177b337ff4    propagate-settings-from-core

3. Наконец, объекты commit образуют историю проекта. Коммит ссылается на tree корневой директории проекта, а также имеет родителя или родителей (которых несколько в случае merge'а). Вот пример объекта commit:

tree fdb267652d8d669e86ad0df61afc81b92a7ce680
parent b95b2ca7e9854898d62fb028f2e6135b3439240d
author Andrey Tarantsov  1223355822 +0700
committer Andrey Tarantsov  1223355822 +0700

Huge performance fix: findGoalStateByGoal is now DFS.

findGoalStateByGoal used to traverse every path is the graph and
thus was very slow (as slow as 500 ms travesing 3M goals on every
subgoal creation!) Changed to a real DFS.

Смотрим содержимое репозитория. Пусть последний коммит проекта имеет, например, имя c889ffc87048cca59f908d3e48becb59a14ce950. Посмотреть его содержимое мы можем, введя команду

git cat-file commit c889ffc87048cca59f908d3e48becb59a14ce950,

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

git ls-tree fdb267652d8d669e86ad0df61afc81b92a7ce680

(деревья хранятся в бинарном формате, поэтому git cat-file tree выдала бы бинарный мусор, а вот вывод ls-tree вы видели выше). Наконец, содержимое файла смотрится, опять же, командой

git cat-file blob 6fccfdcbd0a1cdbf3bf2a5960e601b369c0a921c.

Следует понимать, что вместо команды git cat-file вы можете просто раззиповать нужный файл из .git/objects. (Перед данными файла там окажется префикс из типа объекта и его размера.) Создать объект в репозитории можно командой git hash-object -t тип -w --stdin.

Часть вторая из трёх: ссылки

Как узнать, что коммит c889ff… является последним коммитом проекта? Для этого Git еще хранит так называемые ссылки (references). Например, в файле .git/refs/heads/master в текстовом виде хранится хеш последнего коммита на бранче master.

Ссылки могут ссылаться друг на друга. Например, ссылка .git/HEAD обычно имеет такое содержимое:

ref: refs/heads/master

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

Набрав команду git rev-parse HEAD, можно узнать, на какой именно коммит указывает ссылка с данным именем. Ссылки можно использовать везде вместо названий коммитов, например, можно набрать git cat-file commit refs/heads/master. Имена ссылок можно сокращать, отбрасывая слева куски пути, если это не вызывает неоднозначности. Например, можно написать git cat-file commit master. (Кстати, в мане rev-parse описаны все способы указания коммитов в Git.)

Часть третья из трёх: индекс

Между вашей рабочей директорией и репозиторием есть промежуточное звено, называемое индексом (index). Все изменения, которые вы хотите закоммитить, вам нужно положить в индекс командой git add, а потом по индексу создать коммит командой git commit.

Хозяйке на заметку. На практике я всегда пользуюсь командой git commit --inter -v, которая запускает интерактивный add (git add -i), а потом сразу делает коммит, причем (опция -v) в редакторе показывает мне diff всего, что я собираюсь закоммитить.

Что такое индекс? Индекс похож на дерево (tree), но отличается от него тремя вещами:

Во-первых, индекс хранит ссылки на блобы файлов всех поддиректорий проекта.

Во-вторых, индекс хранит i-node'ы файлов — информацию, позволяющую быстро определять, изменился ли файл в рабочей директории по сравнению с индексом.

В-третьих, при наличии конфликтов merge'а индекс может хранить ссылки на три блоба для каждого файла (базовая версия, "их" версия и "ваша" версия).

Почему вам нужно знать про индекс? Во-первых, потому, что команда commit закоммит не то содержимое файлов, которое лежит в рабочей директории, а то содержимое, которое было добавлено в индекс командой git add. Во-вторых, потому, что при разрешении конфликтов merge'а вам может захотеться вытащить эти альтернативные версии файлов (git ls-files -u покажет вам файлы из индекса, имеющие конфликты, т.е. больше одной версии).

Вот и всё

На манипуляции с объектами, ссылками и индексом строится весь Git. Чаще всего удобно полагаться на неё для выполнения нужных операций, но иногда можно вносить желаемые изменения руками.

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

Git умеет хранить объекты и ссылки компактно в одном файле (которые называются pack'ами), сжимая их чем-то вроде LZW, причем размещая данные в таком порядке, что получается еще эффективнее, чем хранить дельты. Git умеет восстанавливать данные о переименованиях файлов, перемещениях и копированиях кусков файлов уже во время отображения истории.

Как изучать дальше?

Все команды подробно описаны в man pages, которые можно также читать на сайте. Важно понимать структуру объектной базы данных. Читайте Git tutorial (не забудьте прочесть вторую его часть) и описывающий всё-всё-всё Git user manual. Наконец, естественно, есть видеолекция Linus Torvalds on Git (Линус, объясняющий, что такое мастурбация — смотреть всем!)

Далее я попробую резюмировать то, что вам стоит узнать.

Лучше всего избегать merge'ей, они делают историю версий некрасивой (и не так удобно читаемой). Вместо git merge somebody/somebranch старайтесь по возможности использовать git rebase somebody/somebranch (но требуется хорошо понимать, что при этом происходит и чем вы рискуете; никогда так не делайте, если уже залили куда-то свои изменения). Особенно важно держать историю версий линейной, если вы экспортируете коммиты в какой-нибудь svn с помощью git-svn.

Подружитесь с git reset, который един в трёх лицах (soft, mixed и hard). Все три вам в жизни очень понадобятся. Еще полезная штука git stash.

Git умеет импортировать историю из многих систем контроля версий (например см. git cvsimport, также есть много отдельных импортировальщиков), двусторонне синхронизироваться с Subversion (см. git svn). Что касается импорта из CVS, Git в процессе задействует команду cvsps, которая в официальной версии имеет разные баги. Пропатченная версия имеется и очень рекомендуются к использованию при импорте из CVS.

Git умеет переписывать историю. Вообще-то, вооружившись приведенными сведениями, это можно сделать и руками (или хитрым скриптом), но намного быстрее использовать команды git commit --amend, git rebase (особенно git rebase --interactive) и git filter-branch; последний позволяет сделать буквально всё.

Выше ничего не сказано про теги; они есть, причем двух видов (теги можно делать просто ссылками в refs/tags/, а можно дополнительно к ссылкам создавать полноценные объекты, в которые уже помещается комментарий и цифровая подпись). Не упоминался ref log — локальная история изменений каждой ссылки, позволяющая ответить на вопрос, какая версия была у вас в рабочей директории два дня назад (или какой коммит был у вас последним в бранче master вчера). Если вы сделаете дикий rebase и вся история умрёт, ref log вас спасёт; смотрим его командой git log -g.

Есть GitHub, где хостинг для open source-проектов бесплатный, а для проприетарных просто дешевый. GitHub делает управление репозиториями и отслеживание прогресса других маргинально проще, а заодно избавляет от необходимости регулярно вызывать git gc в репозиториях на сервере. (В ваших локальных репозиториях её всё равно нужно регулярно исполнять.)

Наконец, Git — это не только его команды и система контроля версий. Это база данных, которую можно использовать для автоматической децентрализованной синхронизации файлов. Формат базы данных достаточно прост и позволяет работу с ней реализовать на других языках в вашем проекте. В частности, чтение и запись репозиториев Git уже реализована для Java в проекте jgit (и обрастает интересностями вроде встроенной поддержки Amazon S3). Если вам нужна распределенная база данных объектов, похожих на файлы, вам следует посмотреть в сторону Git.