Ленты RSS: фильтрация и полное содержание

Копался и сортировал свои подписки (которые RSS). Попутно решил пару сопутствующих проблем. Хочу поделиться.

Фильтрация

Есть ленты, в которых нет разбиения на какие-либо подразделы / темы. Собственно, почти все они такие. А если тематизация и существует, то достаточно строгая (например, можно подписаться на новости "Политика", но нельзя на новости "Путин" или "Путин или Медведев"). Как следствие, приходится либо просматривать большое количество обновлений такой ленты, либо отказаться от нее совсем (я выбрал второе - придерживаюсь принципа, что рассылка должна иметь большую точность).

Альтернатива - настроить правила подписки самому или фильтровать общий канал на основе своих фильтров. Для решения задачи прошерстил с десяток сайтов, вот что получилось:

1. http://re.rephrase.net/filter  - просто и со вкусом. Скармливаем оригинальный фид, задаем логическое правило пропуска фидов - и вуаля! (новости согласно моим музыкальным вкусам). Проблема только одна, правда серьезная - фильтрация по русским словам не работает. Отсюда второй ресурс.
   
2. Yahoo.Pipes - вагон и маленькая тележка сил и средств по работе с лентами (и не только). Можно делать действительно всё и это достаточно просто. Правда, требует регистрации, но получившийся фид может быть общедоступным (моё Хабра-избранное). Странно, что Google ещё подобный набор не добавил в свой feedburner и/или reader. 
   

Было еще много других, но их с легкостью выдает поисковик по фразе "rss filter". Они либо не работали с русскими фидами, либо портили html-содержание ленты, либо просто мне не понравились.

Полнотекстовые RSS-обновления

Некоторые сайты /блоги публикуют не весь свой контент в ленту один-к-одному, а только заголовок+первый абзац (или по выбору как на Хабре и LiveJournal). Не буду говорить плохо это или хорошо - у каждого способа есть своё применение. Идеально было бы представлять каждую ленту в двух форматах - в полном и в виде анонса. Но так, к сожалению, не везде, а значит есть задача по формированию полностатейной RSS ленты по имеющейся (в которой только анонсы). 

Ресурсы, которые решают эту проблему обычно выкусывают содержимое статьи из соответствующей html-страницы. Нужно только дать ссылку (чуть ли не в XPath) на элемент в HTML-элемент в дереве.

1. feedex.net - принцип "нажал-и-готово". Распознает дерево сам, поэтому частенько глючит. Мне подошел только в половине случаев (удачный пример).
2. RSS-farm - кажется один из первых отечественных ресурсов для мануального создания полнотекстовых лент. Требует установку .NET 3.5
   
3. Readbox - проект хабраюзера. Делает тоже, что и RSS-farm, но требует наличия только Firefox + Firebug (плагин к лисе). Им я смог докрутить оставшиеся ленты до их полнотекстовой версии (тот же удачный пример).

Deadlock на МКАДе

Очень злободневная тема с московскими (да и не только) пробками. Не высказался только ленивый. А так как я не ленивый, то тоже черкану пару строк. Но интересна конечно не столько сама проблема, сколько её решение. Если оно конечно есть. Взять к примеру такую простую вещь, как пересечение дорог. Выясняется, что неверно "развязанные" пересечения сводят на нет и ширину дороги, и её качество. С какой бы скоростью и во сколько бы рядов поток не двигался - ему всё равно стоять на/в/перед перекрестком.

Для визуализации воспользуюсь OpenTTD. Здесь и далее одна ж/д колея может рассматриваться как от 1 до N полос для автотранспорта. Важно направление. Итак, самый примитивный перекресток с 4-мя светофорными парами:

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

Улучшаем конструкцию. Цель - сделать прямой проезд в пересекающихся направлениях неблокирующим друг друга. Блокирующим может быть только поворот направо/налево. Получаем текущие развязки на МКАД в виде 88:

Великолепно работает если основной поток идет по прямым направлениям или, максимум, поворачивает направо. Поворот налево все также сложен - он потенциально блокирует направление с которого сворачивает. Более того, очень легко достижим deadlock (4 поезда поворачивают налево одновременно).

Причем раскрутить такой deadlock очень тяжело - "отвести" в сторону какое-нибудь транспортное средство невозможно - ему в затылок "дышит" другое... Кроме того, поворот налево достаточно трудоемкий - это фактически разворот на 270 градусов вместо 90. Т.е. требует сильного снижения скорости или достаточной площади для большого радиуса. Также при таком повороте в 2х случаях из 4х требуется еще и "взбираться" на уровень вверх...

Эти проблемы решены в новой версии предыдущей развязки. Суть та же, но поворот налево теперь 90-градусный и располагается на том же уровне, что и основная дорога до пересечения. Правда, для пересекающихся направлений теперь нужны туннель (одно направление) и мост (другое).

Под мостами развязка выглядит так:

Смотрится немного громоздко, но запас прочности для deadlock'а теперь больше. Сам он теперь не образуется - а только с помощью внешних факторов - например поломки (на примере поезд на Северо-Запад сломался и перекрыл все повороты налево).

Пока проезд в прямых направлениях возможен, но через некоторое время, когда подойдут другие транспортные средства тоже поворачивающие налево, перекроются и они.

Это была развязка уже на трех уровнях. Что же будет если использовать 4? Возможно ли сделать развязку, в которой поворот налево не пересекается с другим поворотом налево? Да:

Или вот так с прозрачными мостами:

Требуется 4 туннеля и 4 моста. Самый дорогой вариант (что неудивительно). Проезд в одном направлении идет практически по прямой (и на том же уровне). На другом направлении - тоже по прямой, но на -1 уровне. А вот для поворота налево нужно сначала "взобраться" на +1 уровень, на котором проехать под двумя мостами, "взобраться" на другой мост и затем съехать с моста и с холма до начального уровня. Поворот налево снова 90-градусный, что есть несомненный плюс.

Как видно, сама развязка с точки зрения транспортного средства представляет из себя сначала развилку, а потом слияние. Примерно так это работает:

А так это уже делают в реале:

Ничего, когда-нибудь и у нас так будет.

P.S. для тайкуноводов. Как построить последнюю развязку - алгоритм:

Топорный метод борьбы с шумом видекарты

Не открою Америку если скажу что видеокарты - самый-самый компонент современного ПК. Во всех смыслах. 

Самый капризный (2 слота подавай, доп. питание подавай, доп. охлаждение подавай).

