Alive and stirring data

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

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

noreply@blogger.com (Miroff) — Wed, 09 Apr 2008 07:40:00 +0000

Alone

Принято считать, что в современном мире для любой серьезной вещи нужна команда. Поговорки-пословицы всякие: «один в поле, волкам на потеху», «семеро одного не боятся», «команда — все, остальное — волшебные пузырьки». Вроде бы, как само собой разумеется, что производительности одного человека ни для каких серьезных задач недостаточно, а вот команда это сила. Ещё бы, на один только чай команда тратит в день больше времени, чем один человек может удалить работе в неделю. Доходит до того, что привычный к командной работе программист смотрит на индивидуальную задачу и изрекает: «да тут мне одному на полгода». И действительно, провозится с задачей 6 месяцев. В то же время, за стенкой может сидеть человек, стабильно решающий подобные задачи за месяц каждая. Производительность лучших и худших программистов отличается примерно на порядок. Всякий имеющий доступ к метрикам может получить эти данные самостоятельно. Вопрос в том, за счет чего так получается и какую выгоду можно извлечь, если работать в одиночку. Самое очевидное, это работа с постановкой задач. Любую задачу можно решать разными способами. К тому моменту, как задача доходит до программиста через кучу промежуточных звеньев, она обрастает коркой фантазий, зачастую не имеющих никакого отношения к исходной проблеме. Например, клиент хочет, чтобы работающие с программой менеджеры не забывали о назначенных встречах. Можно реализовать управление встречами в программе, а можно обратить внимание, что в компании уже используется для этого Outlook с которым довольно легко интегрироваться. Аналогичные ситуации возникают и при внутреннем взаимодействии. Быстродействующий программист не станет ничего делать пока не выяснит, какую именно проблему он должен решить. Второе, это правильное использование готовых средств. Если собственное решение занимает три недели, а применение готового — несколько часов на чтение документации и пару дней на исправление багов в чужом решении, это сэкономит две недели. В другом случае, частное решение пишется за неделю, а на использование существующего могут уйти недели. Умение верно оценить, сколько времени займет переиспользование, а с сколько собственное решение и есть искусство быстрой сборки из кубиков. У быстродействующего программиста нет времени изобретать все свои велосипеды самостоятельно. На третьем месте — острая пила. Инструмент должен быть адекватен решаемым задачам. Это касается как языков и библиотек, так и окружения. В эту бочку и владение инструментами (от IDE до shell) и DSL, и метапрограммирование с кодогенерацией. Отдельные аспекты «заточки пил» освещены изрядно. Пилы быстродействующего программиста всегда острые. Если хотите готового чеклиста:

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

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

Meeting

-Пойдем с нами, помитингуем. -Надолго? -Да нет, часа на полтора.

Знакомо? Митинги — хороший способ осознать какова сила командной работы. За полтора часа разговоров команда тратит столько времени, сколько тебе в одиночку не потратить за неделю. На первый взгляд, кажется что время тратится с пользой. Люди говорят, спорят, обсуждают, но стоит поймать выходящего из комнаты для совещаний и спросить, что, собственно, обсуждалось, и что было решено, как будет получен ответ в стиле: «Ну взаимодействие системы, А с подсистемой B. Петро будет спеку на интерфейс писать." Помилуйте, что тут можно было обсуждать полтора часа? А ведь существуют компании где на подобные совещания тратится больше половины рабочего времени, а большая часть «митингующих» рисует чертиков. Между тем способ сделать собрания эффективными давно известен всем желающим. Нужно лишь соблюдать несколько простых правил:

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

Более подробно этот подход описан у ДеМарко в «Deadline». Там же есть и примеры удачно проведенных совещаний.

noreply@blogger.com (Miroff) — Mon, 17 Mar 2008 04:51:00 +0000

Code conventions

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

Имена переменных должны удовлетворять camelCase; Недопустимо обращение через две точки, во имя закона Деметры; Бинарные операторы должны быть отделены пробелами с обоих сторон; В сеттерах нужно использовать this; Забытая в микроволновке еда считается общей; и т.д.

