Alive and stirring data

noreply@blogger.com (Miroff) — Mon, 27 Jun 2011 12:13:00 +0000

Msrgincon'11

Подготовка

Вот и прошел очередной Margincon. Попробую рассказать, как оно было на этот раз. Незадолго до, ВНЕЗАПНО выяснилось, что докладов всего 4, и один из них мой. Прознав о моей беде, соратники по OpenStreetMap предложили воспользоваться случаем и сделать lighting talk про OSM. Так что мне пришлось не только спешно дописывать основной доклад, а еще и готовиться к lighting talk. И все в последние два дня. Дальше традиционный поезд Нск-Омск. Twitter хорошо годится для поиска попутчиков. В соседнем купе две девчонки-второкурсницы из НИИЖДа целенаправленно склеили матерого железнодорожника так что он всю дорогу рассказывал им про СЦБ. Затем Омск, традиционная прогулка по набережной с не менее традиционными поисками еды и транспорта до ОмГУ.

Регистрация

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

Доклады

Было всего три штуки. Федор Индутный с докладом про node.js до конференции не добрался чем навсегда испортил себе карму. А жаль, было о чем поговорить с человеком, использующим node.js в продакшене.

Оставшиеся два доклада очень понравились. Александр Гладыш произвел впечатляющий анализ визуальных редакторов бизнес-логики и ненавязчиво презентовал собственный редактор. Макс Трескин рассказал про язык Go. В качестве замены C этот язык выглядит перспективно, но сыровато. Вопрос, есть ли игра Го на Go остался нераскрытым.

Из-за отсутствия Федора участникам пришлось выкручиваться самостоятельно. Lighting talks дали затравку к обсуждению, которое плавно перетекло в open space и afterparty, где желающие могли наобщаться всласть.

Впечатления

Все супер, но мало. И участников и докладов. Университетская аудитория с кафедрой, посаженным проектором и рваным экраном плохо подходит для конференции. Если с докладами еще ничего, то Open Space на ступеньках не очень удался, по сравнению с виски-пати на Codefest. Очень порадовала теплая, дружеская атмосфера. Только ради этого стоит ездить на Margincon. Огромное спасибо Юрию и все кто помогал в организации.

На мой взгляд, формат Margincon'а, как конференции о маргинальных языках, себя исчерпал. Не так уж много этих языков и довольно мало людей могут рассказать что-нибудь помимо стандартного getting started. С другой стороны, хотелось бы избежать рассказов про "новый MVC фреймворк для PHP" или "мобильный битрикс", которые заняли львиную долю того же CodeFest. Хотелось бы услышать доклады про немейнстримные технологии: не-MVC веб-фреймворки, высоконагруженные архитектуры, noSQL и т.п.

Надеюсь, традиция Margincon'а будет продолжаться. Это прекрасный способ узнать что-то новое познакомиться с интересными людьми и услышать в поезде философскую идею Ruby on Rail.

PS: Ни одной фотографии за всю поездку я так и не сделал, так что пост без фотографии.

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

noreply@blogger.com (Miroff) — Thu, 14 Oct 2010 03:45:00 +0000

Что писать в лог

Как-то получается, что когда есть о чем писать нет времени, а когда есть время, писать не о чем. Зато есть проверенные временем посты на RSDN, на которые изредка требуется ссылаться. Вот некрокросспостингом я сейчас и займусь.

Регулярно люди спрашивают как и что писать в логи. Могу рассказать как это сделано в одном реальном проекте. Способов применения логов ровно два: а) помогать инженерам отвечать на вопросы пользователей в стиле "Что я только сделал не так?", и б) помогать разработчикам воспроизводить баги. Для этого критично знать, что, как и в какой последовательности происходило в системе. Если по логу не удается локализовать баг с точностью до строчки кода -- не страшно. Задача лога примерно очертить место поиска.

Уровней логгирования используется всего четыре:

DEBUG

INFO

WARNING

ERROR

Уровень CRITICAL не используется потому что изнутри системы невозможно обрушить ее целиком и навсегда. Поэтому вместо log.crit() вставлен код восстанавливающий систему после ошибки. Внешние сбои, конечно, могут обрушить что угодно, но они фиксируются внешними средствами. В данном случае в роли внешних средств выступает довольно серьезная система мониторинга на основе cacti. На практике не очень интересно, как именно система упала, если отвалился жесткий диск или рухнула сеть.

На продакшене всегда включен уровень INFO. Очень редко, когда требуется воспроизвести особо злобный баг или проверить правильность алгоритма логгирование переключается на DEBUG. Снижать уровень до WARNING или ERROR не имеет смысла, потому что теряется необходимая информация. Если какая-то подсистема (чаще всего демон) забивает общий лог своими сообщениями, то для нее выделяется отдельный лог файл. Разные части системы пишут в собственные лог файлы. Все логи ротируются раз в сутки, а также при каждом перезапуске системы. Это полезно при апгрейдах, чтобы четко различать какие ошибки относятся к старой версии, а какие к новой.

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

ERROR

Логгирование с уровнем ERROR пишется в следующих местах:

там где мы бросаем исключение, при условии, что есть важная информация, которая не попадает в исключение. На самом деле это архитектурный косяк, но все бывает.
```
if (phaseOfMoon.isIncorrect()) {     
    log.error("Incorrect phase of moon at " + someEnvironment);     
    throw new AstronomyException("Incorrect phase of moon"); 
} 
```
там, где мы преобразуем исключение в более общее с потерей информации. Обычно это происходит на границы системы, когда мы не хотим отдавать наружу специфичную информацию.
```
} catch (SQLException ex) {     
    log.error("Databse error", ex);
    throw new SomeInterfaceException("Шеф, все пропало, шеф.") 
} 
```
там, где исключение пробрасывается выше границы нашей системы

там, где прекращается обработка исключения


} catch (SomeException ex) { 
    log.error("Не шмогла, ну и ладно", ex); 
}

в случае ошибок, не связанных с исключениями


if (positiveValue < 0) {
    log.error("Sanity check: positive is negative");
    return;
}

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

WARNING

Общее правило: если какая-то неприятность произошла, но ее появление ожидаемо, неприятность не критична для работы или status quo может быть восстановлен автоматически, то это WARNING. Он пишется в момент обнаружения если неприятность невосстановима, или же в момент автоматического восстановления. Под warning попадают попытки восстановить соединение с сервером, перечитать файл, и т.п.

INFO

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

DEBUG

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

Ну и напоследок несколько метрик. На 1000 строк кода приходится 5 записей в лог. Из них:

51% — Error
21% — Warning
13% — Info
15% — Debug

noreply@blogger.com (Miroff) — Mon, 28 Jun 2010 04:45:00 +0000

MarginCon'10

В субботу прошел очередной MarginCon'10 (потомок RuPy.ru). На этот раз начало было в 0900, так что прогуляться по городу в поисках еды и лулзов не удалось. Ну и ладно, тоже неплохо. По дороге выяснилось, что билет на поезд Новосибирск - Омск можно купить онлайн, при этом его даже забирать не обязательно. Есть электронный check in, как в аэропорту. В следующий раз обязательно воспользуюсь.

На самой конференции было шесть полновесных докладов, некоторое количество микро-докладов на 5 минут и 1 час свободного общения. Затем желающие собрались в заведении под вывеской "Колчак" на afterparty. Увы, билеты на поезд помешали в полной мере насладиться восточной кухней и живым общением, так что засвидетельствовав свое почтение, пришлось отправляться восвояси.

Что было хорошо

Рекламная кампания. Я узнал о MarginCon'е за месяц, как миминиум из трех источников.
Полновесные доклады были очень интересные. Практически не было пересказов мануалов.
Видео-доклады были на высоте. Если в нашем углу нет мало интересных людей, их можно приглашать выступать онлайн. Снимаю шляпу перед блестящей идеей. Отдельное спасибо Льву Валкину за рассказ о собственно опыте.
Twitter в качестве СМИ показал себя великолепно. Завел себе.

Что не очень

