вторник, 10 сентября 2013 г.

Куда нас ведет "общий код" или как реализовать бизнес логику в сложной системе



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

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

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

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

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

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

Сейчас объем кода, который делается по старому, т.е. не в гемах в десятки раз превышает объем кода, который делается условно правильно. Это говорит о том, что даже тот путь, который "как бы" выбрали не приближает нас к цели. Так зачем мы интерсно по нему идем? Мучаем наших заказчиков и мучаемся сами, не понятно.

Давайте подумаем, какие есть еще варианты. Это далеко не решение, это мысли на тему.

"Свобода рождается в ограничениях" (с)

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

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

Как быть с задачами, которые должны использоваться на всех проектах? Есть вариант реализовывать примерно такую структуру: работа с общими данными реализуется через веб-сервисы, которые изолированы и умеют работать только со своими данными и практически ничего не знают о других частях системы. Вся бизнес логика живет в проекте, данные предоставляемые этими сервисами.

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

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

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

Надо исследовать и надо время на подумать. Взять, например, отзывы Близко и попробовать на их примере построить веб-сервис + портальную часть для его использования. Попробовать варианты, посмотреть, как они будут работать.

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

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


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

Возможно, есть другие решения, было бы интересно выслушать ваше мнение.

понедельник, 14 ноября 2011 г.

Работа на результат или мини-заметка о качестве

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

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

Все врут, врут заказчики, когда говорят, что требования НИКОГДА в этом месте не изменятся и мы точно делаем так. Потому что они уже немного ориентируются в наших решениях и знают, что если они скажут иначе, то срок возрастет в разы...ну или иногда ладно, они искренне полагают, что требования не изменятся.

Врут менеджеры, когда говорят, что нам на 5 дней осталось всего 5 задач по дню, фигня война, прорвемся. Они то знают, что осталось еще 10 задач и 50 ошибок =)

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

Зачем я все это говорю? Да затем, чтобы показать, что не надо полностью зависеть от окружающей информации. Успеха добивается тот, кто идет своим путем (правильным желательно ;).

среда, 12 октября 2011 г.

Web development TO-BE


"Есть только один способ проделать большую работу — полюбить ее. Если вы к этому не пришли, подождите. Не беритесь за дело. Пусть сначала сердце подскажет его вам." (с) Steve Jobs

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

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

Проблемы, которые мы будем бороть описаны в предыдущей публикации: Web Development And Internet AS-IS


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

Цитата:
"есть еще такая вещь, на которую если посчитаешь нужным обрати внимание. я считаю у нас очень низкий уровень проработанности задач поступает от заказчиков. (эти файлики которые они посылают на почту и которые мы читаем на планировании. в результате оценка превращяется в коллективное чтение и обсуждение, если задача более менее сложная её оценка, часто ставится на основании интуиции и опыта + %"
Здесь, по сути, отход от методологии SCRUM, последствия, мне кажется, тоже очевидные.

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

Поехали.

Структура

В структуре подразделения должны быть следующие роли, они реализуют матричную структуру, к которой мы неизбежно идем при увеличении количества людей и проектов:

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

Почему именно матричная структура? Для нас важны такие ее качества как:
- Распределение знания о системе в нескольких головах
- Отсутствие перегрузки людей, через которых проходит аггрегированная информация
- Но при этом остаются люди, которые могут держат в голове всю картину происходящего, но уже на более абстрактном уровне, без перегрузки деталями

Картинка получается следующая:


Теперь давайте разберемся, как всё это работает.

Менеджерская составляющая должна разделиться на две сущности: продуктовую и техническую.

Продуктовый менеджер работает на уровне требований, его задача постоянно держать связь с заказчиком и готовить своевременно требования к началу следующего спринта. Он следит, чтобы требования появлялись не в день планирования спринта, а как положено за 3-5 дней, в зависимости от сложности задачи. И не говорите мне, что это не возможно :) Стоит один раз поднапрячься и день сдачи требований уже будет плановым для заказчика, а не pain is the ass, как сейчас. Продуктовые менеджеры контролируют соблюдение методологии SCRUM и в случае необходимости прибегают к помощи продуктового директора. Продуктовые менеджеры рисуют прототипы в Axure и всячески помогают заказчикам в разработке требований.

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

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

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

