Показаны сообщения с ярлыком technology grumbling. Показать все сообщения
Показаны сообщения с ярлыком technology grumbling. Показать все сообщения
четверг, 13 декабря 2012 г.
Кислорода у нас завались
Интересно, сколько литров драгоценного кислорода в среднем в секунду превращается в окиси углерода и окиси азота, благодаря миллионам двигателей внутреннего сгорания. Практически, вопрос для собеседования в Майкрософт, но заставляет задуматься совсем о другом.
пятница, 11 ноября 2011 г.
понедельник, 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]
вторник, 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% команды проекта - менеджеры. Смысл вовсе не рационализировать деятельность компании, а создать больше возможностей для карьерной возни. Причем, судя по уровню технических решений в остальных проектах, даже архитекторы уже за еду работают.
Глядя изнутри и понимая каким же образом услуги компании мне как пользователю предоставляются, становится безрадостно как-то. Нафиг мне сдались такие услуги?
понедельник, 12 октября 2009 г.
"Мы просто винтики в машине"
От собратьев-программистов часто приходится слышать фразу, полную негодования и отчаяния, смысл которой сводится примерно к такому: "Никого не волнует какой ты замечательный специалист. Все мы просто винтики в машине - поработал и выкинули". Подумалось вчера, что не всё так удручающее плохо, и, если поразмыслить, основная формула-то верная. Да, мы - винтики, да - в машине. Иначе и быть не может! Когда какой-либо процесс задуман работать продолжительное время с заданными характеристиками, естественным развитием первоначально кривенького, чадящего прототипа будет замена его на более современные высокотехнологичные машины. Для бизнеса (как хотелось бы его понимать :) нормальным развитием является наращивание темпов и объемов производства товаров или услуг, что невозможно осуществить без рационализации бизнес-процессов.
С моей точки зрения, взаимоотношение бизнеса и IT с точки зрения использования программного обеспечения ничем не отличается от использования любого агрегата в производстве. Есть пользователь агрегата - сборщик/оператор/операционист банка/трейдер. Есть агрегат - будь то конвейер или домна или АСУ или банковская система или трейдинг-система. И, естественно, есть тот, кто этот агрегат собрал и настроил, кто его обслуживает. Но в целом все три компонента все равно представляют собой части машины, производящей продукт. Поэтому любой из них можно считать "винтиком" этой одной большой машины.
Отчего же настолько часто айтишников раздражает осознание своей роли как "винтика"? Думаю, один из ответов мне понятен. Любая машина, независимо от её сложности, требует постоянного и тщательного ухода. Рачительный владелец будет свою машину беречь и ухаживать за ней. Для эффективной работы всего агрегата винтики необходимо, например, защищать от коррозии, перегрузки, может быть перегрева, и не когда-то, а сразу после установки. Нагрузку на каждый необходимо рассчитывать; там где достаточно одного, должен быть один, где нагрузка велика и её следует распределить - должно быть несколько. То есть подход, как ни крути, остаётся инженерным и требует определенных интелектуальных затрат при имплементации. Сдаётся мне, что в подавляющем большинстве случаев приходится сталкиваться с агрегатами, брошенными на произвол судьбы, лишь бы прибыль была. А это не может не раздражать любого, для кого слово "инженер" не пустой звук.
С моей точки зрения, взаимоотношение бизнеса и IT с точки зрения использования программного обеспечения ничем не отличается от использования любого агрегата в производстве. Есть пользователь агрегата - сборщик/оператор/операционист банка/трейдер. Есть агрегат - будь то конвейер или домна или АСУ или банковская система или трейдинг-система. И, естественно, есть тот, кто этот агрегат собрал и настроил, кто его обслуживает. Но в целом все три компонента все равно представляют собой части машины, производящей продукт. Поэтому любой из них можно считать "винтиком" этой одной большой машины.
Отчего же настолько часто айтишников раздражает осознание своей роли как "винтика"? Думаю, один из ответов мне понятен. Любая машина, независимо от её сложности, требует постоянного и тщательного ухода. Рачительный владелец будет свою машину беречь и ухаживать за ней. Для эффективной работы всего агрегата винтики необходимо, например, защищать от коррозии, перегрузки, может быть перегрева, и не когда-то, а сразу после установки. Нагрузку на каждый необходимо рассчитывать; там где достаточно одного, должен быть один, где нагрузка велика и её следует распределить - должно быть несколько. То есть подход, как ни крути, остаётся инженерным и требует определенных интелектуальных затрат при имплементации. Сдаётся мне, что в подавляющем большинстве случаев приходится сталкиваться с агрегатами, брошенными на произвол судьбы, лишь бы прибыль была. А это не может не раздражать любого, для кого слово "инженер" не пустой звук.
Подписаться на:
Сообщения (Atom)