Самый дорогой (да-да, чего уж там - топ видекарты (или двух)  - дороже топа ЦП. Ну я не имею ввиду серверные варианты - только десктопные.

Самый быстроустаревающий - вышла новая версия DirectX и все, вы уже за бортом современности дорогой владелец.

Самый ненадежный - наверное следствие предыдущего свойства. Производители просто не закладывают большой срок работы ибо он никому не нужен - через 2-3 года будет апгрейд...

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

Расскажу как я боролся с последним свойством. Удивительно что производители видеокарт до сих пор не установили (хотя может уже есть?) систему контроля температуры и соответствующей скорости работы вентиляторов охлаждения на карте. Чтобы она работала сама - без драйверов, программных настроек и проч. Пока этого нет, пользователям приходится иметь с этим дело. Чаще всего, конечно, любителям разгона или тем кто просто разбирается. Основная же масса людей просто терпит "пылесосный" шум видеокарты всю  недолгую жизнь компа - при этом 99% времени не запуская на нем ничего нагружающего видяху больше, чем YouTube.

Итак, если у вас шумная видеокарта в "default" режиме - добро пожаловать в волшебный мир RivaTuner. Если вам вдвойне не повезло и RivaTuner не споcобна регулировать обороты вентилятора видекарты  - тогда вы мой друг и товарищ. Тогда этот пост для вас.

Имею видяшку среднего класса (ну по крайней мере, когда я ее брал - она была средней) Asus ENGTS250 Dark Knight с вышеописанной проблемой: вентилятор все время "пилит" на максимуме и жить не дает. :) Решаем проблему топорно - меняем вентилятор на тихий. Что? Специальное охлаждение для видяхи - сразу нет по нескольким причинам:

1. Разные форм-факторы систем охлаждения - без всякой гарантии что подойдет - надо просто брать и "примерять"
2. Цена - на middle-ware видяху ставить охлаждение в треть или половину цены самой видяхи - нерентабельно.

Итак, приступим. Для начала снимем штатный вентилятор

Питание конечно же у него свое - "видяшечное", т.е. не такое как на материнской плате. Это значит что наш новый вентилятор будет питаться от материнки. Ничего, главное чтобы видеокарта стартовала с нулевым потреблением по каналу питания вентилятора (а то кто ж их знаешь - может "перебдели").

Идем дальше. Берем проволоку (у меня это была 1,5 мм медный кабель) и делаем из нее две буквы П

Вставляем проволоку за "крылья" радиатора

Ну вот все готово. Где же наш новый герой? Вот он:

Насаживаем новый вентилятор на видеокарточевский радиатор и закрепляем проволокой

Всё! Вставляем в корпус и наслаждаемся тишиной

Недостатки думаю видны - вентилятор неплотно примыкает к центру радиатора. Опыты показали что испытание "меховым бубликом" такая видяшка не прошла - на температуре порядка 95С система ушла в перезагрузку. Поэтому на температуру в 90С у меня стоит даунлокинг - он впрочем пока срабатывал всего пару раз - этим летом.

Как я сделал свой ПК совсем тихим

Цель

Минимизировать шумовой эффект типичного домашнего ПК собранного в HTPC-формате. Как будет видно внизу я не заморачивался подбором специальных тихих компонентов ПК и всегда ориентировался на соотношение цена-производительность-шум. Ну разве что цену корпуса я проигнорировал. Как потом оказалось совершенно правильно, ибо он (корпус) того стоит.

Задачу можно считать выполненной если в комнате с данным ПК можно спать, а при просмотре тихих сцен фильмов комп никак не напоминает о своем присутствии (прежде всего шумом вентиляторов и жесткими дисками).

Конфигурация

Процессор:  Intel Core 2 Duo E7400 (охлаждение: Noctua NH-U12P)

Материнская плата: Gigabyte GA-EP45-DS3P

Оперативная память: Kingston KHX8500D2/G2

Видеокарта: Asus ENGTS250 Dark Knight (охлаждение штатное)

Жесткие диски (RAID-0): Hitachi Deskstar 7K100.B HDT721010SLA360 и отдельно Seagate Barracuda 7200.11 750 Gb

Блок питания: Corsair HX520W

DVD-привод: Lite-on iHAS422-31

Корпус: Antec Fusion Remote Max

В собранном состоянии (но со снятой верхней крышкой, снятым DVD-приводом и верхней крышкой отсека жестких дисков) он выглядит вот так:

Материалы

Демпфирующий материал - для шумопоглощения. Будет наклеен на все стены внутренних поверхностей, которые образуют замкнутое пространство. Чем чаще звук внутри корпуса натолкнется на такую "мягкую" стенку - тем лучше.

Антирезонансный материал - будет прокладкой между любым вибрирующим девайсом (все вентиляторы, привод, блок питания, жесткие диски) и корпусом. Представляет из себя практически самоклеящийся рубероид.

Любой герметик - я взял прозрачный сантехнический просто потому что он тогда у меня был.

Двухсторонний скотч, ножницы, нож, маркер.

Приступаем

Корпус устроен таким образом что все внутренне пространство делит на 3 отсека: БП (блок питания + две 3,5'' секции), маленький (два 3,5'' секции) и основной (все остальное - проц, мать, видяха, DVD-привод). Охлаждение работает следующим образом: воздух втягивается из двух неосновных отсеков, проходит через 3,5'' секции и попадает в основной отсек. Из основного отсека он выдувается двумя корпусными вентиляторами: 120 мм и 140 мм. БП в этом воздушном цикле не участвует: он потребляет воздух с боковой стенки и выбрасывает его с задней стенки.

Нужно помнить: шумоизоляция не должна усложнить проникновение и вообще весь путь воздуха внутри корпуса.

Внутри корпуса 3 секции: две секции с двумя 3,5'' отсеками каждая и одна съемная секция с двумя 5,25'' отсеками.

Обрабатываем 5,25'' секцию. На боковые стенки наклеиваем антирезонансный материал (места соприкосновения секции с корпусом). На внутреннюю поверхность пустого 5,25'' слота наклеиваем демпфирующий материал:

"Обезвреживаем" возможное дребезжание верхней крышки. По периметру в углах промазываем герметиком ( 0,5 - 1 мм слой) и ждем высыхания. Получается так:

Снимаем корпусные вентиляторы и по периметру их примыкания с корпусом проклеиваем антирезонансный материал (полосочки ширином 4-5 мм). Ставим вентиляторы обратно. Также проеклеиваем стенки внутри корпуса в местах где он соприкасается с БП.

Теперь самое интересное. На стенки корпуса с внутренней стороны наклеиваем демпферный материал, стараясь не заслонить слоты мат. платы. Получается как-то так (съемки против часовой со всех углов):

Важно, что отверстия воздухозабора остались незаслонёнными. У одной стенки, пришлось немного подрезать демпф. материал, чтобы не потерять жесткость конструкции:

Результаты

Разница почувствовалась сразу. Никаких визжащих звуков от жестких дисков и небольшого вентилятора видеокарты. Шум, который слышно непосредственно у корпуса напоминает шум движения воздуха по такому [непростому] маршруту. Скорее для самоуспокоения я позже поменял штатные корпусные вентиляторы на тихие от Cooler Master (на подшипниках скольжения). Если сидеть на диване (2,5 м перед компом в стойке) , то шум от компа слышен только ночью с закрытыми окнами и дверью в кухню (там шумит холодильник). Задача выполнена :)

P.S. 