Мало обсуждений. Скорее всего из-за того, что люди рассказывали о своем использовании чужих технологий. У них нет уникального знания, которого нельзя нагуглить самому. Разработчики, рассказывающие о собственных технологиях, вызывают гораздо больший интерес.
Lighting talks. Мало, и большей частью ни о чем. Хотя рассказ о Common Lisp очень понравился.
Open Spaces. Опять же общих тем для обсуждения не было. В результате все скатилось в привычное "Образование", "Gnome vs. KDE", "emacs vs. vim" и т.п. Идея с выбором тем, которые потом будут организованно обсуждать радостно провалилась. Народ просто не оставил достаточно заявок.

Что можно изменить

Сменить акцент конференции с собственно маргинальных языков на разработку на маргинальных языках. Тогда под формат попадут вещи связанные с языком, вроде: "Какие новые либы вы пропустили", "Куда движется Python", "Что будет в новой версии Rail", "Когда наконец выйдет Scala 2.8". Понятно, что большинство из этих тем недостойны полновесных докладов и в любом случае будут пересказом чьих-то слов, но Lighting Talks ими вполне можно интересно заполнить.
Выкинуть Open Spaces. После конференции можно сразу переместиться на afterparty (возможно более организованно) и уже там, под пиво, обсуждать. Ресторан для этого мало подходит. Скорее придется снять какое-нибудь кафе. Под такое дело, я даже готов сдать взнос.
Ну и, я надеюсь, слайды и записи будут выложены на сайт.

noreply@blogger.com (Miroff) — Wed, 10 Mar 2010 10:33:00 +0000

Versions

Я уже как-то писал про нумерацию версий на RSDN. Возникла нужда сослаться, так что выношу тот пост сюда с некоторыми изменениями.

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

Не стоит путать внутренний и маркетинговый номера версий. Если меркетинг хочет чтобы какая-то версия называлась Gold Enterprise Platinum Edition 7.0 то это никак не влияет на внутренний номер версии.

Простая и в то же время достаточная система именования версий используют комбинацию из четырех чисел, записанных через точку: major.minor.hotfix.build

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

major — основной номер версии. Переход от одной основной версии к другой означает существенные изменения, часто вызывающие несовместимость с предыдущей версией без дополнительных ухищрений. Смена формата данных, глобальный рефакторинг, редизайн, существенное изменение функционала — достаточные основания для увеличения версии. Исправления багов, даже самых злокозненных, нет. Это число может только инкрементироваться. Увеличение major версии на единицу сбрасывает minor и hotfix в ноль. Традиционно, до релиза major версии равен нулю, с тем, чтобы в момент релиза выкатить пользователям 1.0.0.xxxx и в дальнейшем считать от него.

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

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

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

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

noreply@blogger.com (Miroff) — Mon, 01 Mar 2010 08:37:00 +0000

Bug theory - Initialization flow bug

С простыми багами вроде покончено. Перейдем к более сложным.

Initialization flow bug

Симптомы:

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

Критические места:

Инициализация модулей, добавление новых зависимостей, изменения порядка инициализации.

Проблема в том, что инициализация отдельных компонентов происходит позже, чем их первое использование. В многопоточном случае все может быть осложнено возможным race condition.

Профилактика:

Локализовать инициализацию в одно месте, практиковать Dependency injection, писать интеграционные тесты, при добавлении зависимости анализировать порядок инициализации для разных случаев.

noreply@blogger.com (Miroff) — Wed, 24 Feb 2010 13:15:00 +0000

Bug theory - Redundant expectations

Redundant expectations

Симптомы:

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

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

Это типичный баг "на границе". В определенных условиях сторонний модуль ведет себя не так, как ожидалось. Чаще всего это происходит когда документация на интерфейс была прочитана невнимательно или изначально была неполна. Хороший пример, это NullPointerException при нарушении принципа Деметры.

person.getLeftHand().getRingFinger();

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

Профилактика:

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

noreply@blogger.com (Miroff) — Wed, 17 Feb 2010 12:29:00 +0000

Bug theory - TODO: Implement

TODO: Implement

Симптомы:

Не происходит то, что ожидалось. Выбрасывается NullPointerException, OperationNotSupportedException, InvalidArgumentException или любое другое похожее исключение. Такие баги легко обнаруживаются и легко воспроизводятся. При анализе в коде обнаруживается комментарий "TODO: Implement" или просто отсутствие необходимого кода.

Критические места:

Код после рефакторинга, новые фичи, реализации интерфейсов.

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

Профилактика:

Избегать противоречивых и слишком сложных интерфейсов. После рефакторинга обязательно проверять появившиеся TODO/FIXME.

noreply@blogger.com (Miroff) — Tue, 16 Feb 2010 13:04:00 +0000

Bug theory

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

Ну и для затравки:

Misprints

Симптомы:

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

Критические места:

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

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

Профилактика:

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

noreply@blogger.com (Miroff) — Fri, 30 Jan 2009 07:00:00 +0000

The validation problem

Сложно найти программиста, который бы никогда не сталкивался с задачей проверки пользовательских данных. Буквально на первой же лабе в институте, преподаватель "ломает" программу некорректным вводом. Почти все через это прошли и признают, что относится к входным данным нужно со здоровой паранойей. Вопрос лишь в том, где именно проверять входные данные. Возбужденные сторонники ООП поднимают на щит инкапсуляцию и провозглашают немедленную валидацию на уровне классов бизнес-сущностей, бородатые DBA ратуют за проверки на уровне БД, очкастые архитекторы стоят на вынесении валидаторов в отдельную сущность, аппелируя к SRP. Разумеется, все они правы по-своему.

Есть такая штука, которая называется инвариантом системы. Это такой набор утверждений, истинных в любом ее состоянии. Хороший пример такого инварианта -- бухгалтерский баланс. Сумма активов равна сумме пассивов. Если это не так, значит где-то произошла серьезная ошибка. Для отдельных компонентов могут быть свои инварианты, попроще. Например, для любого счета всегда известна валюта или метод никогда не возвращает null. В первую очередь инварианты нужны внутри самой системы. Если мы знаем, что для всех счетов всегда известна валюта, мы можем обращаться к ней без проверки не рискуя получить NullPointerException. Кто же ответсвенен за консистентное состояние системы? Очевидно, сама система. Технически это можно сделать разными способами. Годятся простые проверки, вынос обязательных полей в конструкторы, констрейнты на базе, ассерты, современные средства контрактного программирования и все прочее, что придет в голову. Однако у инварианта есть side effect в том, что каждое дополнительное утверждение снижает гибкость системы. Если какое-то состояние системы нарушает инвариант, оно невозможно, независимо от желаний программиста. Избыточность в инварианте системы приводит к тому, что вместо простых действий устраиваются танцы вприсядку с целью обойти инвариант.

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

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

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

noreply@blogger.com (Miroff) — Sun, 11 Jan 2009 07:00:00 +0000

Chinese classification

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

принадлежащих императору;

бальзамированных;

домашних;

молочных поросят;

сирен;

сказочных;

бродячих псов;

включённых в эту классификацию;

бешеных;

бессчетных;

нарисованных тончайшей кистью из верблюжьей шерсти;

прочих;

только что разбивших кувшин;

издалека кажущихся мухами.

С точки зрения современного образованного человека китайская классификация выглядит дико. С другой стороны такие классификации встречаются повсеместно, достаточной вспомнить классификатор жанров FB2, библиотечный каталог, или классификатор МКБ-10. ailev вообще высказал мысль о том, что все онтологии -- это замаскированные китайские классификации, ибо именно таковые классификации лежат в основе мира, именно к таким классификациям привыкли люди. Если это так, возникает вопрос, откуда берутся "китайские классификации" и почему люди охотнее создают и пользуются ими вместо строгих таксономий?