Сейчас по факту менеджеры очень часто уступают заказчикам, что приводит к неполноценным тз, сдаче требований в день перед спринтом и прочим мелочам, которые сбивают весь цикл разработки. Продуктовый директор должен иметь полномочия не принимать задачу в разработку, если она не соответствует требованиям, с другой стороны он так же должен приложить все усилия, для минимизации этого. Это важный момент! Задача состоит не в том, чтобы зарезать требования заказчика (хотя ох как хочется :), а том, чтобы их максимальное количество вовремя и правильно описанными попали разработчикам.

Технический директор управляет взаимодействием тимлидов. Он отвечает за показатели качества системы: надежность, производительность, доступность, отсутствие ошибок. Он организует технологические процессы и контроллирует их: процесс деплоя, процесс обновления ПО серверов, выпуск Hotfix'а и т.д. Он участвует во всех обсуждениях тимлидов и может, при необходимости заменить любого из них, хотя бы частично, хотя бы встать на помощь продуктовому менеджеру, который лишился своего напарника-тимлида.

Поддержка

Она же support. У поддержки цель: обеспечить качество системы. Две основные задачи: рефакторинг/оптимизация и правка ошибок.

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

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

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

Еще раз повторюсь, что в поддержке должны быть несколько разработчиков, которые составляют ее ядро, они не меняются во времени и занимаются только поддержкой.

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

Поддержка занимается hotfix'ами, т.е. исправляет ошибки, найденные на продакшене. Это важно и принципиально, потому что поможет не отвлекать команду разработки, которая уже занимается следующим спринтом. Из данного утверждения следует еще одно: тимлид поддержки при приеме релиза на поддержку, должен всеми средствами удостовериться в том, что ему передают код без ошибок, и который держит нагрузку, иначе потом придется много работать :)

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

Тесты и тестирование

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

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

База знаний и передача задачи из разработки в поддержку

База знаний - это некое хранилище документов, прочитав которые, можно получить знание о:
- Архитектурных решениях
- Технологических процессах разработки
- Сложных функциональных частях системы
- Посмотреть требования подготовленные продуктовыми менеджерами

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

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

Примером документов могли бы быть (эх, где вы, эти документы): описание системы кеширования, описание работы с очередями, описание работы с bg_executor и т.д.

Деплой

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

Битва за людей

Честно говоря от чего пытались при помощи SCRUM уйти, к тому опять и пришли, перестав следовать его методологии.

Важно добиться того, чтобы не было ситуации, когда с одним человеком работает несколько менеджеров. Ситуация, когда человек поработал 2 дня на один проект, а остальное время у него как бы идет спринт по другому, ужасная.

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

Еще немного

Предложенная структура имеет максимальную масштабируемость. При ней уже не важно сколько добавится проектов или людей. Управляемость ситуацией сохранится.

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

Решение о том, как распределять новую задачу по плагинам/приложению должны определять совместно тимлид и продуктовый менеджер. Продуктовый менеджер несет знание о том, как данная функциональность должна быть использована на всех проектах, а тимлид несет знание о внутренней архитектуре. Только вместе они могут принять решение, что делать плагином, а что нет, но никак не продуктовый менеджер! Не мучайте его такими непонятными вопросами :)

В данной схеме есть перспективы роста, для тех, кому это важно.

Рано или поздно программист устает от определенного направления деятельности - есть возможность перемещаться между командами.

Как предложенная схема решает проблемы

ПРОБЛЕМА: Нет работы в потоке
ОТВЕТ: Саппорт занимается не запланированными ошибками, отвлечения разработки от спринта нет.

ПРОБЛЕМА: Появление нового сотрудника
ОТВЕТ: Есть база знаний, есть работа в поддержке, для изучения всей системы.

ПРОБЛЕМА: Уникальное знание о части системы в одной голове
ОТВЕТ: Про одну конкретную часть системы знают как миниум двое - саппорт и девелопмент, который делал + продуктовый менеджер + тимлид + технический и продуктовый директора + документация.