Несмотря на то, что корпус считается достаточно большим для HTPC-семейства, не всякий башенный процессорный кулер в него войдет. Например мой оставил расстояние всего порядка 2 мм (!) от верхней крышки. Так что кулеры выше моего в этот корпус брать настоятельно не рекомендую - не влезет (фото сделано через щель для DVD-привода): 

Что читаю

Решил опубликовать около-профессиональные блоги*рассылки, которые сейчас читаю. Через некоторое время будет интересно оценить тренд в подписках. :)

http://googlerussiablog.blogspot.com/atom.xml

Без комментариев :)

http://company.yandex.ru/news/news.rss

Тут тоже все понятно

http://blogs.sun.com/main/feed/entries/atom?tags=projectcoin

Новости про Project Coin для JDK 7. Чтобы быть в курсе

http://www.javaworld.com/features/index.xml

Статьи с одноименной Java конфы

http://www.joelonsoftware.com/rss.xml

Широкоизвестный в узких ИТ-кругах блоггер

http://martinfowler.com/bliki/bliki.atom

Мартин Фаулер. Сейчас в основном пишет про свою новую книжку и про конференции в которых учавствует

http://nighthacks.com/roller/jag/feed/entries/atom

James Gosling. Папа Java. Главным образом идеологические новости вроде "Оракл - жадные хапуги" и "Даешь Java моей мечты". Также всякие интересные истории из жизни Sun.

http://blogs.sun.com/theplanetarium_ru/feed/entries/atom

Русскоязычные новости про Java от Sun. Давно уже не обновлялся - наверное загнулся

http://yakov-sirotkin.livejournal.com/data/rss

Бывший Яндексовый программист, основатель JUG.ru, Java-программист, ну и просто хороший вентилятор

http://codingmatters.blogspot.com/feeds/posts/default

Мой бывший коллега. Апологет test driven development и agile. Просто хороший спец

http://smart-haos.livejournal.com/data/rss

Еще один человек из Яндекса. Тим-лид. На тему менеджмента и тим-лидерства и пишет

http://d-zh.livejournal.com/data/rss

Владелец HFLabs - очень амбициозной компании, когда-то бывшей старт-апом. Пишет про ИТ в бизнесе и влияние одного на другое. Достаточно высокоуровневые вещи...

http://kholodova.livejournal.com/data/rss

Project manager оттуда же.

http://aivanov.livejournal.com/data/rss

Циничный ИТ-менеджер из Borland, теперь из JetBrains. Пишет про программирование и ИТ-менеджерство

http://dolzhenko.blogspot.com/feeds/posts/default

Коллега пишет про ФП и иногда копипастит задачки с braingames.ru

http://feeds2.feedburner.com/stephansblog

Опытный разрабочик о работе программиста во всех ее аспектах

http://just-developer.livejournal.com/data/rss

Белорусский Java программист работающий в Лондоне. Понравился во здравым комментам в ru_java

Ну вот и всё. Если поделитесь своими - буду рад.

Peopleware - команды

Продолжение впечатлений от Peopleware

О командах - это наверное самое интересное что прочиталось. Авторы приводят блестящий пример когда сравнивают группу программистов не с командой, а с оркестром.

Команда - понятие скорее спортивное - там просто правила игры такие, что всем вместе надо добиваться общей цели. В то же время, конкуренция внутри может достигать космических масштабов. Как пример можно взять любой чемпионат мира, где какая-нибудь команда "без звезд" обыгрывала "дрим тим" апологетов футбола. Просто потому, что при слабом составе ни на что, кроме как на командную работу рассчитывать не приходится. Это как 2+2=5 в слабой персоналиями но слаженной команде, и 3+3=3 в звездной но конкурирующей (за мяч) команде.

Другое дело с оркестром. Одну и ту же сонату, в общем-то, может сыграть как квартет, так и большой симфонический оркестр. И скрипач никак не может отобрать работу у виолончелиста (ну только если он и на виолончели играть может), а альтист - у скрипача. Если же кто-то начинает "лажать" - общий результат сразу страдает, причем сильно. Квартет может играть сам, но большой оркестр - только с дирижером.

Теперь - что вам ближе как участнику группы программистов? Я бы точно "ушел" в оркестр.

Ближе к цитатам. О недопущении "Борьбы за мяч": "любое действие, дифференцирующее награждение участников команды, вероятно будет способствовать конкуренции." Вы же не будете по результатам концерта и громкости оваций выбирать "лучшего музыканта"? А если и будете, то кого выберете? Скрипача (больше всего солирует)? Солистов (поют как-никак)? Дирижера?..

Кроме того, авторы резюмируют действия направленные на разрушение команды:

• недоверие начальства к команде (ну-ка, объясни мне в деталях как ты будет решать эту задачу)
• бюрократия (сначала получи подтверждение у господина Х)
• физическое разделение
• дробление рабочего времени (40% своего времени делай эту задачу и 60% другую)
• снижение качества продукта (давайте выпустим как есть - все равно никто не заметит)
• идиотские сроки сдачи (9 месяцев на ребенка - это не годится. Давайте это будут 2 женщины - но за 4,5 мес)

Тут правда хочется плакать. В связи с нашей реструктуризацией, наша команда имеет 4 пункта и 6ти. Правда месяца три назад их было все 6.

О собраниях/совещаниях: "настоящее рабочее собрание созывается когда есть реальная потребность в совместном обдумывании некоторых вопросов всеми собравшимися." Следует заметить, что тонкий момент здесь - в определении этой "потребности". Начальство чаще всего предполагает что она есть, команда - что нет. Единственное что приходит мне на ум - дать участникам самим решить будут они собираться или нет.

А вот что нужно делать, чтобы команда становилась все более "оркестром":

• возводить качество в ранг культа
• создавать многочисленные промежуточные финиши, приносящее удовлетворение
• внушать чувство элитарности
• допускать и поощрять неоднородность
• сохранять и защищать успешные команды
• раздавать стратегические но не тактические указания

Снова позволю вернутся себе к моей текущей работе. 1 из 6ти. Печально. Причем 4 оставшихся пункта можно "пропихнуть" через руководство - оно так или иначе с ними согласится. Но вот "неоднородность" прямо противоречит линии партии, которая гласит "мы должны иметь пул программистов, каждый из которых способен решать поставленные задачи". Бред полный конечно...

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

Осталось определиться с чего начать...

Peopleware - корпоративная культура

Продолжение впечатлений от Peopleware

Корпоративные делишки

