Всех с наступающим!
Вспоминайте всё самое хорошее, чтобы забрать с собой в следующий год. Пусть сбудутся мечты!ОМ!
четверг, 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 г.
Влад Жигалов: О лирике и физике
Влад Жигалов замечательно отразил ощущения от происходящего в своей новой статье. Чему я несказанно рад, ибо мне такая четкость изложения не подвластна, а мысли-то в голове те же самые крутятся! Присоединяюсь к твоим словам, Влад! Спасибо, дружище! :-)
четверг, 26 ноября 2009 г.
Чуть-чуть о СССР
Кажется я знаю, что было такого в СССР, чего теперь почти не найти - практически не было манипуляций сознанием на бытовом уровне. Идеология КПСС, безусловно, та еще промывка мозгов была. Но зато тебе никто ничего не пытался впарить или выманить денег, используя многочисленные манипулятивные техники. Люди, по-моему, даже не задумывались, что такое возможно. Больше искренности было, что-ли. Незамутненность.
И еще одно наблюдение - мне иногда кажется, что не только россияне, нынешние или бывшие, по СССР скучают как о сказке, которая могла бы сбыться.
P.S. Это я вовсе не о "назад в СССР". Это о том, что ценным бывает не только то, что можно приобрести за золотые. Потерять такое богатство, как оказалось, проще, но найти очень сложно.
И еще одно наблюдение - мне иногда кажется, что не только россияне, нынешние или бывшие, по СССР скучают как о сказке, которая могла бы сбыться.
P.S. Это я вовсе не о "назад в СССР". Это о том, что ценным бывает не только то, что можно приобрести за золотые. Потерять такое богатство, как оказалось, проще, но найти очень сложно.
среда, 25 ноября 2009 г.
Избушку хочу
Пришёл, видимо, к закономерному пониманию того, что работа в офисе, независимо от её сложности и интересности, абсолютно не приносит морального удовлетворения. Хочется работать так, чтобы чувстовать приятную усталость в конце дня. Если честно, уже не помню когда такое было в последний раз.Потому для меня всё более привлекательной выглядит идея, воплощенная Германом Стерлиговым - завести свой дом в сельской местности, хозяйство, растить на свежем воздухе детей, приучая их к труду. Как-то естественно и честно жить такой жизнью для человека. Решаешь сам, как хозяйство развивать и что делать для этого нужно. Да и получаешь ровно столько сколько наработал. Главное, что занят с утра до вечера, без возможности предаваться лени. Чтоб было как учили: "делу время, потехе час".
пятница, 6 ноября 2009 г.
А ну-ка песню нам пропой, веселый ветер!
Который раз замечаю как старые песни "цепляют" своим бесконечным положительным зарядом несоизмеримо сильнее, чем любые проявления современной культуры.Вот, например, только что послушал эту, так сразу чакры открываться стали. :)Богатые душой люди все-таки жили тогда.
Песенка Роберта Гранта из к/ф "Дети капитана Гранта"
Музыка: И.О. Дунаевский Слова: В.И. Лебедев-Кумач.
Песенка Роберта Гранта из к/ф "Дети капитана Гранта"
Музыка: И.О. Дунаевский Слова: В.И. Лебедев-Кумач.
А ну-ка песню нам пропой, веселый ветер!
Веселый ветер, веселый ветер!
Моря и горы ты обшарил все на свете
И все на свете песенки слыхал.
Спой нам, ветер, про дикие горы,
Про глубокие тайны морей,
Про птичьи разговоры,
Про синие просторы,
Про смелых и больших людей.
Кто привык за победу бороться,
С нами вместе пускай запоет:
"Кто весел - тот смеется,
Кто хочет - тот добьется,
Кто ищет - тот всегда найдет!"
А ну-ка песню нам пропой, веселый ветер!
Веселый ветер, веселый ветер!
Моря и горы ты обшарил все на свете
И все на свете песенки слыхал.
Спой нам, ветер, про чащи лесные,
Про звериный запутанный след,
Про шорохи ночные,
Про мускулы стальные,
Про радость боевых побед.
Кто привык за победу бороться,
С нами вместе пускай запоет:
"Кто весел - тот смеется,
Кто хочет - тот добьется,
Кто ищет - тот всегда найдет!"
А ну-ка песню нам пропой, веселый ветер!
Веселый ветер, веселый ветер!
Моря и горы ты обшарил все на свете
И все на свете песенки слыхал.
Спой нам, ветер, про славу и смелость,
Про ученых, героев, бойцов,
Чтоб сердце загорелось,
Чтоб каждому хотелось
Догнать и перегнать отцов.
Кто привык за победу бороться,
С нами вместе пускай запоет:
"Кто весел - тот смеется,
Кто хочет - тот добьется,
Кто ищет - тот всегда найдет!"
А ну-ка песню нам пропой, веселый ветер!
Веселый ветер, веселый ветер!
Моря и горы ты обшарил все на свете
И все на свете песенки слыхал.
Спой нам песню, чтоб в ней прозвучали
Все весенние песни земли,
Чтоб трубы заиграли,
Чтоб губы подпевали,
Чтоб ноги веселей пошли.
Кто привык за победу бороться,
С нами вместе пускай запоет:
"Кто весел - тот смеется,
Кто хочет - тот добьется,
Кто ищет - тот всегда найдет!"
вторник, 27 октября 2009 г.
Злое о проекте
Меня безумно раздражает отсутствие аккуратности и здравого инженерного смысла при создании приложений. Просто бесит. В погоне за get it done (...and screw it up as much as possible) умудряются выдать на гора тонны компоста. Сотня бессмысленных классов пусть даже и красиво названных (например, ...Factory, ...DAO) легко в проекте появляется, тысячи строк копи-пейста, какие-то невнятные навороты над хибернейтом. Сплошной бред какой-то. Вопрос - зачем??? Причем, я не ставлю под сомнение необходимость иметь DAO, Factory и проч. Речь о том, что если уж есть слой DAO, то его расширение должно происходить в консистентной манере, а не так, что тут у нас есть DAO для конкретного бизнес-объекта, а тут было лень думать и мы сделали один большой DAO на всё приложение.
Не умеешь пользоваться хибернейтом - не трогай его вообще, отойди подальше. Но, пожалуйста, не трать время компании и терпение команды на демонстрацию умения писать много строк кода.
Лишнего - раз в 10 больше, чем необходимо. Какая тут нафиг эффективность? Угрохать полтора года чтобы написать свой незабываемый workflow manager для ETL трансформации? Идиоты... Возьмите SQL Server и SSIS (Integration Services) - там всё давное уже сделано. Нет, не можем, у нас Oracle, у нас специалисты. Распух у них Оракл и не падает, ёпрст! Сколько денег и сил в результате впустую, чтобы очередного монстра на Java и PL/SQL породить. В конце концов, если без Оракла никак, джавовскую часть можно на OpenSymphony построить и избежать тупизны и отсутствия гибкости своей имплементации workflow.
Зато становится понятно почему 60% команды проекта - менеджеры. Смысл вовсе не рационализировать деятельность компании, а создать больше возможностей для карьерной возни. Причем, судя по уровню технических решений в остальных проектах, даже архитекторы уже за еду работают.
Глядя изнутри и понимая каким же образом услуги компании мне как пользователю предоставляются, становится безрадостно как-то. Нафиг мне сдались такие услуги?
Не умеешь пользоваться хибернейтом - не трогай его вообще, отойди подальше. Но, пожалуйста, не трать время компании и терпение команды на демонстрацию умения писать много строк кода.
Лишнего - раз в 10 больше, чем необходимо. Какая тут нафиг эффективность? Угрохать полтора года чтобы написать свой незабываемый workflow manager для ETL трансформации? Идиоты... Возьмите SQL Server и SSIS (Integration Services) - там всё давное уже сделано. Нет, не можем, у нас Oracle, у нас специалисты. Распух у них Оракл и не падает, ёпрст! Сколько денег и сил в результате впустую, чтобы очередного монстра на Java и PL/SQL породить. В конце концов, если без Оракла никак, джавовскую часть можно на OpenSymphony построить и избежать тупизны и отсутствия гибкости своей имплементации workflow.
Зато становится понятно почему 60% команды проекта - менеджеры. Смысл вовсе не рационализировать деятельность компании, а создать больше возможностей для карьерной возни. Причем, судя по уровню технических решений в остальных проектах, даже архитекторы уже за еду работают.
Глядя изнутри и понимая каким же образом услуги компании мне как пользователю предоставляются, становится безрадостно как-то. Нафиг мне сдались такие услуги?
Споры о глобальном потеплении
Бессмысленная полемика развернулась по поводу этой статьи. Вкратце: статья оспаривает выводы, сделанные в британском документальном фильме The Great Global Warming Swindle. Фильм утверждает, что причиной так называемого "глобального потепления" деятельность человека вовсе не является, как пытаются доказать миру, например, ООН или Альберт Гор. Автор статьи защищает точку зрения последних. А в комментариях, как всегда, борются за правду.
Вот честно, мне абсолютно одинаково, что именно является причиной наблюдаемых климатических изменений - человеческая деятельность или же солнечная активность или же дрейф солнечной системы по галактике или все это вместе взятое. Не важно так же глобальное ли это потепление или похолодание. Важно то, что изменение привычного поведения природы ведёт к серьезному психологическому дискомфорту у многих жителей планеты. Это определенно худшим образом влияет как на моментальное самочувстие, так и на здоровье в целом. Внутренний дискомфорт ведёт к тому, что растёт раздражение к окружающим людям. И чем больше оно растёт, тем дальше человечество отодвигается от воможности мирно сосуществовать. То есть вместо прогрессивного развития цивилизации наблюдается как раз обратное - деградация. Казалось бы, есть продвинутые технологии, есть наука, есть деньги, есть человеческие ресурсы, но использовать всё это так, чтобы сохранить в человеке человеческое ну никак не получается. То есть все как бы понимают, что климат какой-то не тот, воздух грязный, что "все кругом - идиоты, один я умный", но все равно продолжают "жрать кактус". Как-то даже не хочется слово "цивилизация" использовать, чтобы обозначить субъект.
Согласившись с мнением, что да, человек своей деятельностью нарушает устоявшиеся климатические процессы, можно прийти к выводу, что это противоестественно поскольку повсеместно разрушает среду обитания.
Предположим, однако, что масштабная индустриализация не влияет на климат. То есть климат меняется, но причины не техногенные. Но на экологию-то индустриализация ого-го как влияет! А экология - это здоровье. А здоровье - это гармония внутри. А гармония внутри - это то, что уже нарушено изменениями климата. Опять выходит, что цивилизация деградирует - и так плохо, но с тупым упорством будем делать еще хуже, потому что остановится не можем. Хотя, казалось бы, при таких богатых ресурсах есть все возможности для сохранения единственно и истино ценного на этой планете - мира.
З.Ы. А полемику я считаю неразумной оттого, что есть проблемы поважнее, чем поиск того, кто заинтересован в рекламе идеи глобального потепления. "Эту бы энергию да в мирных целях".
Вот честно, мне абсолютно одинаково, что именно является причиной наблюдаемых климатических изменений - человеческая деятельность или же солнечная активность или же дрейф солнечной системы по галактике или все это вместе взятое. Не важно так же глобальное ли это потепление или похолодание. Важно то, что изменение привычного поведения природы ведёт к серьезному психологическому дискомфорту у многих жителей планеты. Это определенно худшим образом влияет как на моментальное самочувстие, так и на здоровье в целом. Внутренний дискомфорт ведёт к тому, что растёт раздражение к окружающим людям. И чем больше оно растёт, тем дальше человечество отодвигается от воможности мирно сосуществовать. То есть вместо прогрессивного развития цивилизации наблюдается как раз обратное - деградация. Казалось бы, есть продвинутые технологии, есть наука, есть деньги, есть человеческие ресурсы, но использовать всё это так, чтобы сохранить в человеке человеческое ну никак не получается. То есть все как бы понимают, что климат какой-то не тот, воздух грязный, что "все кругом - идиоты, один я умный", но все равно продолжают "жрать кактус". Как-то даже не хочется слово "цивилизация" использовать, чтобы обозначить субъект.
Согласившись с мнением, что да, человек своей деятельностью нарушает устоявшиеся климатические процессы, можно прийти к выводу, что это противоестественно поскольку повсеместно разрушает среду обитания.
Предположим, однако, что масштабная индустриализация не влияет на климат. То есть климат меняется, но причины не техногенные. Но на экологию-то индустриализация ого-го как влияет! А экология - это здоровье. А здоровье - это гармония внутри. А гармония внутри - это то, что уже нарушено изменениями климата. Опять выходит, что цивилизация деградирует - и так плохо, но с тупым упорством будем делать еще хуже, потому что остановится не можем. Хотя, казалось бы, при таких богатых ресурсах есть все возможности для сохранения единственно и истино ценного на этой планете - мира.
З.Ы. А полемику я считаю неразумной оттого, что есть проблемы поважнее, чем поиск того, кто заинтересован в рекламе идеи глобального потепления. "Эту бы энергию да в мирных целях".
среда, 14 октября 2009 г.
Историю нужно знать, иногда не такую уж давнюю
Чтиво о суровой реальности 90-х - апофеоз "патриотизма". Потому-то мы всё там же где были 20 лет назад.
понедельник, 12 октября 2009 г.
"Мы просто винтики в машине"
От собратьев-программистов часто приходится слышать фразу, полную негодования и отчаяния, смысл которой сводится примерно к такому: "Никого не волнует какой ты замечательный специалист. Все мы просто винтики в машине - поработал и выкинули". Подумалось вчера, что не всё так удручающее плохо, и, если поразмыслить, основная формула-то верная. Да, мы - винтики, да - в машине. Иначе и быть не может! Когда какой-либо процесс задуман работать продолжительное время с заданными характеристиками, естественным развитием первоначально кривенького, чадящего прототипа будет замена его на более современные высокотехнологичные машины. Для бизнеса (как хотелось бы его понимать :) нормальным развитием является наращивание темпов и объемов производства товаров или услуг, что невозможно осуществить без рационализации бизнес-процессов.
С моей точки зрения, взаимоотношение бизнеса и IT с точки зрения использования программного обеспечения ничем не отличается от использования любого агрегата в производстве. Есть пользователь агрегата - сборщик/оператор/операционист банка/трейдер. Есть агрегат - будь то конвейер или домна или АСУ или банковская система или трейдинг-система. И, естественно, есть тот, кто этот агрегат собрал и настроил, кто его обслуживает. Но в целом все три компонента все равно представляют собой части машины, производящей продукт. Поэтому любой из них можно считать "винтиком" этой одной большой машины.
Отчего же настолько часто айтишников раздражает осознание своей роли как "винтика"? Думаю, один из ответов мне понятен. Любая машина, независимо от её сложности, требует постоянного и тщательного ухода. Рачительный владелец будет свою машину беречь и ухаживать за ней. Для эффективной работы всего агрегата винтики необходимо, например, защищать от коррозии, перегрузки, может быть перегрева, и не когда-то, а сразу после установки. Нагрузку на каждый необходимо рассчитывать; там где достаточно одного, должен быть один, где нагрузка велика и её следует распределить - должно быть несколько. То есть подход, как ни крути, остаётся инженерным и требует определенных интелектуальных затрат при имплементации. Сдаётся мне, что в подавляющем большинстве случаев приходится сталкиваться с агрегатами, брошенными на произвол судьбы, лишь бы прибыль была. А это не может не раздражать любого, для кого слово "инженер" не пустой звук.
С моей точки зрения, взаимоотношение бизнеса и IT с точки зрения использования программного обеспечения ничем не отличается от использования любого агрегата в производстве. Есть пользователь агрегата - сборщик/оператор/операционист банка/трейдер. Есть агрегат - будь то конвейер или домна или АСУ или банковская система или трейдинг-система. И, естественно, есть тот, кто этот агрегат собрал и настроил, кто его обслуживает. Но в целом все три компонента все равно представляют собой части машины, производящей продукт. Поэтому любой из них можно считать "винтиком" этой одной большой машины.
Отчего же настолько часто айтишников раздражает осознание своей роли как "винтика"? Думаю, один из ответов мне понятен. Любая машина, независимо от её сложности, требует постоянного и тщательного ухода. Рачительный владелец будет свою машину беречь и ухаживать за ней. Для эффективной работы всего агрегата винтики необходимо, например, защищать от коррозии, перегрузки, может быть перегрева, и не когда-то, а сразу после установки. Нагрузку на каждый необходимо рассчитывать; там где достаточно одного, должен быть один, где нагрузка велика и её следует распределить - должно быть несколько. То есть подход, как ни крути, остаётся инженерным и требует определенных интелектуальных затрат при имплементации. Сдаётся мне, что в подавляющем большинстве случаев приходится сталкиваться с агрегатами, брошенными на произвол судьбы, лишь бы прибыль была. А это не может не раздражать любого, для кого слово "инженер" не пустой звук.
понедельник, 5 октября 2009 г.
Запасные подушечки для наушников
Есть у меня гарнитура Sennheiser типа вот этой и стерлись у неё давеча подушечки. Одна так просто в труху развалилась. Понятно, что так задумано, но еще более понятно становится, когда обнаруживаешь запасные подушечки в магазине по 15 SGD... Космические технологии, видимо. Или вручную крючком вышивают...
Такие же подушечки от Koss, но три в упаковке стоят 16+ SGD.
А такие же, но без громкого имени и по 4 SGD, все раскупили. :(
Причем, фабрика, наверняка, одна во всех трёх случаях.
Такие же подушечки от Koss, но три в упаковке стоят 16+ SGD.
А такие же, но без громкого имени и по 4 SGD, все раскупили. :(
Причем, фабрика, наверняка, одна во всех трёх случаях.
воскресенье, 4 октября 2009 г.
Возможен ли борщ в Сингапуре?
Жена вчера сварила борщ. Получилось очень вкусно, хотя свекла тут не такая хорошая по нашим меркам - слишком водянистая. Сегодня мы его успешно прикончили :)
Каюсь, был не готов и не сделал фотки в качестве доказательства. Учту на будущее.
Каюсь, был не готов и не сделал фотки в качестве доказательства. Учту на будущее.
Подписаться на:
Сообщения (Atom)