Не смотря на кажущуюся сумбурность, "китайская классификация" подчинена определенной внутренней логике. Строгая таксономия делит мир на классы согласно некоторого рационального критерия: принадлежит животное императору или нет; домашнее оно или дикое; существует оно в реальности или же оно вымышленное и т.п. Для "китайской" классификации в качестве основания выступает не рациональный критерий а степень важности некоторого класса. В каноническом примере, создателя классификации равно интересуют, как животные императора, так и домашние животные, независимо от того, кому они принадлежат. Если бы автор пожелал создать на тех же критериях строгую рациональную классификацию, она получилась бы в несколько раз больше и многие ее классы оказались бы невостребованными. "Китайские классификации" стоит рассматривать как оптимизации строгих таксономий под конкретные способы использования.

Очевидно, что любую строгую иерархическую классификацицию можно сделать китайской. Достаточно присвоить классам разные веса и сгруппировать на одном уровне классы с одинаковым весом. Некоторый аналог такого приема в дизайне интерфейсов -- быстрые закладки для часто используемых функций. К сожалению, простого способа обратного преобразования не существует, поскольку невозможно автоматически выделить рациональные критерии из мешанины классов. Единственный достоверный способ на сегодня, это кропотливая ручная обработка. Неудивительно, что инициатива semantic web продвигается с таким скрипом. "Китайские" классификации это объективная часть природы человека, и хотим мы этого или нет, нам придется учиться с ними справляться.

noreply@blogger.com (Miroff) — Fri, 19 Dec 2008 14:00:00 +0000

Data about data

Если открыть спецификацию какого-нибудь формата данных, в ней скорее всего обнаружится раздей посвященный метаданным. Иногда, такой раздел превышает остальную спецификацию в несколько раз по объему и по сложности. В то же время, на практике метаданные используют весьма и весьма нечасто. Существуют даже форматы, которые никто так полностью и не имплементировал, по причине невостребованности. Например, тот же ID3v2 (метаданные для MP3) с его несколькими сотнями тегов начиная от автора песни и заканчивая переводами лирики. Или EXIF, которым пользуются ровно потому, что все современные камры пишут в него параметры съемки. Еще ни разу не видел, чтобы из него кто-нибудь использовал разделы описания или копирайта. Или FB2, по поводу метаданных которого регулярно возникают споры на форумах о том, как их заполнять. Или MARC, с правильным заполнением которого проблемы даже у профессиональных библиотекарей, хотя им-то сам бог велел прекрасно разбираться в предметной области. И какой формат ни возьми, с метаданными будет плохо. Или мало, или много, или в самый раз, но совсем не то, что нужно.

Для того чтобы понять почему так происходит, нужно определить, что такое метаданные. Лаконичное определение из заголовка, конечно, прекрасно, но оно ничего не говорит о том, какие это данные. Почти все факты о данных можно представить в виде утверждений <субъект, свойство, значение>. А набор свойств из предметной области и доменов для значений суть онтология. Например, фокусное расстояние это свойство, которое может принимать значение типа длина (а не угол или скорость). В большинстве форматов онтология жестко зафиксирована, так что не бросается в глаза, но она всегда присутствует.

Вернемся к проблеме. Разработчик формата всегда держит в голове какой-то способ использования этого формата. Иначе он в принципе не смог бы разработать ничего полезного. Однако, как только он фиксируеется на способе он начинает представлять себе предметную область с одной, узкой, точки зрения. В результате получается онтология, описывающая каую-то узкую область, которую разработчик считает верной. Однако, у пользователей совсем другое мнение на этот счет. Почти наверняка кто-то будет использовать формат по другому. ID3 созвался для музыки, но его можно использовать для кучи разных вещей: от записи телефонных разговоров, до калибровочных сигналов дефект-детекторов. EXIF хорошо описывает метаданные съемки, но не годится для описания преобразований, проделанных с оригинальным изображением. Проблема в том, что невоможно предусмотреть все способы использования метаданных и разработать всеобъемлющую онтологию. Более того, такие попытки почти всегда приводят либо к излишней общности либо к излишней сложности. И то и другое отталкивает пользователей от использования метаданных. Хуже, когда появляются несколько стандартов метаданных для одного формата. В итоге каждый софт какие-то форматы метаданных поддерживает, а какие-то нет, что еще сильнее отвращает пользователей. Никому не хочется описывать файл, если при следующей обработке или конвертации эти сведения потеряются.

Как можно с этой проблемой справиться? Если вы разработчик формата, не пытайтесь думать за пользователей -- все равно не выйдет. Дайте им возможность определять собственные онтологии и снабдите их парой убедительных примеров для конкретных узких областей. Хороший пример движения в нужном направлении Adobe XMP основанный на RDF. Нельзя сказать, что этот формат идеален, но хоть что-то.

noreply@blogger.com (Miroff) — Fri, 28 Nov 2008 10:30:00 +0000

Time to live

У каждого предмета есть определенное время жизни. Рано или поздно он устареет, износится и потребует замены новым. Или просто исчезнет проблема, ради решения которой этот предмет создавался, как исчезли мундштуки, подстаканники, пресс-папье и буфеты. Это касается не только материальных объектов, но и информации, в том числе и информационных систем. У каждой строчки кода, у каждого килобайта данных есть собственное время жизни. Время жизни есть даже у таких неосязаемых сущностей, как идеи или соглашения. Для того, чтобы научиться оценивать характерное время жизни, нужно хорошо понимать механизмы разрушения объектов. Например, автомобиль может разрушится в результате аварии, физического износа или морального устаревания. Если известно, что автомобиль морально устареет через 10 лет, нецелесообразно обеспечивать его надежную работу в течение большего срока. Все равно к тому времени он уже окажется под прессом. Знание характерного времени жизни позволяет поддерживать качество на необходимом уровне, не больше и не меньше. Зачем делать автомобиль надежным, если через 10 лет он все равно окажется на помойке, где не важно работает он или нет.

Данные

Оставим за скобками временные данные, которые на то и временные, что их время жизни невелико. Для данных постоянных время жизни составляет от 25 лет до бесконечности. Данные редко становятся не нужны, a накопленные за долгие годы данные невозможно ничем заменить. Например снимки допоптопных аппаратов советской серии Венера, несмотря на отвратительное качество будут жить еще долго. Сперва в качестве основного источника информации, затем для сравнения с современными снимками и анализа изменений. Обычно, вменяемые люди стараются не уничтожать данные, мало ли что еще пригодится. Вдруг завтра из них удастся извлечь новую информацию. Мне доводилось работать с базами, которые пережили три поколения бизнес-кода и переживут еще как минимум столько же. Поэтому к проектированию баз данных нужно относиться особо внимально. Любое ваше сиюминутное решение в угоду производительности или простоте кодирования будут с матюками вспоминать через много лет. Изменить что-то в унаследованной базе, в которой уже накопились гигабайты данных нереально сложно.

Протоколы и стандарты

Две причины, по которым устаревают стандарты и протоколы: они перестают отвечать изменившимся требованиям или появляется способ сделать то же самое проще. Поскольку технологии непрерывно меняются и то, что раньше требовало дестятка PhD, сегодня доступно школьнику, редкий стандарт проживет больше 10 -- 15 лет. Затем, если представится возможность, он отправится на помойку истории. К сожалению это происходит не всегда. Очень часто изменения уже внедренного стандарта, процесс настолько болезненный, что стандарт активно используется не смотря на то, что они окончательно устарели. В качестве вопиющих примеров можно вспомнить Z39.50, SMTP, FTP и HTTP. К проектированию стандартов имеет смысл относиться даже более внимательно, чем к проектированию баз данных. "Внимательно" в данном случае означает не "предусмотреть все возможные случаи", а обеспечить возможность изменений. Все равно предусмотреть все не удастся, а если и удастся, то этим все равно не станут пользоваться из за непомерной сложности.

Код

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

Абстракции и модели данных

Абстракции живут от нескольких минут до тех пор, пока их помнят или пока не придумают что-то получше. Двойная бухгалтерская запись была изобретена в XV веке, а используется по сей день, несмотря на то, что в эпоху компьютеров без нее легко можно обойтись. Даже если абстракция хреновая, она все равно не умирает. Слишком много всего от нее зависит. Тут и код, и привычки людей, и их внутрення картина мира. Если вы предложите бухгатерам отказаться от двойной записи, они вас съедят. Будьте осторожны, если ваша абстракция получит распространение, вы ее уже не остановите.