1. Отношения к корпоративным ценностям и целям. Цели организации постоянно критически рассматриваются сотрудниками этой организации, и большинство этих целей оценивается как ужасный бред. На дворе 2010 год, а в коридорах всё также висят плакаты "Даешь произвотельность!"... Смешно и грустно.
2. Недавно был свидетелем зарождения нового как любят говорить "горизонтального" сервиса в банке. Назвали его "Enterprise Architecture". Не буду вдаваться в подробности смысла существования сего подразделения, но подавляющему большинству он остается непонятен. Или каждый его понимает по-своему. Но суть не в этом. Как часть расходов бюджета этого подразделения были изданы плакаты и заказаны футболки с логотипом. Прямо-таки пример из книги (напомню 85 год написания): "Эти так называемые мотивирующие аксессуары (включая кружки для кофе со слоганами, плакаты в рамках, булавки, брелоки, награды) символизируют победу формы над смыслом... Мотивирующие аксессуары настолько лживы, что у большинства людей от них мурашки по коже"
3. Переработки или сверхурочные. "Мы работаем сверхурочно не для того чтобы сделать работу, но для того, чтобы оградить себя от обвинений, когда работа не будет сделана в срок". Абсолютно согласен. Никак не вяжутся переработки человека с его способностью сдавать дела в срок.

А вообще, в США конечно корпоративная культура имеет в разы большую историю, чем наша. Наверное поэтому мы сейчас проходим этапы развития уже ими пройденные... Не думаю что в Советском Союзе конторы обладали похожими проблемами. Все-таки уволить человека в СССР за неэффективность дело было сложное. 

Peopleware - управление проектами

Почитал классическую книжку из тех, которые пришли к нам из 80х об управлении проектами.

Конечно прочитав её, трудно не упасть духом. Потому что описанные там проблемы остались. Как будто бы только немногие, кто осознал и на практике принял во внимание содержание книжки, стали успешны. Львиная же доля индустрии продолжает забивать микроскопом гвозди.

Моменты которые меня зацепили - касающиеся управления проектами.

Управление проектами

1. Ошибки и люди, которые их совершают. И отношение к ним. Если в команде за ошибки сурово наказывают, возникает достаточно тяжелая атмосфера. Люди будут занимать оборонительную позицию в контексте рисков и инициатив. Идея в том, чтобы минимизировать вред который ошибка причиняет и максимизировать опыт который из нее извлекается. В такой среде каждая ошибка - это практически вклад в успех.
2. Управление людьми - не пытаться сделать их одинаковыми и взаимозаменяемыми в производственном процессе (как на заводе), а уметь использовать их уникальность. Очень тонкий момент. Насколько часто хочется "сделать всех взаимозаменяемыми" настолько же часто хочется чтобы "каждый имел свою специализацию". Тонкий и холиварный момент...
3. Отношение к качеству. Профессионализм программиста не позволяет сдавать продукт с низким качеством. С другой стороны, на идеальное качество уйдет бесконечно большое время. Продавливание сдачи продукта с качеством, которое не удовлетворяет программиста обычно отражается на его самооценке и мотивации. Тонкий момент... С другой стороны, те кто готов в конечном итоге платить за качество большую цену, для них оно  в конечном итоге ничего не стоит.
4. Давление начальства на ход выполнения проекта. Оказывается "проекты в которых шеф не оказывал временного давления вообще ("Разбудите меня когда будет готово"), характеризовались самой высокой производительностью". Например с этим у нас сейчас тяжело. Каждый день разработчика кто-нибудь да спросит (причем в синхронном режиме по телефону / мессенджеру / лично): "Как там у нас дела? Как сроки?" Думаю давление можно и нужно сводить к минимуму путем асинхронной отчетности (как я её называю) - например через JIRA.
5. Производительность разработчиков и факторы которые на ее влияют. Оказывается, язык значения не имеет (опыт 84-85 годов). Склонен согласиться с этим. Не думаю, что ОО-дизайн программы на Java будет как-то отличатся по времени от С++. При условии достаточного профессионала с обеих сторон. Также не имеет значения опыт, в определенных границах (от 2х до 10 лет). И, главное, зарплата - лучшие получали всего на 9% больше худших (при двукратно лучших результатов). Теперь финансовое  стремление нанимать звезд.
6. Эффект Готорна. "Люди работают лучше когда пробуют что-то новое". Подписываюсь 
7. Отличная мысль по поводу экспериментов и пилотов: Не экспериментируйте более чем с одним технологическим аспектом в пределах одного пилотного проекта.

Продолжение следует...

Проактивность

Когда человек родится, он слаб и гибок, когда умирает, он
крепок и черств. Когда дерево растет, оно нежно и гибко, а когда оно сухо
и жестко, оно умирает. Черствость и сила спутники смерти, гибкость и
слабость выражают свежесть бытия. Поэтому что отвердело, то не победит.

А. и Б. Стругацкие. Сценарий к к/ф "Сталкер"

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

В этом-то и проблема. Собрав программистов и их начальников и вложив им в мозг подобное определение, а потом еще и смотивировав их соответствующим образом, поставив однозначное соответствие "проактивный -> эффективный -> успешный -> богатый/счастливый" ничего хорошего достигнуть нельзя. Ну скажем, какая-то часть сотрудников промотивировалась, например треть. Причем велика вероятность это эти люди и так достаточно эффективно и хорошо работают, они ответственны, исполнительны и инициативны. Так же к ним наверняка примкнут сотрудники с "синдромом отличника" - объявили задачу, объявили шкалу оценок - теперь они будут делать все чтобы оказаться в рейтинге на месте, тешащее их самолюбие. 

На следующий день эти люди, хорошенько подумав и прикинув пути "проактивности" - т.е. "где и как копать", приходят на работу. И еще ничего если они перед тем как начать копать приходят на начальнику/коллегам и уточняют, хорошо ли будет если они начнут копать в том направлении. Тут начнется диалог и есть шанс что энергия копателя будет направлена в нужное русло. Но программисты как правило интроверты, а значит не очень общительны особенно в том, что касается их будущих побед. Поэтому велик шанс что сотрудник начинает копать сам, никого не поставив в известность. Это почти всегда означает, что он (программист) начинает:

• рефакторить, то что его давно раздражало 
• сочинять новый фрэймворк
• писать все "с нуля", чтобы когда-нибудь в один прекрасный момент это выпустить
• прикручивать новомодную технологию / фреймворк, которую так давно хотелось попробовать
• бросаться в неопределенные академические изыскания

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

А теперь представим что в одной команде оказалось больше одного такого "проактиватора". Если в команде / продукте есть определенные проблемы, наверняка оба заметят их и начнут решать. Параллельно. Причем, наверняка разными способами.

Приходим к выводу что "проактивные" в том смысле в каком описано выше, это "неэффективные". Потому что упущен главный момент - коммуникация.

Но это еще не все. В проактивности как таковой есть еще один момент. Проактивность в любом ее проявлении направлена на самого индивидуума, а не на его окружение. Если программист бросается переписывать все с нуля - значит он просто не может смириться с таким кодом. В то же время не в его силах / власти принять решение о переписывании старого кода. То есть, он начинает менять свое окружение (код) в то время как не имеет власти принять решение о его изменении (даже если он его перепишет, маловероятно что его изменения решат выпускать). В его силах только изменить отношение к нему. Смириться проще говоря :) А если серьезно, то вполне в его компетенции и власти выяснить список моментов и неудачных решений в коде, которые так его раздражают. Выяснив этот список можно просто сказать себе "я так делать не буду" - и это уже будет правильным проактивным действием. Более того, переписывать весь код ему не под силу, но "правило бой-скаута" никто не отменял. Никто не будет против инкрементальных изменений направленных на точечные улучшения конкретных моментов.

