urn:lj:livejournal.com:atom1:about_zero about_zero about_zero 2008-06-20T15:13:55Z urn:lj:livejournal.com:atom1:about_zero:13517 2008-06-20T15:13:55Z 2008-06-20T15:13:55Z Интересно, каково было бы Гераклу, если бы подвиг по вычистке Авгиевых конюшен ему пришлось бы повторять постоянно, вместо остальных 11ти подвигов?<br /><br />NB. а не пора ли вам сударь, обновить свой рекламный щит и встать у дороги? urn:lj:livejournal.com:atom1:about_zero:13256 2008-03-26T18:31:37Z 2008-03-26T18:31:37Z - Здравствуйте, я бы хотел заказать у вас садовую скамейку. Знаете, обычную такую, пара досок поперек, и спинка.<br />- Замечательно, что вы обратились именно к нам. Давайте, мы разработаем чертежи скамейки, приходите через неделю.<br />... прошла неделя...<br />- Здравствуйте, я насчет скамейки...<br />- Замечательно что вы пришли. Смотрите, у нас получился замечательный диван в викторианском стиле. Сейчас мы заняты тем, что рассчитываем толщину пуленепробиваемого стекла, стена из которого будет окружать ваш диван.<br />- Э... минуточку, мне нужна обычная садовая скамейка, ничего более...<br />- Мы все понимаем, не волнуйтесь. Вот, не могли бы вы взглянуть на эту электрическую схему? Она позволяет вам дистанционно управлять углом наклона спинки дивана. Правда здорово?<br />- Но мне нужна была всего лишь скамейка...<br />- Мы специалисты в своем деле, не волнуйтесь. Мы можем предугадать ваши дальнейшие потребности, и заложить механизмы реализации уже прямо сейчас. Как вам идея сделать вместо ножек у дивана гусеницы? Это поможет вам передвигаться на нем по пересеченной местности...<br />- Да я... Просто хотел поставить ее во дворе, чтобы бабушкам было на чем сидеть...<br />... хватает топор... urn:lj:livejournal.com:atom1:about_zero:12503 2008-02-02T13:51:19Z 2008-02-02T13:51:19Z Вот, немножко начал игратся с distributed cvs, т.к. до этого опыта никакого с ними не имел. Далее просто неформальное изложение мыслей, чтобы потом не потерялось...<br />Итак, начинаем играться с mercurial. Почему именно оно, а не darcs или git? Не знаю, честно говоря, просто в памяти отложился.<br />Итак, начинаем тихие игры. Самый лучший кандидат на контроль версий в linux системе имхо это /etc :) С него и начнем. Нам нужно создать 2 репозитория (можно обойтись и одним, но зачем тогда dcvs? :) ).<br />1-й, типа удаленный. Для простоты делаем его в домашнем каталоге. <br />mkdir -p ~/repo/etc<br />cd ~/repo/etc<br />hg init<br />Создали каталог и проинициализировали репозиторий.<br />Далее уже под root идем в /etc<br />cd /etc<br />hg init<br />hg add <br />hg commit -m "initial revision"<br />Проиницализировали типа локальный репозиторий, добавили в него файлы, и закоммитили в локальный репозиторий.<br />При коммите пишем текст сообщения, иначе по-любому поднимется редактор и заставит его написать :)<br />В процессе можно поиграться с <br />hg status - выводит статус файлов в директории относительно хранящихся в локальном репозитории<br />hg log - показывает лог коммитов<br />Теперь отправляем файлы из "локального" в "удаленный" репозиторий (иожно делать и под обычным пользователем)<br />cd /etc<br />hg push ~/repo/etc<br />И получаем их в "удаленном" репозитории<br />cd ~/repo/etc<br />hg update<br /><br />В общем, как я понял, идеология поощряет использование отдельных репозиториев на каждый бранч (путем hg clone), правки там, и потом hg push в родительский, с периодическим выполнением hg poll для обновления содержимого локального репозитория urn:lj:livejournal.com:atom1:about_zero:12281 2008-01-28T19:43:45Z 2008-01-28T19:43:45Z Видимо после небольшого перенапряжения на текущем проекте начали меня посещать несообразные мысли об альтернативном пути в жизни - т.н. downshifting... Ну типа там свалить в Гоа, питаться бананами, и ничего не делать. Как щадящий вариант с минимумом изменений - пользуясь бумом спроса на программистов, свалить куда-нибудь обычным рядовым программистом клепать формочки и запросы, по вечерам выходя в космос и общаясь с астралом. Звучит все это черезвычайно заманчиво, удачно вписываясь в анекдот про негра и сбор бананов. <br />К чему это я все написал? Честно говоря не знаю, просто захотелось структурированно изложить кашу, которая сейчас крутится у меня в голове, авось заодно и смысл жизни найдется, и тогда глупые вопросы перестанут возникать.<br /><br />ЗЫ: А вот неудобно иногда, что в OCaml по умолчанию string &lt;&gt; char list, и нужно писать преобразование ручками. Или это я такой невнимательный? :) urn:lj:livejournal.com:atom1:about_zero:11778 2007-11-22T18:56:09Z 2007-11-25T13:11:28Z Читаю сейчас замечательную книжку Leo Brodie "Thinking Forth" (<a href="http://thinking-forth.sourceforge.net/">ссылка</a>)<br />Несмотря на то, что книга выпущена в 1984 году, актуальности своей она не потеряла. Читаю, и все больше убеждаюсь в корректности изречения "Все новое - это хорошо забытое старое".<br /><br />Создание DSL как основной способ решения задач.<br />Быстрые итерации, прототипирование, постоянное взаимодействие с пользователем - основные постулаты Agile методик. <br /><br />Помимо всего прочего, и сам язык показался мне весьма интересным и приспособленным именно под подобный стиль разработки. urn:lj:livejournal.com:atom1:about_zero:11267 2007-10-25T17:40:21Z 2007-10-25T17:40:21Z "Структура банковских данных слишком сложна, чтобы применять к ней правила реляционного моделирования" - шедевральная цитата, взята <a href="http://dom.bankir.ru/showthread.php?t=77431&amp;page=2">из обсуждения здесь</a>.<br />Это я к тому, что все виденные мной схемы БД для банков, действительно выглядят несколько "лохмато". Широкие таблицы, куча редкоиспользуемых колонок, дублирующихся значений, смешение различных сущностей в одной таблице... Все это в той или иной степени присутствует во всех виденных системах. Похоже, что либо все архитекторы придерживаются этой максимы, либо таков неумолимый эволюционный процесс, что любая схема БД со временем накапливает энтропию и деградирует до 1НФ (или в лучшем случае до 2НФ)? urn:lj:livejournal.com:atom1:about_zero:11094 2007-10-02T16:13:20Z 2007-10-02T16:13:20Z В очередной раз перечитываю "Путь камикадзе" Йордона. До чего же хорошая, успокаивающая и умная книжка... Просто сейчас вживую наблюдаю все то, что написано в книжке, точность попадания и систематизации просто поражающая.... urn:lj:livejournal.com:atom1:about_zero:10911 2007-08-16T16:22:48Z 2007-08-16T16:22:48Z Интересно, какое название лучше подойдет - некропрограммист или археолог-программист? Не хочу ни так, ни так на самом деле... urn:lj:livejournal.com:atom1:about_zero:10642 2007-08-09T17:40:24Z 2007-08-09T17:40:24Z Еще несколько наблюдений из разряда типовых задач для баз данных. Итак, времязависимые данные. Есть 2 основных подхода для хранения периода актуальности у сущности:<br /><br />- EntityPK, ValidFrom. В этом случае периоды постоянства следуют один за другим без разрывов, до следующего ValidFrom с тем же EntityPK. Из явных плюсов - нет проблем с контролем интервалов постоянства (на наличие дырок, на наличие пересечений), нет проблем при загрузке данных в хранилище (нет необходимости корректировать остальные записи). Но есть один явный недостаток - для определения состояния на дату необходим подзапрос<br /><br />- EntityPK, ValidFrom, ValidTo. В этом случае все ровно наоборот - простота выборки и сложность добавления и поддержания согласованности данных.<br /><br />Кроме чистого подхода, можно например оптимизировать первый вариант для наиболее часто встречающегося случая - запрос актуальных данных на текущую дату, путем добавления поля-признака isActualState. Вариантов реализации много, от триггера до materialized view.<br /><br />Но по большому счету это все проблемы физической реализации типа данных - "временной интервал". У Дейта хорошо описано, что это такое и зачем нужно. И вот меня сейчас мучает вопрос - пропустил ли я что-то в возможностях современных СУБД в этой области, или до сих пор нет удобного типа данных для решения подобных задач? <br /><br />Здесь неполный список того, что хотелось бы видеть от этого типа даных.<br />- Задание даты начала, даты конца. Поддержка +/- бесконечности<br />- Получение длительности.<br />- Возможность арифметических действий - сложение, вычитание, пересечение, проверка на равенство.<br />- Проверка вхождения даты в интервал<br />- Возможность построения индекса по полям данного типа<br />- Проверка интервала на уникальность (что нет пересечений с другими значениями данного поля)<br />- Поддержка NULL-значений urn:lj:livejournal.com:atom1:about_zero:10244 2007-07-27T17:51:37Z 2007-07-27T17:51:37Z Планета Шелезяка. Жизни нет, мозгов нет, населена биомассой... urn:lj:livejournal.com:atom1:about_zero:10019 2007-07-26T17:38:09Z 2007-07-26T17:38:09Z Из разряда wtf...<br /><a href="http://dom.bankir.ru/showthread.php?t=75882">Автоматизация</a> во всей красе :)<br />Похоже что разработчиков в Диасе уже не осталось... urn:lj:livejournal.com:atom1:about_zero:9850 2007-07-16T18:52:58Z 2007-07-16T18:52:58Z Интересно наблюдать эволюцию развития банковских систем "у нас" и "у них". Очень четко прослеживается разница в подходах к проектированию и решаемых задачах. Почти все отечественные системы для банков идут от бухгалтерского учета, соответственно, вся доступная информация о движении средств доступна через проводки и остатки на счетах. Т.е. главное - выполнение ПБУ и банковская отчетность, а собственно задачи учета и анализа - вторичны. В забугорных системах (не могу сказать, что я видел их много, но все же...) - изначально все шло похоже именно от задач учета. Этот подход мне нравится больше, для текущих решаемых задач возьму похоже за образец аналогичный подход...<br />Еще до кучи мелкая архитектурная заметка - остатки по валютным счетам. Если мы храним приведенную сумму, то записи будут множиться ежедневно, т.к. курс меняется, соответственно идет переоценка остатка. Другой вариант - таблица курсов. Минус - лишнее соединение, недостаточно таблицы курсов ЦБ, потому что нужен курс на любую дату, в т.ч. и на праздники, что выливается либо в подзапросы, либо в доп. логику при загрузке курсов. А вот при хранении первичных документов проще всего сразу хранить приведенную сумму. Так что надо будет прикинуть и выбрать. urn:lj:livejournal.com:atom1:about_zero:9514 2007-06-22T17:11:46Z 2007-06-22T17:11:46Z <a href="http://www.onliner.by/test/gsm/nokia_gold/print">Правильные телефоны</a> :) А то я что-то завыбирался, зажрался так сказать... :) urn:lj:livejournal.com:atom1:about_zero:9399 2007-06-19T18:03:54Z 2007-06-19T18:03:54Z А вот мне интересно, это судьба у меня такая идти по стопам "архитекторов" и доводить "решенные задачи" и "готовые модули" до рабочего состояния? Вроде уже не мальчик, да и с "архитектором" мы это уже все неоднократно проходили в прошлом... Так чеж я удивляюсь как в первый раз? urn:lj:livejournal.com:atom1:about_zero:9151 2007-05-21T17:49:02Z 2007-05-21T17:49:02Z <a href="http://www.sql.ru/forum/actualthread.aspx?bid=9&amp;tid=428093&amp;pg=1">Kичный ИТ ассистент генерального директора компании</a><br />Порадовало :) urn:lj:livejournal.com:atom1:about_zero:8837 2007-04-24T17:39:43Z 2007-04-24T17:39:43Z <a href="http://rsdn.ru/Forum/Message.aspx?mid=2457628&amp;only=1">Это пять</a>, если товарищ не стебется... Вот они, подрастающие программисты, наша надежда и опора :) urn:lj:livejournal.com:atom1:about_zero:8504 2007-04-17T16:17:12Z 2007-04-17T16:17:12Z Господа, а кто что может порекомендовать почитать хорошего по основам статистики и анализа данных? Чтобы после прочтения не пугаться слов типа линейная регрессия, кластеризация и т.д? Если литература на английском, то возможно это будет даже лучше. urn:lj:livejournal.com:atom1:about_zero:8358 2007-04-11T18:56:45Z 2007-04-11T18:56:45Z Спровоцирована <a href="http://fishki.net/comment.php?id=19900">вот этим постом</a>. Почти все из перечисленного было и у меня, разве что вместо палицы и нунчаков использовалась велосипедная цепь :) Эх, было время... urn:lj:livejournal.com:atom1:about_zero:7646 2007-03-27T07:21:23Z 2007-03-28T05:46:32Z Перекраивая в очередной раз sql-код, с горечью раздумываю на тему, почему же unit-testing так непопулярен при разработке БД? По идее, никаких противопоказаний на этот счет нет, есть даже некий DbUnit... Но что получается на самом деле...<br />Если в базе только CRUD-операции, то все выглядит более-менее пристойно, просто и понятно. Но как только в базе появляется БЛ (бизнес-логика, про которую Фаулер помнится писал "странно, что такую нечеткую, нелогичную, часто меняющуюся вещь назвали термином бизнес-логика"), начинается цирк. Особенно если пытаешься использовать TDD с середины разрабокти или не дай бог когда началась поддержка. Рассмотрим этот самый крайний случай.<br />- Нужна база в жестком зафиксированном состоянии, причем для некоторых тестов эти состояния могут быть взаимоисключающими. Т.е. подняли эталонный дамп - прогнали тесты, и так по кругу. <br />- Все время приходится балансировать между производительным кодом, и кодом удобным для тестирования. Например, код, который бежит курсором по данным и вызывает для каждой строки процедуру, которая полагается только на переданные ей параметры, тестировать гораздо легче, чем код, состоящий из диких insert/update/delete, использующий кучу временных таблиц, которые заполнены за пару вызовов вверх. <br />- Следующий из предыдущего пункта вывод - для таких случаев черезвычайно сложно подготовить набор тестовых данных.<br />- Еще более следующий вывод - то что в этом случае получается уже сложно назвать unit-test'ом, это скорее уже функциональные тесты, которые логичнее производить со стороны вызывающего кода.<br />- Время выполнения набора тестов может получиться неприлично большим, что сводит на нет их полезность. Если после каждой правки мне нужно ждать даже 10 минут чтобы быть уверенным что я ничего не поломал - никуда не годная ситуация. А так как я не один, и каждый хочет запускать свои тесты на чистой тестовой базе, то получается очень много согласований и ненужной суеты.<br /><br />В результате полчается, что даже есть желание, реализовать полноценное unit-тестирование большого проекта практически невозможно :( Что я уже и наблюдал пару раз на разных проектах... К сожалению...<br /><br /><b>Upd.</b> Вот <a href="http://www.rsdn.ru/Forum/Message.aspx?mid=2025093">более развернутая</a> мысль на эту же тему... Человек более грамотным и культурным языком чем я описывает свое видение данной проблемы... urn:lj:livejournal.com:atom1:about_zero:7257 2007-03-26T09:03:59Z 2007-03-26T09:03:59Z <a href="http://jemacs.sourceforge.net/JEmacs-FSM.html">Оригинально...</a> Жалко только что наверняка несовместимо с оригнальным Emacs... А так идея хороша :) urn:lj:livejournal.com:atom1:about_zero:6939 2007-03-23T08:22:54Z 2007-03-23T08:22:54Z Наткнулся тут нас обсуждение на "Королевстве Дельфи"<br /><br />"<br />Правильным названием для новых сред от CodeGear было не не Дельфи для чего то там, а TurboPHP, TurboRuby, TurboPyhton, TurboLisp (мечтать не вредно :)) )<br />Это гораздо эффективнее и в маркетинговом плане.<br />...<br />...<br />ЗЫ. Да, TurboHaskell - это было бы неплохо! :о))<br />"<br /><br />Красота... :))) urn:lj:livejournal.com:atom1:about_zero:6903 2007-03-22T18:05:13Z 2007-03-22T19:14:06Z Вот как надо <a href="http://programming.reddit.com/goto?rss=true&amp;id=1c3u6">людей на работу приглашать</a> :). А то понимаешь ли... urn:lj:livejournal.com:atom1:about_zero:6155 2007-03-16T18:16:51Z 2007-03-17T09:44:37Z Вот. Попробую описать свой велосипед, дабы получить критику и новый опыт. Итак, часть 1-я. <a name="cutid1"></a><br /><br />Сначала небольшой пример. Вот так выглядит выражение для разбора числа с плавающей запятой.<br /><pre> get_float = [PMany1 [PDigit], POpt [PChar '.', PMany1 [PDigit], POpt [PChar 'E', POpt [POneOf ['+', '-']], PMany1 [PDigit] ]]] </pre><br />Напоминает Parsec, не так ли? :) Надеюсь что названия говорят сами за себя.<br />Входная точка разбора <pre>get_token :: String -&gt; [PV] -&gt; (Maybe String, String)</pre><br />Здесь PV - тип, констукторами которого являются PDigit, PMany, ...<br />Возврат - (Nothing, исходная строка) в случае если начало строки не совпадает с указанным образцом, и (Just совпавшая часть, остаток строки) в противоположном случае. Реализация "в лоб" путем прохода по списку паттернов с рекурсией, если необходимо и сопоставлением текущего символа строки с текущим элементарным паттерном.<br /><pre> 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, _) -&gt; [(Nothing, datas)] (Just v, rest) -&gt; get_token' rest xs ((Just v, rest) : accum) </pre><br />pass - вспомогательная функция, которая проверяет совпадение с конкретным паттерном.<br /><br />Вот, это основной кирпичик. Далее на него навешивается<br />- набор выражений для опознания основных токенов. Числа, строки, переменные, идентификаторы, комментарии, ...<br />Разбор текста точно также примитивен.<br /><pre> 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 ] </pre><br />Полный список распознаваемых токенов. Процедура получения из строки списка токенов заключается в последовательном примении функции try_apply.<br /><pre> try_apply s = try_apply' s tokens -- если перебрали весь список возможных токенов, и ни один не подошел, то ой... try_apply' s [] = (Nothing, s) try_apply' s (x:xs) = case r of (Just v, rest) -&gt; (Just $ TokenData x v, rest) (Nothing, _) -&gt; try_apply' s xs where r = get_token s (get_token_list x) get_token_list (Token name lst) = lst </pre><br />Вот в общем-то и все на текущий момент из глобального. Поверх этого в два касания был реализован<br />перевод зарезервированных слов t-sql к uppercase и вырезание комментариев. Так сказать чтобы была пользая и на практике :)<br /><br />ЗЫ: Для тех, кто все-таки дочитал до конца - о наличии Parsec.ParsecLanguage и иже с ними я осведомлен :) Просто нужно было написать что-то несложное, дабы почувствовать язык. urn:lj:livejournal.com:atom1:about_zero:6018 2007-03-16T12:46:57Z 2007-03-16T12:46:57Z Ну вот, дописал до относительно рабочего состояния свой первый небольшой проект на haskell. ~200 строчек кода вместе с тестами и готовым применением. Если причесать и окультурить, то будет меньше. Примитивный велосипедообразный разбор на лексемы, с готовым применением под t-sql :) С Parsec было бы раза в 2 меньше, но не так интересно :)<br />Писать честно говоря было приятно и удобно (за исключением отладки :) ), но не уверен, что я смогу разобраться в этом коде через месяц например...<br />Следующим шагом будет докрутка фич, ради которых это все собственно говоря и затевалось... urn:lj:livejournal.com:atom1:about_zero:5732 2007-03-10T14:25:52Z 2007-03-10T14:25:52Z Итак. Чего хочется. Хочется в виртуальной машине погонять Linux или BSD. Т.к. виртуальная машина, то не хочется ставить современный мощный пользовательский дистрибутив, им моего компа и вживую маловато ;). Из маленьких и шустрых которые более-менее на слуху, нашел 2. Zenwalk 4.4.1 и ArchLinux 0.7.2.<br />Что есть. Есть WinXP с стоящим VMWare 5.5.1. <br />Zenwalk 4.4.1 с ядром 2.6.20 - начинается установка, но не может найти почему-то CRDOM. Дальше этого не идем.<br />ArchLinux 0.7.2. Ставится. Начинаем устанавливать VMWare-tools как изложено у них в wiki. Нифига. Никак у него `uname -r` не совпадает с UTS_RELEASE в include/linux/version.h, хотя должон :) Хачить их конфигуратор на perl мне было влом.<br />Итак, чего бы мне еще попробовать? <br />Что нужно от дистрибутива. Относительная современность, чтобы не было проблем со сборкой из исходников, в случае чего. Из GUI там будет fluxbox или Xfce как барский вариант. Ну и набор разработчика. Религиозных предубеждений Linux vs. BSD, или rpm vs. deb vs. tar.gz или прочих не имею :) <br />Главное, чтобы хорошо работало под виртуальной машиной. Кстати, может есть что-то лчуше чем VMWare?<br /><br />Вот, продолжу поиски, авось что-то найдется.