ПРОБЛЕМА: Качество
ОТВЕТ: Тесты, отдельно выделенная поддержка, база знаний, роли, которые несут структурное знание, распространяют его и контроллируют

ПРОБЛЕМА: Продуктовому менеджеру взрывают мозг
ОТВЕТ: Теперь у него есть напарник-тимлид (вожно теперь взрывать мозг им обоим, это намного веселей =)

ПРОБЛЕМА: Есть задачи для избранных
ОТВЕТ: Нет задач для избранных, есть общее знание о системе. К этому надо будет прийти, сразу этого не достичь, сложная задача.

The End And The New Beggining

Шаги по переходу, это уже наша внутренняя работа. Предлагаю обсуждать предложенную схему и потом двигаться в ее направлении.

вторник, 11 октября 2011 г.

Web Development And Internet AS-IS

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

У нас классная команда! Сейчас мы переживаем естественный процесс пробуксовки от увеличения количества людей. Но я уверен, у нас получится реструктуризоваться (ох, слово то какое) и  выйти на новый уровень качества! Вперед, друзья! =)

Я пишу исключительно свои наблюдения. Буду рад, если вы присоединитесь к обсуждению, как минимум на уровне обозначения проблемы.

ВРИН изначально было "Веб Разработки и Интернет", т.е. на английском правильнее будет WDI - аббревиатура. Не знаю, зачем я это написал, но пусть будет.

Для начала опишу текущую структуру нашей работы.

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

Внутри отдела:
- руководитель отдела
- проектные менеджеры
- ведущие разработчики
- разработчики
- верстальщики
- системные администраторы
- Web-дизайнер

Есть так же отдельный отдел тестирования со своим руководителем и тестировщиками, которые проводят ручное тестирование (с автоматизацией его при помощи SAHI)

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

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

Проблемы есть следующие.

У сотрудников практически нет возможности работать в потоке

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

Приводит это вот к чему. Допустим разработчик сделал задачу в текущий спринт, начался следующий, он уже делает вторую задачу, которую все дружно оценили, и, вроде бы ее реально можно сделать за обещанное время. Но! Каждый день начинаются дергания по старой задаче, тут немного доделать, там немного hotfix'а выпустить и все, оцененные сроки летят и моральное не удовлетворены все, начиная от самого разработчика и заканчивая заказчиком...

Конечно, в SCRUM есть фокус-фактор, скажете вы. Но кто мне сейчас с ходу скажет, как правильно должна попадать ошибка в спринт?..

Появление нового сотрудника

Одновременно радостное и печальное событие. Новый человек горит желанием скорее начать работать и приносить пользу. А не тут то было! Нет возможности самостоятельно разобраться в системе за разумное время, потому что нет ВООБЩЕ никакой документации.

Вики страницы с заданиями есть только по ДК и Близко, но они описывают 5% проекта, да и то, с точки зрения пользователя, а не программиста. По остальным проектам всё, видимо, в виде файликов и задач в JIRA. JIRA - это явление ситуативное, в ней вообще происходит процессное взаимодействие, изменяющееся во времени, она не является инструментом для создания постоянных во времени срезов информации.

Что получаем в итоге? Новый сотрудник вынужден приставать к существующим с вопросами, следовательно опять идет их отвлечение. Итого цена ввода нового сотрудника в строй растет, при чем не в линейной даже прогрессии, а по экспоненте.

Уникальное знание о части системы в одной голове

И когда с этой головой что-то случается (да, остальные части тела сейчас не так важны =), она уходит в отпуск, к другому работодателю, или еще что-то, то происходит полный fuckup! Другим людям, даже опытным надо далеко не нулевое время, для того чтобы разобраться с "черным ящиком".

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

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

Качество


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

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

С тестированием отдельная песня. Мое imho - нельзя отделу тестирования, быть отдельным отделом. Тестирование - это неотъемлемая часть разработки, один из ее шагов. А сейчас - это какая-то "штука с боку". О борьбе с багами и тестировании расскажу чуть позже, в разделе TO-BE. А сейчас лишь констатируем, появляется огромное желание сделать задачу кое-как, тестировщики найдут ошибку, разработчик ее поправит, еще пару итераций и...на продакшене еще раз нашли баг, сделали hotfix и!...бл@ - опять баг на продакшене (пользователи в печали), поправили hotfix и!...так до бесконечности. Без багов никуда, но зачем же так-то...