Главный момент о которым почему-то не говорят в корпоративной среде - проактивность означает работу исключительно над собой (и над тем, что ты в силах силах изменить), а не над окружением которое ты поменять не в состоянии.

Пример из жизни. Собрались мы как-то командой для обсуждения наболевших вопросов. Причем всех. План совещания был определить темы для следующих совещаний (да, так все плохо - проблем много :)). Каждый был достаточно воодушевлен и готов был общаться и совместно решать проблемы. Однако в ходе обсуждения один участник никак не мог найти общий язык со всеми остальными. Так как все были нацелены на продуктивную и плодотворную работу, все кидались к нему чтобы помочь понять и выйти на общий уровень общения. Он расценивал это как нападки и споры, и еще больше уходил в оппозицию. В результате мы потратили в 1,5 раза больше времени чем планировали и решили половину задач из тех которые должны были решить. 

Сама проблема отношений внутри команды к делу не относится. Интересно что было дальше. Часть участников резко понизили свое отношение к "оппозиционеру". Они говорили: "С ним невозможно вести диалог", "Он все время перебивает", "Он троллит нас", "Он не хочет приходить к общему решению". 

Другая же часть оценивала ситуацию по-другому: "Мы не слышали, что он хотел до нас донести", "Мы должны ему помочь с его новой зоной ответственности", "Нам нужно принимать во внимание его мнение, пусть оно даже нас не устраивает", "Мы должны дать ему понять, что он такой же как и мы, и мы ценим его так же, как и всех остальных".

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

Будьте проактивны - это интересно

Java: finally + return всё стерпит

Конструкция try-catch-finally в Java. Finally выполняется всегда. Это знают все. А что если в finally стоит return, а в try или catch случился exception? 

Вот такой примерчик. Предположим у нас есть наш собственный checked my.ArithmeticException которым мы оборачиваем стандартный unchecked ArithmeticException по каким-то своим причинам. Как-то так:

1. public int myDiv(int a, int b) throws my.ArithmeticException{
2.     int result = 0;
3.     try{
4.          result = a / b;
5.     }
6.     catch (java.lang.ArithmeticException arex){
7.          throw new my.ArithmeticException("Division by zero", arex);
8.     }
9.     finally{
10.         return result;
11.     }
12. }Syhi-подсветка кода

Запускаем. Для входных параметров 12345 и 0 (деление на 0) наш exception не бросается а результат операции равен нулю.

Что же произошло? Почему отработал return а не throws?

Разберемся, как работает JVM при выходе из метода. Выход из метода - значение на стеке. И throws и return занимают её место, когда работа метода завершается. В нашем случае, в стек сначала попадает throws my.ArithmeticException, затем начинает работать finally который кладет на стек return и перетирает наш exception. Он теряется. Навсегда.

Как это может быть полезно? Да никак. Если уж очень надо чтобы метод всегда завершал работу штатно (например) , обычно пишут catch(Throwable) в котором хотя бы можно залогировать проблему перед тем как ее игнорировать. Finally + return затирает ВСЕ (да-да, и OutOfMemory тоже) exception'ы и вы никак об этом не узнаете.

Наверное единственный правильный вывод к которому я пришел - не писать return в finally.

XML

Последнее время часто слышу недовольство XML.

1. Медленный (в смысле маршаллинга/де-маршаллинга)
2. Слишком низкое отношение сигнал/шум (то есть на каждое значение приходится пара тегов и/или аттрибут - а это все буквы/байты) для использования XML протоколов в сети
3. XML-валидация по факту не работает. То есть работает на стороне того, кто XML отправляет (можно сразу понять что хотим послать невалидный XML и что-то с этим сделать). На стороне же приемника XML-документа чаще всего в реальной системе нужно некорректные поля просто отбросить и обработать хотя бы то, что пришло. Чем просто падать - мол, входной документ невалиден и всё тут.
4. Слабое распространение XML схем в предметных областях. Например, в электронной торговле придумали FpML, который по идее должен был описывать все возможные варианты электронных сделок. По факту, всегда найдется какое-нибудь значение/свойство экзотического финансового инструмента, которое нельзя корректно положить в FpML - не хватает элемента или тэга. Простота создание XML схемы порождает сильное желание написать её самому, а не искать и разбираться в чужой. Как следствие, чуть ли не каждый финансовый институт добавляет собственное расширение FpML, и смысл единого стандарта теряется. 

Во всем этом безусловно есть смысл. Наверное, на пике XML-эйфории его стали бездумно пихать во все решения (см. Золотой молот) - и в конфиги, и в протоколы между высокопроизводительными приложениями, и в кодогенерацию, и да мало ли куда еще. Вот народ и "наелся" :)

Задачка про мальчиков

Еще одна задача. Такую не знал. Мне кажется ответ: 0,33.

Изначально расклад такой:

М+М

М+Д

Д+М

Д+Д

вероятность каждой комбинации 0,25. Теперь мы узнаем что один ребенок - точно мальчик. Вариант Д+Д отпадает. Остается три равновариантных ответа.

Режимы в пользовательском интерфейсе. Расширение функциональности или головная боль?

Режимы в пользовательском интерфейсе - зло. Это знают все, кто хоть немного интересовался дизайном пользовательских интерфейсов (и не только). Но иногда так соблазнительно добавить режим для того, получить такой же набор управления, какой есть уже, но с другими функциональными возможностями. 

Примеры:

Смеситель в ванной - имеющий переключатель "кран/душ". Бывает в двух вариантах - советском и современном. В советском варианте, вы рычагом переводили поток воды в другое русло. Проблема заключалась в том, что никто не запоминал, какое положение рычага отвечает за кран, а какое - за душ. Как следствие, если кто-то принимал душ, выключил воду и ушел, а вы собираетесь просто включить воду из крана - будете облиты водой из душа. Потому что "по умолчанию" вы ожидаете воды из-под крана, а никак не из душа. Проблема в режиме в котором находится кран и о которой вы (пользователь) никогда не помните. 

Современные краны имеют немного другой дизайн. Они сбрасывают положение рычажка (он уже в виде кнопки/гвоздя) как только вы выключаете воду. То есть, если вода не течет, то при включении воды она всегда пойдет из крана, до тех пор пока вы не переключите на душ. Эта концепция работает :)

Другой пример - пульт Logitech Harmony 555. Имеет 2 кнопки для перехода в режимы управления устройствами звука или изображения (т.е. усилителя или телика соответственно). Та же проблема. Включив режим "настроить звук" и настроив его - вы тотчас забываете что пульт все еще находится в режиме "настроить звук". Поэтому когда вы в следующий раз начнете им управлять - первые несколько действий он будет делать совсем не то, что нужно (как вода из душа на голову), пока вы не сообразите вернуть пульт из режима "управление звуком" в обычный. Решением было бы - возвращать пульт в обычный режим по тайм-ауту, но инженеры Logitech решили совсем от него отказаться и режимы в последней модели (Harmony One) убрали совсем. 

