Batch operation with Apache Camel

This is a small post of how can we organize batching in apache camel 2.8.0.

Given

Apache camel version 2.8.0. Hot higher because it's production restriction so far.

A list of pojos as input

A csv file as output

Test

Camel allows to advise producer endpoints with mocks, look at setup method. Starting from camel 2.10 mocking can be done with annotations. MockEndpoint provides flexible expectation and assertion mechanism

Implementation 

Spring context

By default split output will be the same as input. Developer can change this behavior by adding AggregationStrategy like:

In camel AggregationStrategy always receives null in oldExchange for the first record in batch. All subsequent batch records will be accumulated in oldExchange by appending String with record from newExchange. Aggregation executed after all transformation in split closure body.

Definition body within split tells camel to drop input list of pojos into single elements and pass them in subsequent csvRowFormatter processor.

CsvFormatter

It's pretty simple. Extract pojo from camel exchange, format csv from it and push it back into exchange.

Conclusion

Camel provides flexible mechanism for building routing engines. It allows to build batching as well. For full version of example refer to github

This post was created mostly like a reminder.

Разработка через тестирование. Организовываем Додзё

Сегодня в Luxoft UBS DC удалось организовать двухчасовую сессию посвященную TDD и coding dojo практикам.

Было минимум теории. Благодаря SmartBoard удалось достичь максимальной вовлеченности участников.

Всего было 8 человек, каждый успел побывать в роли pilot и copilot. 

Тренировались на кате Game Of Life

К сожалению мы не успели закончить полностью, закончили лишь на 80 - 90 % реализации.

Зато провели ретроспекцию, что очень важно в такого рода мероприятиях.

Среди недостатков отметили отсутвие дизайн сессии и работы у WiteBoard. Кроме того специфика Dojo привнесла некую сумбурность в процесс, потому как приходилось каждые 7 минут ротировать участников.

Однако, всем понравилось, и все изъявили желание продолжать проведения такого рода мероприятий, что скорее всего приведет к образованию KievGojo.

Для тех кому интересна эта тема предлагаю посмотреть пятиминутный ролик о том как организовать подобного рода мероприятие. А также добро пожаловать на сайт энтузиастов coding dojo.

В дальнейшем планируется провести ряд практических и теоретических сессий по методологиям, инструментам и подходам к написанию тестов.

Пока все.

Investigation through the testing

Я заранее прошу прошение у читателя за обилия терминологии на английском, просто иногда трудно перевести на русский, да и стоит ли переводить?

Я уже полтора года работаю в условиях Agile а именно по Scrum методологии. причем мы проповедуем Large Scale Distributed Scrum. У нас порядка 8 команд распределенных по всему земному шару, которые работают над одним продуктом и в одном codebase.

Пару спринтов назад к нам поступила в работу User Story которая требовала дополнительного технического исследования перед планированием и оцениванием трудозатрат для реализации. К сожалению сценариев еще не было готово поэтому Specification by Example, которые потом практически безболезненно ложатся на интеграционные или функциональные тесты, мы сочиняли параллельно исследованию. Решено было попробовать описать сценарий интеграционным тестом который бы покрывал один из пунктов Spec by Example.

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

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

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