about_zero

на злобу дня

Fri, 20 Jun 2008 15:13:55 GMT

Интересно, каково было бы Гераклу, если бы подвиг по вычистке Авгиевых конюшен ему пришлось бы повторять постоянно, вместо остальных 11ти подвигов?

NB. а не пора ли вам сударь, обновить свой рекламный щит и встать у дороги?

диалог, которого не было

Wed, 26 Mar 2008 18:31:37 GMT

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

записки на манжетах

Sat, 02 Feb 2008 13:51:19 GMT

Вот, немножко начал игратся с distributed cvs, т.к. до этого опыта никакого с ними не имел. Далее просто неформальное изложение мыслей, чтобы потом не потерялось...
Итак, начинаем играться с mercurial. Почему именно оно, а не darcs или git? Не знаю, честно говоря, просто в памяти отложился.
Итак, начинаем тихие игры. Самый лучший кандидат на контроль версий в linux системе имхо это /etc :) С него и начнем. Нам нужно создать 2 репозитория (можно обойтись и одним, но зачем тогда dcvs? :) ).
1-й, типа удаленный. Для простоты делаем его в домашнем каталоге.
mkdir -p ~/repo/etc
cd ~/repo/etc
hg init
Создали каталог и проинициализировали репозиторий.
Далее уже под root идем в /etc
cd /etc
hg init
hg add
hg commit -m "initial revision"
Проиницализировали типа локальный репозиторий, добавили в него файлы, и закоммитили в локальный репозиторий.
При коммите пишем текст сообщения, иначе по-любому поднимется редактор и заставит его написать :)
В процессе можно поиграться с
hg status - выводит статус файлов в директории относительно хранящихся в локальном репозитории
hg log - показывает лог коммитов
Теперь отправляем файлы из "локального" в "удаленный" репозиторий (иожно делать и под обычным пользователем)
cd /etc
hg push ~/repo/etc
И получаем их в "удаленном" репозитории
cd ~/repo/etc
hg update

В общем, как я понял, идеология поощряет использование отдельных репозиториев на каждый бранч (путем hg clone), правки там, и потом hg push в родительский, с периодическим выполнением hg poll для обновления содержимого локального репозитория

бессознательное

Mon, 28 Jan 2008 19:43:45 GMT

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

ЗЫ: А вот неудобно иногда, что в OCaml по умолчанию string <> char list, и нужно писать преобразование ручками. Или это я такой невнимательный? :)

back to future

Thu, 22 Nov 2007 18:56:09 GMT

Читаю сейчас замечательную книжку Leo Brodie "Thinking Forth" (ссылка)
Несмотря на то, что книга выпущена в 1984 году, актуальности своей она не потеряла. Читаю, и все больше убеждаюсь в корректности изречения "Все новое - это хорошо забытое старое".

Создание DSL как основной способ решения задач.
Быстрые итерации, прототипирование, постоянное взаимодействие с пользователем - основные постулаты Agile методик.

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

лохматость

Thu, 25 Oct 2007 17:40:21 GMT

"Структура банковских данных слишком сложна, чтобы применять к ней правила реляционного моделирования" - шедевральная цитата, взята из обсуждения здесь.
Это я к тому, что все виденные мной схемы БД для банков, действительно выглядят несколько "лохмато". Широкие таблицы, куча редкоиспользуемых колонок, дублирующихся значений, смешение различных сущностей в одной таблице... Все это в той или иной степени присутствует во всех виденных системах. Похоже, что либо все архитекторы придерживаются этой максимы, либо таков неумолимый эволюционный процесс, что любая схема БД со временем накапливает энтропию и деградирует до 1НФ (или в лучшем случае до 2НФ)?

классика

Tue, 02 Oct 2007 16:13:20 GMT

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

забавно

Thu, 16 Aug 2007 16:22:48 GMT

Интересно, какое название лучше подойдет - некропрограммист или археолог-программист? Не хочу ни так, ни так на самом деле...

мысли вслух...

Thu, 09 Aug 2007 17:40:24 GMT

Еще несколько наблюдений из разряда типовых задач для баз данных. Итак, времязависимые данные. Есть 2 основных подхода для хранения периода актуальности у сущности:

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

- EntityPK, ValidFrom, ValidTo. В этом случае все ровно наоборот - простота выборки и сложность добавления и поддержания согласованности данных.

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

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

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

наболело

Fri, 27 Jul 2007 17:51:37 GMT

Планета Шелезяка. Жизни нет, мозгов нет, населена биомассой...

Аляска, сэр...

Thu, 26 Jul 2007 17:38:09 GMT

Из разряда wtf...
Автоматизация во всей красе :)
Похоже что разработчиков в Диасе уже не осталось...

заметки на полях

Mon, 16 Jul 2007 18:52:58 GMT