Пользовательский интерфейс

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

noreply@blogger.com (Miroff) — Thu, 25 Sep 2008 11:02:00 +0000

ICFP Contest '08 Final results

На официальной странице ICFP Contest выложены результаты, которые так долго ждали большевики. Было проведено 11 заездов, в результате которых был определен один победитель (Team Smartass) и 297 неудачников, которым не так повезло. К сожалению финальные карты еще не выложены, поэтому трудно сказать что пошло не так, но финалисты предыдущего чекпойнта "вылетели за ограждение". Как в прошлый раз, я подготовил таблицу с суммарными результатами. Команды отсортированы по количеству раундов, в которых они приняли участие независимо от результата. Команды, прошедшие одинаковое число раундов отсортированы по рейтингу. Напоминаю, чем меньше рейтинг, тем круче. Для каждой команды приведена статистика исходов по всем пяти заездам каждого раунда. В общем, можно меряться. Get it and use it well.

Моя команда называется Mosquito. Каким чудом она попала на 11 место, оставив позади страшных монстров, сам не понимаю. Видимо, новичкам везет.

#	Team	Rounds	Score	Home	Martian	Crater	Timeout	Error
1	Team Smartass	11	512510	50	5
2	shinh	11	515370	49	5	1
3	Error 404	11	541960	50	3	2
4	UBE	11	546000	48	7
5	LazyBear	11	556870	51	2	2
6	SzM	11	608630	40	5	5	5
7	souris aveugle	11	611620	40	12	3
8	frank324	11	643610	39	6	5	5
9	kstm.org	11	674530	40	13	2
10	fireinthedisco2	11	689400	45	8	2
11	Mosquito	11	730040	41	8	5	1
12	Om Nom Nom Nom	11	743140	37	15	3
13	Giantslalom	11	748550	38	16	1
14	epriestley	11	765090	33	17		5
15	intelliarts	10	609050	37	8	1	4
16	cw	10	617070	40	10
17	The B-Team: 25/26ths as good as the A-Team	10	619280	40	1	4	5
18	Blue Iris	10	626860	37	13
19	Spore Sept 7th, only $49.99! Play Bejeweled @ popcap.com!	10	631580	38	10	1	1
20	team_bruno	10	649780	41	9
21	Hands Solo	10	652200	40	8	2
22	jabber.ru	10	654310	37	13
23	Celestial Dire Badger	10	659590	44	6
24	Side Effects May Include...	10	660740	38	12
25	Apathy Kings	10	665890	36	12	1	1
26	CNaml	10	672810	37	13
27	Cup<'t>	10	695250	36	13		1
28	TC2	10	703310	40	10
29	Team Meh	10	710430	38	12
30	Yeahbut	10	712870	43	7
31	td	10	716950	42	7	1
32	Purple Pointer Eaters	10	719560	35	15
33	TeamDJ	10	721200	36	13	1
34	ur 67P	10	723350	32	17	1
35	NMSU	10	732770	39	11
36	Actua	10	739020	34	16
37	Eger a Marson	10	739540	35	13	2
38	EdFred	10	742580	38	10	2
39	Arekuma	10	748030	35	13	2
40	little lemon	10	784960	34	14	2
41	Order of the Fridge	10	805310	33	17
42	HackerDom_1	9	442150	35	10
43	ais523	9	442380	38	7
44	ILL martians	9	448300	34	11
45	Sir Bedevere the Wise	9	450780	34	9	2
46	Kee	9	455360	36	9
47	Urxae	9	465070	34	10	1
48	Heklers	9	465790	33	8	4
49	Malfunctional Programmer	9	470250	35	10
50	42	9	477900	33	11	1
51	Slow	9	478020	36	9
52	LUHPI	9	484290	36	7	2
53	tidder	9	486570	34	10	1
54	elbereth@utmc	9	487230	37	8
55	Wile E.	9	492300	35	9		1
56	12a0	9	494180	31	14
57	PurelyFunctionalInfrastructure	9	501520	34	11
58	RHZ	9	501570	36	7	2
59	m1-speedygonzalez	9	515180	34	11
60	Five of Six	9	516800	30	7	6	2
61	Bobry	9	543260	29	4	11	1
62	a1k0n	9	553370	28	13	4
63	Team Sampou	9	572500	30	14	1
64	taxi driver	8	398800	29	10	1
65	BugbearR	8	411060	34	5	1
66	Dee Mon	8	428540	34	6
67	ayatuki	8	433350	26	9	5
68	HackerDom	8	434210	28	12
69	Too Simplicity and Beyond!	8	438920	26	9	4	1
70	I-cons-a-lot	8	448770	29	9	2
71	The Dibbies	8	448860	23	11	6
72	Hacking in the Rain	8	454330	24	7	8	1
73	Altair	8	462550	29	9	2
74	lazymonkeys	8	468020	30	6	3	1
75	'a infvec	8	471290	28	7	5
76	protocolocon	8	472150	31	4	1		4
77	Kharkiv MIND	8	479810	27	8	5
78	Begot	8	501070	25	15
79	Lazy elf	8	509630	23	10	6	1
80	astsmtl	7	313950	27	8
81	shitamachi no ue	7	319560	27	7	1
82	kounoike	7	323950	28	7
83	Java Jones and the Kingdom of the Crystal Crater	7	331520	26	7	2
84	TBD	7	331980	25	10
85	lepidum	7	333640	27	8
86	ktkr-cpp	7	339090	26	6	2	1
87	miyu	7	341220	30	4	1
88	Gcup	7	341560	26	8	1
89	Epsilon	7	353250	29	4	2
90	nanndemoiidesu	7	355670	25	9		1
91	pirapira	7	357200	25	10
92	barry, our driver, is reckless	7	366510	25	9	1
93	NAU ACM	7	372490	21	9	5
94	TheRoverers	7	373210	24	11
95	DotWeb	7	403330	20	9	6
96	SwtPl	7	403430	21	10	4
97	7-15	7	416680	22	12		1
98	Beer:Thirty	6	263510	24	3	2		1
99	Team DumbAss	6	278530	21	8	1
100	inforfun	6	278540	24	6
101	Team Lolemnity	6	284370	21	5	2	2
102	ntua 67P	6	285500	23	4	3
103	jan nasa	6	295270	23	5	2
104	Pear Programmers	6	295850	24	4	2
105	Christoph Breitkopf	6	297470	24	6
106	spotrover	6	297980	21	3	5	1
107	cashto	6	298450	22	5	3
108	The Weyburn Expatriates	6	299910	22	3	5
109	ORBIT	6	301320	24	2	4
110	Rhope Burn	6	301820	23	2	5
111	aruhimorinonaka	6	302020	22	7	1
112	green_tea	6	303570	24	4	2
113	Bob's Store	6	305870	22	2	6
114	WindowMakers	6	307600	22	7	1
115	The Blind Hen	6	307990	22	6	2
116	bmm team	6	309570	24	2	4
117	Grasshoppers	6	309860	21	6	3
118	The Tcler	6	320610	20	3	6	1
119	ksk	6	321500	21	2	7
120	MIMUW 4060	6	325260	22	6		2
121	Florida Institute of Technology	6	325410	22	5	3
122	D&D	6	327400	18	3	7	2
123	wjdogs	6	328260	17	5	8
124	Kerochan	6	329180	20	7	3
125	The Unchecked Exceptions	6	329930	20	1	9
126	In dumb we trust	6	335040	19	7	4
127	Curry On!	6	335190	17	3	6	4
128	KFL	6	335540	21	2	5	2
129	hibi@utmc.or.jp	6	336640	21	3	5	1
130	YBuzz	6	338630	20	3	6	1
131	Dragons	6	339210	18	3	8	1
132	Q42/Xopus	6	341840	18	4	7	1
133	Team Guyford	6	342030	18	12
134	Arsbit	6	351210	18	5	7
135	one canuck	6	354510	17	7	6
136	Chouser	6	355910	18	3	7	2
137	uguu.org	6	356690	18	4	8
138	midoj	6	367820	19	6	4	1
139	The Tweezer Minstrels	6	370960	15	7	8
140	bens	6	373000	17	8	5
141	apple2gs	6	378790	21	5	4
142	yarunee	6	381880	16	3	8	3
143	The Usual Suspects	6	382080	21	3	6
144	Ramen Holiday	6	383550	19	4	6	1
145	The Code Alchemists	6	384790	21	8	1
146	Team Rocket	6	389320	19	4	7
147	nekoneko	6	393150	17	5	7	1
148	The Inmates	6	393770	20	7	3
149	camping gaz international	6	397790	22	2	6
150	solo r6	6	402650	20	8	1	1
151	GRoboCode	6	403340	19	3	8
152	ktkr-ocaml	6	411990	18	5	7
153	LazyBottoms	6	445710	16	6	7	1
154	spbsunt	5	176870	21		4
155	It's all about the Pentiums.	5	183290	19	3	3
156	Emory PChem	5	184270	19	5		1
157	Toasted Monkeys	5	186140	19	2	2	2
158	Le club des 5	5	188750	19	4	2
159	suihan_jar	5	193440	17	4	3	1
160	Wobbla Team	5	193980	20	4	1
161	__ufo42	5	205480	13	2	6	4
162	Dis Functional	5	209550	15	4	6
163	POSTECH-PL	5	210090	16	5	4
164	The Higher Order Of Zeuxis	5	212910	17	3	3	2
165	Unary Operator	5	214170	18	4	3
166	POSCAT@POSTECH	5	222830	14	2	5	4
167	suzumiyaharuhiko	5	224050	11	7	4	3
168	Hidden Agenda	4	147770	14	6
169	Incompetent Design	4	148210	11	5	3	1
170	OCamlCore	4	153050	12	5	3
171	Knights of Cydonia	4	159050	12	5	3
172	Marcin Simonides	4	160540	12	8
173	td2	4	160620	13	3	4
174	efg	4	161220	13	3	3	1
175	AntiCylonDefenseTeamImpersonator	4	161650	12	6	2
176	ikon	4	162730	10	3	4	3
177	o(ry	4	164470	14	5	1
178	bucchigiri	4	165230	13	2	5
179	Dylan Hackers	4	165310	13	5	2
180	Team Gales	4	165700	11	2	5	2
181	The Rover Routers	4	166900	13	5	1	1
182	Anairiats	4	167190	14	3	2	1
183	Tigerfunk	4	170840	6	2	8	4
184	dot-emacs	4	173780	7	2	8	3
185	Fly (Yaroslavl)	4	175800	12	7	1
186	K&R	4	175840	13	3	4
187	Mostly Harmless	4	178490	12	7	1
188	AyaCFP	4	178530	13	7
189	putzen along	4	178740	12	7	1
190	Enoch Root	4	179780	11	5	3	1
191	futurelabs	4	180990	12	4	4
192	Molotov Mocktail	4	186430	9	7	2	2
193	Servants of Barsoom	4	187290	12	8
194	NetHack	4	187550	12	6	2
195	Ruby Team	4	187930	12	8
196	Almaya	4	188130	12	5	2	1
197	gassa & toxa	4	193000	11	7	2
198	(defun friends)	3	107180	10	3	2
199	The Lone TeXnician	3	107700	8	2	3	2
200	hogelog	3	108370	6		6	3
201	Insane Closure Posse	3	111800	11		4
202	Macrott	3	113310	9	3	2	1
203	Blazing Saddles	3	115370	9	3	1	2
204	yet another team	3	115550	7	4	1	3
205	honey_rooibos	3	116140	9	6
206	Evil Geniuses For a Better Tomorrow	3	117360	10	4	1
207	TeamNewshamBros	3	117630	9	2	4
208	Illudium Q-36 Explosive Space Modulator	3	118060	9	4	1	1
209	Giver	3	118500	9	2	4
210	rmathew	3	119120	5	2	5	3
211	SIMAP	3	119570	9	3	2	1
212	eugene_jeff	3	122240	6	4	2	3
213	polka	3	124300	8	4	2	1
214	Func-n-stein	3	125140	7	2	4	2
215	EddieHasNoPreferenceForName	3	126480	8	5	2
216	Xebia	3	128110	8	3	3	1
217	Bad Science	3	129430	8	6		1
218	Stern Types	3	130400	7	3	2	3
219	siti	3	132470	7	6	1	1
220	panard_groumpf	3	134380	5	3	3	4
221	SugarSun	3	134660	8	6	1
222	mfp	3	135860	4	5	1	5
223	NCSU ARC Alums	3	136960	9	3	3
224	The Bobcat Hackers	3	138980	6	5	2	2
225	Knights of the Crescent Moon	3	140250	5	4	2	4
226	isobe	3	140660	7	4	3	1
227	EarthFusion	3	144310	8	5	1	1
228	Epic Fail	3	146750	6	5	2	2
229	plai	3	147620	5	6	2	2
230	ozy4dm	3	157370	7	8
231	wheezards	2	57930	8	1			1
232	Soul Trader	2	77580	4	2	1	3
233	404 NOT FOUND	2	78470	3		1	5	1
234	WE NEED A TEAM NAME	2	78540	6	2	1	1
235	Not a Number	2	78910	5	2	1	2
236	Stanfy	2	79440	7	1	2
237	Bloody Camls	2	79500	7	3
238	Team Sparrow	2	79740	6	3		1
239	Too much free time	2	80430	6	2	2
240	Linkage Failure	2	80660	7	3
241	kt3k	2	81230	7				3
242	Suzumiya Haruhiko wo Ooini Shizumeru Fullbocco-dan	2	81960	6	3	1
243	University of Western Australia	2	83980	6	2	2
244	Littlechina	2	84830	5	3	1	1
245	Drifter's Revenge	2	85150	5	2	1	2
246	Erraen	2	85860	6	3	1
247	cthulhuivore	2	86940	2	1	3	4
248	ktkr-java	2	89390	4	2	1	3
249	Ocamlman	2	89500	5	2	2	1
250	Team Cow	2	90130	6	2	2
251	Rhinos	2	90200	1	1		8
252	Cup<T>	2	92040	6	3	1
253	The Chun Council	2	92340	6	4
254	FUN	2	92460	4	5		1
255	ICSkies of Blue and F(P)	2	92550	4	2	3	1
256	Felspar	2	92560	6	3	1
257	Happy Camels	2	92670	6	3	1
258	The Teddyborg	2	92850	2	3	1	4
259	drunken ants	2	92860	5	2	2	1
260	foognostic	2	92950	1	2		7
261	Marti	2	93070	6	3	1
262	StreetMagic	2	94650	6	2	2
263	Cal Poly Pomona Computer Science Society	2	97530	6	4
264	nishiohirokazu	2	98510	6	4
265	United Coding Team	2	98880	5	5
266	KuntbucketsAndKuntrags	2	100630	1	3		6
267	Turn Right Left	2	100670	5	5
268	mazeSolver@UTMC	2	102330	3	4		3
269	Schwarzschild	2	107120	5	3	2
270	gpfault id-alex	2	107250	2	4		4
271	aalto high school	2	115320	1	5	1	3
272	The Dudes	2	115510	3	5		2
273	Engineers Without Boulders	2	116710	4	4	1	1
274	The Al-Gore-Rhythms AKA The Doug Boat	2	117700	1	3	1	5
275	Team_XIII	2	119200	5	5
276	The Armstrongs	2	124310	5	1			4
277	casillero del diablo	2	125570	1	5		4
278	gzoluble	2	130690	5				5
279	Chvex Stucture	2	148470	1			4	5
280	SATiriker	1	36160	1			3	1
281	The unmoving notogawa	1	42300				5
282	Monkeyget	1	42300				5
283	Sim	1	42300				5
284	P Squared	1	42300				5
285	gb	1	42300				5
286	mokehehe	1	42300				5
287	ocaml users anonymous	1	42300				5
288	LISA~HackLab-FI	1	42300				5
289	zetafish	1	42300				5
290	Puddingforce	1	42300				5
291	Chicago Blubs	1	42300				5
292	Nodal Asymmetry	1	84000					5
293	incognito	1	84000					5
294	Monadic Cows	1	84000					5
295	Late Ocamler	1	84000					5
296	Rufus2	1	84000					5
297	greedy	1	84000					5
298	The Shiniest of Heisenbugs	1	84000					5

noreply@blogger.com (Miroff) — Mon, 08 Sep 2008 07:45:00 +0000

Закон больших чисел

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

На большой выборке даже маловероятные события становятся наблюдаемыми.

На практике этот закон означает полную неприменимость «наивной» аналитики и, как следствие, «наивного» тестирования при проектировании информационных систем. Если не предусмотреть редкие случаи ещё при проектировании они больно стукнут на стадии эксплуатации, причем далеко не сразу, а лишь по прошествии некоторого инкубационного периода. Это чревато хотя бы тем, что багфиксинг на внедренной системе, в которой уже накоплен значительный объем данных — отдельное развлечение.

Ещё одно проявление Закона больших чисел в том, что невозможно построить информационную систему гарантированно не содержащую ошибок в данных. Простой пример: Оператор вводит данные вручную. Оператор не идеален, поэтому он делает одну ошибку на 100 записей. Это означает, что на 1 000 000 введенных записей будет порядка 10 000 ошибок. Поскольку такое количество ошибок нас не устраивает, мы садим поверх оператора контроллера, который будет проверять правильность ввода. Пусть контроллер более внимателен и продуктивен, однако и он не идеален, поэтому допускает одну ошибку на 1000 записей. Тогда вероятность ошибки снижается до 10^-5 на запись. Однако, на миллионе записей это даст примерно 10 ошибок. Если количество данных неограниченно растет, а так бывает почти всегда, никаким контролем не добиться гарантированного отсутствия ошибок. Даже оценить вероятность ошибки и то не всегда возможно. Люди не механические приборы, к ним паспортов точности не полагается.

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

Признают, что качество данных не имеет значения для бизнеса;
Контролируют качество собственными силами;
Выбирают один из наборов данных и признают его эталонным.

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

noreply@blogger.com (Miroff) — Mon, 11 Aug 2008 11:07:00 +0000

ICFP '08 Results

Опубликованы результыты первых восьми заездов. Для удобства фаллометрии свел все в одну табличку. Get it and use it well.

Score — сумма по всем восьми заездам.

Команды не допущенные до девятого заезда в табличку не включены.

UPD: Добавил восьмой заезд. Плюс организаторы вернули еще 16 команд, дисквалифицированных по техническим причинам.

Team	Score
1	UBE	327090
2	td	329520
3	Celestial Dire Badger	330350
4	Hands Solo	330560
5	Blue Iris	331800
6	Team Meh	332900
7	shinh	333270
8	NMSU	333390
9	team_bruno	333590
10	Team Smartass	334470
11	CNaml	334680
12	Error 404	334770
13	cw	336130
14	HackerDom_1	336740
15	Actua	337670
16	ILL martians	337870
17	Yeahbut	338630
18	fireinthedisco2	340290
19	ais523	340450
20	Arekuma	341070
21	TC2	341190
22	elbereth@utmc	341290
23	Spore Sept 7th, only $49.99! Play Bejeweled @ popcap.com!	341510
24	Apathy Kings	342900
25	LazyBear	347940
26	SzM	348090
27	Wile E.	352650
28	Sir Bedevere the Wise	353750
29	TeamDJ	353980
30	Kee	355170
31	jabber.ru	356170
32	frank324	356270
33	Urxae	358030
34	Malfunctional Programmer	358770
35	Heklers	359580
36	PurelyFunctionalInfrastructure	361340
37	Cup<'t>	362370
38	Side Effects May Include...	362960
39	Purple Pointer Eaters	363780
40	intelliarts	365870
41	Slow	366260
42	EdFred	367150
43	42	367510
44	The B-Team: 25/26ths as good as the A-Team	371520
45	a1k0n	373610
46	RHZ	373950
47	souris aveugle	374140
48	LUHPI	374310
49	little lemon	375620
50	kstm.org	376070
51	m1-speedygonzalez	377810
52	Team Sampou	378210
53	Five of Six	378920
54	Mosquito	381240
55	Eger a Marson	381530
56	ur 67P	385050
57	tidder	385790
58	12a0	389440
59	Giantslalom	390270
60	epriestley	408520
61	Om Nom Nom Nom	409070
62	Bobry	412030

noreply@blogger.com (Miroff) — Tue, 29 Jul 2008 11:41:00 +0000

Nomen est omen

Представим себе гипотетическую ситуацию: некий юноша-с-косичкой подрядился писать программу. Ну хотя бы учет посетителей в библиотеке. (Ещё ни одной приличной не видел) И вот доходят у него руки до учета пользователей и он радостно создает в базе табличку visitors {firstName, lastName, middleName}. А что, у всех буквально есть фамилия, имя и отчество. Вот у его знакомых в родном Крыжополе точно у всех. Да и девочка-библиотекарь, которая заместо аналитика, говорит что так правильно. И вот поступает такая система в эксплуатацию. А там кого только нет: и Александров-Погорельский, Ли Син Цин, и Хосе Луис Мария Педро Фернандос. И вот мучаются библиотекари, стараясь всунуть чуждые имена в прокрустово ложе программы, сыплются проклятья и летят в сторону незадачливого юноши лучики поноса.

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

Ещё одна распространенная ошибка — трактовать отчество как middle-name. Мне попадался даже один декан, который подписывался Boris A. Gladkih, видимо, не подозревая, что читается это как Борис Афанасий Гладких, что суть нонсенс. Второе имя это именно самостоятельное имя, которое можно использовать отдельно, пусть даже оно и дается в честь отца или деда. Отчество же без имени употребляется исключительно в качестве прозвища и только отдельно от фамилии: «Кузмич — за пивом пойдет». На эти грабли качественно наступили создатели формата fb2.

В наш век всеобщей глобализации правильнее не задумываться над традициями присвоения имен, а признать, что человек может сам выбрать как ему называться. Технологически, ничего сложного в этом нет, если только вы не хотите поддерживать все возможные традиции именования. Зато, если завтра к вам придет посетитель, у которого в паспорте написано «БОЧ рВФ 260602 Вячеславович Воронин-Фролов» вы будете к этому готовы.

noreply@blogger.com (Miroff) — Wed, 16 Jul 2008 10:19:00 +0000

ICFP '08 Contest

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

Preambula

Про ICFP contest я узнал начитавшись отчетов и сразуже захотел попробовать. Этот контест выгодно отличается от ненавистных мне «академических» олимпиад и их идиотскими заданиями, не имеющими ни малейшего отношения к реальности. Поскольку по одним субъективными отчетам трудно достоверно оценить явление было решено потрогать воду лапкой прежде чем готовиться к участвовать всерьез. Что и было проделано с величайшим удовольствием. Однако, некоторую подготовку я все же провел: настроил NetBeans с Ruby, создал необходимую структуру папок для проекта, поднял на всякий случай Linux под виртуальной машиной, скачал и запустил LiveCD

Day 0. Landing

За час до начала вылезаю на канал #icfp-contest и наблюдаю там больше 200 человек. С трудом дожидаюсь публикации задания. Большого смысла в этом нет, но хочется уже прочесть его, составить план штурма и отправится спать. Время из-за разницы во времени довольно позднее. В час «X» вся эта толпа, коей набралось уже за 300 человек радостно тянется качать задание и на несколько минут роняет сервер. Наконец я добираюсь до нужного документа и погружаюсь в чтение. Итак, задача этого года, в моем кратком изложении

Есть квадратное поле заданных размеров, представляющее поверхность Марса. На поверхности имеются:

кратеры, в которые можно упасть, насмерть, много;

валуны, о которые можно стукнуться, больно, тоже много;

марсиане, которые норовят сожрать, самоходные, много;

база, дружественная, одна;

марсоход, свой, один.

На поверхность в произвольной точке высаживают марсоход (с довольно реалистичной физической моделью) для которого нужно написать программу управления (общающуюся с сервером по TCP/IP), приводящую его к базе в обход кратеров, валунов и марсиан. Соревноваться в итоге будут программы между собой, у кого лучше, тот и победитель. В деталях, оригинал на 12 страницах.

Прочитав задание, понимаю, что Ruby тут не при делах. Марсоход — железка глупая, не станет ждать пока досчитается, укатится к черту на рога. Решаю применить запасной вариант и использовать Java. Пока разворачивается IDE, лезу качать симулятор, но его ещё не выложили. Основных проблем в задании видится три: 1) Сетевой протокол; 2) Алгоритм управления; 3) Визуализатор для отладки. За пару часов реализую сетевой протокол, описываю необходимые структуры данных и с чистой совестью отправляюсь спать