Продуктовому менеджеру взрывают мозг
Взрывают мозг техническими вопросами - индексы БД, плагины, ajax и т.д. Конечно, человек, ставящий задачи для разработчиков должен немного ориентироваться в этом. Но не так глубоко! И тем более не предлагать решения! Его основная задача - это работа с заказчиками, формулирование требований для разработки. Да-да! Именно требований, потому что сложность системы уже достигла такого уровня, что технические решения должны приниматься только тим-лидами. От продуктового менеджера нужна только четкая пользовательская постановка и удерживание заказичков подальше от разработчиков в течение спринта :)

Сейчас появляется новая тема, менеджерам надо будет приниматься решение о том, делать плагин или нет? Ой-ой, а вот должны ли они принимать такие решения? Вот вы, когда сидите у стоматолога, он у вас советы спрашивает, как вас лечить? =)

О том, кто и когда принимает технические решения поговорим так же в разделе TO-BE.

Есть задачи для избранных

По мере повышения сложности системы появляется все большее ее частей, которые понимают и могу за разумное время модифицировать, только несколько сотрудников отдела. Это приводит к огромным сложностям в планировании: вот эту задачу, несмотря на ее важность давайте пододвинем сюда, потому что ведущий разработчик занят, а другие будут в ней долго разбираться. Ну круто! А где же тогда возможность для остальных разобраться с этой сложной и интересной частью? Ждать пока этот человек куда-то денется?

Попредававшись сладостному обличению (эх всегда круто критиковать =) перехожу к описанию конструктивных шагов и предложений, как все можно сделать получше или совсем хорошо. Читаем Web development TO-BE

суббота, 8 октября 2011 г.

Epic fail with MacPro и прочие радости

Ссылки на предыдущие части:
Начало истории: Высоконагруженная поездка 2011
Вторая часть: Hard Rock Cafe и первый день конференции

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


После посещения Fridays наши стопы устремили наши тела в направлении дружелюбного афро-азиатского хостела. Упорно передвигаясь по широким улицам к метро мы ни на секунду не забывали, что у Леши Горбова вот-вот наступит день рождения. Да...приближалось 4 октября.

Дабы не быть шаблонными мы решили поздравить Лешу неожиданно и поздравили: остановились ровно в 00:00, это оказалось серединой пешеходного перехода широкой дороги, и громко прокричали, все что хотелось. Хотелось многое, но успели: "С ДНЕМ РОЖДЕНИЯ!", потому что времени на переход дороги в Москве дают ой как мало... Леха, с Днем Рождения тебя еще раз!

Второй день конференции начался с интересных докладов про Redis.


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

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

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


У кресла этого чудесного огромное количество функций. Порадовал режим ударов, который методично простукивал спину, жалко не было более тонкого тюнинга, почки, печень...

Началось! Все падкие до халявы, а таких оказалось большинство, собрались около сцены. Сначала разыгрывали бочонки с пивом. Мы были почти на грани победы: "Федоров Денис!", объявил ведущий...Эх...почему я не Федоров или почему Серега не Денис, не понятно. Потом Гугл  разыграл android-коммуникатор, вроде Samsung и вот, начался розыгрыш Мака!

Kamagames написали целое сложное приложение, которое рандомом выбирало победителя. Сразу пошли шуточки, что надо бы показать исходники и т.д. Но данные вроде были честные, среди занесенных в базу людей промелькнул Леша Горбов. Все затаили дыхание, генератор псевдослучайных чисел поднапрягся и выдал победителя! Ура! Но его не оказалось в зале...Вот я бы реально расстроился... Дубль два, крутись-вертись рандом, ба-бах и второго победителя тоже в зале нет! Да, как так! =) Может они просто оказались слабенькими и не смогли дойти до сцены?..

В третий раз победитель все таки нашелся и 25кг адски быстрого ябложелЕза обрели хозяина.


Вот так и закончилась конференция. Было интересно, познавательно, мыслевозбуждающе и полезно во всех смыслах и направлениях.

