итоги года

год уходящий был сложен и в тоже время более чем продуктивен. на первый план в году уходящем, с самого его начала, вышли проблемы, к профессиональной деятельности отношения не имеющие. огромное спасибо всем, кто поддержал меня в трудную минуту испытаний, благодаря всем вам я сохранил ясность рассудка, желание жить, трудиться и созидать разумное, доброе, вечное.
в профессиональной сфере год 2008й ознаменовался прежде всего тем, что мне удалось примерить фуражку начальник отдела, вплотную заняться управлением сначала ресурсами, а потом и проектами. довольно долгий период времени это была моя цель, к которой я подходил может быть даже слишком долго. результатами своей деятельности я доволен, хотя без ошибок тут не обошлось. однако, что не убивает нас, то делает нас сильнее. я бы рекомендовал все програмистам, уровня Senior Developer, попробовать себя в роли менеджеров официально или не официально в данном случае значения не имеет. но роль управленца в проекте или подпроетке очень здорово прочищает мозги и позволяет взглянуть на знакомую и рутинную работу под новым углом. заниматься ли управление дальше? это каждый рещи сам, но опыт в управлении поистине бесценен, да и в резюме будет смотреться не лишним.
так уж получилось, что в свою предыдущую компанию я пришел исключительно в порядке эксперимента, можно сказать даже авантюры. прежде всего мне понравились люди, которым предстояло стать моими начальниками. и я не ошибся. это были прекрасные месяцы работы в слаженном коллективе, с взаимопонимаем, единой целью и четким путем ее достижения. спасибо огромное, ребята.
однако, все проходит, так или иначе, но пути моих предыдущих начальников увели их прочь из конторы. до осени я еще пытался эксперемнировать на предыдущем месте, хотя делать это становилось все сложнее и понимание того, что мои инициативы никому, кроме меня, не нужны становилось все яснее. осенью грянул кризис и время для экспериментов кончилось. я довольно удачно сменил работу и ожидаю новых и приятных впечатление от нового места и новых людей.
несмотря на неблагоприятные прогнозы, я искрене верю в то, что кризис это прежде всего новые возможности. возможности личного и профессионального роста; возможности начать делать то, что давно следовало; возможности изменить себя и свою жизнь; возможности стать лучше, честнее, отвественнее, профессиональнее, человечнее, добрее, терпимие. я верю, что кризис принесет миру обновление, которое в конечном итоге пойдет миру на пользу.
так что в новом, 2009м году, желаю всем вам мира, добра и достатка. желаю, что бы каждый из вас смог увидеть возможность измениться к лучшему самому и изменить к лучшему мир вокруг и этой возможностью воспользовался.
с Новым 2009м Годом!

relationship: employer & employee

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

Warranty

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

Роман Хмиль о настоящем и будущем украиского ИТ

данная статья цитируется по материалам обсуждения сайта developers.org.ua с разрешения всех заинтересованных сторон.
вопросы подготовлены пользователем realist, отвечает Роман Хмиль, CEO Global Logic Ukraine.
(с) realist, 02/08/2008
(c) Роман Хмиль AKA Romki, 03/08/2008

итоги подведем

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

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


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


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


4. публикация задач, включающая информацию о estimated & spend time, start & due date... позволяет всем stakeholders отслеживать состояние задач


5. постоянный контроль деятельности команды. разбирать полеты и хвалить людей необходимо как можно оперативнее оносительно достижений и провалов


6. ежедневная сборка проекта для тестирования. лучше 2 раза в день, хуже -- один

еще один холодный день в аду

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

про стартап или нет никакой ложки

я считаю, что для успешности любого стартапа нужно всего три вещи:

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