Day 1. Doctrine: Mobility

Пока я спал, организаторы выложили симулятор, а участники в чате и рассылке развели невообразимый флейм. Быстро скачав симулятор, проверяю свой код. Сетевой протокол работает без отладки. В симуляторе оказывается встроенный визуализатор, так что от одной задачи я на некоторое время избавлен. Несколько часов уходит на то, чтобы научить марсоход ехать в заданную точку. Дело продвигается медленно, потому как тригонометрию я напрочь забыл, уж слишком давно не делал ничего подобного. Когда первая карта проходит отправляюсь кататься на велосипеде, а вечером принимаюсь за объезд препятствий. Лобовое решение, отворачивать от препятствия расположенного в опасном угле по курсу работает плохо. Объехав первый кратер, марсоход сослепу ухает во второй. Мне подкидывают идею, предсказывать положение марсохода на несколько ходов. Решаю заняться этим завтра и отправляюсь спать.

Day 2. Doctrine: Flexibility

Со вчерашнего дня обнаружилась ещё одна проблема: перерегуляция, приводящая к том, что марсоход пролетает мимо базы. Решил сперва побороть её и ввел эвристики, запрещающие крутые повороты вдали от базы для наведения на цель. С предсказанием все плохо, марсоход едет довольно паршиво, часто падает в кратеры и стукается о валуны. Приседания с параметрами дают немного. Это продолжается до тех пор, пока я не начинаю проверять точность предсказаний в реальном времени. Сперва обнаруживается, что я забыл учесть трение и предсказания скорости не слишком точны. Добавив систему оценки трения и ускорения, получаю точность предсказания скорости до четвертого знака. Выглядит хорошо, но точность предсказания расстояния не изменилась. Проверяю расчеты калькулятором и обнаруживаю, что java.lang.Math принимает аргументы синусов и косинусов в радианах, а я считаю углы в градусах. Правлю и точность hgtlcrfpfybq достигает требуемой. Поскольку нет необходимости в играх с параметрами, устанавливаю предсказания на 5 секунд вперед. Все три тестовые карты проходятся, так что я начинаю искать, на чем бы ещё протестировать. Поскольку возможности достать и померяться прямо в процессе организаторы не предусмотрели народ во всю обсуждает результаты и выкладывает собственные карты. Пытаюсь протестировать на чужих картах и обнаруживаю два факта: а) на рандомных картах сходных с тесовыми все работает идеально; б) стенки, «рюмки», «бутылки», лабиринты и прочие непрерывности вводят марсоход в ступор. На этой прекрасной ноте отправляюсь спать.