Выходим под дождик и пешочком двигаемся к Павелецкому вокзалу.



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

Потом был бег на отъезжающий аэроэкспресс, мы никуда не опаздывали, просто мужик очень зажигательно бежал по переходу, восклицая: "Би-би!!!", и мы не смогли не составить ему компанию. Потом Домодедово, турнир по аэрохоккею на iPad'е, потом самолет, в котором встретили парней, которые тоже возвращались в Екб с Highload'а, потом пощекотавшая нервы посадка под проливным дождем, такси...дом...спать... (кстати парни, кто летел за нами в самолете, если вдруг наткнетесь на этот пост, дайте знать, я был уже без сил, чтобы знакомиться, а так, буду рад пообщаться)

Все!  

пятница, 7 октября 2011 г.

Hard Rock Cafe и первый день конференции

Начало истории: Высоконагруженная поездка 2011

Продолжаем наше высоконагруженное путешествие.

По дороге до Арбата нашли тайную явку Абак Пресса.

Прогулявшись Московскими переулками мы вышли на Арбат, это ведь просто Вайнера какое-то! В сумерках вообще создавалось ощущение, что мы через пару сотен метров дойдем до Гринвича, а там и Абак недалеко...

В Hard Rock Cafe были =)

По дороге домой все никак не могли нормально выговорить "Садовое кольцо", получалось или "кольцовое садо" или "кадовое сальцо" или все в таком духе. В хостеле...спим?..спим...утро...будильник...ААА!!! Надо бежать на регистрацию!

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

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

Побродив вокруг решили уже занять хорошие места и разошлись по залам, парни пошли слушать доклад про RabbitMQ, а я пошел на доклад Mamba, о том как масштабировать команду, при росте количества людей, да у менеджеров свои проблемы с  Highload'ом =)

Удобно устроившись на стуле я просматривал твитер по хештегу #highload и ждал доклад. В ленте вдруг стали появляться подозрительные слова: "boobs, сиське" и все в таком духе. Но тут начался доклад и  все мое внимание переключилось на него. Ярослав Сергеев из Mamba интересно рассказал о том, как они масштабировали структуру управления, при росте количества сотрудников и задач и каким образом решают проблему разделения разработки и поддержки/сопровождения. Зарядившись полезными мыслями и размышлениями переходим к следующему докладу от Гугла.

Гугловцы жгли ) Первый докладчик сильно стеснялся и постоянно запинался в своих мыслях. Рассказали о том, как они достигают качества, т.е. опять же про разделение разработки и поддержки, рассказали о том, как передаются знания внутри компании и что много общаться, это хорошо. Вообще, стало понятно, что в Гугле нет проблем, на все вопросы ответы были примерно такие: "- Как вы решаете проблему ###? - Нууу, у нас есть для этого 10000 серваков и 100000 людей и все они профессионалы и поэтому мы счастливы...". Или: "- Как вы собираете и анализируете логи? - Нууу, мы их собираем и анализируем, да" Хотелось сказать: "Спасибо КЭП!"

После доклада пошли искать boobs и ведь не обманули нас, все как и писали в твитере, дабы убедиться, что не фейк, идем фоткаться =)

Затверждаю - не фейк =) На девушках из одежды был нарисованный QR-код, все аутентично оказалось обстановке.

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


Двигались, конечно, в направлении Красной площади, многие из нас видели ее только на картинках.
И вот...
Целовать камни, конечно, не бросились, но историчность места немного придавила...Серегу и Лешу особенно, вот они думают о России...


Ненадолго правда придавило и вот мы влились в ряды многочисленных людей запечатляющих себя на фото.






Фотограф из меня тот еще, так что обрезанные ноги, заваленный горизонт, все это есть на фото =)

Возвращаясь на конференцию нашли посольство Мадагаскара (i like to move it, move it, ой о чем это я...)
На конференции продуктивно почитали твитер дослушали доклады и устремились на вечерний фуршет.


Продуктивная работа на второй день конференции начинала подвергаться опасности. Но наши молодые организмы пережили все трудности и даже выступление Кати Гордон. Около восьми часов вечера ивент закончился и мы вышли на улицу полные планов по дальнейшей культурной программе.

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