все остальные факторы, которые часто преподносятся в виде барьеров: "разобранные" рынки, большая конкуренция, огромное количество аналогов, существующие успешные реализации идеи являются лишь барьерами в нашей голове, шорами на наших глазах, поводом отказаться от рисков. Брин сотоварищи выходил на рынок "разобранный" Yahoo! и Altavista, Джобс возглавил Pixar, во времена всецелого господства Walt Disney Pictures, и Apple, во времена господства PC и Nokia. когда каждый и подобных людей добивался успеха, миллиардное мировое сообщество судорожно выдыхало: "ах! вот это человек, вот это повезло". везения в чистом виде не существует -- есть лишь каждодневная кропотливая работа, лишь стойкость перед любыми препятствиями, лишь планомерное движение к намеченной цели, лишь креативность подхода и умение видеть старые вещи в новом свете. и тогда Удача сама постучится в двери, не нужно охотиться на птицу цвета ультрамарин, нужно создайть такие условия, чтобы она прилетела сама... и осталась навсегда. но это не легко.

про доллар или о наболевшем

а вчера были большие... но по пять. а сегодня по три... но маленькие. а вчера были по пять, но большие. а сегодня маленькие... но по три.
(с) Михаил Жванецкий

не секрет, что в украинском IT все зарплаты считаются в долларах. слышал я про конторы, что работают с европейцами и считают в евро, но их количество настолько мало, что им можно пренебречь :) во всяком случае мне ни разу не попадались. и до сих пор всех все устраивало. в 2005 было взывли наши разработчики, когда НБУ понизил официальный обменный курс с 5,3 гривень за доллар до 5, но эта волна как-то быстро спала. а может быть я не заметил "кругов на воде" из-за того, что в той конторе, где я тогда работал, нас было всего 12 человек. с новой силой поднялось возмущение в апреле-мае этого года. тогда банки и обменные пункты снизили наличный обменный курс до 4,4 гривни за доллар. некоторые из моих подчинненых сразу начали размышлять о том, как было бы хорошо пересчитать зарплаты в евро. а евро в то время стоил 8 гривень. я расчитывал, что это чисто украинское "а отам я бурячки посаджу" (с) пройдет быстро. но нет, люди совершенно искренне придумывают все новые и новые схемы, по которым компания "должна" с ними работать. хоть зарплаты в евро уже хочется меньше -- все-таки он уже стал стоить 7,3 гривни -- но есть другие схемы. в моем личном хит параде лидирует следующая: "было бы хорошо договориться с компанией, что если курс опускается ниже 4,8 за доллар, то нам считают по 4,8. в если поднимается -- тогда по официальному курсу". действительно, простота хуже воровства.

про рынок труда

ты помнишь, как все начиналось?
все было впервые и вновь,
как строили лодки,
и лодки завлись "Вера", "Надежда", "Любовь"
(с) Машина Времени

вспоминая самый старт моей програмистской карьеры я каждый раз прихожу к мысли, что тогда все было иначе. небо голубее, трава зеленее, девушки красивее я начинал искать работу в 2000м году, сразу после того, как развалился наш студенческий стартап. мне, сначала студенту, а потом уже выпускнику профильного ВУЗа, пришлось пройти 17 неудачных собеседований за два года, чтобы устроиться на свою первую работу с кабальными условиями. чистой потогонкой была та работа, но и она была ценна. уже тем, что она была и за нее платили хорошие деньги. мы, программисты, ценили факт наличия работы, мы видели снаружи последствия краха доткомов, и 09/11, и краха Телесенса. для меня это была первая работа, и я вдвойне ценил таким трудом добытое место. я учился отвественности, и качеству, и работе по 14 часов в сутки, и быстрому обучению, и долгому саппорту. очень много мне дала первая работа, и в профессиональном и в личном плане.
а после работы, вне стен офиса, мы -- я и мои друзья-коллеги -- мечтали о том, как станем мы экспертами. как будем не мы искать работу, а она нас. как сможем не терпеть прихоти локальной администрации, а ставить условия. как будут считаться с тем, что все-таки мы -- программисты -- создаем реальные продукты. да, роль менедмента и администрации важна, но не следует относитсья к нам, как к крепостным крестьянам. бойтесь своих желаний, они имеют тенденцию сбываться.