Day 3. Doctrine: Initiative

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

Conclusions

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

noreply@blogger.com (Miroff) — Thu, 03 Jul 2008 05:01:00 +0000

Date, Time, Interval, and Duration

С представлением времени в большинстве систем творится полный бардак. Ладно, RDF с OWL’ем, там и без этого все плохо, но даже в стандартных библиотеках самых что ни на есть мейнстримных языков полный бардак. Ну что нужно курить чтобы в стандартный класс Date добавить преобразование к Юлианскому календарю? Ни разу не встречал человека, которому бы это потребовалось. Зато вычислять интервал между двумя событиями приходится вручную. Давайте попробуем спроектировать библиотеку для работы со временем правильно. Может хоть кому-нибудь живой пример вправит мозги.

Итак, что такое время для программиста? Это одна координатная прямая, на которой определена выделенная точка «сейчас», делящая прямую на «прошлое» и «будущее». Примитивные племена на этом и останавливаются, оперируя тремя понятиями: «было», «есть» и «будет». Современному человеку требуется больше: время должно быть измеримо. Это позволит производить вычисления (до сеанса осталось полчаса) и учитывать порядок событий ([сначала]он мне в глаз, а [затем] я ему в ухо) от которого и до причинно-следственной связи недалеко. Для того чтобы сделать время измеримым на прямую произвольным образом добавляют фиксированную выделенную точку «0». Исторически сложилось так, что в разных культурах эту точку добавляли по-своему. Это мог быть день коронования императора, начало определенного года, произвольно выбранный момент времени и даже время «сотворения мира». В мире UNIX, например, это полночь 1 января 1970 года.