Интересно наблюдать эволюцию развития банковских систем "у нас" и "у них". Очень четко прослеживается разница в подходах к проектированию и решаемых задачах. Почти все отечественные системы для банков идут от бухгалтерского учета, соответственно, вся доступная информация о движении средств доступна через проводки и остатки на счетах. Т.е. главное - выполнение ПБУ и банковская отчетность, а собственно задачи учета и анализа - вторичны. В забугорных системах (не могу сказать, что я видел их много, но все же...) - изначально все шло похоже именно от задач учета. Этот подход мне нравится больше, для текущих решаемых задач возьму похоже за образец аналогичный подход...
Еще до кучи мелкая архитектурная заметка - остатки по валютным счетам. Если мы храним приведенную сумму, то записи будут множиться ежедневно, т.к. курс меняется, соответственно идет переоценка остатка. Другой вариант - таблица курсов. Минус - лишнее соединение, недостаточно таблицы курсов ЦБ, потому что нужен курс на любую дату, в т.ч. и на праздники, что выливается либо в подзапросы, либо в доп. логику при загрузке курсов. А вот при хранении первичных документов проще всего сразу хранить приведенную сумму. Так что надо будет прикинуть и выбрать.

бревно запроса :)

Fri, 22 Jun 2007 17:11:46 GMT

Правильные телефоны :) А то я что-то завыбирался, зажрался так сказать... :)

недоуменное

Tue, 19 Jun 2007 18:03:54 GMT

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

В ассистенты б я пошел...

Mon, 21 May 2007 17:49:02 GMT

Kичный ИТ ассистент генерального директора компании
Порадовало :)

дожили...

Tue, 24 Apr 2007 17:39:43 GMT

Это пять, если товарищ не стебется... Вот они, подрастающие программисты, наша надежда и опора :)

литература

Tue, 17 Apr 2007 16:17:12 GMT

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

ностальгия

Wed, 11 Apr 2007 18:56:45 GMT

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

стоя на лыжах... в гамаке...

Tue, 27 Mar 2007 07:21:23 GMT

Перекраивая в очередной раз sql-код, с горечью раздумываю на тему, почему же unit-testing так непопулярен при разработке БД? По идее, никаких противопоказаний на этот счет нет, есть даже некий DbUnit... Но что получается на самом деле...
Если в базе только CRUD-операции, то все выглядит более-менее пристойно, просто и понятно. Но как только в базе появляется БЛ (бизнес-логика, про которую Фаулер помнится писал "странно, что такую нечеткую, нелогичную, часто меняющуюся вещь назвали термином бизнес-логика"), начинается цирк. Особенно если пытаешься использовать TDD с середины разрабокти или не дай бог когда началась поддержка. Рассмотрим этот самый крайний случай.
- Нужна база в жестком зафиксированном состоянии, причем для некоторых тестов эти состояния могут быть взаимоисключающими. Т.е. подняли эталонный дамп - прогнали тесты, и так по кругу.
- Все время приходится балансировать между производительным кодом, и кодом удобным для тестирования. Например, код, который бежит курсором по данным и вызывает для каждой строки процедуру, которая полагается только на переданные ей параметры, тестировать гораздо легче, чем код, состоящий из диких insert/update/delete, использующий кучу временных таблиц, которые заполнены за пару вызовов вверх.
- Следующий из предыдущего пункта вывод - для таких случаев черезвычайно сложно подготовить набор тестовых данных.
- Еще более следующий вывод - то что в этом случае получается уже сложно назвать unit-test'ом, это скорее уже функциональные тесты, которые логичнее производить со стороны вызывающего кода.
- Время выполнения набора тестов может получиться неприлично большим, что сводит на нет их полезность. Если после каждой правки мне нужно ждать даже 10 минут чтобы быть уверенным что я ничего не поломал - никуда не годная ситуация. А так как я не один, и каждый хочет запускать свои тесты на чистой тестовой базе, то получается очень много согласований и ненужной суеты.

В результате полчается, что даже есть желание, реализовать полноценное unit-тестирование большого проекта практически невозможно :( Что я уже и наблюдал пару раз на разных проектах... К сожалению...

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

redesign wheel...

Mon, 26 Mar 2007 09:03:59 GMT

Оригинально... Жалко только что наверняка несовместимо с оригнальным Emacs... А так идея хороша :)

а почему бы и нет? :)

Fri, 23 Mar 2007 08:22:54 GMT

Наткнулся тут нас обсуждение на "Королевстве Дельфи"

"
Правильным названием для новых сред от CodeGear было не не Дельфи для чего то там, а TurboPHP, TurboRuby, TurboPyhton, TurboLisp (мечтать не вредно :)) )
Это гораздо эффективнее и в маркетинговом плане.
...
...
ЗЫ. Да, TurboHaskell - это было бы неплохо! :о))
"

Красота... :)))

повеселило

Thu, 22 Mar 2007 18:05:13 GMT

Вот как надо людей на работу приглашать :). А то понимаешь ли...

чуть-чуть

Fri, 16 Mar 2007 18:16:51 GMT

