There is a production web application based on Ruby on Rails codebase and infrastructure parts such as PostgreSql and Elasticsearch. I guessed that a solution based on Ruby on Rails is too problematic for using in production. To mitigate the problems I designed and dedicated Layered parts (DAO, Service, Application, Presentation). I also implemented "validation module" that lets performing type safe method calls. My another improvement was a set of tools for validation of preconditions (I mean "design by contract" approach). So, seems that's it.

A potential customer came to our company with a production application that has been implemented using PowerBuilder. The Application was implemented in a complicated way that is why support and extension of it was too expensive. So that App had to be ported to a modern platform with new approaches. I was one of those who spoke with the customer before the actual coding started. At that time we prepared technical documentation about the new architecture and started our implementation. The architecture was "service oriented" (SOA) with dedicated layers: DAO Layer, Service Layer, Presentation Layer (Spring, JPA, RestEasy). Infrastructure parts: Microsoft SQL Server, JBoss. Since then team has grown up and the customer has started new projects with SumSolutions.

1. Координация технической части разработки плагина для Jira. Плагин представляет из себя сегмент функциональности, для внутреннего корпоративного менеджмента сотрудников и статистических данных. Плагин был успешно спроектирован и запущен, и используется в настоящее время. 2. Развертка платформы для портирования проекта http://ur.hh.ru на новый стек технологий, а именно, была выстроена послойная архитектура с использованием технологий: java, spring, jpa2 (hibernate) и play. После разветки платформы проект передали другим разработчикам для непосредственного портирования функциональности. 3. Также принимал участие в разработке основного продукта: http://hh.ru Вынесенный опыт: 1. При недостаточной квалификации команды лучше разделение на слои системы делегировать maven. Тогда, у разработчиков гораздо меньше возможностей писать код "не туда". Иначе идет размытие слоев (вплоть до написания нативного sql в презентешн слое), и в итоге непонятно где искать заданную функциональность, так как бизнеслогика размазана по всему проекту. 2. Необходимо явное выделение менеджмент слоя, в котором необходимо сосредоточить CRULD операции с источником данных. 3. Если позволяет квалификация команды, то лучше, опять же с помощью maven выделить доменную модель в независимый базовый модуль, без источника данных и сосредоточить всю бизнес логику именно в доменной модели. Это позволяет писать тесты на бизнес логику, используя классы без контекста источника данных. 4. В распределенной системе стоит искать пути для реализации отдельных модулей системы с независимым источником данных и более выделенной областью ответственности, вместо централизованного использования кластера БД с распределенным кешем. В идеале, каждый модуль должен четко очерчивать свою часть работы и работать с соответствующими данными исключительно монопольно.

Проект представляет из себя web сервер с использованием базы данных PostgreSql. Работа с источником данных реализована через JPA. В проекте используется spring framework. Используется тонкий ui слой основанный на Wicket. Бизнес логика завернута в доменную модель + тонкий application слой, используемый для посылки сообщений. Все вызовы ui транслируются в application layer либо в доменную модель, что позволило реализовать acceptance тесты в виде скриптов, которые также делегируют к доменной модели и аппликационному слою. Реализован импорт справочных данных (xml, xsd), если в xml есть данные которых еще нету в системе, они сначала высасываются в pojo, они же jpa объекты, после чего персистятся в базу данных. Также реализована видимость ui компонент в зависимости от состояния пользователя через AOP. Вынесенный опыт: 1. Освоено OOP, OOD. 2. Освоены AOP, JPA, работа с xsd. 3. Debugger очень спорный инструмент. Если принципиально им не пользоваться, то будет развиваться правильное логирование, а код будет требовать читаемости. 4. Работа с доменной моделью требует более высокой квалификации чем система с бизнес логикой зашитой в аппликационном слое, зато при правильном проектировании система с доменной моделью в разы компактней и понятней. 5. JPA: желательно до реализации определить, что важнее, более гибкая доменная модель, или производительность системы. От этого зависит выбор стратегии наследования в конкретных узлах. 6. JPA: хороший дизайн доменной модели совместно с активированным hibernate кешем позволяет добиться очень высокой эффективности в работе с БД. 7. Wicket: правильный дизайн компонентной базы, позволяет свести к минимуму написание разметки, а именно - только в базовых компонентах.

Участвовал в развитии проекта СмартАСР (http://www.smartasr.ru/). Биллиговая система, клиентами которой являются половина региональных ТрансТелеКомов, а так же ряд других клиентов. Система Представляет собой Web сервер с поддержкой части бизнес логики через web сервисы, с импортом и экспортом данных. Имеет место интеграция с федеральным ТТК, а также с несколькими сторонними сервисами. Поддерживаемые базы данных: PostgreeSql, Oracle. Самописный фрейворк для работы с базой данных. Вынесенный опыт: 1. Работа с фреймворком spring. 2. Плюсы послойной архитектуры приложения. 3. Освоен git. 4. Оттачивание принципов OOD. 5. Работа с SOAP сервисами.

Проекты: IT2ME (позднее куплен как успешный более крупной компанией: http://www.comettrackerweb.com/). Треккер, отслеживающий перемещение gps устройств с возможностью посылки sms. Сервер - система на java c web интерфейсом, базой данных и фоновыми процессами. БД — mysql. Приложение реализовано на Сервлетах и JSP. Для фоновых процессов использовался quartz. Вприложении использовался самописный фреймворк branexplorer, который собственно и включал в себя фоновые процессы, и генерацию UI (html) для данных из базы. UI включал в себя представления (таблицы) и операции над данными этого представления. Существенные действия и вынесенный опыт: 1. Был развернут тестовый фреймворк и приложение удалось более или менее стабилизировать. Легаси системы очень нуждаются в тестах, в случае их развития и поддержки. ОГБД Ветераны (http://www.developmentontheedge.com/about_ogbd.shtml.ru). Централизованная база данных ветеранов России. Сервер - на branexplorer. Существенные действия и вынесенный опыт: 1. Пользуясь случаем автоматической генерации UI, было реализована автоматическая генерация UI-ных тестов (через http unit). Пункт меню, проверялся вручную, делался вывод, что он работает корректно, и натравливался инструмент генерации. Инструмент парсил все представления этого меню и операции и генерировал код теста. 2. Лень двигатель прогресса :). Нужно не лениться и автоматизировать все, что можно автоматизировать. 3. Правильная работа с исключениями. TISNSO (http://nso.tisnso.ru/). Единое окно государственных услуг. (ЖКХ, ФСС, ЗАГС и т.п.) Сервер - на branexplorer. Так-же тамошним архитектором была предпринята попытка написать универсальный движок импорта. Вынесенный опыт: 1. Невозможно написать универсальную систему на все случаи жизни. Чем более универсальна система, тем хуже она решает конкретные задачи. Зато можно создавать расширяемые системы и у каждого компонента должна быть строго ограниченная область ответственности и не более.

На языке С++ с использованием stl был написан драйвер для системы тепловизоров предназначенной для доменной печи. Функциональность: построение интерактивной карты температур. Также была написана расширенная хранимая процедура для MS SQL Servcer для статистической постобработки собранных данных. Вынесенный опыт: Автоматическое тестирование сильно экономит время, особенно для проектов с не полностью формализованным ТЗ.