С другой стороны люди привыкли к довольно неудобной для вычислений системе предстваления времени, связанной с циклами вращения Земли. Опять же, в разных культурах к этой проблеме подходили по разному. В результате год начинается в разное время и по разному делится на месяцы в зависимости от культуры. Более того, в разных культурах привычные способы записи времени сильно отличаются, даже если системы счисления времени совпадают. Та же американская ММ/ДД/ГГ и русская ДД.ММ.ГГ.

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

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

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

Первое, что нам требуется, это момент времени (Timestamp) заданный с максимальной возможной точностью в некоторой системе отсчета, хоть UNIX time. Этот класс является платформозависимым, поскольку умеет работать с системным таймером. Никаких преобразований или вычислений этот класс делать не должен. Очень часто требуется работать с моментами времени с точностью до минуты, дня или года, в этом случае максимальное разрешение тут только мешает. Для некоторой частых случаев можно определить классы Date и DateTime и точностью, соответственно, до дня и до секунды. Timestamp должен корректно поддерживать сравнение отметок времени с максимальной и ограниченной точностью.

Второе — интервал между двумя моментами времени (Interval) Интервал можно представить двумя моментами времени: начало интервала и конец интервала. Интервал должен уметь вычислять свою продолжительность. Кроме того, нужна возможность зная начало или конец интервала и продолжительность, получить интервал.

Третье — продолжительносить (Duration) Внутри продолжительность хранится в максимально возможной системной точностью.

Для каждой из трех сущностей потребуется два интерфейса: *Parser и *Formatter имплементации которых служат для преобразования сущностей из строки и к строке (или прочим типам). Кроме форматирования, их зона ответственности — преобразование к другим системам представления времени, например к тому же юлианскому календарю.

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


duration = Duration.measure do
...
end

noreply@blogger.com (Miroff) — Tue, 24 Jun 2008 02:54:00 +0000

RuPyRu 2008. Конференция

Пару слов о самой конференции. В целом RuPyRu оправдала мои ожидания: хорошая, добротная провинциальная конференция.

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

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

Познать механизм деления докладов на «общий» и «специальный» потоки мне не удалось. Интересные доклады были и там и там. Я бы предложил деление на «пользовательский» и «авторский» потоки. В первом — краткие обзорные доклады, посвященные чужим технологиями, во втором — доклады авторов о собственных разработках и доклады экспертов. Понравилось, что Ruby и Python не были разнесены на отдельные потоки, что позволило познакомиться с конкурентными технологиями.

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

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

Из интересного для меня оказались совершенно не раскрыты темы развертывания Rails и Django приложений, использования динамических языков для кодогенерации, использования Ruby и Python в качестве скриптовых языков внутри приложения и создания DSL на базе динамических языков.

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