В Сырной дырке как-то сразу не задалось...Есть особо не хотели, а выпивка была дорогая. После недолгих скитаний оказались во Fridays, опять бургеры...Хотя вот по Мише не скажешь, что он расстраивается.

Посидели, пообщались, двум ИТшникам никогда скучно не бывает, а уже если их восемь собралось, то, вообще...

Эх, все таки ответственный народ у нас поехал, все прониклись тем, что второй день конференции еще впереди и мы пошли домой. Приближался хостел дружбы народов, второй день Highload'а и Лехин день рождения...

Продолжение Epic fail with MacPro и прочие радости

Часть с конференции фото сделана @kamagames - даже меня умудрились зафоткать )

четверг, 6 октября 2011 г.

Высоконагруженная поездка 2011

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

Все началось в воскресение 2 октября, в Кольцово все было как обычно, народу не много, все по домашнему, только Вася зачем то подстриг волосы! Реально удивило =)

В самолете с нами летели Уральские пельмени, пилота звали Артур Петросян. Все намекало на то, что будет не скучно.

В Москве нас прокатили на уютных Volkswagen Jetta практически до самого Buddy Bear хостела. Таксисты попались странные, как то не захотели они искать точно адрес, высадили нас просто на Садовом кольце в предполагаемой по навигатору близости от хостела и уехали =) Через пару минут мы поняли почему... Оказывается "строение" и "корпус" вещи разные, побродив по дворам с помощью гуглекарт мы нашли отделение милиции, странный розовый домик, но не нашли наш хостел...

Позвонив по телефону указанному на booking.com я пообщался с приветливой девушкой, которая сообщила, что нам оказывается надо прибыть на адрес в трех кварталах от нашего текущего положения, booking.com подвел...неожидал такой неактуальной информации от него, хорошо хоть бронирование было в силе.

Через 10 минут бодрой пешей прогулки оказались в хостеле...Это был обычный подъезд, настолько обычный, что даже запах указывал на его сильную обычность, в небольшом смятении поднимаемся на 5й этаж, Серега что-то загоняет про места, из которых увозят рабов в Китай, но все равно поднимаемся...

И правда бле@ть КИТАЙ! С нами жили все, кроме русских. В основном, афронегры и представители восточных племен, предположительно студенты, но мы с ними так и не познакомились. В целом хостел оказался нормальным, все чистенько, тепло, переночевать 2 раза за такие маленькие деньги в самом центре Москвы, лучше не придумаешь.

Позвонили Диме Словинскому, который нас пригласил на экскурсию в Яндекс, стрёмно отказываться от шанса узнать побольше про будущего работодателя одну из ведущих компаний нашей страны. Дима, кстати, спасибо тебе большое! Благодаря тебе мы практически и не ощутили, что оказались в большом и незнакомом городе, такое ощущение, что потусили в таком увеличенном Ебурге...

Итак, идем в Яндекс. На входе проходим гостевую авторизацию (бейджик "Гость"). Леха попытался сломать брутфорсом турникет, но защита Яндекса не подвела =) Леху зажало дверками и проскочить не удалось.

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


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



А еще в Яндексе есть баги, я знал, я знал! =) Вернее жук-багрепортер. Это такая внутренняя фича, чтобы сотрудники могли удобно постить ошибки в сервисыах.




В очередной раз убедился, что профессии, связанные с девелопментом, творческие профессии, только средства выражения очень разнообразны, это видно буквально на каждом шагу, веселые рисунки, личные вещи, порой самые неожиданные (по крайней мере для нашего работодателя, да-да это камешек такой маленький улетел =), атмосфера, по которой видно, что люди на работе не только работают, а точнее сказать проводят часть своего времени, тогда почему бы не сделать эту часть времени более красочной и приятной...



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


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




Много еще чего повидали, библиотека, телевизор, который в реальном времени показывает, что делают пользователи на народных Картах и т.д. Проникнувшись атмосферой мы покинули приветливые стены Яндекса, посмотрели на коней и выдвинулись в направлении Hard Rock Cafe, но об этом чуть позже...

Читать дальше Hard Rock Cafe и первый день конференции