Вывод. Если очень хочется - режимы можно использовать, но только если иметь один "главный режим" и несколько второстепенных, из которых устройство возвращается в главный по таум-ауту.

Задачка про таблэтки

Мы очень любили эту задачку на интервью спрашивать. Чаще её почему-то девушки хорошо и быстро решали. Надо бы теперь что-нибудь другое подыскать...

Qcon 2010. День третий

С запозданием заканчиваю делиться впечатлениями от поездки на Qcon-London 2010. Кажется, что на третий день спихнули самые сомнительные доклады, чтобы так сказать не потерять аудиторию в первые два дня. А может и нет.

Создатель Erlang рассказывал про Erlang. :) Прикольный дядька оказался, говорил много правды :) В общем, всем идти расширять сознание и учить Erlang. Нет правда. Я уже пошел.

После обеда Ральф Джонсон снова вещал со своего высокого уровня сумрака абстракции о "шаблоне языка для параллельного программирования". Он и еще несколько гуру пишут книгу на эту тему, а университеты инвестируют в это направление. Короче, года через 2-3 (4-5?) можно ожидать новой модной тенденции в сфере параллельного программирования. Хотя с другой стороны чем им Erlang не угодил?

Последним докладом конференции, на котором я побывал, был доклад о тестировании производительности. Скажем есть задача инкрементального улучшения производительности или как минимум отсутствие в ней регрессии. Профайлинг для этой не совсем цели подходит, потому что требует много внимания и больших усилий. Остается постоянное сравнение "производительность предыдущей версии против новой". Имея в распоряжении список изменений, всегда ясно где искать регрессию (в случае чего). Так же ясно какие изменения дают наибольший эффект.

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

Ну вот и всё. Ждем Qcon в Сан-Франциско и, конечно, JavaOne!

QCon 2010. День второй

Второй день начался с презентации Ральфа Джонсона (да, того самого). Доклад показался мне слегка занудным и скучноватым - видимо профессоры в computer science на седьмом десятке переходят на 5й уровень сумрака такой высокий уровень абстракции, на котором понимать их становится тяжело. Тем не менее, пара мыслей мне показалась интересной:

• Капитал в ИТ смысле - это не только программное обеспечение, но и знание о том, как оно работает. Сразу вспоминаются слова "документация", "спека", "вики-странички", правда? )
• Признание кода "legacy" - расписка в собственной некомпетентности по отношению к нему. Когда не хватает знаний об используемых там технологиях или архитектуре (функциональной и инфраструктурной).
• Скоро программисты будут работать с программами, которые старше их самих. Прям мурашки по коже )

Следующий доклад был у другого апологета. Трек, который начинал Мартин, обещал быть малочисленным, поэтому комнату под него выделили маленькую. А послушать первый доклад пришло много. Как следствие - все полтора часа слушал на ногах, стоя в дверном проеме. Может быть поэтому, а может и потому что видеоряда не было (Мартин просто вещал в народ), доклад показался мне скучным. Несколько философских вещей, которые заставили задуматься (наверное еще что-нибудь напишу по этому поводу):

• Подумай, где ты работаешь - приносит ли это пользу людям. Становится ли от этого лучше планете.
• Женщины в ИТ - почему их так мало? Это ненормальное явление и с ним надо бороться. Правда, пока неизвестно как.

Секция "Программное обеспечение в 2015" привлекла меня парой докладов. Первый был о смартфонах. К моему удивлению, спрогнозировали на удивление мало. По сравнению с текущими устройствами, в их потомках появятся датчик температуры, давление, влажности (а оно надо?) и сенсоры (вроде распознаватели отпечатков пальцев - и в топку пароли!). Отметили зоопарк технологий на сегодняшний момент (альтернативные Java и С++, Object C), слабость фреймворков (нет MVC), неприменимость относительно удачных десктопных платформ (Gears, Air, Flash) на мобильных устройствах.

Еще в будущем нас ждет:

• производительность на смартфонах сравнимая с современными серверами (!)
• управление голосом, перевод "на лету"
• использование устройства как пропуск в здение, метро, как платежное средство

Короче, вполне закономерные и эволюционные вещи. Революция уже произошла.

Про программирование Java Virtual Machine рассказывал Alex Buckley. Это действительно огромный труд про написанию подобного приложения. Приводились примеры различных оптимизаций, которые JVM делает. Делается предположение, что JVM и дальше будет увеличивать свое влияние вплоть до "Universe VM". Уже сейчас можно (нужно?):

• юнит тесты писать на Scala
• бизнес-логику на Java
• вэб-приложения на JRuby
• конфигурационные скрипты на Jithon

Складно :)

Следующему докладу я посвятил отдельную запись.

В конце второго дня был доклад человека, который называет себя "упрощателя софта". Действительно, современные многозвенки иногда производят впечатление артиллерийской установки, бьющей по голубям на крыше. И голуби разлетаются и крышу разносит и люди страдают от осадков. Главный посыл когда проектируете многозвенку - "задумайтесь, оно надо?". Рекомендую посмотреть презентацию и/или видео, это определенно взгляд на многозвенки с другого угла.

[Sun] Tech Days 2010

Побывал на tech days 2010. Хотелось сравнить с прошлогодней, особенно в свете всеми известных событий. Ну и на Джеймса Гослинга хотелось посмотреть.

День первый

Пленарка обещала быть интересной: 0 будущем Java в Oracle должен был рассказать Сам. Но не рассказал. Вместо этого почти 2 часа нас снова пичкали JavaFX (доколе?). Половина докладов была один-в-один прошлогодние, что добавляло скуки. Один из топ-менеджеров Oracle, в задачу которого я так понимаю входило "завести" аудиторию, с ней не справился и скучно вещал ничего не обещающие утверждения о том, что "с Java в Oracle все будет хорошо, потому что мы ее любим и ценим". Единственное что было услышано мной в первый (и не последний) раз - о closures в JDK7. 

Затем я отправился в секцию Solaris, где название звучало как обещание озвучить roadmap для Solaris. Опустив "рекламу" (Solaris это надежность, масштабируемость и защищенность), я вынес главное утверждение доклада - в рамках Oracle будут развиваться и Solaris и Linux. Без расставление акцентов. Оба.

Дальше прослушал пару стендовых докладов. JetBrains рассказывали про TeamCity. Ничего нового не узнал. TeamCity быстр удобен и вообще мне нравится :) Потом предствитель OpenJDK (все тот же Sun) рассказывал как собрать OpenJDK самому. Мало что запомнилось, помимо того, что это непросто и займет часы.

После обеда Саймон рассказывал про скриптовые языки в JVM. Запомнилось "Выбирайте  язык исходя из поставленной задачи, JVM всё стерпит". И еще "создатель Groovy признался, что он бы не придумал Groovy, если бы в то время была Scala". Учить Groovy сразу расхотелось :)

