Обратная связь

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

пятница, 18 июля 2014 г.

Command and Query Responsibility Segregation (CQRS) на практике

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

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

суббота, 17 мая 2014 г.

IT-образование в ВУЗах

Окончился очередной учебный год в университете. Ниже будет мой отчет по работе на IT-специальности. Возможно кому-то тема обучения в ВУЗе близка, буду рад вашим комментариям и замечаниям, идеям как можно сделать лучше.

На данный момент у меня 4 года опыта преподавания в ВУЗах. Первые 3 года вел ООП и Технологии программирования у 4-го курса на кафедре Информатики в ЮУрГУ. Этот опыт я уже описывал в статье Обучение IT-специалистов в университете. Текущий год я провел на ВМИ в ЮУрГУ и эпизодически в ЧелГУ на нескольких лекциях.

понедельник, 12 мая 2014 г.

Переход от монолитной архитектуры к распределенной

Последние 2 года большая часть проектов моей компании - это унаследованные системы. Я уже писал, что это за системы, какие риски возникают при работе с такими системами и каким образом проводится анализ. Интересно, что все эти системы имели монолитную архитектуру, которая была основной проблемой на пути к горизонтальному масштабированию. Для меня было вопросом как и почему получается монолитная архитектура? Как избежать такого подхода?

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

воскресенье, 2 марта 2014 г.

IT-конференции на ближайшее время

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

пятница, 24 января 2014 г.

Приемочное тестирование как производственная необходимость

Все программисты — оптимисты. Возможно, эта современная разновидность колдовства особенно привлекательна для тех, кто верит в хэппи-энды и добрых фей. Возможно, сотни неудач отталкивают всех, кроме тех, кто привык сосредоточиваться на конечной цели. А может быть, дело всего лишь в том, что компьютеры и программисты молоды, а молодости свойствен оптимизм. Как бы то ни было, в результате одно: «На этот раз она точно пойдет!» Или : «Я только что выявил последнюю ошибку!»
"Мифический человеко-месяц", Ф.Брукс

Не сосчитать сколько раз я сам и мои коллеги спотыкались о проблему, описанную Бруксом. В последнее время появилась полезная привычка остановиться и подумать над тем, что делаешь. Не как раньше кидаться на проблему с шашкой на перевес. Видимо 7 лет в разработке ПО наталкивают на новые схемы восприятия проблем. Хочу, чтобы этот пост был маячком, который заставит вас в нужный момент задуматься о том, как сделать правильно, без спешки.

Я выбрал 3 задачи из практики, с которыми скорее всего сталкивался каждый разработчик. Многие разработчики делали эти задачи и ленились, как и я, сначала придумать как измерить успешность задачи. До начала надо ответить на вопрос: "Как я могу узнать, что сделал всё правильно?". Обо всем по порядку.

вторник, 14 января 2014 г.

Integration Patterns: Shared DB, state machine и очередь сообщений

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

среда, 8 января 2014 г.

Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы

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

Сейчас я хочу рассмотреть более общий вариант работы со старыми или плохоработающими системами. Хочу дать ответ на вопрос: Что делать, если вам досталась в работу legacy system? В статье я буду использовать термины legacy system (унаследованная система) и legacy code (унаследованный код).

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

пятница, 27 декабря 2013 г.

Integration Patterns: Репликация и очередь сообщений

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

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

Сложность была в том, чтобы достаточно быстро обрабатывать большие объемы данных. База данных проекта размером порядка 700 ГБ, среднее количество записей в основных таблицах около 100 млн.

понедельник, 16 декабря 2013 г.

Определения провала IT-проекта

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

"Мифический человеко-месяц", Ф.Брукс

Хочу поделиться обобщением историй от заказчиков IT-проектов, с которыми мне удалось пообщаться и поработать. Эти истории очень похожи, а значит из них можно научится, сделав нужные выводы.

Так получается, что в мою компанию приходят проекты, у которых прошел первый deadline, прошел второй, инвесторы в отчаянии, проект готовы выкинуть и признать провальным. Мы вытащили не один такой проект.

четверг, 10 октября 2013 г.

Проекты моей компании

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

  • Высоконагруженные приложения
  • Облачная инфраструктура (AWS, Azure)
  • Data mining

Основные технологии:

  • .NET Framework
  • JavaScript (SPA)