Всех с наступающим!
Вспоминайте всё самое хорошее, чтобы забрать с собой в следующий год. Пусть сбудутся мечты!ОМ!
четверг, 31 декабря 2009 г.
вторник, 29 декабря 2009 г.
Откуда bl-blx взялся
Вдруг вспомнил откуда вообще этот ник "bl-blx" в моей голове появился. Старый анекдот:
А с тех пор как в КС на зарубежных серверах попробовал рубиться, решил ник латиницей набирать всегда. Пусть там мучаются, читают "Блыблыкс". Наши-то поймут.
Каморка папы Карло. На стене — кусок холста. Папа Карло истязает полено:
— Во-от какой мальчишка будет смышленый! Ы-ых! Девчонка! Ы-ых! Безногая, но работя-аща-а-ая! Ы-ых! Собачка! Ых! Лягушка! Ых! Черт с вами, брелок.
Очень трогательно. Такая вот она — работа настоящего мастера.— Во-от какой мальчишка будет смышленый! Ы-ых! Девчонка! Ы-ых! Безногая, но работя-аща-а-ая! Ы-ых! Собачка! Ых! Лягушка! Ых! Черт с вами, брелок.
А с тех пор как в КС на зарубежных серверах попробовал рубиться, решил ник латиницей набирать всегда. Пусть там мучаются, читают "Блыблыкс". Наши-то поймут.
понедельник, 28 декабря 2009 г.
Аа-a-a!!!
Чего я вообще в этих дурацких офисах столько лет уже здоровье порчу? Я не собирался застревать в этом так надолго.
Хочу опять йогой заниматься, но только уже без всяких помех в виде тупой работы. Как так получилось, что я йогу променял на офисное безумие?? Я зол.
Хочу опять йогой заниматься, но только уже без всяких помех в виде тупой работы. Как так получилось, что я йогу променял на офисное безумие?? Я зол.
среда, 23 декабря 2009 г.
Сингапур - про дороги
Дороги тут качественные несмотря на тропические ливни и жару. Практически неизменная температура воздуха, вероятно, играет важную роль в сохранности дорожного покрытия. Помимо обычных улиц и проспектов в городе есть сеть expressway. Типичный expressway — 4 полосы туда, 4 обратно. Естественно, есть развязки везде по городу. Пешеход может пересечь магистраль только по переходу, чаще всего наземному. Подземных переходов тут не много, поскольку (моё предположение) частые ливневые дожди требуют строительства специального дренажа, что намного усложняет конструкцию.
За пользование многими дорогами автоматически взимается плата. При въезде на платный участок стоит электронное табло, указывающее текущую стоимость проезда для различных типов транспорта. Больше всего мне нравится уровень автоматизации. Каждое траспортное средство оснащается небольшим электронным устройством-терминалом (IU, in-vehicle unit) для дистанционной оплаты при помощи кредитных карт. Вставляешь карту — и вперёд. Монетки через окно бросать нет необходимости.
Тем не менее, наличие expressway не решает проблему пробок, которые тут периодически случаются. Конечно, до Садового Кольца или МКАД тут еще далеко, но затыки бывают. Стóит, например, на одной полосе кому-нибудь поломаться, тут же очередь на пару километров вырастает. То есть текущая пропускная способность уже где-то близка к пределу. Да и невозможно, по-моему, в текущих технологиях разрешить эту проблему, особенно заметную в пиковые часы утром и вечером.
Ситуацию на дорогах как она есть на данный момент, включая фотографии с камер, можно посмотреть тут.
За пользование многими дорогами автоматически взимается плата. При въезде на платный участок стоит электронное табло, указывающее текущую стоимость проезда для различных типов транспорта. Больше всего мне нравится уровень автоматизации. Каждое траспортное средство оснащается небольшим электронным устройством-терминалом (IU, in-vehicle unit) для дистанционной оплаты при помощи кредитных карт. Вставляешь карту — и вперёд. Монетки через окно бросать нет необходимости.
Тем не менее, наличие expressway не решает проблему пробок, которые тут периодически случаются. Конечно, до Садового Кольца или МКАД тут еще далеко, но затыки бывают. Стóит, например, на одной полосе кому-нибудь поломаться, тут же очередь на пару километров вырастает. То есть текущая пропускная способность уже где-то близка к пределу. Да и невозможно, по-моему, в текущих технологиях разрешить эту проблему, особенно заметную в пиковые часы утром и вечером.
Ситуацию на дорогах как она есть на данный момент, включая фотографии с камер, можно посмотреть тут.
вторник, 22 декабря 2009 г.
Петр Мостовой: Есть ли будущее у общества потребления?
А что, я почти со всем согласен - ровно такие же мысли крутятся.
И еще одна мысль вдогонку (вряд ли она моя):
И еще одна мысль вдогонку (вряд ли она моя):
В современной экономике спрос и предложение отнюдь не к товару или услуге относятся. Покупается и продается прибыль. Потому-то и качество товара/услуги перестало быть столь важным, как в классической теории.
И еще одно соображение:Производство дешевых товаров из дешевого сырья означает многократный, по сравнению с производством качественных вещей, экологический ущерб. Во-первых, дешевым обычно бывает сырье низкого качества. Переработка природных богатств в низкокачественное сырье требует затрат энергии и сопряжено с генерацией отходов. Потребление этого сырья поощряет его производство, чем косвенно и наносит экологический ущерб №1.
Далее, производство товаров из низкокачественного сырья, очевидно, также порождает какие-то отходы. Имеем №2.
Низкокачественные товары имеют своим свойством быстрый износ. Частая массовая их утилизация - №3.
И, наконец, низкое качество сырья приводит к повышенному проценту вредных веществ при утилизации - №4.
Далее, производство товаров из низкокачественного сырья, очевидно, также порождает какие-то отходы. Имеем №2.
Низкокачественные товары имеют своим свойством быстрый износ. Частая массовая их утилизация - №3.
И, наконец, низкое качество сырья приводит к повышенному проценту вредных веществ при утилизации - №4.
Зеленоград - водители vs пешеходы
Ну вот, опять...Каждый раз, когда в Зеленоградских новостях встречаю сообщение об очередном наезде на пешехода, грустно делается. Вроде и город небольшой, и совсем не такой безумный как дефолт-сити, и люди грамотные живут, да и разгоняться-то особо некуда и незачем. И всё равно случается. Я не понимаю этого. Да, конечно, статистика, погодные условия, непродуманная дорожная разметка, бестолковые пешеходы - всё есть. Но ведь автомобиль - это же огромная ответственность! То, что денег на авто заработал - еще не повод кормить своё ЧСВ и забывать об окружающих. Как пришло - так и уйдет.
Что, настолько все ослабленные, что повышенное внимание дороге уделить ну никак?! Нужна то всего лишь элементарнейшая дисциплина, на порядок проще той, что в армии, например!
Что, настолько все ослабленные, что повышенное внимание дороге уделить ну никак?! Нужна то всего лишь элементарнейшая дисциплина, на порядок проще той, что в армии, например!
Утренний пафос
Менеджеры, которые существуют ради освоения бюджета, проекты ради менеджеров, наём бестолковых работников ради возможности управлять - видимость активности при незначительной эффективности. Взять выше - власть ради себя самой, забывшая своё назначение. Мир заврался.
воскресенье, 20 декабря 2009 г.
Рождество близко
А в Сингапуре уже вовсю ёлки наряжают повсеместно. :) Готовятся, значит.На верхней фотка даже Снегурочка в сапожках есть!!!
Хорошие песни
Ух ты! Наткнулся на сайт Сергея Никитина, а там некоторые его песни для прослушивания доступны. Буду наслаждаться :-)
пятница, 18 декабря 2009 г.
Труды Маркса
Что ж, пора восполнить огромный пробел в образовании и познакомиться с трудами Карла Маркса поближе.
среда, 16 декабря 2009 г.
Сингапур - водители vs пешеходы
Другое забавноe, ортогональное по сравнению с мск, наблюдение — водители всегда пропускают пешеходов. Без жестикуляции и взаимных оскорблений.
При этом во время ливня никто о пешеходах особенно не печётся. Так что можно запросто получить ведро воды из ближайшей к тротуару лужи. Особенно характерно для автобусов.
При этом во время ливня никто о пешеходах особенно не печётся. Так что можно запросто получить ведро воды из ближайшей к тротуару лужи. Особенно характерно для автобусов.
Про сингапурское метро
Внезапно понял одно "существенное" отличие местного метро от мск — в вагонах кроме трех-четырех пиктограмм на тему что запрещено: курить, перевозить легковоспламеняющиеся вещества, употреблять пищу и/или напитки (плюс иногда запрет провозить дуриан встречается) больше никаких инструкций и правил пользования. Есть еще пиктограммы, обозначающие Priority Seat — места для пассажиров с детьми и инвалидов. Всё. Никаких табличек с десятками предложений, которые так увлекательно читать по дороге.
Годовая аттестация
Аттестация — по-моему, так это называлось в советское время. В западных компаниях это обычно носит название вроде Employee Performance Assessement или Employee Development Plan. Раз в полгода-год каждый сотрудник составляет список целей, которые он собирается достичь в ближайщие полгода-год. Этот список затем обсуждается с непосредственным начальником на предмет достижимости каждой из целей в указанный срок. Далее согласованный список отправляется в HR. Когда наступает указанный срок , работник производит оценку своей работы, указывая для каждой цели насколько он, по его мнению, достиг поставленных задач. Затем оценки расставляет начальник. После чего идёт обсуждение с целью прояснения различий в оценке и ознакомления со взаимными ожиданиями. Такая вот простая, но, обычно, весьма формализованная процедура.
Но что до сих пор для меня находится выше границы принятия рассудком это то, почему подобной активности уделяется много внимания и сил, в то время как собственно работе достаётся гораздо меньше. Я не понимаю почему организации процесса разработки программного продукта — активности, не зависящей от назначения последнего, вопреки широко пропагандируемому менеджерами стереотипу, — уделяется гораздо меньше сил и внимания нежели подобной аттестации. То есть, получается, эффективная организация собственной деятельности компании не столь уж и важна.
ЗЫ На самом деле причины понятны, но разум отказывается их принять как нечто незыблимое — количество менеджеров растёт, в то время как мотиваций для непосредственных исполнителей становится всё меньше.
ЗЗЫ После того как под давлением "кризиса" многие компании показали себя отнюдь не с лучшей стороны, у меня совсем доверие пропало к подобным аттестациям.
Но что до сих пор для меня находится выше границы принятия рассудком это то, почему подобной активности уделяется много внимания и сил, в то время как собственно работе достаётся гораздо меньше. Я не понимаю почему организации процесса разработки программного продукта — активности, не зависящей от назначения последнего, вопреки широко пропагандируемому менеджерами стереотипу, — уделяется гораздо меньше сил и внимания нежели подобной аттестации. То есть, получается, эффективная организация собственной деятельности компании не столь уж и важна.
ЗЫ На самом деле причины понятны, но разум отказывается их принять как нечто незыблимое — количество менеджеров растёт, в то время как мотиваций для непосредственных исполнителей становится всё меньше.
ЗЗЫ После того как под давлением "кризиса" многие компании показали себя отнюдь не с лучшей стороны, у меня совсем доверие пропало к подобным аттестациям.
вторник, 15 декабря 2009 г.
Неожиданная мысль
Чего-то мне вдруг обратно в Зелик захотелось...
Только я не хочу больше в к316 жить — слишком там много ошибок строители понаделали :-) Может, в МЖК? Но там дома слишком близко к шумной Ленинградке, а над ней, если с верхней точки смотреть, откровенно серый смог висит почти все время. :-(
В новом городе селиться не хочу - лысый он, без деревьев.
Только я не хочу больше в к316 жить — слишком там много ошибок строители понаделали :-) Может, в МЖК? Но там дома слишком близко к шумной Ленинградке, а над ней, если с верхней точки смотреть, откровенно серый смог висит почти все время. :-(
В новом городе селиться не хочу - лысый он, без деревьев.
понедельник, 14 декабря 2009 г.
четверг, 10 декабря 2009 г.
Небольшая утопия
Иногда приходят мысли из разряда сказок, утопий. Одна из них о том, что единственный разумный способ выхода из того хаоса, что творится в России - это каким-то чудесным образом выпросить государственный грант на строительство нового города по типу закрытых городов, каких было много в Союзе.
Каждого кандидата на жизнь в таком городе собеседовать на наличие совести и трудолюбия. Тех, у кого таковых нет, отметать сразу и без компромиссов. Набирать в основном молодёжь, которая еще не заражена вирусами халтуры и халявы, не знает, что такое функционер и номенклатура (заменить по вкусу), и имеет силы и желание строить. Конечно, городу понадобятся опытные мастера-профессионалы в качественаставников, учителей, руководителей, но, я думаю, таких людей найтиможно в достаточном количестве. Просто они обычно незаметны по тойпростой причине, что не тратят своё время на демагогию, а тихо испокойно делают своё дело.
С самого основания организовать комитет по борьбе с коррупцией. Спекуляцию ограничить. Вообще ввести строгое регулирование рисковых операций. Разрешить импорт только качественной продукции.
Экологию поставить на первое место с тем, чтоб дети рождались и росли здоровыми.
Самая главная идея - это изолировать здоровое от больного. При гриппе основная рекомендация ограничить социальные контакты. Ситуация в масштабе страны во многом схожая. То, что творится последние 20 лет - это какая-то непрерывная болезнь. Причем вирусная и весьма заразная. Среди многочисленных возбудителей определенно можно выделить вирусы глупости, жадности, гордыни и разгильдяйства.
И дать такому городу возможность расти и расширяться.
Отчего вдруг на сказки потянуло? В связи с трагедией в Перми я вспомнил, как несколько лет назад жил в замечательном городе Зеленограде. Снимал квартиру в недавно построенном доме (к.316). С виду - симпатичный новый дом. Количество же различных недочётов внутри оказалось выше моего понимания.
Чем можно объяснить, например, то, что два пожарных датчика, установленных в квартире, оказались в 10см(!) друг от друга и оба в корридоре? Если это дублирование, то почему установлены ненадежные датчики? Если же это формальное соблюдение требования "датчик на Х кв.м.", то куда смотрела приемная комиссия и смотрела ли она вообще? Почему ответственный за монтаж системы пожарной безопасности позволил установку с нарушением нормативов?
Говорите, "бдительность", "усилить проверки", "принять меры"? Но почему это всё после, а не до? Что делали все те люди, результат деятельности которых наверняка не в одном отдельно-взятом жилом помещении размножен? Эх...
Каждого кандидата на жизнь в таком городе собеседовать на наличие совести и трудолюбия. Тех, у кого таковых нет, отметать сразу и без компромиссов. Набирать в основном молодёжь, которая еще не заражена вирусами халтуры и халявы, не знает, что такое функционер и номенклатура (заменить по вкусу), и имеет силы и желание строить. Конечно, городу понадобятся опытные мастера-профессионалы в качественаставников, учителей, руководителей, но, я думаю, таких людей найтиможно в достаточном количестве. Просто они обычно незаметны по тойпростой причине, что не тратят своё время на демагогию, а тихо испокойно делают своё дело.
С самого основания организовать комитет по борьбе с коррупцией. Спекуляцию ограничить. Вообще ввести строгое регулирование рисковых операций. Разрешить импорт только качественной продукции.
Экологию поставить на первое место с тем, чтоб дети рождались и росли здоровыми.
Самая главная идея - это изолировать здоровое от больного. При гриппе основная рекомендация ограничить социальные контакты. Ситуация в масштабе страны во многом схожая. То, что творится последние 20 лет - это какая-то непрерывная болезнь. Причем вирусная и весьма заразная. Среди многочисленных возбудителей определенно можно выделить вирусы глупости, жадности, гордыни и разгильдяйства.
И дать такому городу возможность расти и расширяться.
Отчего вдруг на сказки потянуло? В связи с трагедией в Перми я вспомнил, как несколько лет назад жил в замечательном городе Зеленограде. Снимал квартиру в недавно построенном доме (к.316). С виду - симпатичный новый дом. Количество же различных недочётов внутри оказалось выше моего понимания.
Чем можно объяснить, например, то, что два пожарных датчика, установленных в квартире, оказались в 10см(!) друг от друга и оба в корридоре? Если это дублирование, то почему установлены ненадежные датчики? Если же это формальное соблюдение требования "датчик на Х кв.м.", то куда смотрела приемная комиссия и смотрела ли она вообще? Почему ответственный за монтаж системы пожарной безопасности позволил установку с нарушением нормативов?
Говорите, "бдительность", "усилить проверки", "принять меры"? Но почему это всё после, а не до? Что делали все те люди, результат деятельности которых наверняка не в одном отдельно-взятом жилом помещении размножен? Эх...
среда, 9 декабря 2009 г.
Про кризис
Кризис, рецессия. А с чего все взяли, что это кризис? Это тяжкое похмелье после эйфории "легких" денег. Пора уже учиться честным трудом зарабатывать. Хотя некоторым уже поздно...
понедельник, 7 декабря 2009 г.
Старость - не радость
Совершенно не могу работать в проектах, где не я архитектуру/дизайн разрабатывал и/или одобрял. Замечаю такое количество ошибок, что просто отворачивает сразу и надолго. Когда в такой проект попадаешь, как-то не вяжется с тем, что уже вроде как 2009 год. Старость, что-ли?
Вот, например, текущий проект. Множество ETL трансформаций перерабатывает данные от различных торговых систем банка. Трансформация стартуют в тот момент, когда внешняя система публикует очередной снимок своего состояния в виде CSV файла или в Oracle view. Переработанные данные складываются в гигантскую базу на основе Oracle, где хранятся на протяжении нескольких лет.
Соответственно, хаотический подход к проектированию породил зверя, у которого трансформации конфигурируются через базу данных, планировщик, их запускающий, написан на Java, а сами трансформации по большей части на PL/SQL. Типичная трансформация работает так: планировщик обнаруживает новую версию файла и запускает SQL Loader. Loader заливает данные в нелогируемую и неархивируемую таблицу. Далее планировщик запускает хранимую процедуру валидации, которая проверяет, что нет повторений и все важные поля не пусты. После этого он выполняет другую процедуру, которая перемещает данные в основную логируемую и архивируемую таблицу, где данные остаются жить на веки вечные. Следующий и последний шаг, который исполняется планировщиком также путем вызова хранимки, - формирование и рассылка событий с помощью OracleAQ.
Что и почему мне категорически не нравится в имплементации? Попробую раскрыть подробнее:
Планировщик
Что есть:
практически единственный, жестко-фиксированный тип задания, который он может обработать - проверить, есть ли новый снимок и запустить трансформацию из фиксированного набора шагов (см. выше). Конфигурировать можно то, какие хранимки вызываются, но их набор ограничивается структурой таблицы, а порядок вызова - джавовским обработчиком.
Что наблюдаем:
помимо оригинального требования к обработке файлов от внешних систем появились новые - импорт из view, автономный периодический экспорт своего состояния, etc. Всё новое в существующую схему БД вписывается очень криво, многие поля начинают трактоваться по-иному, в зависимости от типа задания.
Должно быть:
гибкий планировщик с персистентностью, безразличный к реализации выполняемых задач. Планировщик должен уметь регулярно или однократно запускать задачу, продвигать задачу из состояния в состояния, сохранять его при необходимости, иметь четко выраженный интерфейс управления и мониторинга. Фактически, persisting workflow manager.
Конфигурацию для задания также как и его состояние вовсе не обязательно размазывать по туче таблиц. Можно хранить в виде XML или JSON.
Трансформации
Что есть:
Куча однотипных PL/SQL процедур, которые варьируются в зависимости от внешней системы, откуда происходит импорт. Используются составные ключи из трех компонент: тип задачи, версия данных и дата обработки.
Что наблюдаем:
Огромное количество copy-paste кода с крайне ограниченным повторным использованием, без намека на юнит-тесты.Не говоря уже о том, что PL/SQL выглядит крайне убого и угрожающе громоздко в тех случаях,когда требуется найти дупликаты или обнаружить пропущенные значения.(PL/SQL вообще недоязык какой-то - длина идентификатора ограничена 30 символами, пространств имен нет, набор функций крайне ограниченный,разбиение пакетов на спецификацию и тело живо напоминает о всех сходных неудобствах с++; в общем - откровенное старьё).
Проблемы управления экземпляром Оракла, где постоянно на больших объёмах данных происходит переполнение архивного лога. Вопрос скорее организационный, но, зная тормознутость местных админов, нужно было это предвидеть и учесть в архитектуре.
Следует использовать однокомпонентные ключи хотя бы для того, чтобы избежать необходимости повторять набор параметров в процедурах. Тем более, что наиболее часто встречающаяся комбинация из нескольких компонент [тип, версия, дата], скорее всего, идентифицирует один объект - Job (тогда описание задания будет именоваться JobTemplate).
Должно быть:
Варант 1 - нафиг Оракл, используем SQL Server и SSIS. Все трансформации конфигурируются в виде SSIS-пакеты и деплоятся как задачи в SQLServer Agent.
Кстати, SQLServer обладает серьезным преимуществом перед Ораклом в том, что возможно выполнять bulk load, используя клиентское API. В Оракле же - только sqlldr.
Вариант 2 - цепочку sql loader >> java scheduler- >> duplicate-and-null check stored proc выбрасываем. Вместо этого читаем CSV на Java, отбрасываем дупликаты, проверяем на null, и результат сохраняем в CSV-файл, который затем загружается Loader-ом в основную таблицу. Получаем важное преимущество - независимый процесс гораздо проще контролировать, чем поведение экземпляра Оракл, нагруженного обработкой больших объёмов данных. Более того, исчерпание дискового пространства также проще контролировать и исправлять проблемы, нежели управлять экземпляром Оракла при помощи местных админов.
С точки зрения производительности проведенный мной несложный тест показал, что скорость такого процессинга сравнима, если не лучше, чем в оргинальной последовательности.
[To be updated]
Вот, например, текущий проект. Множество ETL трансформаций перерабатывает данные от различных торговых систем банка. Трансформация стартуют в тот момент, когда внешняя система публикует очередной снимок своего состояния в виде CSV файла или в Oracle view. Переработанные данные складываются в гигантскую базу на основе Oracle, где хранятся на протяжении нескольких лет.
Соответственно, хаотический подход к проектированию породил зверя, у которого трансформации конфигурируются через базу данных, планировщик, их запускающий, написан на Java, а сами трансформации по большей части на PL/SQL. Типичная трансформация работает так: планировщик обнаруживает новую версию файла и запускает SQL Loader. Loader заливает данные в нелогируемую и неархивируемую таблицу. Далее планировщик запускает хранимую процедуру валидации, которая проверяет, что нет повторений и все важные поля не пусты. После этого он выполняет другую процедуру, которая перемещает данные в основную логируемую и архивируемую таблицу, где данные остаются жить на веки вечные. Следующий и последний шаг, который исполняется планировщиком также путем вызова хранимки, - формирование и рассылка событий с помощью OracleAQ.
Что и почему мне категорически не нравится в имплементации? Попробую раскрыть подробнее:
Планировщик
Что есть:
практически единственный, жестко-фиксированный тип задания, который он может обработать - проверить, есть ли новый снимок и запустить трансформацию из фиксированного набора шагов (см. выше). Конфигурировать можно то, какие хранимки вызываются, но их набор ограничивается структурой таблицы, а порядок вызова - джавовским обработчиком.
Что наблюдаем:
помимо оригинального требования к обработке файлов от внешних систем появились новые - импорт из view, автономный периодический экспорт своего состояния, etc. Всё новое в существующую схему БД вписывается очень криво, многие поля начинают трактоваться по-иному, в зависимости от типа задания.
Должно быть:
гибкий планировщик с персистентностью, безразличный к реализации выполняемых задач. Планировщик должен уметь регулярно или однократно запускать задачу, продвигать задачу из состояния в состояния, сохранять его при необходимости, иметь четко выраженный интерфейс управления и мониторинга. Фактически, persisting workflow manager.
Конфигурацию для задания также как и его состояние вовсе не обязательно размазывать по туче таблиц. Можно хранить в виде XML или JSON.
Трансформации
Что есть:
Куча однотипных PL/SQL процедур, которые варьируются в зависимости от внешней системы, откуда происходит импорт. Используются составные ключи из трех компонент: тип задачи, версия данных и дата обработки.
Что наблюдаем:
Огромное количество copy-paste кода с крайне ограниченным повторным использованием, без намека на юнит-тесты.Не говоря уже о том, что PL/SQL выглядит крайне убого и угрожающе громоздко в тех случаях,когда требуется найти дупликаты или обнаружить пропущенные значения.(PL/SQL вообще недоязык какой-то - длина идентификатора ограничена 30 символами, пространств имен нет, набор функций крайне ограниченный,разбиение пакетов на спецификацию и тело живо напоминает о всех сходных неудобствах с++; в общем - откровенное старьё).
Проблемы управления экземпляром Оракла, где постоянно на больших объёмах данных происходит переполнение архивного лога. Вопрос скорее организационный, но, зная тормознутость местных админов, нужно было это предвидеть и учесть в архитектуре.
Следует использовать однокомпонентные ключи хотя бы для того, чтобы избежать необходимости повторять набор параметров в процедурах. Тем более, что наиболее часто встречающаяся комбинация из нескольких компонент [тип, версия, дата], скорее всего, идентифицирует один объект - Job (тогда описание задания будет именоваться JobTemplate).
Должно быть:
Варант 1 - нафиг Оракл, используем SQL Server и SSIS. Все трансформации конфигурируются в виде SSIS-пакеты и деплоятся как задачи в SQLServer Agent.
Кстати, SQLServer обладает серьезным преимуществом перед Ораклом в том, что возможно выполнять bulk load, используя клиентское API. В Оракле же - только sqlldr.
Вариант 2 - цепочку sql loader >> java scheduler- >> duplicate-and-null check stored proc выбрасываем. Вместо этого читаем CSV на Java, отбрасываем дупликаты, проверяем на null, и результат сохраняем в CSV-файл, который затем загружается Loader-ом в основную таблицу. Получаем важное преимущество - независимый процесс гораздо проще контролировать, чем поведение экземпляра Оракл, нагруженного обработкой больших объёмов данных. Более того, исчерпание дискового пространства также проще контролировать и исправлять проблемы, нежели управлять экземпляром Оракла при помощи местных админов.
С точки зрения производительности проведенный мной несложный тест показал, что скорость такого процессинга сравнима, если не лучше, чем в оргинальной последовательности.
[To be updated]
пятница, 4 декабря 2009 г.
Бизнес-линч - вариант code review?
Забавно, сейчас вдруг подумалось, что Бизнес-линч студии Лебедева - это тоже вариант design/code review.
Почему-то подобная практика всё еще слишком редка в разработке ПО. Существенное отличие нормально организованного программистского код-ревью от Бизнес-линча - гораздо более мягкая форма указания на недостатки. :-)
Почему-то подобная практика всё еще слишком редка в разработке ПО. Существенное отличие нормально организованного программистского код-ревью от Бизнес-линча - гораздо более мягкая форма указания на недостатки. :-)
четверг, 3 декабря 2009 г.
Влад Жигалов: О лирике и физике
Влад Жигалов замечательно отразил ощущения от происходящего в своей новой статье. Чему я несказанно рад, ибо мне такая четкость изложения не подвластна, а мысли-то в голове те же самые крутятся! Присоединяюсь к твоим словам, Влад! Спасибо, дружище! :-)
Подписаться на:
Сообщения (Atom)