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

Сегодня на тренинге от 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

Что я не напишу в своем резюме

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

Итак, чего не надо делать в своем резюме (ИМХО):

1) Писать желаемую ЗП
Это очень провоцирует интервьюеров. Если вы себя переоцените - вас не возьмут просто потому что вы себя "перехвалили" и от вас ожидали большего. Если вы себя недооценили, а вашими результатами довольны - интервьюеры будут сомневаться, что же это они так вас переоценили выше вас самих. Или вас просто возьмут на меньшие деньги.
Если вы свою цену знаете, интервьюеры ее тоже знают (в случае вашего успеха), тогда зачем её писать? :)

2) Ставить список технологий после мест работы
Очень утомляет листать вниз и искать "что собственно этот человек умеет делать, в каких технологиях разбирается". Технологии, которыми вы владеете, надо писать сразу после контактных данных и образования. И, конечно, не начинать с Операционок и MS Office :)

3) Разбивать время работы в одной компании на несколько периодов на разных должностях
апрель 1994 - н.в. ООО "МММ". Старший помощник младшей технички
май 1993 - апрель 1994. ООО "МММ". Младший помощник старшей технички
Конечно, иногда хочется подчеркнуть быстроту своего карьерного роста :) Но его и так будет видно исходя из разниц позиций на прошлой и текущей работах.
Написав по одному временному интервалу для каждой работы, будет видно сколько человек обычно на ней задерживается и это удобно.

4) Упоминать название проектов вместо их краткого описания
И вообще, если название вашего проекта нельзя нагуглить - не пишите его.

5) Перечислять пройденные курсы и тренинги
Если только они не заканчивались настоящим экзаменом. Всегда задаюсь вопросом - что человек хочет этим сказать? Что он умело продает навыки данные им на деньги другой компании?

6) Помещать фотографию
Ваша фотография ничего не скажет интервьюеру о ваших профессиональных навыках. Зачем тогда ее размещать?


Ну вот как-то так. Приходите к нам на собеседования :)
22 дек 2009