Обычно такой документ живет ровно две недели, затем перемещается в архив, извлекаемый оттуда только для того чтобы продемонстрировать его новичкам. Поскольку документ изначально не соблюдался и разительно отличается от негласных соглашений принятых в коде, новички тоже откладывают его в сторону. От проекта к проекту такая ситуация повторяется с завидной регулярностью. Причина в том, что любая дополнительная активность, как написание комментариев, проверка кода на соответствие соглашениям, комментарии к коммиту в VCS требует дополнительных затрат. Если преимущества от этих действий неочевидны человек склонен «забывать» их делать. Поэтому введение в проекте code conventions автоматически означает появление роли следящего за их соблюдением. Для того чтобы решить проблему недостаточно опубликовать документ, каким бы хорошим он ни был. Нужна постоянная активность, это везде так. Отлично, но следить за соблюдением правил, описанных на двадцати страницах, отнимает прорву времени. И это вторая причина, по которой затея с code conventions проваливается. Теперь, когда мы добрались до сути, мы можем сформулировать рекомендации для написания соглашений. Но, сперва, давайте обозначим проблему, которую мы собираемся решать. Разные программисты предпочитают разные стили написания кода. Если несколько разных стилей смешиваются в одном файле, этот файл становится трудным для чтения. Разнобой в стиле выглядит неряшливо и поощряет неряшливость уже в самом коде. Соглашения о коде призваны устранять неоднозначности в выборе несущественных деталей оформления, в идеале сужая пространство вариантов до одного. Как же писать code conventions? Определите кто ваши программисты. Кто сказал: «Они все здесь»? А как же библиотеки, которыми вы пользуетесь. Их интерфейсы должны вашим соглашениям. Естественно, вы не в силах заставить сторонних разработчиков соблюдать ваши стандарты, но вы всегда можете подогнать стандарты под них. В противном случае использование библиотек будет выбиваться из общего стиля и увеличивать энтропию проекта. Все соглашения можно разделить на две части: поддающиеся автоматическому переформатированию и не поддающиеся. Переформатированию поддаются такие вещи как количество пробелов, формирование отступов, расположение скобок, длина строк и т.п. Лучший способ их публикации, это положить в VCS файл настроек для IDE. Можно также настроить VCS сервер на вызов автоформаттера перед каждым коммитом и забыть о них навсегда. Описывать их в документе совершенно не обязательно. Не стоит поручать человеку делать то, что сумеет машина. Не поддаются переформатированию такие вещи, как имена файлов, переменных, пакетов и классов, стиль работы с исключениями, расположение файлов. Продвинутые автоформаттеры умеют отлавливать ошибки, но исправлять из автоматически невозможно. Поэтому все что не поддается автоформатированию придется описать в документе явно. Документ содержащий code conventions не должен быть большим. Четырех страниц более чем достаточно. По крайней мере ограничение объема избавит вас от соблазна включать в документ правила пользования микроволновкой. Если есть возможность, не изобретайте велосипедов. Почти всегда можно взять готовые документы у разработчиков языка или людей в нем авторитетных. Вот несколько таких примеров:

Утилиты для автоформатирования кода:

noreply@blogger.com (Miroff) — Tue, 11 Mar 2008 09:30:00 +0000

Как выбирать библиотеку

Каждый раз сталкиваясь с новой задачей мы задаем себе вопрос: Стоит ли ее решать? Возможно, удастся использовать готовое решение. В этом сила программирования, для большинства задач, таких как вывод суммы прописью или реализация протокола Z39.50 давно существуют готовые решения. Но, если решений несколько, как выбрать одно из них? Или может быть отказаться от всех них и реализовать задачу самому? Для многих такой выбор оказывается черезмерно сложным и они скатываются к одной из двух крайностей: предпочитают во всех случаях готовые средства или всегда изобретают велосипеды. Однако, разумные люди предпочитают объективно оценивать ресурсы. Я определил следующий набор критериев:

Большинство библиотек плохо работают на грани своей области применимости. Например, все известные мне попытки применить Hibernate или ActiveRecords из Ruby on Rail к сложной унаследованной базе, вдобавок денормализованной достигали цели только посредством тяжких ухищрений. Убедитесь, что вы собираетесь использовать библиотеку именно так, как это запланировано разработчиками. В противном случае, выбросьте ее сразу. Все равно она для вас не подходит.
Срок жизни кода в среднем составляет 5-10 лет до того момента как он морально устареет и будет выброшен. Это тот срок, когда кому-то нужно будет поддерживать код. Соответственно поддержка библиотеки должна быть расчитана на тот-же срок. Будет неприятно, если через пять лет в критичной библиотеке найдется критичный баг, который невозможно исправить, поскольку разработчики библиотеки давно испарились вместе с исходниками. Для коммерческих библиотек с закрытыми исходниками это может стать серьезной проблемой. Для Open Source такой гарантией может стать поддержка большого сообщества или серьезной конторы вроде IBM, Intel или Sun
Критичный для функционала проекта должен писаться только собственноручно хотя бы на один уровень вглубь. Например, если мы занимаемся разработкой GIS системы, мы можем взять набор классов с представлением географических координат из десятков библиотек. Но координаты расползутся по всему приложению и заменить библиотеку когда она перестанет удовлетворять будет практически невозможно. Модели предметной области, бизнес правила, уникальные для вашей предметной области элементы интерфейса должны разрабатывать только вы сами. В противном случае у вас есть все шансы при очередном изменении требований столкнуться с ограниченностью библиотеки. К сожалению разработчики библиотек этого не понимают и норовят запихнуть свои «фреймворки», «модели предметной области» и «наборы бизнес правил» во все подходящие, на их взгляд, проекты
Любая библиотека имеет склонность врастать в продукт и изменять его вокруг себя. Выбор, например, log4* навсегда определит вашу стратегию логгирования. Хорошая библиотека, изменит продукт в лучшую сторону, плохая только ухудшит. Стоит следить, чтобы архитектурные принципы используемых библиотек были сходны с вашими, code conventions не слишком отличались, а политика релизов была ясной и прозрачной. Плохое регрессионное тестирование библиотек или нарушение обратной совместимости приведет к шаманствам с зависимостями при сборке проекта и багам при обновлении библиотек. Важно понимать, что библиотека это не просто набор интерфейсов, а живой организм со своими особенностями.

Для того чтобы руководствоваться этими принципами на практике есть простой чеклист:

Функционал реализуемый библиотекой критичен для проекта?
Насколько сложно написать собственный код по сравнению с использованием библиотеки?
Является ли библиотека open source либо предоставляют ли производители какие-то осязаемые гарантии?
Насколько велико сообщество пользователей библиотеки?
Как часто выходят релизы и фиксятся баги?
Насколько хорош код библиотеки?
Насколько хороша документация?

noreply@blogger.com (Miroff) — Mon, 03 Mar 2008 08:33:00 +0000

Очередной пример "замечательного" перевода. Фильм Zodiac, фраза: "His ashes were scattered by his family in San Francisco Bay", перевод: "Его статьи и записи были проданы его семьей с аукциона E-Bay". Я нашел только два совпадающих слова. Интересно, что курил переводчик?

noreply@blogger.com (Miroff) — Tue, 26 Feb 2008 13:18:00 +0000

Ноль это бесконечность, а минус единица это ноль

В некотором отделе некоторой компании разрабатывали продукты, да не простой а коробочные. Целые отдел маркетинга днями и ночами продукты те толстым буржуям продавал, да лицензии для них генерировал. И были те лицензии не простые, а с ограниченным сроком годности. Кому на месяц, кому на полгода, а кому и год. Жили они так не тужили, пока отдел маркетинга не задумался, а что это мы продукты по одному продаем, несолидно. Cтали они продукты на части разбирать в ящики складывать и ящики продавать. А на ящиках тех златом, али серебром писать слова иностранные. Все бы ничего, да продукт-то программный, а значит ящики — фикция одна. Дело только в лицензиях, в которых для каждой части строчка отдельная добавилась. А в строчке той цифирь, означающая сколько частей в ящике. Тут бы им жить поживать, да встретился местный барин на какой-то конференции с барином иностранным, другом старым. Тот-то ему и пожаловался: «Мы, — говорит, — друзья старые, а твои архаровцы меня заставляют на каждую новую часть отдельную лицензию делать. А у меня этих лицензий уже два камаза с прицепом» Призвал барин программистов пред светлы очи и повелел бесконечную лицензию выдумать. Но поскольку призывал он всех по отдельности, разные продукты разное выдумали, потому как нет такой цифири «бесконечность». Один решил вместо бесконечности «0» писать, все равно на ноль штук лицензия не нужна. Другой решил, что ноль ему пригодится и «-1» под такое дело зарезервировал. Ну а третий долго не думая самое большое число, которое знал, использовал. Долго ли, коротко ли, придумал отдел маркетинга новую забаву. Теперь пока лицензия не кончилась, ее стало можно переоформить: частей добавить или изъять. Ну а раз изъять, то и нули в строках стали возможны. Пришлось программистам еще раз напрячься, да ноль выдумать. Ну а когда стали правила лицензирования в отдельный продукт собирать, запестрел он правилами вроде «если продукт один ноль это бесконечность, а минус единица это ноль, а ежели другой, то все наоборот». И набралась таких правил толстая книга. Мораль, прежде чем изобретать велосипед, посмотри уже изобретенные, да посоветуйся с коллегами.

