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

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

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

Вот, немножко начал игратся с 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 для обновления содержимого локального репозитория

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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