Николай Иготти как и в прошлом году рассказывал про VirtualBox. Продукт определенно неплохой, попробую когда начнет поддерживать MacOS как гостевую систему.

В секции стендовых докладов рассказывали про Sun Java Realtime System. За 20 минут успели рассказать что из себя она собственно представляет, но ничего нового я не услышал. Была отличная статья на английской про Java RTS, но ссылку не помню. Сановская реализация сейчас основана на JDK 5 и работает на всех Solaris и на real-time kernel Linux.

День второй

На второй день слушать про JavaFX на пленарке не было никакого желания, поэтому я выбрал сон :). А день начался со стендовых докладов. JetBrains рассказали что эксперимент с бесплатной IDEA был признан успешным, что они дальше будут портировать больше функциональности из платной версии в бесплатную. Еще сказали что дальнейшее развитие видят в минорных вещах, крупный функционал уже сделан. Порадовали проектом IDE для разработки под IPhone. Давно пора :)

Доклад о новых фишках в JDK7 ребята из Sun рассказали неплохо. Спровоцировали пару холиваров и блестяще их парировали пригласив всех в онлайн конференцию по JDK. А вообще, здесь описано лучше и объемнее чем это могу сделать я.

В секции Solaris рассказывали про "многоядерный мир" и как в нем следует разрабатывать приложения (для Solaris, конечно). Было неинтересно, я запомнил только что нужно использовать специальную солярную функцию для выделения памяти, а не malloc.

JetBrains хвастались о MPS. Штука интересная, непростая и наверное полезная. Осталость только придумать где бы ее применить да еще при желании не ломая старое, а встраиваясь в него. С последним пока непонятки... Задумался, является ли Google Protobuf MPS или нет.

Снова Sun рассказывал про новый сборщик мусора как и в прошлом году. В этот раз доклад был менее информативен в технических деталях, а потому зацепил не очень. Главное, (в чем я почему-то заблуждался) это то, что Stop-the-world пауза вызывается для сборок и молодого и старого поколений, хотя сами поколения для G1 достаточно условны. Пообещали что в JDK7 будет стабильная версия. Хотя у меня и теперешняя не падала (ну разве что в IDEA).

И напоследок был интересный доклад про "внутренности JVM". То есть, я думал, что он будет про внутренности. А нам рассказали про оптимизации, которые JVM делает во время JIT компиляции в runtime. Давно хотел это услышать из первых уст. Заниматься микро оптимизациями (вроде замены StringBuffer на StringBuilder) расхотелось совсем. У JVM всё равно получится лучше. Главный посыл - писать код как все, как рекомендуют гуру и лучше не изобретать велосипедов. Потому что JVM оптимизаторы тренируются на похожем коде библиотек, которые все используют.

Ну а дальше были выходные с отличной и нехарактерной для Питера солнечной погодой...

Архитектурные качели

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

Идеальное слабое связывание - набор компонент, которые ни от кого (кроме себя) не зависят. :) Утопия. Как только 2 компонента начинают иметь общий функционал, этот функционал выносится в отдельный компонент. Эта итерация повторяется до тех пор пока каждый компонент не начинает исполнять свою уникальную задачу. Казалось бы, все хорошо. И связывание слабое и повторное использование максимальное. На деле всё не всегда так. Операцию по выделению дубликатов можно проводить очень долго, спускаясь по уровню декомпозиции все ниже и ниже. В результате может получится "экономия на спичках" когда небольшой и простой функционал (например логирование) выделяется в отдельный компонент, который после выделения становится чрезвычайно негибким в плане изменений и настроек под конкретный компонент, который его использует.

Поэтому качели "слабое связывание <-> повторное использование" должны оставаться в равновесии, без перекосов.

Qcon 2010. День первый

Вводное слово было у Роберта Мартина, который видимо был призван задать позитивный настрой на все три дня конференции. Собственно, у него это получилось. Роберт с такой американской экспрессией рассказывал, как надо писать хороший код. Нового почти ничего не сказал, все те же прописные истины:

• Функции - небольшой размер (1-4 строки - это нормально, больше - уже много :) )
• Аргументы функций - в идеале 0. 1 нормально, 2 уже плохо, а 3+ вообще беда. Особняком стоят аргументы boolean - их вообще быть не должно (2 метода с двумя вариациями в названии замен)
• Имена - чем больше видимость тем длиннее имя
• Классы - 200-300 строк, 10-30 методов, 0-6 полей
• тесты, продолжающаяся интеграция, парное программирование

Узнал, что моя обычная практика при внесении изменений в код (затронул класс - пофикси в нем все косяки которые там есть), затронул пакет - если есть что в нем улучшить - улучши. Эта практика небольших инкрементальных улучшений в "бэкграунде" - оказывается называется "Boy Scout Rule". Блин, может я еще что-то делаю, что как-нибудь прикольно называется, а я этого не знаю? :)

Еще новое слово, которое похоже будет все чаще звучать - Craftsmanship. В манифесте собственно все сказано, идея мне нравится, буду пользоваться.

В общем, было весело :) Запала хватило на весь день :)

Дальше я пошел в секцию функционального программирования на два доклада. Послевкусие после них оказалось не очень. Первый как будто бы рассказывал о функциональном программировании вообще, но по факту как-то больше о Scheme. Понравилась пара определений: функций (еще один тип данных) и замыканий (функции с их собственным локальным окружением, неизменяемым извне).

Второй доклад был больше о функциональном программировании в контексте параллелизма. По факту - о F# и о том, насколько лаконичнее в функциональных языках синтаксис. Презентация была достаточно информативна, правда ничего выделить не могу.

Интригующее название "The Craftsman Learns" заставило меня пойти на этот доклад после обеда. Докладчик сразу расположил к себе тем, что был босиком :) Узнал много нового:

• Учиться это как плыть против течения. Если ты не плывешь вперед, тебе кажется что ты стоишь на месте, но по факту ты движешься назад
• Спрашивать 5 раз "почему? зачем?" над каждой непонятной вещью
• Проговаривать вслух вещи над которыми раздумываешь. Рассказать мучающую тебя проблему коту или мягкой игрушке - это может помочь не только сформулировать вопрос, но и тут же ответить на него :)
• Думая над логическими/рациональными вещами, подключать нерациональную (правую) часть мозга - рисовать, говорить, дрыгать ногой :)
• Делиться тем, чему сам недавно обучился - это поможет самому лучше понять (как в том анекдоте)
• После изучения теории нужна практика. Причем внимательная и вдумчивая (я часто грешу одной теорией)
• Ментальные карты - я даже на iPhone скачал приложение, которое их рисует. Чувствую, что такой техники мне не хватало, частенько бумажки просто исписаны без какой-либо структуры. С другой стороны возникает ощущение структурирования неструктурированного - то есть усложнение непонятного :)

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

Не могу не отметить веселую презентацию. Рекомендую посмотреть.