noreply@blogger.com (Miroff) — Tue, 19 Feb 2008 10:28:00 +0000

У каждого бага есть имя, фамилия и отчество

Был такой замечательный человек, Лазарь Моисеевич Каганович. Сейчас как-то принято ругать всю сталинскую эпоху скопом, поэтому Лазаря Моисеевича чаще всего вспоминают как в связи со "сталинскими" репрессиями, коллективизацией сельского хозяйства на Украине и сносом старых зданий в Москве. Умер Каганович в 1991 году, в возрасте 97 лет, совсем немного недотянув до развала СССР. Так вот, в бытность свою наркомом путей сообщения, Каганович произнес замечательную фразу: "У каждой аварии есть имя, фамилия и отчество". Слово не разошлось с делом, начались служебные расследования и многие нерадивые, как тогда было заведено, были обвинены во вредительстве и отстранены. Результат: в начале Войны при эвакуации, несмотря на страшную перегрузку всей транспортной системы, не произошло ни одной серьезной аварии. На мой взгляд, это самый выдающийся результат, который вообще возможен. К сожалению эту замечательную фразу в последнее время забыли и уж тем более не принимают как руководство к действию. Сейчас принято считать, что бывают ситуации, в которых никто не виноват. Они как-бы происходят сами собой, безо всякого человеческого вмешательства либо считаются просчетом всего коллектива, всего общества. Рванула чернобыльская АЭС, виновата "некомпетентность". Застрелился новобранец, виноваты "деды". Выпустили релиз с блокером, виновата команда. И как-то так получается, что никто конкретно и не виноват. А раз никто не виноват, так действительно накосячивший никогда не осознает совей ошибки и обречен повторять ее снова и снова.

noreply@blogger.com (Miroff) — Fri, 01 Feb 2008 06:58:00 +0000

Primary keys in life

Те, кто изучал реляционные базы данных в теории обычно убеждены в том, что некоторые виды объектов по самой своей природе обладают некоторым привычным ключом. Обычно приводят такие примеры: человек — серия и номер паспорта или номер социального страхования или ИНН; книга — ISBN и так далее. На первый взгляд кажется, что эти поля подходят для первичного ключа. При некоторых допущениях так и есть. Однако так ли это на самом деле? Рассмотрим того же человека:

Серия и паспорт человека меняется как минимум трижды в течение жизни;
У книги может быть как несколько номеров ISBN, так и не быть ни одного;
Бывают люди без ИНН и номера социального страхования

Однако на этом проблему не заканчиваются. Что будет если нам придется импортировать данные из сторонних систем? Можем ли мы использовать первичные ключи для этого? Предположим, мы импортируем список людей содержащий имена, даты рождения, данные паспорта и СНИЛС. Совпадение каких полей может служить однозначной идентификации? Правильный ответ: только совпадение всех полей позволяет однозначно связать две записи. Рассмотрим пример подробнее. У нас есть несколько кластеров данных в каждой записи: 1. Тройка фамилия-имя-отчество 2. Дата рождения 3. Данные паспорта (серия-номер-дата выдачи-выдавший орган) 4. Номер социального страхования СНИЛС Я намеренно упустил из виду существование других документов удостоверяющих личность, лиц без гражданства, иностранных граждан и т.п. Будет достаточно одного простейшего случая. Из предметной области мы знаем:

У человека может измениться фамилия, что происходит довольно часто, имя или отчество, что происходит занчительно реже;
В особых случаях у человека может измениться дата рождения;
Смена фамилии, имени или даты рождения влечет смену документа удостоверяющего личность
Человек может получить новый паспорт с совершенно другими данными, никак не связанными с предыдущим;
Человек может получить другой номер ИНН, что происходит довольно редко, но происходит;
Человек может получить другой СНИЛС, что происходит довольно регулярно;
При внесении данных в базу возможны ошибки оператора;
На больших объемах данные проявляется "эффект больших чисел": разные люди с частично совпадающими данными.

Этого уже достаточно чтобы понять — никакого первичного ключа здесь нет. Более того, как только нам потребуется вносить данные в систему мы непременно столкнемся с проблемой идентификации, которую невозможно разрешить автоматически. Единственный выход — система синхронизации на основе правил и ручного анализ спорных случаев оператором. Любые попытки изобрести первичный ключ из любой комбинации полей приведут к отсечению части вполне законных use cases предметной области, как это произошло здесь