одной строкой

про слухи:
харьковское сообщество IT специалистов довольно узко. в том плане, что через три рукопожатия ты знаком практически со всеми, а за 5 лет в индустрии -- через два рукопожатия. тем забавнее слышать, каких размеров достигают слухи в устах людей с высшим техническим образованием, которые в большистве своем блещут воспитанием, терпимостью и толерантностью гораздо больше иных своих сограждан. слухи иногда даже превосходят своими размерами и глупостью обычную "бытовуху" о "красных радоактивных осадках" (ТМ). узость комьюнити также обрекает на неудачу любую попытку что-то скрыть. если действительно необходимо скрыть что-то, то об этом не должен знать никто. а такое не всегда возможно.

JavaScript tips&tricks

для того, чтобы сделать быстрый unescaping специальных символов в строке, достаточно употребить конструкцию:

...
var tmpDiv = document.createElement("div");
tmpDiv.innerHTML = <escaped_text>;
var unescaped = tmpDiv.innerHTML;
...

функция, аналогичная org.apache.commons.StringUtils.split:

function splitString(source, separator) {
    var result = new Array();
    var i = 0;
    var index = source.indexOf(separator);
    while (index > 0) {
        var token = source.substring(0, index);
        source = source.substring(index);
        index = source.indexOf(index);
        result[i++] = token;
    }
    result[i] = source;
    return result;
}

кроссбраузерный (Internet Explorer 6.x,7.x, Opera 9.x, FireFox 2.x) способ динамического добавления обработчика событий:

function eventListener(param) {
    alert(param);
}

function addOnClickListener(elementId) {
    var element = document.getElementById(elementId);
    element.onclick = eval("eventListener'" + "Hello JS world!" + "')");
}

весна: играй гормон

И что из того, что разорваны связи?
И что из того, что молчат провода?
И что из того, что все песни похожи
одна на другую, а та - на тебя?
В моей преисподней
Как будто бы людно,
но поздно сшивать уже
рану край в край,
и я разделяю все случаи жизни
на что было до и после тебя!
(с) Светлана Сурганова

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

Аспектно-Ориентированное Программирование: Предисловие

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

Monday hard

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

JSR-168 Portal + JSF: Работа с настройками портлетов

копия моей статьи на Liveinternet.ru от 9 октября 2007

все порталы, удовлетворяющие спецификации JSR-168, предоставляют стандартный механизм доступа и модификации настроек портлетов, посредством реализации интерфейса javax.portlet.PortletPreferences. в данной заметке рассмотрим способ работы с настройками портлета, реализованного с помощью технологии JavaServer Faces.

Liferay + JSF + ICEfaces

копия моей статьи на Liveinternet.ru от 2 октября 2007

интеграцию портала Liferay и JavaServer Faces компонентов ICEfaces можно считать условно завершенной. безусловно, это только начало интеграции и впереди еще долгий путь полный устранения дефектов, реализации улучшений и всего прочего, чем богата наша програмисткая работа. но первый шаг сделан, анонсированная в начале лета интеграция AJAX JSF framework с Liferay порталом состоялась. сегодня я протестировал портлет, использующий ICEfaces components весрии 1.7-DR1 в контейнере Liferay Portal версии 4.3.2. успешно работает отрисовка, навигация и взаимодействие компонентов. уверен, что валидация также работает.

Liferay 4.2.2 themes handling bug

копия моей статьи на Liveinternet.ru от 11 июля 2007

Ошибка обработки идентификаторов темы в Liferay Portal 4.2.2
для версии 4.2.2 Liferay Portal зафиксирована не корректная работа с идентификаторами портальных тем, развернутых как внешние WAR-приложения с помощью механизма автоматического развертывания компонентов портала (тем, шаблонов расположения и портлетов).

once upon time....

что ж, попробуем поселится здесь :) всем доброго времени суток.