Вот. Попробую описать свой велосипед, дабы получить критику и новый опыт. Итак, часть 1-я.

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

get_float =
	[PMany1 [PDigit],
		POpt [PChar '.',
		PMany1 [PDigit],
		POpt [PChar 'E', POpt [POneOf ['+', '-']], PMany1 [PDigit]
	]]]

Напоминает Parsec, не так ли? :) Надеюсь что названия говорят сами за себя.
Входная точка разбора

get_token :: String -> [PV] -> (Maybe String, String)

Здесь PV - тип, констукторами которого являются PDigit, PMany, ...
Возврат - (Nothing, исходная строка) в случае если начало строки не совпадает с указанным образцом, и (Just совпавшая часть, остаток строки) в противоположном случае. Реализация "в лоб" путем прохода по списку паттернов с рекурсией, если необходимо и сопоставлением текущего символа строки с текущим элементарным паттерном.

get_token datas lst =
    unmapParts $ reverse $ get_token' datas lst []
    where
	get_token' _ [] accum = accum
	get_token' s (x:xs) accum =
	    case pass s x of
-- если на каком-то этапе не смогли сопоставить с образцом
-- то значит вся строка нам не подходит
	        (Nothing, _) -> [(Nothing, datas)] 
	        (Just v, rest) -> get_token' rest xs ((Just v, rest) : accum)

pass - вспомогательная функция, которая проверяет совпадение с конкретным паттерном.

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

tokens = [
	Token "Space" get_space,
	Token "Comment" get_comment,
	Token "Comment" get_comment2,
	Token "String" get_string,
	Token "String" get_string2,
	Token "Number" get_float,
	Token "Identifier" get_identifier,
	Token "Variable" get_variable,
	Token "GlobalVar" get_global_variable,
	Token "Op" get_operand
	]

Полный список распознаваемых токенов. Процедура получения из строки списка токенов заключается в последовательном примении функции try_apply.

try_apply s = try_apply' s tokens
-- если перебрали весь список возможных токенов, и ни один не подошел, то ой...
try_apply' s [] = (Nothing, s) 
try_apply' s (x:xs) =
    case r of
        (Just v, rest) -> (Just $ TokenData x v, rest)
        (Nothing, _) -> try_apply' s xs
    where
        r = get_token s (get_token_list x)
        get_token_list (Token name lst) = lst

Вот в общем-то и все на текущий момент из глобального. Поверх этого в два касания был реализован
перевод зарезервированных слов t-sql к uppercase и вырезание комментариев. Так сказать чтобы была пользая и на практике :)

ЗЫ: Для тех, кто все-таки дочитал до конца - о наличии Parsec.ParsecLanguage и иже с ними я осведомлен :) Просто нужно было написать что-то несложное, дабы почувствовать язык.

ффух...

Fri, 16 Mar 2007 12:46:57 GMT

Ну вот, дописал до относительно рабочего состояния свой первый небольшой проект на haskell. ~200 строчек кода вместе с тестами и готовым применением. Если причесать и окультурить, то будет меньше. Примитивный велосипедообразный разбор на лексемы, с готовым применением под t-sql :) С Parsec было бы раза в 2 меньше, но не так интересно :)
Писать честно говоря было приятно и удобно (за исключением отладки :) ), но не уверен, что я смогу разобраться в этом коде через месяц например...
Следующим шагом будет докрутка фич, ради которых это все собственно говоря и затевалось...

Виртуализация

Sat, 10 Mar 2007 14:25:52 GMT

Итак. Чего хочется. Хочется в виртуальной машине погонять Linux или BSD. Т.к. виртуальная машина, то не хочется ставить современный мощный пользовательский дистрибутив, им моего компа и вживую маловато ;). Из маленьких и шустрых которые более-менее на слуху, нашел 2. Zenwalk 4.4.1 и ArchLinux 0.7.2.
Что есть. Есть WinXP с стоящим VMWare 5.5.1.
Zenwalk 4.4.1 с ядром 2.6.20 - начинается установка, но не может найти почему-то CRDOM. Дальше этого не идем.
ArchLinux 0.7.2. Ставится. Начинаем устанавливать VMWare-tools как изложено у них в wiki. Нифига. Никак у него `uname -r` не совпадает с UTS_RELEASE в include/linux/version.h, хотя должон :) Хачить их конфигуратор на perl мне было влом.
Итак, чего бы мне еще попробовать?
Что нужно от дистрибутива. Относительная современность, чтобы не было проблем со сборкой из исходников, в случае чего. Из GUI там будет fluxbox или Xfce как барский вариант. Ну и набор разработчика. Религиозных предубеждений Linux vs. BSD, или rpm vs. deb vs. tar.gz или прочих не имею :)
Главное, чтобы хорошо работало под виртуальной машиной. Кстати, может есть что-то лчуше чем VMWare?

Вот, продолжу поиски, авось что-то найдется.