noreply@blogger.com (Miroff) — Tue, 24 Jun 2008 02:44:00 +0000

RuPyRu 2008. Омск

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

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

В центре города нам встретился памятник ~~Говночерпию~~ Сантехнику, из вечно актуальной серии памятников рабочему классу (памятники Электрику и Дворнику в Томске) Расположенный прямо на тротуаре, он символизирует близость рыцаря труб и задвижек к народу, а умиротворенное выражение лица убеждает в чистоте его намерений.

Из современных форм искусства нам встретилось вот такое трафаретное граффити в стиле Fallout. Сложно сказать, что оно должно означать, но прикольно. Я всегда считал, что за трафаретным граффити будущее уличной живописи.

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

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

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

noreply@blogger.com (Miroff) — Wed, 18 Jun 2008 04:32:00 +0000

Just few photos

Вернулись со сплава по Средней Катуни. Выяснилось несколько забавных вещей:

Камера µ 770 SW + запасной аккумулятор + 2Гб флешка категорически рулят. Мочить камеру водой не страшно, поэтому вдохновившись радостно наснимали 1.5Гб фотографий, из которых, правда, половина — чье-то весло или каска.
С каждым годом количество крупных вещей уменьшается, а мелких — растет приближаясь к стандарту «все необходимое можно распихать по карманам»
В следующий раз в качестве полезной вещи нужно брать термос с горячим чаем. Правильно зафиксированный, он, скорее всего, не разобьется.
Свой котелок и горелку мы совершенно напрасно не взяли, понадеявшись на общественный. В результате, большую часть времени обходились без чая потому, как дождавщись когда он согреется, уже никакого чая не хочется.
После Алтая воняет даже Академгородок:-(

Несколько пейзажей без сюжета:

noreply@blogger.com (Miroff) — Wed, 11 Jun 2008 05:38:00 +0000

Declarative interface

Gineer, попросил меня описать, что я понимаю под декларативным интерфейсом. Признаться, идея пришла мне в голову прямо здесь, но я попытаюсь оформить ее в разумную форму. Любой прибой, по сути своей является черным ящиком для пользователя. Разговаривая по телефону, можно ничего не знать о модуляции, СВЧ технике или принципах маршрутизации голосового траффика. Декларативным я называю интерфейс, построенный в терминах потребностей пользователя, а не средств их достижения. По идее, любой интерфейс любого прибора может быть декларативным, однако, на практике это не так. Например, мой телефон требует для установки будильника следующей последовательности команд: Меню > Развлечения > Будильники > Выбор одного из трех возможных > Включение > Установка времени > Установка режима "повторять ежедневно/по будням/никогда" > Выбор мелодии > Подтверждение. Это идиотский интерфейс, потому что он заставляет меня думать не об исходной потребности, а о деталях реализации. Мне нужно, чтобы телефон разбудил меня в указанное время. Все остальное лишь опции. Для чего мне знать, сколько у телефона будильников (готов спорить, их три, только для того, чтобы влезли на один экран в интерфейсе), которые из них включены и как именно он меня собирается будить. Декларативным будет примерно такой интерфейс: разбуди_меня вермя|интервал [периодичность] [способ], где вермя может быть в любом формате от "в 1130" до "завтра в 8", а то и вовсе интервал: "через 2 часа". Конечно, это потребует продвинутого date/time picker, но изваять такой уже давно не проблема. Еще понадобятся две функции: покажи_список_будильников и отмени_будильник > выбор будильника Может показаться, что приведенный синтаксис относится только к CLI, однако это не так. Аргументы команды вполне могут выбираться самостоятельным диалогом. В GUI команду можно представить в качестве мастера, опциональные параметры которого легко пропустить или установить в любом порядке. Из идеи декларативного интерфейса есть одно интересное следствие, которое стоит обдумать. Если более строго описать синтаксис UNIX команд с учетом зависимостей, типов и связей параметров, возможно, удастся помирить GUI с CLI. Хотя бы посредством автогенерации интерфейсов.

noreply@blogger.com (Miroff) — Thu, 01 May 2008 02:28:00 +0000

What do you need to know

Как вести проектную документацию? Оставим в стороне ГОСТы, RUP, фантазии некомпетентных и прочую фигню и сосредоточимся на одном вопросе: "Какая документация вам нужна в проекте, рассчитанном на несколько лет?" Проекты в стиле "Сделал и забыл" (а это большая часть аутсорсинга) в документации не нуждаются и останутся за скобками. Итак, поехали:

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

Как именно работать с требованиями много говорили и без меня. Единственное, что стоит отметить: чем глубже проанализированы требования, тем легче. Требование "заказчик хочет зеленую кнопку" менее ценно чем "интерфейс должен, по возможности, соответствовать программе X с которой у пользователей есть опыт работы". В случае, если кнопку не удастся сделать зеленой, хотя бы понятно с какой стороны начинать переговоры по поиску компромисса.

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

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

noreply@blogger.com (Miroff) — Thu, 24 Apr 2008 04:36:00 +0000

Geoid

Земля имеет форму шара, Забавно видеть хуй омара. Азбука

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

Геоид- фигура, отражающая форму Земли, важное понятие в геодезии.

Помилуйте, геоид не имеет решительно никакого отношения к форме Земли. Более того, изобретать просто так фигуру «описывающую форму Земли» бессмысленно. Однако, математики давно прослыли чудаками и эта бессмысленность не бросается обывателю в глаза. Если вы приглядитесь к картинке, геоид довольно слабо напоминает форму Земли. Откуда же он взялся? На самом деле геоид имеет вполне практическое применение. Как вы все наверняка знаете, географические координаты (те которые широта и долгота) суть координаты сферические. Однако, поскольку земля не сфера и не эллипс, возникает вопрос: относительно какой сферы задаются географические координаты? Математики давно предложили работающее решение: использовать мнимый эллипсоид вращения как-то худо-бедно совпадающий с земной поверхностью. Для вычислений идеально, однако, стоя в чистом поле довольно трудно этот эллипсоид обнаружить. Он же математическая абстракция. Мудрые математики и тут не сплошали. Они расположили эллипсоид так, чтобы короткая ось его совпадала с осью вращения земли, в центр его совпадал с центром масс Земли или был смещен относительно него на какое-то расстояние. Из физики мы знаем, что ось вращения проходит через центр масс. Осталась малость, вычислить его положение относительно поверхности. Для это была проведена гравиразведка все поверхности земли и построен геоид — фигура на поверхности которой сила тяжести постоянна и совпадает со средней силой тяжести на поверхности моря. Этого достаточно чтобы определить центр масс геоида, который совпадает с центром масс Земли. Зная, где находится центр масс, мы можем поместить в центр земли эллипсоид (умозрительно, конечно) и использовать его для определения координат.

noreply@blogger.com (Miroff) — Thu, 10 Apr 2008 04:15:00 +0000

Half-life

Период полураспада для большинства нововведений составляет две недели. Вне зависимости от того в чем состоит идея: вести документацию в wiki или штрафовать за неположенное распитие пива. Каждый может припомнить несколько довольно хороших (или ужасных) идей, которые «не пошли». Связано ли это с тем, что идеи плохие? Нет, распадаются и вполне хорошие начинания. Со стороны видно, что внедрить что-то сложнее чем кажется. Любая система обладает некоторым запасом инерции и социальные системы не исключение. После того как программистам наказали указывать номер бага при коммите обязательно придется некоторое время следить чтобы это правило выполнялось. И лишь через какое-то время оно перейдет в разряд «здесь так принято». Никогда, ни одно правило не будет выполняться только потому, что оно есть. Время принятия зависит от того, насколько нововведение выгодно конкретным исполнителям. Дневные отчеты могут быть офигенно полезными для проекта и для компании в целом, но если программисты не видят в них смысла, они будут забрасываться при каждом удобном случае. В идеальном случае, когда все без исключения исполнители понимают, какую пользу им принесет нововведение, они способны сами его внедрить. На практике это случается довольно редко. Итак, несколько практических рекомендаций:

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