Про отношения разработчиков и специалистов по развертыванию и сопровождению (людей следящих за системами в работе, следящих за ними, отвечающие за их работоспособность, горячую замену, системные апргрейды, окружающую среду и т.п.) я послушал в 15.00. Ходил собственно чтобы послушать, насколько в Дойче все плохо. Оказалось, что в Дойче всё замечательно. Ну или не всё. Но на твердую четверку. Итак, чего не хватает до пятерки:

• отделять конфиги от бинарников (у нас не везде)
• сделать конфиги легкодоступными для просмотра
• проверять конфиги (имеется ввиду на рабочих станциях перед релизом)
• показывать значения всех конфигов (значения по умолчанию, даже если они в коде)
• failfast - быстропадающее приложение. Оно должно падать как можно быстрее, если конфиг некорректен

Больше всего в первый день я ждал доклада про Skype. Рассказывал молодой парень с таким прикольный акцентом. :) Оказывается Skype это:

• С и С++ в ядре и транспортном уровне
• Delphi (c ума сойти!) в интерфейсе для Skype клиента
• PHP на сайте и онлайн-магазине
• Postgre - БД и около нее

Лейтмотив автора был "функциональной архитектурой должен кто-то заниматься". И "всё гениальное - просто". Больше он ничем не запомнился.

Так закончился первый день. Доклад "мамы Smalltalk" я в расчет не беру - он был уже после пива. Главное, что запомнилось из него - все крутые вещи были придуманы в 70х. Просто тогда у них железа нормального не было :)

Новые программизмы

Сегодня на тренинге от IBM услышал пару новый программизмов:

"Green field environment" - это когда ты разрабатываешь новый проект, а все вокруг/около него гибко / еще не создано / готово к изменениям. Иными словами ты можешь его изменять как тебе угодно.

"Brown field environment" - свой проект ты вынужден "встраивать" в среду которая недружественна к изменениям. То есть скорее ты изменишь свои требования к окружению, чем оно измениться по отношению к твоим. Говенный энвайромент, короче :)

"Gold hammer solution" - когда у тебя в распоряжении есть решение, сработавшее достаточно хорошо пару/несколько раз. И ты начинаешь с помощью него решать все последующие задачи (разбиваешь своим золотым молотком проблемы "в лоб"). Иногда мне кажется, что трехзвенка самый яркий пример такого "золотого молота" :)

Быстро, много и без задержек. Java (?)

Доклад о том, как построить приложение на Java, способное обрабатывать большое количество транзакций в секунду с минимальной задержкой (latency). Авторы построили электронную торговую площадку (родственную Betfair) на основе Java и делятся опытом.

Итак, как осуществить больше 100К+ сложных бизнес-транзакций за время, меньшее 1 миллисекунды.

За транзакцию принимается следующая последовательность:

1. вставка ордера в движок
2. матчинг (с одним или несколькими контр-ордерами)
3. генерация отчетов о сделках
4. их передача в сокет

Зависимость заточки кода под производительность от требуемого количества транзакций:

• 10K+ transactions per second - если не делать глупый вещей
• 100K+ TPS - если придерживаться стандартный библиотек (в смысле не использовать транжирные третьесторонние) и иметь хороший "чистый" код
• 1M+ TPS - пишем собственный кэш для больших объектов, имеем хорошие тесты для измерения производительности, контролируем сборщик мусора (нет лишнему мусору и тюнинг GC параметров), заточенная под скорость архитектура

Архитектура высокопроизводительного приложения (типа exchange :))

Receiver принимает сообщение от клиентов (протокол общение - FIX)

Replicator дублирует поток данных на запасной сервер

Journaller сливает все тот же поток на файловую систему

UnMarshaller парсит сообщения

Business Logic собственно matching engine нашего рынка

Marshaller генерирует execution reports

Publisher отправляет репорты в сеть

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

Слева и справа от бизнес-логики - это входные и выходные буферы соответственно. Просто большие циклические байтовые массивы. Replicator и Journaller используют входной буфер в режиме "только-для-чтения", а Receiver и UnMarshaller - читают и пишут. Receiver - то что получил из сети, а UnMarshaller - то, что распарсил. Видимо, внутренний протокол LMAX гарантирует, что во внутреннем представлении сообщение поместится в тот же место, в котором размещалась закодированная копия.

Business Logic читает из буфера самое старшее сообщение, обрабатывает его и пишет результат в выходной буфер. Где его затем подхватит Marshaller и запишет уже в виде сообщения внешнего протокола. Которое будет отправлено в сеть Publisher'ом.

Такая архитектура позволила добиться порядка 90 микросекундной обработки одной транзакции при 100К+ TPS.

P.S. Рекомендации от авторов

• fastutils для коллекций в целом и хэш-таблиц в частности
• 29West как транспорт
  

P.S.S. LMAX = London Multi-Asset Exchange. То же что и Tradefair

Задачка про груши

Решил задачку про груши (ответы не видел, так как читал по RSS). Один из вариантов:

1111

1100

1010

1001

Рефакторинг как способ осознания кода

На внутренней конференции один наш высокий управленец (топ-менеджер) в сердцах сказал: "У нас в команде ХХХ каждый новый лидер заявляет что код никуда ни годится и нужно все переписать. С начала. Так уже раза 3 было. С каждым новым лидером. Ничего существенного в плане бизнес-функций добавлено в это время не было". Все посмеялись.

Я сразу вспомнил то, что я называю стадии "взросления программиста в проекте". Вот новый программист приходит в проект. Предположим, он достаточно молод (до 7 лет промышленной разработки).

1 стадия - разработчик знакомится с кодом и восклицает "что за хрень тут понаписали!". Ему хочется все переписать, он даже начинает прикидывать как он это сделает.

Но задачи нужно решать, время идет и все переписывать никто не даст. Приходится материться и жить с тем, что есть. Когда решена пара поставленных задач, наступает

2 стадия - разработчик перестает хныкать и жаловаться на несносность кода вслух и местами даже начинает его хвалить ("хм, а вот тут неплохо было придумано"). "Ну не идиоты же его писали, такие же как и я" - и такие мысли тоже появляются. Желание переписать все еще сильно, разработчик даже составляет диаграмму компонентов и классов и расписывает текущий функционал по ним. В процессе создания такой диаграммы разработчик детально знакомится с текущей архитектурой и тут незаметно наступает

3 стадия - "В принципе далеко неглупые люди это сделали". Оценив свои будущие временные затраты на перепись и оригинальные архитектурные решения старого кода, программист всерьез задумывается о смысле. Жизни. Если он решается на перепись, то по прошествии времени вернется к стадии 1. Потому что не повзрослел. Когда повзрослееь, его ждет

4 стадия - "Смирение". "Понятно что здесь не все идеально, но это уже очень долго работает. Причем неплохо работает." Разумный выход конечно - переделать то что плохо. Но не то, что плохо написано, а то что плохо работает.

Думаю так. Да. Надеюсь что до 4й стадии скоро доберусь :)

23 янв 2010