Записки на полях

CAJD::Technologies

2011-06-15T09:53:00.008+03:00

Вопрос второй

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

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

Для этого мысленно посмотрим на рынок навыков Java-программирования 8-10 лет назад. В том время человек, который знал EJB 2.0/2.1 считался джедаем и все новички в Java непременно стремились изучить EJB. Я не был исключением, и мне это удалось, и я знал EJB 2.1 довольно хорошо, и все рвался их применить в проекте. Но время неумолимо шло вперед. Сначала появились Hiberante и Spring, и знания EJB больше не были так необходимы. Потом вообще перестали говорить про middle-tier и стали говорить про JSF, GWT, затем - про NoSQL, Groovy/Grails и прочие модные штуки. К чему я все это рассказываю? К тому, что достаточно просто проследить следующую тенденцию

Человек выучил Hibernate и знает ее досконально. Его знания будут востребованы на рынке до тех пор, пока Hibernate актуален и широко используется. Между тем это всего-лишь один из persistence famework, у которого куча конкурентов.

Человек выучил Java и знает ее не то чтобы досконально, но достаточно хорошо. Его знания будут востребованы ны рынке до тех пор, пока Java актуальна и широко используется. Это уже уровень языка программирования. И сейчас кажется, что так будет всегда. Нам не дано досконально знать будущее - может быть и будет. Но вот C/C++ до сих пор актуален, а найти работу сложнее и сложнее.

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

Человек умеет решать проблемы заказчика. Не просто писать хороший, оптимальный, выверенный код, отдавая себе отчет почему он пишет этот код именно так, а еще и отдавая себе отчет зачем он пишет именно этот код и именно таким образом. Также, человек решает проблемы заказчика в тех временных и бюджетных рамках, которые установлены для задачи. Это уже следующий уровень. На этом этапе можно говорить о том, что само программирование уже не имеет решающего значения. Конечно, освоить принципиально иной инструментарий будет тяжелее, чем выучить новый язык программирования. Но тяжелее, не значит невозможно. Знания и умения этого человека будут востребованы на рынке.... Сложно провести черту, правда? Условно назовем это "инженерные навыки 2.0".

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

Резюме

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

CAJD::Interesting tasks

2011-06-09T09:31:00.005+03:00

Открываю обещанный цикл статей по следам заседания "Клуба анонимных Java-девелоперов" на jeeconf. Пока мне видится такой себе FAQ, по темам, которые всплыли уже надцатый раз и получили конкретные законченные ответы.

Итак, вопрос первый

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

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

Точечные задачи, требующие точечных решений

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

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

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

Заняться параллельно другим проектом. В идеале получить дополнительную оплачиваемую нагрузку. В реальности такое тоже не всегда возможно, но всгеда остается волшебный мир Open Source. И вот там уже можно реализовать себя в любом качестве и изучать все, что угодно душе

Legacy-проект, устаревшие технологии и жесткие ограничения на изменения

Этот вариант встречается в 80% случаев. И в этом случае скука, лишь следствие непонимания сути задачи. Дело в том, что любую проблему можно решать творчески, в любой задаче всегда есть интересное зерно: рутинные, повторяющиеся задачи можно автоматизировать; плохой и медленный код рефакторить; сложный и дремучий копипаст превратить в стройную и логичную структуру классов сохранив публичный API без изменений. В данном случае важно понять, какую именно проблему необходимо решить, зачем и почему выставлен именно такой баг и как наиболее правильно решить проблему. Ключевые слова решить проблему, не исправить баг, не переписать код, не изменить архитектуру - нет, решить проблему. Решение проблем и есть те самые инженерные навыки, которые стоит в себе развивать, но об этом будет отдельный пост.

Краткое резюме

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

JEEconf resume

2011-05-24T00:03:00.002+03:00

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

Организация

Второй раз XPinjection делает конференцию на 5+. Устойчивое интернет-соеденение (в этот раз 8 точек), качественное питание, качественное и равномерное распределение участников, докладчики с реально интересным людям материалом. Все это уже становится визитной карточкой конференций. В двойне радует, что это Киев и наконец-то есть какое-то событие, которое украинцы могут организовать хорошо. Спасибо ребята, спасибо Коле за идею и драйв комьюнити, спасибо Ане за совершенно титанический труд в организации мероприятия на месте, спасибо волонтерам за волонтерство, организаторам за организацию, участникам за участие

Мой псевдо-доклад

Почему псевдо-? Потому что планировалась живая разработка проекта. Как по мне идея стоящая, но рисковая. Так и получилось. Я был бы не честен, если бы продолжил говорить "мой доклад", потому что делали мы его вдвоем с мои другом Юрой Литвиненко. Идея изначально была запрограммировать нечто прямо на конференции. И пришло как минимум 4 человека, которые очень хотели кодить и имели ноуты. Но подавляющее большинство нашей аудитории были "интересующиеся". А так как вшестером довольно сложно получить результат работы за 4 часа, мы с Юрой переформатировали мероприятие в открытые дискуссии. И переименовали в "Клуб анонимных Java-разработчиков". Довольно сложная штука эти открытые дискуссии, их очень не просто вести. Но оказываться можно делать это эффективно. Даже появилась идея продолжить "Клуб..." на харьковской стороне. Посмотрим. В процессе обсуждения всплыли темы, которые стоят отдельных постов. О них я расскажу дальше.

UA Web Challenge 2011

2011-04-23T10:34:00.002+03:00

В один из дней марта, не помню точно в какой именно, мне в телефон позвонил некто Игорь и предложил поучаствовать в жюри всеукраинского конкурса разработчиков UA Web Challenge 2011. А я возьми и согласись. Идея конкурса довольно проста и, как по мне, очень своевременна, она полностью отвечает тенденциям рынка труда - нужно дать возможность прежде всего юношам и девушкам, без опыта или с минимальным опытом работы, как проявить себя, так и найти/сменить работу буде у них такое желание есть/появится. Обе цели были достигнуты, участники разделились на две не равные части - большинство получило удовольствие от соревнования, результатов, новых знаний и знакомств; отдельные личности стали брюзжать на форуме DOU.

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

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

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

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

Хотелось бы подробнее остановится на наиболее типичных ошибках участников

Не знание или не достаточное знание теории проектирования. Это касается всех, включая финалистов и призеров. Коллеги, если вы беретесь проектировать систему, то необходимо точно понимать, какие есть для этого инструменты, императивы и диаграммы. Проектирование имеет очень опосредованное отношение к реализации, поэтому ваши навыки в языках программирования тут скорее вредны, чем полезны.
Все архитекторы рассматривали систему с точки зрения реализации. Что и подвело основную массу полуфиналистов. Реализация - это самый нижний слой архитектуры. Сначала необходимо формализовать требования, выделить основные варианты использования системы, определить основные состояния и последовательности взаимодействия, выделить основные компоненты системы. И только потом можно будет говорить о реализации и классах. Участники соревнования решили идти от обратного - от классов реализации к вариантам использования. Нужно ли говорить, что многие не успели?
На проектирование выделялось всего 3 часа времени. В условиях цейтнота не стоит писать пояснительную записку к дипломному проекту или Software Architecture Document - для этого нет времени. Многие же участники пожертвовали диаграммами и описанием систем в угоду описание ценности, важности и необходимости реализации такого проекта, а также проблем и задач, которые перед проектом стоят. Не могу сказать, что такое описание не важно и его не нужно делать. Но категорий "бизнесс-аналитик", "системный-аналитик" и "специалист по продажам" в соревновании не было. Когда в реальном мире начинают проектирование системы, в ее важности и необходимости уже никаких сомнений нет.
Формат документов, архивов и прочего. Я не стал снижать оценки за такие мелочи, но хочу специально их отметить. Обилие платформ и ОС было представлено уже в полуфинале, можно было воочию наблюдать MacOS, Linux, Windows даже на машинах участников соревнования. Коллеги, почему же вы позволяете себе отдавать документы в MS Office/Libre Office форматах, упакованных коммерческим RAR, с кириллическими именами? Не приходила ли вам в голову светлая мысль, что некоторые документы просто не будут прочитаны? Тоже касается файлов Dia, Visio и прочих средств проектирования. В реальном мире никто не будет возиться с установкой архиваторов и конвертацией файлов - ваша работы просто отправится в корзину. ZIP для архивов, PNG для диаграмм и PDF для документов - вот выигрышная комбинация.

Традиционная для моих отзывов Pro & Contra организации

Pro

Главный офис Ciklum - однозначно зачетное место проведения соревнования. Что касается места, интернет, чай-кофе-печеньки - никаких претензий.
Идея питания участников и судей пиццей с соком однозначно зачетная. Питер, Москва - ау! Это не "ланч-пакеты", а гораздо проще, ага.
Доброжелательная обстановка, реальные сроки для участников и гибкий подход, консультации организаторов по ходу соревнования. Мне бы было комфортно в таких условиях. Судя по отзывам - участникам тоже было комфортно.
Возможность подробно разобрать с судейским коллективом ошибки. Система апелляций была бы лучше, но ее не было.
Централизованная развозка участников от/до метро - очень хорошая идея.

Contra

Время и график. Это полный провал, ребята. Кратко можно было бы сказать, что ничего не началось и не закончилось вовремя. Длинно можно описывать долго и красиво, но я постараюсь очень тезисно. Старт полуфинала в 13:00, а по факту в 14:30 - очень плохая идея. В результате лично у меня суббота с 7:30 до 20:00 оказалась мягко говоря не эффективной. Т.е. я конечно погулял по Киеву до 12, но все остальное - перевод времени. 3 часа я тупо убивал время в офисе Ciklum в ожидании результатов, потом еще 2 часа эти результаты собирались. Второй день был по-лучше, 9:30 хорошее время для старта, но мне нужно было сдать квартиру в 12:00. Итого, нужно более тщательно планировать временные рамки присутствия тех или иных людей в офисе.
Транспорт. Кроме централизованной развозки было бы очень круто описать маршруты общественного транспорта.
Субъективность судейства и отсутсвие апелляций. Я судил категорию один и это не правильно. Равно как не правильно отсутствие системы апелляций. Предлагаю сделать следующий полуфинал онлайновым и за неделю-две до финала. Как-раз хватит времени детально разобраться, разобрать апелляции и отобрать действительно лучших.

JavaOne Moscow 2011

2011-04-16T17:29:00.002+03:00

Откровенно говоря после Sun Tech Days St. Petersburg 2009 не думал, что поеду еще раз на мероприятие Oracle в России. Но, как говорят, строить планы - смешить Бога. В этот раз ее назвали JavaOne и ехали мы вчетвером, я подумал - а почему бы и нет. Тем более, что контора помогла с дорогой и регистрация была платной. Поездкой я доволен, несмотря на некоторые огрехи организации и (привет Бек) отсутствие технической конкретики в большинстве технических докладов.

Два, нет, три основных вывода

С пришествием Oracle и отсечением откровенно "наколенных" поделок язык стал более агрессивным, разработка пошла не в количество фич или новых плюшек, а в качество, производительность и упорядочивание уже созданного. Что есть безусловно хорошим развитием. Потому что создано уже очень много всего, а вот стандартизировать и затюнить - это не к Sun
У меня осталось стойкое ощущение, что Java уходит с front end уже окончательно. Конечно еще трепыхается JavaFX, еще пытаются его прооптимизровать, переписать заново, интегрировать на разных уровнях от JavaPlugin до JavaWebToolkit (GoogleWebToolkit в профиль). Но это скорее похоже на сохранение лица, чем на качественный рывок. Вместо этого мощное и стремительное развитие RESTfull, Servlets, EJB/EJB-light, JMS говорят о том, что основной упор делается и будет делаться на middle tier. Что логично и правильно ИМХО. Последний jersey невероятно прекрасен.
Основные тенденции, основные направления деятельности Oracle достаточно ясны - Project Coins или допилить кривые конструкции языка; Java Memory Model уже сделана и верифицированна правильно, как следствие - работа в multithreading стала более однообразной и предсказуемой на всех платформах; MiddleTier и Enterprice; JVM как платформа динамических языков; тюнинг быстродействия - в первую очередь Garbage Collector и использование сверхбыстрой памяти.

Под катом больше подробностей и нравится/не нравится

День Первый

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

Первым был доклад Simon Ritter "HTML5 и Java: новые горизонты". Откровенно говоря доклад был про HTML5 и очень немного про Java. Совершенно не понятно, зачем нам пересказывали спецификацию, но спасибо докладчику, узнал много нового про HTML5.

Вторым докладом был доклад Ивана Крылова "Будущее JVM - JVM объединение". Вот тут много разного было рассказано про реализацию Java HotSpot и JRockit. Про их особенности реализации, достоинства, недостатки и что Oracle будет с ними делать дальше. Вывод простой - JRockit станет частью HotSpot. Просто потому, что у HotSpot больше пользователей и проникновения. Однако, JRockit не войдет в OpenJDK, или войдет, но не полностью.

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

Четвертый и последний доклад первого дня для меня был доклад Dany Coward "JDK7 и JavaSE". Ничего особенного нового, по сравнению с позапрошлыми планами. Единственно - ясности больше и график развития четче.

Oracle Technology Night познакомило меня с хорошим чешским пивом, средней паршивости русским Будвайзером и волшебным голосом солистки "Шимякина Бэнд". Единственным недостатком была невозможность общаться из-за специфической акустики РАН. Но это скорее плюс солистке и оркестру, чем наоборот.

День Второй

Второй день был еще более хорош, чем первый.

Порадовали доклады про тюнинг производительности JVM, "Servlet 3.0: Расширяемые, асинхронные и простые в использовании", "Улучшенный JavaAPI для RESTfull"

Абсолютным рекордсменом стала 20тиминутка "Модель памяти Java в деталях" - в Белом Зале не было даже "стоячих" мест.

Доклады про JavaFX 2.0 и JPA 2.0 разочаровали, не техническим исполнением или мастерством докладчиков, сколько пониманием того, что обе технологии деградируют. JavaFX просто умирает, JPA - уходит в область очень тяжелых и нагруженных систем. Нужно отдать должное Ludovic Champenous за его ответ "if you want to be fast or agile, it's not a good idea [to use JPA 2.0]". Но это несколько печально.

Ну и наконец традиционная секция Pro&Contra

Pro

Платная конференция. Полностью учтена ошибка Питера-2009 и случайных людей не было. Между тем количество участников колебалось вокруг цифры 3000.
Помещение РАН и 8 потоков в разных залах. Сесть можно было практически везде, лаундж зона была по прежнему одна, но были и другие места для сидения. Однозначный плюс.
Отличный кофе, для растворимого. У меня даже открылись утром глаза.
Вкусные сендвичи и печеньки на кофе-брейках.
Доступный WiFi в Большом Зале и лаундж-зоне (не лег, что характерно)
Халяву выдавали сразу при регистрации, что ликвидировало не нужную давку в другое время
Скидки на продукты JetBrains и книжная "лавка"

Contra

Ланч-пакеты ужасны, как и в Питере-2009. Бутерброд, немного салата и Snickers. Лучше бы взяли плату за обед отдельно, но сделали бы его действительно обедом
WiFi только в Главном Зале и лаундж-зоне. Ну это же конференция разработчиков ПО. Однозначный fail
Присутствие кофе и печенек только в перерывах. Понятно, что нужно убрать-накрыть, но...
Растворимый кофе. Это же Java-конференция! Почему кофе растворимый?!

Expert vs. Multipurpose

2011-04-05T01:07:00.003+03:00

Не могу молчать, как говориться. Невинный вопрос "Если админ не смог настроить принтер на Ubuntu, потому что знает только Windows, значит ли это, что он плохой админ?" Получил совершенно невероятный ответ "Да - значит". Безаппеляционность? Ответчик не подумал? Возможно, но мне кажется, что это своего рода (не люблю слово трэнд) тенденция в обществе. Давайте попытаемся (ибо автор не является специалистом в системном администрировании), разобраться подробнее. Для начала, я представлю себе те области, с которыми сталкивается Windows админ каждый день

Сама система. Windows изнутри не так прост как кажется, доменные и групповые политики, права, доменные учетные записи, права на запуск и остановку сервисов, конфликты сервис-паков, наличие и поддержание актуального состояния драйверов. Тут же проблемы с "железом", которое ведет себя мягко говоря не адекватно, но системная поддержка его есть.
Отдельная тема система активации и корпоративных ключей для офисных программ. Политики реестра, его обновление и чистка. Политики файерволов.
Почта. Outlook + Exchange. Exchange - большая отдельная тема, до конца раскрытая единицами (у каждой единицы лет по 15 опыта за плечами и все в системном администрировании). Sharepoint - головная боль любого Windows админа.
Прикладное ПО. Что-то ставиться криво, что-то выносит систему в BSOD. Нужно следить за "лицензионной чистотой", обеспечивать бесконфликтную работу, опять-таки чистить реестр уже с другой стороны. Дампы и адреса, анализ логов и понимание проблем
Обновление. Критические обновления, зеркалирование, кумулятивные обновления, бэкап данных и образа дисков, периодическое обновление образов.

Уже не так весела и легка жизнь Windows админа? И ведь я смотрю на вещи очень и очень примитивно, только по рассказам друзей и коллег понимая, какова же реальность этой каждодневной работы. А ведь Linux администрирование - это также сложно, но только с другой стороны. И в обоих системах есть нюансы, и профессионал должен их знать, и уметь оперативно решать проблемы, и минимизировать время простоя (что иногда ой-как не просто).

Мне аналогией первого порядка автоматически мниться замечательная история про "если бы водителей принимали на работу так же, как программистов". Ну давайте пофантазируем, на мой взгляд Эксперт в Java - это

Досконально знать JavaSE SDK - типизацию, принципы ООП, generics и autoboxing, аннотации и 6 типов синхронизации потоков, JDBC и AWT, Swing и XML-средства. Знать, понимать и уметь использовать web service annotations. Четко понимать всю иерархию Collections, знать разницу между Set, List и Map, понимать назначение тех или иных реализаций, уметь создать свою реализацию ArrayList, LinkedList, HashMap, TreeHashMap. Уметь написать свой quicksort для коллекций. Досконально знать возможности пакета reflection, особенности реализации garbage collector и class loader. JAAS
Досконально знать JavaEE SDK - servlets, EJB, JSF, Portlets, JPA, JNDI, RESTfull, XML-RPC, JAXB, JAXR, JSP, WebBeans, JTA, JAXP, JMX, JAF, StAX, RMI
Понимать особенности работы JVM - оптимизации, принципы и стратегию работы JIT, механизм компляции и трансформации байт-кода, встроенные в JVM механизмы оптимизаций. Желательно знать, как и с помощью чего они реализованы.
Thrid-party frameworks - Spring, Hibernate, JDO, парочку парсеров (Xserces, jdom, dom4j), Apache commons, SpringSecurity. И разумеется не просто знать, а уметь использовать и понимать принципы реализации. Знать почему лучше фрэймворк А, а не фрэймворк Б.
Версионирование. Отличия как в аспектах языка, так и в реализациях между Java 1.1, 1.3, 1.4, 5, 6, 7. Умение писать обратно-совместимый код, проектировать переносимые приложения. Понимать, как средствами предыдущих версий реализовать механизмы из более старших.

А еще test frameworks, OSGi, AspectJ, Grids, Hadoop, GWT, Groovy/Grails и многие, многие другие. Однако, поскольку тезис наш о том, что "PHP давно не экзотика", то все теже знания и в томже объеме программист должен иметь и в PHP. А как же иначе? И "Python давно не экзотика", значит и Python необходимо знать на том же уровне. А еще С/С++ (ну вдруг нужно будет низкоуровневый модуль написать) и Ruby-on-Rails (ну вдруг нужно будет что-то быстро написать, не нанимать же еще специалиста). И разумеется 1C, ведь все ведут бухгалтерию, ну и Парус до кучи - а то ведь и с госорганами могут быть подряды.

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

А как только речь заходит об админе, то он разумеется должен, поганец, знать Windows и Linux, который давно не экзотика (без поправки на то, Linux - это Ubuntu, Debian, Slakware, Gentoo, RedHat, Mandriva, ASP и еще куча дистрибутивов).

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

jeeconf announcement

2011-03-29T01:44:00.001+03:00

В конце весны 21 мая XP Injection приглашает вас в Киев на специализированную конференцию, посвященную разработке на Java. JEEConf -- это крупная конференция, целью которой является собрать вместе всех, кто использует Java технологии для разработки.

Конференция направлена в первую очередь на:

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

Задача конференции JEEConf заключается в том, чтобы собрать как можно больше практиков и осветить процесс разработки приложений с помощью современных Java технологий. Количество «сухих» теоретических докладов будет сведено к минимуму, а основной акцент будет сделан на практическое применение и разработку реальных проектов. Мы планируем собрать на конференции большое количество докладчиков из разных стран. К участию в конференции приглашаются разработчики, архитекторы, тестировщики, а также руководители и лидеры команд. Если ваша работа связана с Java, то вам стоит принять участие в нашей конференции. Присоединяйтесь, будет интересно!

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

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

Саранча

2011-03-17T18:49:00.000+02:00

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

И я могу понять, когда люди достигли своего потолка - в профессии, в бизнесе, в развитии. Когда кому-то просто тесно в рамках специально усложненной, не совершенной, не работающей системы. Когда кто-то не хочется связываться с недалекими, больными синдромом вахтера чиновниками и силовиками. Это я могу понять. Я могу понять желания вести бизнес в США и не желание делать это в Украине. Более того, я сам считаю, что если есть возможность вести бизнес не в Украине, то стоит делать именно так. Не готова моя несчастная страна к предпринимательству, слишком еще она больна метастазами совка, слишком много еще классовой ненависти, слишком многие хотят получать, но не хотят работать.
Но что странно, люди, которых можно понять в их желании уехать из страны, не кричат об этом на каждом углу. Они просто едут. Просто делают, как и делали до того - не жаловались "мне не дали", "мне не создали условий", "мне не предоставили возможности", "на работе не было на это времени". Нет, просто делали, просто создавали, просто строили. А кричат больше всех те, кто ничего в этой жизни еще толком не достиг - может быть закончил институт, может быть поработал несколько лет. Может быть, благодаря конъюнктуре рынка, заработал несколько больше своих сверстников. Может быть - даже больше родителей. И вот тут в голову бьет струя желтой жидкости, и Чувство Собственной Важности взлетает до небес - "да я уеду", "вы еще пожалеете", "я вообще перестану платить налоги", "новый виток утечки мозгов". Куда? Что? Ау, дружище! Ты никто и звать тебя никак, ты никому не нужен, от тебя толку если и не ноль, то чуть. Кому ты грозишь? Что ты умеешь? На какое отношение ты рассчитываешь, если откровенно задираешь лапки при первых же трудностях?
И носится потом такая саранча по миру, срываясь с места при первых же трудностях или опасностях. И удивляется, за что же ее так не любят? В посольствах очереди, взиы какие-то, правила - не иначе заговор. Нет, не заговор, просто никто не хочет кормить саранчу. Ее можно терпеть, но радоваться ей никто не будет, ну и инсектофобия опять же. И не любовь к паразитам.
Каждый волен выбирать свою судьбу самостоятельно, каждый волен распоряжаться своей жизнь по-своему. Нужно только помнить, что отношение к тебе, если не во всем, формируется тобой и твоим поведением. Не нравится, как к тебе относятся? Не ценят на работе? Менеджер идиот? Жена пилит? Нет друзей? Не можешь заработать? Нет творческой реализации? А есть за что ценить, уважать, поддерживать, платить и давать творчески развиваться? Уверен, что проблема не в зеркале? Точно уверен? А если еще подумать? Мне не нужно отвечать, со мной не нужно быть честным - ответь себе, по большому счету остальным-то наплевать.

SeleniumCamp 2011::Общие впечатления

2011-02-27T10:27:00.002+02:00

или по горячим следам первой Selenium конференции

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

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

Pro

WiFi. Я был бы готов простить гораздо больше недочетов и фэйлов только за то, что параллельно с открытой гостиничной WiFi сетью работали 3 (три!) запароленные точки от SeleniumCamp. Вчера дважды падал Twitter, но ни разу не лег WiFi конференции. Правда сразу после регистрации мы дружно уложили гостиничный, но это потому что никто не читает объявлений. Огромный, очень жирный плюс организаторам. Ребята, вы сделали в чистую Питер, с его Sun Tech Days
Регистрация поделенная на три потока в алфавитном порядке. Очень хорошее решение
Помещения для докладов - был только в A и C. очень хорошо, не идеально, но очень хорошо. Достаточно места, достаточно стульев, вода доступная в холле - и опять таки Питер молча покуривает в сторонке
Питание - Чайкофф очень хорошее место и 50 грн. очень хорошая цена за то качество и обслуживание, которое мы получили
Докладчики - все, кого я слушал, были на высоте. Кто-то более профессионален, кто-то менее, но селекция действительно была, и действительно дала результаты
Не совсем понятная фигня, из которой можно сделать всякое в пакете участника - просто замечательная вишенка, на общем торте. Молодцы
Кофе с печеньками в 16:00 - как ни странно, при всей тесноте, которую могут создать 300+ человек, всем всего хватило и никто никого не толкал в локти или спины. Питер по прежнему курит в сторонке

Contra

Розетки и холодные помещения. Это минус прежде всего гостинице "Братислава", но о нем стоит таки упомянуть. В аудиториях розеток нет. В холле возле конференс залов A и C очень прохладно. Народ жаловался на холод в зале A. Неприятная мелочь, которая конечно не может испортить впечатление от конференции, но говорит о том, что в гостинице "Братислава" я останавливаться не буду и другим не советую. Ресепшин у них как в Европе, но только ресепшин
Удаленность "Чайкофф" от места проведения. Конечно по киевским меркам - это два шага, но все-таки необходимость куда-то идти, потом идти обратно - со всеми вытекающими сборами, одеваниями, поисками и т.п. несколько напрягает. В данном случае все это с лихвой компенсируется качеством еды и обслуживания (я уверен, что "Братислава" не смогла бы дать тоже качество при той же цене, и даже за бОльшую цену), но все-равно это не есть айс
Оплата обеда. Разумеется в результате все получилось и было на высоте, но в следующий раз мне бы очень хотелось иметь возможность оплатить и конференцию, и обед единым платежом. Т.е. либо стоимость питания нужно включить в стоимость конференции, либо сделать опцию при выставлении счета. Плюс, талон на питание очень желательно помещать в пакет участника изначально. Я-то спросил, но некоторые стояли в очереди два раза. Не смертельно, но можно улучшить
Место регистрации выбрано не очень удачно, ИМХО. Было бы совсем хорошо разместить стойку в холле, это помогло бы избежать той толкучки и очередей, которые так любят создавать наши люди
Программа конференции. Идеальным форматом я по прежнему считаю лист формата А4, сложенный гармошкой по разделительным линиям время-поток А-поток Б-поток В и вложенный в нашейный бэйдж участника. Это невероятно юзабельно. Можно конечно распечтатать программу прямо на бейдже, но не уверен в читабельности обоих артефактов

Далі буде...

Outsourcing as service

2011-02-02T15:46:00.000+02:00

С неприлично огромным опозданием исполняю обещание дать ссылку на статью Сергея Бережного "Как определить, хороший ли сервис мы предоставляем заказчику?". Чем интересна тема для меня лично? Мне всегда импонировали смелые и безрассудные идеи. А данная идея изначально кроме улыбки ничего не вызывает - ну что тут рассуждать? Платят? Значит все устраивает!
И только подумав несколько больше, начинаешь понимать, что не факт - может быть устраивает, да не все; может быть не устраивает, но кроме нас никто не сможет; может быть все что угодно. И если мы не спросим (это вообще классическая формула - спрашивать, уточнять, выяснять, обосновывать. Очень многое в мире становится проще и доступнее), то никогда не узнаем.
Вот такой вот анонс, за подробностями - к Сергею.

Игра в революцию

2010-11-12T00:23:00.002+02:00

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

Я помню как все начиналось

Проголосовав на участке единственным для меня способом, я не включал 5й канал, не читал новостей, не смотрел репортажей exit poll'ов - боялся сглазить. Я пытался себя чем-то занять, увести мысли от политики, от выборов, от судьбы страны. Мне казалось, что от результата зависит все - будет здесь Россия или останется Украина. Останется моя страна независимой или станет Украинской Областью. Жить в России мне не хотелось тогда и уж тем более не хочется сейчас, несмотря на очевидные преимущества в удобстве. Ночью, 31 октября 2004 года я курил на кухне и вдруг внезапно понял - все напрасно. ВСЕ НАПРАСНО! просто нам дали выплеснуть пар, поиграть в демократию и создать видимость конкуренции. В политический преферанс выигрывает не тот, кто хорошо играет, а тот, кто пишет "пулю", без вариантов. И без вариантов в первую очередь потому, что люди не готовы отстаивать свои права - пошумят денек на площади, самые принципиальные дождутся милиции. И все... И все. Не готова страна, не готов народ, не свободен, не решителен, кина не будет.
Ноябрь 2004го был холодным. я как-раз был записан делать очередную флюрографию и видел, как во дворе поликлиники Ленинского района девочки и мальчики с погонами курсантов бегают греться в автобус. В соседнем автобусе и рядом прохаживались представительные молодые люди в зимнем камуфляже "Беркута". Ощущение "кина не будет" стало полным. А потом был Майдан. И суд. И 23 января инавгурации президента Ющенко. Это была революция. Но дьявол в деталях, тогда я не знал и не понимал, что революция была. Люди стояли против силы долгие три месяца. Боролись и побороли. И вот тут все, конец. Революция была. Люди действительно оказались не готовы, не готовы отстаивать свой выбор, не готовы отстаивать свои права, свои принципы. Самая проактивная часть решила, что она сделала все, и теперь все станет хорошо само-собой. Самая реактивная часть - начала требовать себе преференций за "стояние на Майдане".

Мадам лягли и просят

Мы разошлись по домам, и стали ждать когда же наступит обещанное "хорошо". Вместо того, чтобы на революционной волне по капле выдавливать из власти и кабинетов засевших там временщиков и бюрократов, мы решили, что это сделают за нас. Мы ведь выбрали правильных людей! Теперь мы можем расслабится. Мы погрязли в спорах "проплаченный/не проплаченный Майдан", "кто лучше Кучма, Ющенко или Янукович", "сам Аваков отвечает на форуме или за него кто-то пишет". Мы утратили инициативу в первую очередь потому, что мы не знали, что мы будем делать ПОСЛЕ того, как победим! Нам важно было победить и мы победили. Чего же боле? Оглядываясь назад я понимаю, что Ющенко ДЕЙСТВИТЕЛЬНО был президентом Майдана - он победил. И, так же как и мы, не понимал, чего же боле? Ничего и не вышло. Программа "10 шагов навстречу людям" так и осталась прокламацией. Потому что никто не знал, как именно ее будут выполнять, откуда будут брать деньги, как будут бороться с наместниками... Не знают и теперь. Главное было победить. Или... может быть никто всерьез не рассчитывал на победу? Может быть главное было ХОРОШО ПРОИГРАТЬ? и тогда становится очевидным паралич власти, вялые решения и действия в месяцы максимальных полномочий.

История повторяется

Сейчас история Янукович vs Ющенко повторяется на харьковском уровне в виде противостояния Кернес vs Аваков. Я читаю новости и форумы и у меня создается ощущение дежа-вю - все уже было. И точно также мы давили на киевскую власть в 2004. И победили. И все - в результате ничего, кроме эфемерного места в эфемерном рейтинге по свободе слова. Форумы сторонников Авакова очень бодры и веселы. Люди бегут на площадь с флагами и транспарантами. Бодро обсуждают сколько было людей, кто чего видел, кто чего сказал. Я хочу задать только один вопрос - что будет дальше? Что будет, когда вы победите? Вы знаете, что вы будете делать, после того, как ваши требования удовлетворят?! По-моему нет. Если же знаете, расскажите. Покажите мне хотя бы приблизительный план каждодневной кропотливой работы по контролю за властью. Покажите рычаги, которыми вы собираетесь влиять на мэра Авакова. Если их нет, то совершенно не важно, кто победит - Аваков, Кернес, дядя Вася-сантехник - ничего никуда не денется. На смену одной команде вороватых чиновников прийдет другая.

Дети?

Увы мне, но мне по-прежнему кажется, что украинский народ еще подросток - сейчас важно, чтобы заметили, чтобы обязательно согласились. Чтобы все было так и только так, как я говорю. И есть только два цвета - черный и белый. И есть только две силы - Добро и Зло. И все ясно, все понятно, чего тут думать - если ты за Добро, у тебя все обязательно будет. Рано или поздно, так или иначе. Вот выберут Добро - и сразу дороги станут ровными, квартиры дешевыми, цены низкими, зарплаты высокими... дети-дети.
Потому и бегут на площадь мои сограждане - там "движуха", там весело, там ощущение причастности. Там игра в революцию. и слава Богу только игра, потому что настоящая революция - это кровь и слезы, террор и расстрелы, произвол власти и власть произвола. Моя несчастная страна уже проходила это не раз - ничем хорошим это не закончилось. Эволюционный путь лучше, как по мне

Кадровая проблема::Общие наброски

2010-11-12T00:07:00.005+02:00

Этой статьей я бы хотел открыть цикл заметок, посвященной кадровой проблеме на рынке труда в ИТ-секторе Украины. И после 11 ноября 2010 года в том, что проблема есть, не может быть никаких сомнений. Если кто-то еще не в курсе, сегодня киевский филиал компании LuxSoft давал 2к долларов за успешную рекомендацию Java Developer'а и 2к долларов при выходе на работу. Будущее опять наступило раньше, чем можно было предположить
Основной проблемой рынка труда является острая нехватка кадров. Тому есть несколько причин, каждая из которых сама-по-себе весьма важна. Однако, главнейшей из причин, я считаю политику компаний-гигантов, которые в эпоху бурного роста 2005-08 годов стремились больше брать готовые кадры с рынка, чем инвестировать в обучение новых. Таким образом, мы оказались в ситуации, когда рынок заполнен либо джуниорами, которые не имею достаточных знаний и опыта, чтобы сразу давать хороший результат; либо переоцененными в финансовом и должностном плане сеньйорами, которые на самом деле являются крепкими мидлами, и мидлами, которые в лучшем случае являются очень хорошими джуниорами.

Кто виноват?

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

Что делать?

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

Постепенное введение практики, когда высококвалифицированные инженеры работают не в одном проекте, а в нескольких. Достичь этого можно снимая рутинную нагрузку с сеньйоров и передавая ее джуниорам. Таковое введение позволит улучшить
1. Лояльность квалифицированных кадров - люди начнут использовать накопленные зания и опыт, избавятся от рутины, будут получать больше удовольствия от работы.
2. Качество проекта - архитектура, которая будет разрабатываться людьми априори квалифицированными с гораздо большей степенью вероятности будет отвечать требованиям к качеству проекта, чем это происходит сейчас
Одним из первых шагов может стать организация экспертных групп, состоящих из высококвалифицированных инженеров. Задачей таких групп я вижу в-первую очередь анализ новых и существующих систем с точки зрения качества кода и архитектурных решений. Второй, но не менее важной задачей, таких групп может стать техническая экспертиза проблемных, важных или не известных остальному персоналу решений, если говорить грубо - эдакая скорая помощь и внутренняя база опыта в едином лице. Организовать такие группы можно
1. Через списки рассылки. Возможно на первых порах нет необходимости закреплять какой-то особенный статус или выделять команду
2. Несколько раз в месяц на регулярной или не регулярной основе проводить брэйнштурмы посвященные улучшению кода, архитектуры, процессов
3. Выделить или вменить в обязанности группе необходимость еженедельных (вариант ежемесячных треннингов) посвященных методологиям повышения качества ПО
И последнее, применяя и расширяя предыдущие практики, добиться ситуации, когда проекты будут менее человекозависимым, а следовательно появится возможность строить более разноуровневые и сбалансированные команды.

Возможно не лишним было бы обсудить тему инкубатора кадров. Организованных по принципу курсов повышения квалификации МИИК или Телесенс-Академии. Но здесь есть два очень тонких момента а) не факт и далеко не факт, что инвестиции в человека будут окупаться (из множества кадров, которые будут учиться, 60-80% будут проходным материалом, по крайней мере на первом этапе) и б) не факт, что инвестиции будут окупаться непосредственно у инвестора (потенциально, из оставшихся 40-20% не все останутся в компании-доноре, по разным причинам). Телесенс-Академия страховала оба риска тем, что курсы были платными, возможно такой вариант имеет смысл. Как альтернативу можно рассмотреть плотное сотрудничество и обмен специалистам с уже существующими учебными организациями типа академии "Шаг". Но в любом случае, эта тема сильно связана с темой образования, по поводу которого мы можем очень долго и очень бессмысленно спорить.

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

Мы стоим на пороге демографической ямы 1993-98, в условиях вакуума "унтер офицеров", или если угодно кадров среднего уровня, на рынке труда. В этой ситуации инвестиции в обучение и повышение квалификации кадров становятся не блажью, но необходимостью. Разумеется, если организация планирует расширятся в следующие 5 лет. Нам негде взять новых людей, никто не подготовит их для нас, более того их УЖЕ не родили для нас, так что работать нам прийдется с теми людьми, которые у нас уже есть.

ITшники и налоги

2010-09-20T09:21:00.000+03:00

пьеса в пяти действиях

действующие лица:
- не самое лучшее правительство не самой богатой страны (П)
- самые умные ITшники (СУ)
- самые громкие ITшники (СГ)
- народ (Н)
место действия - где-то в восточной Европе
время действия - не определено

Действие 1

П: у нас дефицит бюджета и вообще полная фигня. надо что-то делать. давайте наведем порядок с налогами (под порядком понимается такое расределение, чтобы не ущемить клановых интересов и показать заботу о народе)
П (с трибуны): у нас будут самые лучшие налоги!
Н: опа! опять нас пацаны кинуть хотят, да? вот уроды!
П (с трибуны): вот мы тут подумали и решили, налоги будут вот такие
Н: нифига не понятно. но нам-то пофигу. главное, чтобы взятки были фиксированными и платить было понятно кому. а там по пцански разберемся
IT crowd: че? ПРОЦЕНТЫ? сколько?! нифига себе! не-не-не, так не пойдет!
П: все! мы решили! новым налогам быть!
IT crowd: нас 2% от населения страны. мы сила! вместе нас много и нас не победить! да мы, да мы! (пытаются встать с кресла и выйти на улицы. солнце слепит, ходить тяжело, вокруг ходят каки-то люди, которые не поинмают слов компиляция и упячка. в ужасе прячутся под клавиатуры)
СГ: все! уезжаем нах! не ту страну назвали Гондурасом! (последние 20 лет, на любое внешнее раздражение следовала именно такая реакция)

СУ: не-не-не. стоп. мы согласны платить налоги в Голландии, в США. а тут их все-равно разворуют. мы вот платили по 200 бумажек каждый месяц. этож целых 2400 бумажек в год. этож почти 4 пенсии - почему пенсионеры так плохо живут? этож целых 2 сантиметра дорог можно отремонтировать - почему такие плохие дороги? этож целых 3 сантиметра домов можно построить - почему дома стоят так дорого? ясное дело - разворовали! ни копейки не дам! (полковник службы безопасности записывает в книжечку имя и фамилию. следующий пост будте посящен беспределу полиции)
П (к IT crowd): вы чего, собственнно, хотите?
IT crowd: не платить!
П: не, так не пойдет.
IT crowd: уедем! не будем платить! мы умные, да!
П: ну давайте поговорим?
IT crowd: да о чем говорить?! это же ПРОЦЕНТ от дохода! понимаете ПРОЦЕНТ! это ж все так платят! но они-то копейки получают, а мы... не, вот была фиксированная ставка налога и можно было в валюте получать. а сейчас... не, ну о чем говорить?
П: ну вот об этом и поговорим?
IT crowd: вы готовые об этом говорить?
П: ну да, выдвигайте представителей.
IT crowd: ну давайте поговорим
занавес

Действие 2

П: ладно, вот такой расклад вас устроит?
IT crowd delegates: а можно совсем не платить?
П: нельзя!!!!
IT crowd delegates: эх... ну мы же должны были попытаться. ладно, такой расклад нас устроит
П (с трибуны): мы тут подумали, и решили, вот таким налогам быть
IT crowd (к представителям): продажные твари! мы что заказазывали? НЕ ПЛАТИТЬ! почему мы до сих пор что-то должны?
СГ: не, ну вы че внатуре? вы вообще этих козлов нагнуть должны были, чтобы они нам приплачивали! (на сцене появляется спецназ и демостративно бьет самых громких)
СГ: ну мы имели ввиду дотации от государства. вы чего? (спецназ уходит со сцены)
СГ: испуг... вобщем вот так нужно с полицией! видали? (опасливо поглядывая в сторону, куда ушли спецназовцы)
IT crowd (к правительству): нифига мы не согласные
П: ну вы определитесь
IT crowd: вот вам другие делегаты
П: ну началось. давате так. второй раунд и усе
IT crowd: давайте
занавес

Действие 3. Либретто ITшника

(хор): я ITшник. я интеллектуальная элита общества. я сверхчеловек. не чета тем людишкам, которые не умеют правильно сайт настроить. я двигатель прогресса. именно благодаря мне страна все еше не стала банановой республикой.
(СГ): внатуре блин... (опасливо оглядываясь по сторонам). мы хотели сказать, действительно. все именно так. нас надо любить. к нам надо прислушиватся. хотя чего возьмешь с простых людей
(СУ): и не говорите. как могут люди без ITшного образования вообще что-то решать? у них же интеллект маленький
(СГ): бугога. маленький! короткий! бугога!
(СУ): ну вот посмотрите на Голландию
(СГ): офигенно!
(СУ): ну вот посмотрите на Литву
(СГ): прикольно!
(СУ): да на Грузию посмотрите
(СГ): фигассе! не ту страну назвали Гондурасом!
(СГ): а мы что говорили? надо валить (создают сайт и начинают собирать историйки)
IT crowd: надо валить! вот там заживем
(СУ): мы понимаем, что там люди стоили все это много лет. и может быть даже мы могли бы здесь строить что-то много лет. но мы молоды и сильны. мы не хотим строить
(СГ): мы хотим бухать, трахаться и сидеть в ВОВ
(СУ): ну да, ВЫ хотите сидеть в ВОВ. а все остальное ВАМ не доступно
(СГ): это вы на кого наехали?
(СУ): с точки зрения банальной эрудиции люди делятся на две не равные части, одни могут мыслить абстракно и понимать намеки, а другие не особенно отличаются умом от обезьяны
(СГ): че?
(СУ): проехали. короче, мы хотим жить здесь и сейчас. и нефиг нас заставлять участвовать в общественной жизни. кормить чьих-то детей и чьих-то родителей. так?
IT crowd: а то!
(хор): надо валить! надо валить! надо валить!
занавес

Действие 4

П: вот таким налогам быть
IT crowd: что? ФИКСИРОВАННАЯ СТАВКА? да вы охренели совсем! нет, чтобы ПРОЦЕНТ сделать?
П: чиво?
IT crowd: вот уроды!

Действие N. вымышленное, ITшники и народ

(хор): вставай, страна огромная, вставай на смертный бой! с воровской силой темною, с налоговой чумой!
(Н): куда с оружием приходить?
(IT crowd): без оружия пока. будем протестовать мирно и тайно (некоторые почесывают жетые синяки)
(часть Н): сцыкуны. когда эффекта не даст, позовете. (уходят)
(IT crowd): мы не испугались! просто насилие порождает насилие... ну идите-идите. потом нам "спасибо" скажите
(Н): так че делать-то будем? и объясните по-простому, против чего собираемся?
(IT crowd): ну налоги большие
(Н): ну да. они там совсем охренели. вот у меня ювелирная лавка - это все заводы... вот у меня цех по пошиву одежды - это все фабрики... вот у меня секонд-хэнд на таможне (глухие удары). а я-то думал, че у меня одежда хреново продается? (неясный гул голосов, потасовка, от толпы отваливаются избитые граждане)
(IT crowd): стойте, стойте! у нас же одна цель, большие налоги надо снизить
(Н): конечно! до нуля!
(IT crowd): именно! до нуля! пусть отчитаются сначала, куда они наши 200 бумажек в месяц потратили!
(Н): да, пусть отчитаются!
(IT crowd): это не справедливо! мы получали 1000! платили 200! одолжение им делали! а они теперь хотят, чтобы мы платили 1000! каково?!
(Н): постойте, вы же компьютерщики? нам рассказывали, что вы много получаете? вот у меня сын, Вовка, недавно тачку себе купил, иномарку! это на 1000 бумажек? я вот слесарем работаю и то больше получаю. да какая там машина?
(IT crowd): мужик? ну ты подумай? ну какая тысяча бумажек? тысяча денег! и это так, для идиотов. умные получают 2-3 тысячи денег
(Н): а в бумажках это сколько?
(IT crowd): ну где-то 10-20 тысяч
(Н): ага! и эти еще чем-то не довольны?
немая сцена. толпа народа окружает ITшников. слышны глухие удары. крики "помогите убивают" на сцене появляется спецназ. толпу разнимают, часть уводят в наручниках.
на следующий день в интернет СМИ появятся статьи о произволе власти и давлении на свободу слова. в блогах и форумах появятся посты о произволе полиции.
занавес

про собеседования 2

2010-09-17T02:03:00.000+03:00

или мой метод

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

составлено в форме письма другу (собственно является частью комментария к посту)

всегда помни, что для соискателя собеседование стресс (даже если это не так, все равно помни об этом). поэтому улыбаемся, шутим, начинаем собеседование не с технических вопросов, а с разговоров о последнем проекте, целях и желаниях кандидата. даем человеку поговорить о себе и своих достижениях. пусть расслабится. если HR уже говорил на эту тему, а ты не присутствовал, все-равно даем кандидату поговорить. но лучше, чтобы ты присутсвовал с самого начала. или ты спрашивал про это, а не HR. пусть соискатель расслабится, забудет, что это СТРАШНОЕ И УЖАСНОЕ СОБЕСЕДОВАНИЕ, ОТ КОТОРОГО ЗАВИСИТ ЕГО КАРЬЕРА И ЖИЗНЬ (С)
к техническим вопросам переходим плавно, например фразой "а теперь давайте поговорим о Java, Вы же понимаете, от меня требуют отчета". попробуй убедить кандидата в том, что тебе не особенно интересно здесь устраивать экзамен, просто тебя начальство назначило (даже если это не так). вовлеки его в игру, пусть делает тебе одолжение. пусть с самого начала почувствует себя ПОЛЕЗНЫМ ТЕБЕ, ВАЖНЫМ ДЛЯ ТЕБЯ
заведи себе чеклисты. Basic и Advanced. начинай с простого, если кандидат бодро отвечает на простые впросы, сразу переходи к расширенному листу. так быстрее, проще и спокойнее тебе. так лучше для кандидата - он видит стандартную процедуру. не импровизацию направленную на завалить его
заведи себе Impossible or Just Known чеклист. вопросы, ответы на которые нужно просто ЗНАТЬ. очень сильно помогает в работе со "звездами". если кандидат зарывается, можно начать именно с этих вопросов. пусть его попустит
помимо всего прочего, в процессе разговора прислушивайся к человеку, пытайся его понять. помни, перед тобой ВСЕГДА прежде всего ЧЕЛОВЕК и уже потом специалист, программист, сотрудник, соискатель. поступай с другими так, как хочешь, чтобы поступали с тобой. и потом, поняв что за человек к тебе пришел, ты сможешь определить, сработаетесь вы или нет
всегда пытайся понять, чем данный человек может быть ПОЛЕЗЕН команде, не важно чего он не знает, важно, чем он будет ПОЛЕЗЕН
никогда, слышишь, НИКОГДА не унижай человека, не устраивай ему стресс-интервью, не обсужай его с коллегами непосредственно на собеседовании. не верь книжкам и статьям, где пишут, что это поможет понять, как человек работает в стрессовой ситуации - это ложь. все эти практики всего-лишь попытка самоутвердится за чужой счет. сходи в спортзал, попинай грушу
попроси прислать кусочки кода, которые соискатель считает достойными публикации. если таковых нет, пусть напишет и пришлет. код не обязательно должен быть связным или рабочим. вообще это хорошее правило для начала разговора. пусть HRы просят приложить образцы к резюме. "программирование на бумажке" - зло и ересь, программирование на выделеном компьютере - бессмысленная трата времени и ресурсов. СОБЕСЕДОВАНИЕ НЕ ДОЛЖНО занимать больше ЧАСА-ДВУХ времени кандидата. да-да, именно ВРЕМЕНИ КАНДИДАТА, количество твоего времени исключительно проблемы менеджера, проекта и твои

Java talks

2010-09-15T01:35:00.000+03:00

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

я вернувся домів

2010-07-15T03:48:00.001+03:00

или никто никуда не бежит

я нюхав коку в Амстердамі,
у Мюнхені пиво пив,
пальці рвав у Монте-Карло,
в Парижі все на баб спустив.
бився з негром у Нью-Йорку,
в Варшаві трипером хорів,
мні це все осторчортіло -
я вернувся домів
(с) Брати Гадюкіни

как на небе только и разговоров, что о море и о закате, так в Украине только и разговоров, что о Европе и Америке. и небо тут голубее, и трава зеленее, и почему-то все дешевле. особенно остро это воспринимается сидя в отеле за 20 часов пути от дома. в той самой стране, где говорящие мечтают оказаться.
против обыкновения, я не стану растекаться мыслею по древу и опровергать каждое утверждение. небо и трава здесь такие же, цены... техника дешевле и дешевле в несколько раз, мировые бренды одежды тоже можно взять по бросовым ценам (а можно и не взять, это как повезет). все остальное дороже. и крепко дороже. а то, что дешевле, то по качеству сравнить нельзя даже с гинлым луком в харьковских супермаркетах. и считать деньги в чужих карманах мы тоже не станем. у нас от налогового кодекса всех в дрожь бросает, а что будет если все налоги платить прийдется? а тут платят. дело не этом. и даже не в не привычном вкусе продуктов, дело наживное.
дело в другом. я искренне скучаю по друзьям, у меня много друзей и я очень их люблю. и жить в часовом поясе, когда бОльшую часть времени спишь либо ты, либо твои друзья очень сложно. я скучаю по родным, пусть мы видимся не часто, но мы видимся. а здесь -- нет. и есть еще три вещи, по которым я невыносимо скучаю -- 1) возможности завалиться в гости с фразой "привет. ты дома? гостей принимаешь? мы тут случайно шли мимо...", 2) возможности пройти от одной кофейни до другой менее чем за 1,5 часа и 3) траве и древьям, которые растут так, как выросли; людям, которые улыбаются тебе, потому что тебе рады; рукопожатиям и объятьям просто от избытка чувств. а в остальном тут удобно, утилитарно, культурно и вежливо. тут все так боятся наступить друг другу на ауру, что расходятся минимум в метре друг от друга. если вы космополитичны, если вас не напрягают разорванные личные связи, если вы хотите жить в коконе, если вам подходит жизнь по Великому Американскому Стандарту -- США ждет вас, уехать сюда не так уж и сложно.
мне не нравиться здесь жить, я не привык и даже уже успел устать от ощущения статиста в большом кукольном театре, среди декораций, марионеток и нарисованных цветов. я домой хочу. и жить я хочу дома, в Харькове, в Украине. я неверное один такой сентиментальный дурак

Liferay::Plugins

2010-06-18T14:11:00.002+03:00

Plugins SDK

кроме Extension Environment Liferay предоставляет готовую для работы среду для разработки плаигнов - Liferay Plugins SDK. среда представляет собой ZIP архив, который содержит структуру каталогов и файлов сборки Ant. после распаковки архива можно сразу начинать работу. с другой стороны, в отличие от Extension Environment, ни один из плагинов не является плотно интегрированным с Liferay и может быть разработан как с помощью Liferay Plugins SDK, так и без нее.
итак, какие же бывают плагины, с точки зрения Liferay?

Portlets

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

у каждого приложения есть доступ к настройкам - PortletPreferences. настройки сохраняются внутри портала и доступны каждому портлету как при работе, так и между развертываниями. портал отвечает за хранение PortletPrefereces
каждый портлет может находится в трех состояниях VIEW, EDIT и HELP.
состояние VIEW - является состоянием по-умолчанию и именно в нем портлет осуществляет большинство своих функций.
состояние EDIT - обычно используется для изменения настроек портлета. это может быть конфигурация внешних источников, изменение PortletPrefereces и тому подобное
состояние HELP - говрящее само-по-себе. предосталение информации о том, что делает портлет и как с ним работать
каждое окно портлета внутри портала может находиться в трех состояниях NORMAL, MAXIMIZED и MINIMIZED
Look&Feel портлетов определяется порталом, если не реализовано иное. как правило это означает, что разработчику больше не нужно программировать стили для каждого портлета. достаточно написать их однажды. но это уже Theme

hook

Theme

тема представляет собой набор шаблонов, для гернерации страниц портала; набор стилей CSS применимых для всех компонентов и набор картинок, которые будут использованы в портале. тема предоставляет возможность создания нескольких цветовых схем одной и той же темы.
строго говоря, в Liferay версии старше 3, тема представляет собой не столько шаблоны, CSS и картинки, сколько изменения к станадртным темам. но никто не мешает написать свою тему "с нуля". по-умолчанию для описания шаблонов использутеся Apache Velocity. но в Liferay заявлена поддержка практически любого языка шаблонов.
правила развертывания и использования темы описываются деплоймент дескриптором liferay-look-and-feel.xml

Layouts

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

Hooks

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

hey, hey, I save the world today

2010-05-21T01:58:00.001+03:00

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

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

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

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

какой из этого можно сделать практический вывод? менеджеру на заметку: мальчики до 1989 года рождения в 90% случаев мечтали спасти мир, можно поптытаться их этим мотивировать. и не важно, воспримут они это как геройство, или как вызов. в результате-то возьмуться. ну хотя бы 6 из 10, а это уже показатель.

Sun Tech Days St. Petersburg::Вести с полей::День Второй

2010-04-10T17:10:00.000+03:00

второй день выдался более спокойным и, к моему удивлению, не менее продуктивным, чем первый. основной моей целью 9го апреля была третья и последняя часть доклада по J2EE 6. и она состоялась и удалась на славу.
удивительно приятным оказался доклад про внутреннее устройство JVM Ивана Крылова и Дениса Шипелёва. удивительно мне было то, что презентация была поставлена и исполнена на уровне, которым обычно отличаются презентации западных лекторов и евангелистов. никаких "в то время как наши корабли бороздят просторы Большого Театра" и подобной псевдотехнической и псевдозаумной воды, привычку к которой вбивает наше несчастное пост-советское образование. никакого косноязычия или, наоборот, изобилия малопонятных терминов. никакого строго вызубренного текста. все живо, все по теме, все интересно, все динамично. спасибо огромное ребятам.
в плане организации улучшилось только две вещи

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

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

Sun Tech Days St. Petersburg::Вести с полей::День Первый

2010-04-09T10:22:00.000+03:00

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

Pro

из позитивного нужно отметить невероятно высокий профессионализм докладчиков. очень опытные, очень грамотные технические специалисты Simon Ritter, Angela M. Caicedo и Alexis Moussine-Pouchkine это те, которых слушал лично я. прекрасный английский язык, отличная подготовка, яркие и запоминающиеся презентации. все на 5+.
стендовые доклады тоже порадовали. действительно отличные специалисты, замечательные раздаточные материалы. все очень рады помочь, объяснить, рассказать, уточнить
регистратура и информаторы. чудные ребята и девочки, радушные, улыбчивые, приветливые.

Contra

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

в огромном седьмом павильйоне Ленэкспо занято примерно 20% площади. при этом в лаундж зоне от силы сотня-полторы мест. в секции мини-докладов мест от силы полста. участников конференции 2000+ человек. внимание вопрос, почему не расширить зону экспозиции, павильон-то все-равно занят?
отдельной строкой организаторы отмечали, что желают видеть на конференции как можно больше людей. посадочных мест, вместе с лаундж зоной и секцией мини-докладов, вне секций основных докладов максимум 200. что делать всем остальным?
ОДНА WiFi точка с ограниченным радиусом дейстия и пропускной способностью! одна. это катастрофа, это позор
доклады второй и третей секции не способны вместить всех желающих. более 50% людей вынуждены стоять в лучшем случае в видимости экрана. но так повезло тоже не всем. при этом спонсорские места не заняты и не используются. лажают координаторы
никаких предварительных регистраций на секции нет. при том, что они, кроме первой, не способны вместить всех желающих. итог -- невероятные очереди на запуск
действия охраны не синхронизированы. ребята изо всех сил пытаются быть приветливыми и поддерживать порядок, но поскольку очереди очень большие, а запускать в секции они начинают не одновременно, им достается. разумеется только устно :)
раздача питания в стиле "шведский стол" и какое-то маниакальное желание участников получить свой бутерброд и пирожок приводят к давке в зонах питания. никто не пытается организовать очередь и что-то подобное. ситуация усугубляется тем, что в районе Ленэкспо нет доступных пешим ходом точек общепита
кофе ТОЛЬКО в кафе на втором этаже. Джава конференция без кофе. позор. в кафе только бутерброды. горячего нет
зал, ангажированный для открытия конференции Джеймсом Гослингом, не вместил всех зарегистрированных участников, при том, что в седьмом павильоне есть гигантский -- в половину второго этажа -- актовый зал. очереди и давка. позор
Джеймс Гослинг не приехал, об этом сообщили в середине открытия. менеджер Оракла ( к сожалению я забыл, как его зовут) который открывал конференцию вместо Джеймса, сделал все, чтобы потеря была минимальной и ему это удалось. но организаторам жирный минус за утайку информации ради традиционного русского пафоса. да-да, главный организатор призывал зал покричать "Sun Tech Days RUSSIA!", как же без этого

итого: впечатления 50/50. если бы не качество, плотность и полезность информации, конференцию можно было бы считать проваленной. но докладчики компенсируют 50% недостатков. пока я не жалею.

про увольнения

2010-04-06T08:09:00.000+03:00

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

Sun Tech Days St. Petersburg

2010-04-05T20:15:00.001+03:00

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

Liferay::EXT

2010-03-17T21:46:00.006+02:00

EXT Environment

основа Liferay это Spring, Hibernate и AXIS.
Spring управляет зависимостями и инекциями классов между модулями. он же управляет транзакциями, содержит конфигурацию различного рода кешей, пулов, источников данных
Hibernate управляет собственно данными
AXIS предоставляет доступ к данным через веб-сервисы
вокруг этих технлогий Liferay имеет надстройку из собственных классов, которая и является ESB Liferay. эта ESB, в свою очередь, спроектирована по принципу Service Oriented Architecture и разделена на три части:

Persistence Beans, которые являются ничем иным, как объектами Hibernate мэпинга
сервисами, реализующими логику доступа и управления данными
сервисами, обеспечивающими удаленный доступ к логике управления lанными

EXT Environment это сконфигирурованная и готовая к использованию структура директорий, позволяющая просто и прозрачно расширять ESB Liferay. структура директрий генеруется таском build-ext из исходников портала. основными модулями кастомизации являются ext-impl, ext-service и ext-web. директории содержат расширеня presentation layer (ext-web) и persistence layer (ext-impl и ext-service), причем в ext-service лежат декларации сервисов persistence layer, а в ext-impl -- реализации.
для расширения платформы используется класс service.xml, этот класс содержит описание сущностей, которые будут представлены таблицами базы данных и объектами мэппинга Hibernate. формат файла очень похож на формат hbernate.xml, но есть ряд сущетсвенных ограничений для типов сущностей, типов полей сущностей, типов связей и тому подобное. файл этот обрабатывается классом ServiceBuilder, который и генерирует все необходмые классы и конфигурационные файлы для портальной ESB
но ServiceBuilder нужен не только для этого

service.xml

основными элементами service.xml являются

entity -- елемент описание сущности, кроме объявления полей объекта и базы данных содержит в себе все ниже перечисленные
many-to-one (many-to-many) -- описание связи между сущностями аналогичное Hibernate
finder -- по умолчанию, объекты ESB содержат методы для содания, обновление, удаления записи в базе. поиска по первичному ключу и поиска всех записей. если сущность предполагает поиск по какому-то кастомному сочению полей, описывается finder, который и является декларацией соотвествующего метода в итоге

ServiceImpl и LocalServiceImpl

каждая entity, описанная в service.xml превращается в набор классов (до 8 штук) ESB Liferay. уже после генерации классов они содержат методы для базовых операций с данными. иными словами, классы уже являются полноценной кастомизацией ESB. в случае, когда базовых операций недостаточно, на помощь приходят классы *ServiceImpl и *LocalServiceImpl. как явствует из названия, класс *LocalServiceImpl содержит методы, доступные для использования только в рамках одного хоста, а класс *ServiceImpl -- доступные для удаленных вызово. в те времена, когда Liferay был реализован с использованием технологии EJB, это были реализации интерфейсов EJBHome и EJBLocalHome соотвественно. сейчас *ServiceImpl используется для генерации веб сервисов. как правило, основную реализацию дополнительного функционала работы с данными содержит *LocalServiceImpl, *ServiceImpl просто вызывает соотвествующие методы *LocalServiceImpl с минимальной пре- и постобработкой параметров. чтобы исключить дублирование кода. однако, никто никаких запретов на реализацию каждого из сервисов отдельно нет.

*FinderImpl и custom_sql.xml

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

в директории ext-impl/src, в пакете com.liferay.portal.service.persistence создается класс *FinderImpl
в файле custom_sql.xml объявляется тэг с единственным аттрибутом -- id, являющимся уникальным идентификатором SQL запроса. в теле тэга описываться сам текст SQL запроса в JDBC или Hibernate нотации
в классе *FinderImpl реализуется логика обработки, выполнения и обработки результатов выполнения запроса

резюме

для собственно кастомизации ESB Liferay необходимо:

определить entity и finders в service.xml
запустить ant таск для генерации кода
реализовать дополнительный функционал работы с базой данных внутри классов *FinderImpl и описать соотвествующие запросы в custom_sql.xml
запустить ant таск для генерации кода
реализовать сами методы внутри классов *LocalServiceImpl и/или *ServiceImpl
запустить ant таск для генерации кода
и дальше можно запускать ant таск deploy или сразу оба clean deploy

Важно! все изменения классов *LocalServiceImpl, *ServiceImpl и *FinderImpl автоматически попадают в связанные классы и интерфейсы ESB после запуска. эти классы создаются единожды и более не перезаписываются автоматически сгенерированными. наоборот, являются источником для изменения остальных сгенерированных классов

собеседования

2010-03-16T00:00:00.005+02:00

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

что стоит делать

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

чего делать не стоит

не нужно вдаваться в подробности вашей работы на любом из предыдущих мест, если вас явно об этом не спросили. вообще сконцентрируйтесь на заданном вопросе, примеры из практики -- хорошая иллюстрация. ровно до тех пор, пока она не превышает 20% времени ответа
старайтесь меньше упобреблять этипетов "нормальный", "хороший", "интересный", "адекватный" и прочих субъективизмов. помните, люди разные и воспринимают такие слова по-разному. в отношениях с работодателем и работой -- меньше абстракций и больше конкретики
указывайте в резюме только то, о чем можете последовательно и четко рассказать, не стоит упоминать UML, если вы нарисовали когда-то 2 диаграммы в Visio
избегайте максимальных оценок в анкетах, если не уверенны, что действительно знаете все о предмете. английский не бывает fluent, если вы "давно не говорили". JavaScript не может быть уровня expert, если вы не знаете как там реализовано наследование, инкапсуляция и полиморфизм

Liferay::Basics

2009-12-16T01:21:00.007+02:00

Liferay - Введение

Преамбула

С портальными контейнерами спецификации JSR-168 я столкнулся в 2006 году. Все было достаточно тривиально, клиент хотел портальное решение на Java и я был назначен найти наиболее подходящее. После рассмотрения JBoss Portal, Exo, Apache Jetspeed2, Apache Pluto я понял, что в мире порталов пока все еще довольно не просто и не тривиально. И когда я уже готовился с кровью отстаивать очень не быстрые сроки, мне попался Liferay тогда еще версии 3.6.5.
Этот портал, в отличие от братьев по спецификации, бодренько зашуршал из коробки и показал мне много всякого. Его и выбрали в качестве платформы.

Время показало, что платформа действительно хорошая и из коробки умеет массу полезных и приятных вещей. Как и у большиства legacy продуктов платформа содержит в себе некоторое количество архаичной архитектуры и сама построена на технологиях образца 2004-05 года. В 2007 backend платформы был переведен полностью на Spring и версия с EJB канула в лету. Как и большинство других платформ, которые обладают очень широкой функциональностью из коробки, Liferay накладывает на разработчиков ряд сущственных ограничений. Как и любой другой продукт, Liferay содержит в себе порядочное количество багов и особенностей реализации. Иначе говоря, это отнюдь не серебрянная пуля в мире Java порталов. Но, вместе с тем, я считаю Liferay одним из лучших решений в области JSR-168/268 совместимых порталов и лучшим из Open Source реализаций JSR-168/268.

Pro

Чем же хорош Liferay

полноценная реализация Enterprise Serial Bus (ESB) делает доступ к persistence слою простым, понятным, не зависящим от транспорта или слоя логики, где понадобились данные из persistence
ESB берет на себя управление транзакциями, создание таблиц, поддержание целостности данных, обработку запросов в зависимости от сервера базы данных, генерацию различного рода классов, которые являются частью ESB, организацию доступа к данным, кеширование, генерацию ключей и UUID
портал предоставляет возможность расширять ESB с помощью заранее сконфигурированного и готового к работе пакета расширения. пакт содержит все необходимое для того, чтобы классы расширения были успешно интегрированны в развернутую копию Liferay
механизм кастомных обработчиков событий портала, в терминологии Liferay hooks, позволяет изменять и дополнять поведение портала "на лету", без изменения исходный кодов самой платформы
процесс hot deploy для компонентов портальной среды позволяет интегировать компоненты при самой минимальной и самой формальной кастомизации дескрипторов. иначе говоря для успешного деплоймента компонента Liferay достаточно наличия файла liferay-portlet.xml внутри портлетного war и простого описания портлета в этом дескрипторе. тонкая настройка или правильность формата не обязательна
наличие готовых портлетных мостов позволяет создавать портлеты на разных языках от PHP до Ruby-on-Rails, не говоря уже о всем многообразии Java frontend фреймворков
наличие собственной библиотеки тэгов позволяет разрабатывать локализованный и готовый к использованию интерфейс очень быстро и просто
наличие специфических WindowState для портлетов, позволяет легко реализоваывать и просто работать со всплыващющими окнами и embedded контентом
для кастомизации основной темы портала достаточно прописать только дополнительные CSS классы, изменений в шаблонах и добавить дополнительные ресурсы, стандартные файлы темы будут добавлены к новому пакету автоматически
библиотеки, поставляемые с порталом, можно повторно использовать в своих собственных портлетах. для этого нужно перечислить необходимые jar в файле liferay-portlet.properties. это решает проблему совместимости библиотеки и проблему размера портлетного war
портал поставляет собственную, полновесную и полнофункциональную Content Management System
портал поддерживает до 4 типов портлетного контента, включая прямую интеграцию удаленного ресурса
портал содержит развернутую контрольную панель, предоставляющую доступ к настройкам любого уровня -- от учетных записей пользователя до управления хостингом и физическими параметрами JVM. контрольная панель доступна для расширения кастомными портлетами
портал предоставляет разветвленную систему управления правами пользователя, основанную на групповой модели. эта система прав едина для всей портальной системы и покрывает весь workflow от авторизации до разграничения доступа и даже рендеринга контента, в зависимости от прав конкретного пользователя
портал предоставляет администратору возможность предопределить не ограниченное число layouts, каждый из которых может сочетать в себе произвольную конфигурацию любых портлетов и тем, доступных в системе. с помощью системы аутентификации администратор может предоставить пользователю доступ к одному или нескольким layouts, назначить тот или иной в качестве layout по-умолчанию как для контретного пользователя, так и для группы пользователей
портал интегрирован с широким спектром third-party софта, включая таки известные продукты как ICEfaces, Alfresco, Apache Jackrabbit, Apache Lucene, JBoss JBPM и даже такими сложными, как Pentaho BI Platform

Contra

при всех достоинствах, не следует также забывать и о недостатках

за исключением нескольких, довольно объемных, руководств по администрированию, разработке и пользованию CMS, документация технического характера крайне поверхностна и эпизодична
полностью отсутсвует JavaDoc, единтсвенный способ узнать о назчении и особенности реализации той или иной функции -- исходный код
ESB предоставляет возможность пользоваться только ограниченым набором фич и приемов. нет возможности изменить базовую реализацию ORM, на которой основана ESB. часто нет возможности использовать какие-то advanced tips&trics для ORM, по той причине, что ORM полностью закрыта фунционалом ESB. как следствие, любой дефект или не реализованная фича ESB автоматически лишает программиста возможности использовать сломанную или не реализованную функциональность в своих проектах. даже если ORM поддерживает эту функциональность
ESB включает в себя генерацию и взаимодествие ядра портала с внешним миром через SOAP протокол. генерация WSDL и WSDD полностью скрыта ESB. таким образом, у программиста никакой возможности влиять на формат или валидность первого и второго. также не может быть изменена реализация SOAP протокола
набор событий, генерируемых порталом, очень скромен, поэтому тонкая настройка поведения через хуки исключена
процесс hot deploy не совершенен. так, если в процессе развертывания со стороны портала произошло обращение к портлету или теме, старая версия которых анулирована, а новая еще не развернута, портлет или тема будут недоступны вплоть до следующего развертывания или перезапуска портала
тема представляет из себя набор шаблонов Apache Velocity. полного перечня переменных и CSS классов в публичном доступе не существует. теоретически тему можно разрабатывать на pure JSP или HTML, на практике это означает создание темы с нуля
пакет кастомизации ESB заточен под сборку Ant и определенную структуру файловой системы. изменения структуры файловой системы возможны, но весьма не значительные. изменения сборочной системы не возможны из-за огромного количества сборочных скриптов, перекрывающих и дополняющих друг друга
мосты для других языков и технологий представления, отличных от Struts, часто реализованы не до конца или содержат недоработки. в доступном комьюнити зачастую разобратны только самые тривиальные и простые варианты использования. очень часто приходится потратить очень много времени для интеграции того, что уже объявлено, как совместимое
интеграция third-party software очень часто не содержит никакой другой информации, кроме объявления про интеграцию
библиотека кастом тэгов, как и большинство UI сделана очень давно и несет в себе все возможные недостатки pure JSP подхода. судя по количеству и проявлению дефектов, UI не является наивысшим приоритеом разработчиков
перенос дерева контента из одного портала в другой заявлен, но также работает не всегда корректно. перенос дерева контента между порталами разных версий не возможен в принципе
достаточно широкое community организовано крайне странно и хаотично, поиск по существующим материалам затруднен, материала википедии намернно слиты с материалами форумов. использование community довольно затруднительно

Заключение

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

Coffee'n'Code Kharkiv

2009-11-24T23:52:00.000+02:00

Сформированна программа мероприятия, подробности на сайте.
Приходите, будет интересно

jQuery && WebKit based browsers

2009-11-24T23:34:00.003+02:00

хозяйке на заметку, события document.ready и window.load в браузерах основанных на WebKit срабатывают раньше, чем будут загружены основные ресурсы. таким образом никак невозможно критически важные JavaScript функции, срабатывание которых запланированно на момент загрузки окна или DOM Document'а, помещать во внешние файлы.

господа Google-разработчики -- это таки баг

Spring Portlet MVC

2009-11-24T23:16:00.002+02:00

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

a) в простейшем случае это просто RenderRequest, который на стороне контроллера обрабатывается методом processRenderRequest
б) в случае, если произошел сабмит формы или просто был вызван ActionRequest, то сначала отработает метод onSubmitAction, а потом будет сформирован RenderRequest и выполненн метод processRenderRequest
казалось бы все просто и довольно прозрачно, и Spring предоставляет возможность указывать, какие именно параметры сохранять в конце onSubmitAction, для их использования в RenderRequest. но тут нас поджидает ряд сюпризов

параметры, перечисленные в свойстве контроллера setRenderParameters из ActionRequest не копируются. во всяком случае базовое поведение контроллера именно таково
метод формирования объекта команды fromBackingObject вызывается только в двух случаях -- при сабмите формы и при начальном открытии формы, если указано свойство bindOnNewForm=true. в случае RenderRequest данный метод игнорируется полностью
с сабмитом формы тоже не все просто. по мере вызова методов от processActionRequest до showForm параметры запроса несколько раз валидируются, сравниваются с существующими и перекладываются из одного формата в другой. если по мере выполнения функционала окажется, что параметры запроса совпадают с сохраненными в контроллере, метод onSubmitRender может быть проигнорирован. равно как будет проигнорирован вызов метода formBackingObject в случае принудительного программного редиректа с одного контроллера на другой
в том случае, если необходимо сделать принудительный программный редирект к начальному состоянию портлета, единственный способ это сделать -- установить параметр action RenderRequest в пустое значение или значение, соотвествующее начальному состоянию портлета. определить параметры successView и redirectAction контроллера не достаточно -- в этом случае сохраняется состояние портлета, в котором он находился на момент сабмита ActionRequest
в портлетной инкарнации Spring MVC объект сессионной формы всегда удаляется из сессии после второго обращения к нему. иначе говоря
а) объект попадает в сессию после создания и заполнения параметрами
б) контроллер проверяет, имеет ли место быть сохраненный объект и если да, то считывает и удаляет
в) если зарегистрованно еще одно обращение к объекту формы, то конроллер положит обновленный объект обратно
таким образом не стоит переживать насчет заполнения сессии мертвыми объектами или фиксации их состояния

Maven2::Part #5

2009-10-08T12:41:00.005+03:00

Assembly plugin

несколько слов об assembly plugin. Maven предоставляет возможность формировать delivery package с помощью assembly plugin. стандартная документация описывает процесс создания конечного пакета в формате bin и src, как это обычно выглядит для всех продуктов Apache Software Foundation. однако, с помощью этого плагина можно формировать пакеты абсолютно произвольного формата. для этого понадобиться дескриптор assembly.xml, в котором с помощью тэгов включаются и исключаются необходимые артефакты и исходники, а с помощью тэгов -- артефакты зависимостей, необходимые в delivery package. все остальные тэги assembly.xml можно не использовать. с другой стороны, если delivery package соотвествует формату, принятому в Apache Software Foundation, можно использовать стандартные конфигурации assembly.xml, которые представлены на сайте Maven

Maven2::Part #4

2009-09-27T10:04:00.010+03:00

Управление зависимостями (Dependency Management)

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

включение и исключение библиотек при объявлении зависимостей

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

при огранизации зависимостей разрабатываемого модуля или приложения от сторонних библиотек, необходимо помнить, что все зависимости, для которых указан scope compile или не указан scope, будут автоматически включены в зависимости модуля, который использует разрабатываемый модуль. или, более простыми словами, если ваш модуль будет использован в дальнейшей разработки, все зависимости scope compile, автоматически окажутся в вашем локально репозитории и директории lib для war и ear. в случае, когда в таком поведении системы нет строгой необходимости использование тега optional более чем желательно.
в противном случае все пользователи вашего модуля будут получать на выходе гиганские объемы библиотек, которые они не используют. или же будут прибегать к практике из пункта 2
при использовании сторонних библиотек следует обязательно обратить внимание на количество зависимостей, не отмеченных как optional, у используемого модуля. ярким примером являются релизы Spring весии 2.x, каждый модуль которого норовит вытащить из репозитория 90% фреймворка.
для того, чтобы избежать такого поведения той или иной библиотеки из зависимостей, необходимо отключить все не нужные в приложении зависимости, не объявленные в pom библиотеки, как optional.

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

dependencyManagement vs dependencies. в чем разница?

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

определить зависимости той или иной библиотеки можно окрыв ее pom файл внутри репозитория или используя специальный ресурс

управление зависмостями в multimodule projects

для многомодульных проектов сложно переоценить значение секции dependencyManagement. ее использование позволяет объявить, а следовательно и управлять, зависимости в в одном единственном месте включая все необхоимые значения scope, exclusions и optional. этим местом является parent pom файл всего проекта. в pom файле каждого из модулей, в секции dependencies достаточно указать groupId и artifactId кокретной зависимости или плагина. Maven автоматически использует остальные параметры аналогичной зависимости из parent pom файла

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

Maven::Part #3

2009-09-14T09:50:00.013+03:00

Multimodule projects

каждый pom.xml файл описывает build workflow для одного проекта, в конечной фазе которого мы имеем один артефакт установленный в локальный и удаленный репозитарий. однако Maven позволяет легко и удобно работать с многомодульными проектами. при этом задача управления зависимостями между внешними библиотеками и между модулями внтури проекта полностью решается самим Maven.

Особенности конфигурации

для того, чтобы сконфигурировть build workflow для multimodule project необходимо

создать в корневом каталоге, общем для всех модулей, pom.xml файл родительского модуля, для которого указать
...
<packaging>pom</packaging>
...
такое значение артефакта указывается Maven на то, что данный проект является мета-проектом и не требует сборки конечного артефакта на выходе. в итоге в репозитариях будет просто сгенерирована мета-информация об этом проекте, без наличия конркетных артефактов.
далее в родительском pom.xml файле мы должны определить конфигурацию модулей
...
<modules>
  <module>module1_directory_name</module>
  <module>module2_directory_name</module>
...
  <module>moduleN_directory_name</module>
</modules>
...
где
module_directory_name -- имя каталога, в котором находятся файлы конкретного модуля.
Важно: имена модулей в родительском pom.xml и имена каталогов, в котором расположены файлы модуля должны быть идентичны. имена каталогов модулей обрабатываются как пути к этим каталогам. таким образом, если структура конкретного проекта предполагает взаимонезависимое расположение каталогов с модулями, то следует указывать их абсолютные или отностительные пути
для pom.xml каждого из модулей, входящих в multimodule project необходимо указать
...
<parent>
  <groupId>project_group_id</groupId>
  <actifactId>parent_artifact_id</artifactId>
  <version>project_version</version>
  [<relativePath>path_to_parent_pom.xml</relativePath>]
...
где
project_group_id -- идентификатор группы, в которой будут сохранены все артефакты проекта. в случае multimodel project может быть указана для родительского модуля и parent-секции модуля. для конкретных модулей наследуется из родительского, если не указана явно
parent_artifact_id -- идентификатор артефакта родительского проекта. этот интификатор необходим в любом случае и для любого проекта. даже для мета-проекта, которым часто является родительский проект
project_version -- текущая версия проекта. в случае multimodel project может быть указана для родительского модуля и parent-секции модуля. для конкретных модулей наследуется из родительского, если не указана явно
relativePath -- относительный путь к родительскому pom.xml. его необходимо указать в том случае, если каталог уровнем выше каталога модуля, не содержит родительского pom.xml

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

Maven2::Part #1

2009-09-13T11:29:00.008+03:00

Maven build workflow

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

...
<plugin>
   <groupId>com.mycompany.example</groupId>
   <artifactId>maven-touch-plugin</artifactId>
   <version>1.0</version>
   <executions>
     <execution>
       <phase>process-test-resources</phase>
       <goals>
         <goal>timestamp</goal>
       </goals>
     </execution>
   </executions>
</plugin>
...

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

отдельно следует отметить фазы цикла package, install и deploy.
package -- фаза, когда происходит сборка артефакта. стандартные плагины, для сборки артефактов, входящие в поставку Maven, умеют собирать jar, war, ear, ejb, rar, shade. каждый из сборщиков умеет класть внутрь архива необходимые ресурсы и раскладывать их по необходимым местам автоматически.
install -- фаза, когда собранные на этапе package артефакты проекта устанавливаются в локальный репозитарий. плагин создает каталоги группы и версии, копирует в созданную структуру артефакт и генерирует необходимую метаинформацию
deploy -- фаза, когда проинсталлированные в локальный репозитарий артефакты, переносятся в удаленный репозитарий. тут важно отметить, что Maven следит за обновлениями удаленных репозитариев автоматически. так что для того, чтобы обновить какой-то модуль для удаленной команды, необходимо только задеплоить его в общий удаленные репозитарий.

Maven2::Part #0

2009-09-13T00:58:00.010+03:00

Общая информация

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

систем автоматической сборки проектов на Java сущетсвует наверняка очень много. но самыми популярными и используемыми являются Ant и Maven2 (актуальным проектом является Maven2, Maven is dead и это было предрешено). собственно обе системы являются Java-приложениями и обе системы разработаны Apache Sotware Foundation. более того, Maven2 умеет вызывать изнутри себя Ant.

пара слов об Ant.

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

И тут пришел Maven

самая главная проблема полной свободы дествий есть отсутсвие стандартов по-умолчанию. нужно в 151й раз создавать одни и теже каталоги, в одной и той же последовательности, в одной и той же структуре от проекта к проекту, от компьютера к компьютеру. при это нужно убедить коллег, старших товарищей, младших товарищей, конфигурэйшин менеджеров и менеджеров проекта, что эта структура проекта хороша. а кому-то нравится своя, а третьему вообще ничего не нравится и всякая структура есть зло и насилие над личностью.
Maven решает проблему стандартизации кталогов, для хранения исходников, ресурсов и файлов, сопутсвующих исходникам (jsp, images, css, deployment descriptors, etc) очень просто -- у него есть формат каталогов по-умолчанию. разумеется можно все переопределить, переназначить и тому подобное. просто делать это каждый раз утомительно и время на это тратить не целесообразно, есть более приоритетные задачи.
1. Maven предоставляет стандартизованную структуру каталогов для хранения исходников
вторая проблема Ant -- необходимость самостоятельно строить workflow сборки. включая очистку старого окружения, создание нового, изменение версий артефактов, именование артефактов и delivery-архивов.
Maven решает данную проблему опять-таки наличие стандартного механизма именования артефактов, размещения файлов релиза и тестирования, размещения ресурсов и промежуточных каталогов. так же у Maven есть предопределнный workflow, где все операции следуют в четкой, заранее определенной последовательности. на входе у нас исходники проекта, на выходе -- готовые jar/war/ear. если нам необходимо, то путем задания опреденных правил, мы можем сформировать delivery-архив и даже технический сайт проекта. просто используя соотвествующие части workflow, без дополнительного кодирования или установки правил.
2. Maven имеет стандартный build worlflow, стандартную политику именования артифактов, стандартные имена output каталогов для кода проекта, и кода тестов. Так Maven сам заботиться о том, чтобы необходимые ресурсы попали в необходимые артефакты.
третья проблема, которая является проблемой не только и не столько Ant, сколько программирования на Java вообще -- это проблема хранения библиотек. если с кодом все более-менее ясно и систем хранения и версионирования кода существует более чем достаточно, то с готовыми библиотеками все несколько сложнее. как правило эти готовые библиотеки кладутся в SVN рядом с исходниками. что сущетсвенно увеличивает время выгрузки исходников из системы контроля версий. более того, если имя библиотеки не содержит номера версии, то обновить таковую песня отдельная. хорошим вариантом является хранение библиотек отдельно от кода проекта. это решает проблему скорости обновления и checkout исходников проекта, но все-равно в SVN у нас остается несколько сот метров бинарного кода, который там просто лежит.
одна из главных особенностей Maven -- это возможность управления зависимостями. собственно Maven и создавался для того, чтобы решить проблему хранения готовых библиотек, их обновления и управления ими.
в случае Maven мы имеем некоторое количество репозиториев, которые хранят бинарные артефакты и метаданные к ним единым и стандартным способом. на уровне конфигурации сборки проекта тот или иной репозитарий может быть влючен в список источников, для поиска артефактов. артифактом является каждая бинарная библиотека, включающая:

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

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

Важно: проект Apache Ivy позволяет использовать репозитории артефактов Maven для управления зависимостями внутри проектов, собираемых с помощью Ant

С чего начинается Maven

для старта проекта под управлением Maven необходимо создать pom.xml (Project Object Model) файл в каталоге, который стане корневым для Вашего проекта. и разумеется скачать сам Maven.

Spring MVC: не очевидное

2009-09-01T07:58:00.006+03:00

Есть ряд совершенно не очевидных вещей внутри Spring MVC, например
1) чтобы форма работала и обрабатывалась нормально нужно, чтобы у нее обязательно были прописаны id и name. и то, и другое, одновременно. иначе возможны сбои
2) чтобы механизм автоматического binding'а элементов формы работал, нужно, чтобы имена полей формы совпадали с именами полей класса, в который они байндятся. Т.е.


Java class:
public class BackingBean {
    private long id;
    private String name;

    public void setId(long id) {
        this.id = id;
    }
 
    public long getId() {
        return id;
    }

    public void setName(String name) {
        this.name = name;
    }
 
    public long get() {
        return name;
    }
}

JSP:
<form id="foo" name"foo" method="post" action="/somewhere-on-server">
    <spring:bind path="backingBean.id">
        <input type="text" name="id"/>
    </spring:bind>
    <spring:bind path="backingBean.name">
        <input type="text" name="name"/>
    </spring:bind>
</form>

5) метод formBackingObject всегда создает новый экземпляр объекта, если его перегрузить таким образом, чтобы он делал проверку наличия уже созданного объекта в аттрибутах запроса, это позволит уменьшить количество объектов в памяти и сократить время, необходимое для создания этого объекта
4) в Spring Portlet MVC метод onSubmitRender вызывается только в том случае, когда состояние формы было изменено. поэтому в этом методе нельзя реализовывать обработку RenderRequest's, общих для всего контроллера. для обработки общих запросов можно использовать методы showForm, handleRenderRequestInternal, handleRenderRequest
p.s. а в многом остальном Spring MVC прекрасен, как и весь Spring пожалуй

конфигурация Java Service Wrapper для старта Tomcat6

2009-08-20T11:43:00.006+03:00

есть в этом мире такая прекрасная библиотека, как Java Service Wrapper. она позволяет любую Java программу запустить как системную службу (особенно это важно для Windows, потому что иного способа часто нет). но беда этой прекрасной библиотеки в том, что разработчики не обновляют документацию на сайте. поэтому ниже файл конфигурации этой библиотеки для запуска tomcat-6.x.x как сервиса

#********************************************************************
# Wrapper License Properties (Ignored by Community Edition)
#********************************************************************
# Include file problems can be debugged by removing the first '#'
#  from the following line:
##include.debug
#include ../conf/wrapper-license.conf
#include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf

#********************************************************************
# Wrapper Java Properties
#********************************************************************
# Java Application
wrapper.java.command=%JAVA_HOME%/bin/java

# Tell the Wrapper to log the full generated Java command line.
#wrapper.java.command.loglevel=INFO

# Java Main class.  This class must implement the WrapperListener interface
#  or guarantee that the WrapperManager class is initialized.  Helper
#  classes are provided to do this for you.  See the Integration section
#  of the documentation for details.
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperStartStopApp

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
wrapper.java.classpath.3=../bin/bootstrap.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib

# Java Bits.  On applicable platforms, tells the JVM to run in 32 or 64-bit mode.
wrapper.java.additional.auto_bits=TRUE

# Java Additional Parameters
wrapper.java.additional.1=-Dcatalina.base=..
wrapper.java.additional.2=-Dcatalina.home=..
wrapper.java.additional.3=-Djava.io.tempdir=../temp
wrapper.java.additional.4=-XX:MaxPermSize=256m

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=128

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=512

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.2=1
wrapper.app.parameter.3=start
wrapper.app.parameter.4=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.5=true
wrapper.app.parameter.6=1
wrapper.app.parameter.7=stop

#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Enables Debug output from the Wrapper.
# wrapper.debug=TRUE

# Format of output for the console.  (See docs for formats)
wrapper.console.format=PM

# Log Level for console output.  (See docs for log levels)
wrapper.console.loglevel=INFO

# Log file to use for wrapper output logging.
wrapper.logfile=../logs/wrapper.log

# Format of output for the log file.  (See docs for formats)
wrapper.logfile.format=LPTM

# Log Level for log file output.  (See docs for log levels)
wrapper.logfile.loglevel=INFO

# Maximum size that the log file will be allowed to grow to before
#  the log is rolled. Size is specified in bytes.  The default value
#  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
#  'm' (mb) suffix.  For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=0

# Maximum number of rolled log files which will be allowed before old
#  files are deleted.  The default value of 0 implies no limit.
wrapper.logfile.maxfiles=0

# Log Level for sys/event log output.  (See docs for log levels)
wrapper.syslog.loglevel=NONE

#********************************************************************
# Wrapper Windows Properties
#********************************************************************
# Title to use when running as a console
wrapper.console.title=Tomcat Servlet Container 6.0.18

#********************************************************************
# Wrapper Windows NT/2000/XP Service Properties
#********************************************************************
# WARNING - Do not modify any of these properties when an application
#  using this configuration file has been installed as a service.
#  Please uninstall the service before modifying this section.  The
#  service can then be reinstalled.

# Name of the service
wrapper.ntservice.name=tomcat6

# Display name of the service
wrapper.ntservice.displayname=Tomcat Servlet Container 6.0.18

# Description of the service
wrapper.ntservice.description=Tomcat Servlet Container 6.0.18

Bundled NT service wrapper

# Service dependencies.  Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=

# Mode in which the service is installed.  AUTO_START or DEMAND_START
wrapper.ntservice.starttype=AUTO_START

# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=false

о целях и спорах

2009-06-06T01:35:00.004+03:00

иногда бывает познавательно наблюдать, как люди пытаются давать советы. очень часто советы одного человека встречают просто шквал критики со стороны другого. потом появляется группа поддержки у первого и второго спорщика. потом подтягиваются старые опоненты первого, второго, группы поддержки номер раз, группы поддержки номер два. страсти накаляются, трещат копья, летит шерсть клочками. между тем тема, вокруг которой разгорелись совершенно не связанные с ней дискуссии, часто остается не раскрытой.
я думаю, что так случается потому, что у разных людей разные цели. давая совет, мы подспудно ставим себя на место автора вопроса и стоветуем ему то, чего хотели бы сами. чего не сделали, недоучили, не успели или собираемся сделать, выучить, успеть. это вполне естественно, но не правильно. потому что люди разные и цели, опять-таки разные. всегда нужно делать поправку на это маленький, но очень существенный факт.
а еще мечты какие-то мелкие, местечковые. современному украинскому программисту пределом мечтаний видится работа в IBM, Google, Microsoft. это должно стать решением всех проблем и ответом на все вопросы. по-моему это ошибочное мнение. человек должен уметь самостоятельно решать свои проблемы, самостоятельно удовлетворять собственные амбиции. иначе Энцо Феррари до конца жизни работал бы в Alfa Romeo, Билл Гейтс был бы топ-менеджером IBM, а Сергей Брин преподавателем Стэнфорда.

"Слабого судьба тащит на веревке, того, кто сильнее, - за руку ведет, а самый сильный сам судьбой становится..."
(с) Андрей Валентинов "Диомед, сын Тидея"

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

по следам 7го ITtalk

2009-05-22T18:36:00.004+03:00

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

Шахтар ЧЕМПІОН

2009-05-21T00:16:00.001+03:00

Шахтар виграв Кубок УЄФА! Слава Україні!

Graph framework for Java web UI

2009-05-20T23:42:00.003+03:00

а не посоветуют ли благородные доны какую-нибудь готовую Open Source реализацию Java framework для построения графов? мне нужен самый простой функционал -- возможность формирования модели и отображение этой модели в web UI. желательно, каким-нибудь более современным способом, чем Applet. поиска путей, опитимизации путей и прочей математики не требуется. про yWorks и ILOG я знаю, но во-первый, денег на коммерческие компоненты у проекта нет, во-вторых, компоненты содержат слишком много излишнего функционала, за который никто платить не захоче.
вот такие дела.

Java & Active Directory

2009-01-08T00:39:00.005+02:00

кратенькая заметка о том, как легко и непринужденно сделать single sign on в Java web приложении для серверов, включенных в домен Windows (Samba) Active Directory.
минимально необходимая библиотека jCIFS. настройки по интеграции достаточно просты и для самого простого случая достаточно минимальных, описанных на сайте. логин и пароль для Samba можно не указывать. в этом случае приложение напишет в логи сообщение, что Samba может работать не корретно, но в целом процедура авторизации работает.
также понадобится настройка браузера
Internet Explorer
достаточно включить опцию Internet Options -> Advanced -> Security -> Enable Integrated Windows Authentication
Firefox
1. откройте Firefox
2. загрузите url about:config
3. перечислите через запятую адреса серверов для следующих параметров
network.automatic-ntlm-auth.trusted-uris
network.negotiate-auth.delegation-uris
network.negotiate-auth.trusted-uris
Opera
википедия говорит, что с 9 версии прозрачная аутентификация поддерживается. никаких дополнительных настроек никто не предлагает. я не проверял, поэтому прийдется принять этот факт на веру и проверить на практике.
Safari
опять таки, доподлинно не известно, работает ли аутентификация в Safari on Windows, кое-где есть ссылки, что не рабоает. иначе говоря, как и для Оперы нужно проверять.
Google Chrome и прочие
да простят меня фанаты Chrome, но на текущий момент это еще бОльшая экзотика, чем Опера или Сафари, так что здесь я предлагаю фанатам проверить совместимость самим :)

итоги года

2008-12-31T14:44:00.003+02:00

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

relationship: employer & employee

2008-09-28T10:49:00.013+03:00

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

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

чтобы взаимодействие со стороны сотрудника было партнерским, необходимо как минимум

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

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

Warranty

2008-09-06T09:32:00.005+03:00

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

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

2008-08-16T10:52:00.005+03:00

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

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

я думаю, это несколько причин:
1. система образования и профессиональных тренингов. Первая вообще никудышняя, тренингов как кот наплакал. Компании мало вкладывают в повышение экспертизы людей, потому что рынок еще не насыщен и удержать человека, в которого вложился юридически сложно. В результате все пытаются купить готовых специалистов, в которых кто-то уже вложился, пусть и задорого. Но зато уже сегодня и это все равно часто дешевле, чем трейнить. ведь образование, если посчитать все непрямые затраты, достаточно дорогая штука. Вот такой замкнутый круг …
2. Опытные люди, поработав 5-10 лет и не решив материальные проблемы (например квартира), все еще уезжают за Запад (хотя уже реже чем в 90х). Это проблема страны. К сожалению, даже несмотря на резкое повышение зарплат в последние несколько лет, это не решает проблему “уровня жизни”. Ведь качество жизни сильно зависит от развитости инфраструктуры, которую нужно строить десятилетиями. И люди не хотят ждать … Если бы страна еще демонстрировала хорошие темпы в нужном направлении. А мы топчемся на месте и теряем время. Это прискорбно, так как иммиграция, повышая материальный уровень, имеет огромный недостаток - потеря социального круга общения и родины. Что это такое резко осознаешь через 2-3 года, когда эйфория переезда прошла.
3. У нас пока что профессия менеджера действительно дает больше денег и быстрее (см. следующий вопрос). Это перекос, на Западе не так и горизонтальная карьера там более интересна, чем вертикальная. У нас же это обусловлено быстрым ростом индустрии, в результате чего нужно все больше менеджеров, а их никто не готовит. Вот и выдергиваем технарей, решение, кстати, далеко не оптимальное.

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

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

Вы как-то упоминали за горизонтальный рост девелопера до категории “гуру” (так вроде в Глобале эта позиция называется). Это не более чем кичливый титул или это дает реальные преимущества по зарплате, славе, бонус от реализованного проекта и прочее? Является ли эта позиция вроде Apple Fellow, то есть творю “что-то особенного” на благо любимой компании?

Только сейчас мы переходим к новой системе, в которой менеджмент позиции отделены от технических. И в которой позиция “архитектор” будет по статусу эквивалентна директору подразделения. А Project Manager будет находиться на одном уровне с Med Tester/Developer. В результате действительно появляется позиция “Fellow”, которая по статусу приравнивается к CEO, CTO, CFO уровню. И вилки зарплат постепенно будут приведены в соответствие. Вот тогда человек, который инженер, а не менеджер по натуре, еще сто раз подумает, прежде чем начать новую жизнь и перейти в менеджмент. А текущая ситуация подталкивает людей, в походе за деньгами, к переходу в менеджмент. Нужно давать возможность талантливым инженерам оставаться таковыми и зарабатывать не меньше менеджеров …

Являетесь ли вы “кузнецей кадров” для иновационных проектов, то есть когда приходит например аспирант и предлагает инвестировать на протяжении N-лет его работу за символическую зарплату с последующим делением авторских прав?

мы даем доступ сотрудникам к самым что ни на есть инновационным проектам - нашими клиентами являются продуктовые компании, которые все время придумывают новые продукты. А мы им помогаем придумывать и реализовать … довести идеи до коробки. У нас есть примеры, когда ребята, поработав у нас и научившись делать продукты “под ключ” основали свои собственные “стартапы”. Мы поддерживаем тех сотрудников, которые ведут какие-то исследования в ИТ, ездят на конференции и так далее.
Поэтому я берусь утверждать,что наш портфель проектов более “инновационен”, чем у других аутсорсинговых компаний на рынке. Но мы не вкладываем в собственные разработки, это рискованное дело и им пусть занимаются профессиональные венчурные фонды. Поэтому по сравнению с продуктовыми компаниями можно сказать, что мы чуть менее инновационны.

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

по большому счету без этого наша отрасль обречена. К сожалению (что не у нас), в Индии и Китае построены системы массовой подготовки программистов. За счет хорошего качества образования, доступа к передовым технологиям и крупным международным проектам, качество программистов там не хуже нашего. Просто они уже контролируют 95% мирового рынка и за счет этого мы чаще слышим об их “факапах”. А на самом деле наши компании валят проекты не реже, просто об этом никто не говорит потому что мы - 1% мирового рынка. В общем качество работы - сравнимое.
За счет массовости, эти страны сбили цены и могут удерживать среднюю стоимость разработки на текущем уровне. Если не произойдет каких-то макроэкономических потрясений в Индии. В конце прошлого года средняя зарплата в нашей компании сравнялась с индийской … И если она продолжит расти, нужны аргументы почему аутсорс должен идти в Украину. Никто не будет завозить сюда программистов из Индии. В нашей компании уже есть офис там, в этом году мы купили компанию в Китае, на базе которой будем расти дальше. Остальные компании (ЕПАМ, Люксофт) тоже активно ищут возможности открыть офис в Индии, Вьетнаме или Бразилии. Чтобы в случае дальнейшего роста зарплат здесь переводить проекты в регионы, где можно продолжать работать.
Это не конец света, конечно. Но сейчас некий переломный и исторический момент … И я вижу 2 пути дальнейшего развития:
1. Средняя зарплата у нас останавливается на текущем уровне. В этом случае аутсорсинг продолжает жить. Уровень жизни в ИТ растет за счет того, что зарплаты опытных людей растут, а неопытных падают. Плюс можно продолжать набирать молодежь и за счет этого повышать опытных людей. Но нужно еще больше замедлить темп роста зарплат молодежи, ведь их стоимость на сегодня не соответствует отдаче …
Также есть небольшая надежда, что жизнь в нашей стране все-таки будет улучшаться. Вот в этом году дорогу на Львов ремонтируют полностью. Это же на лыжи можно будет на 2-3 часа быстрее доехать!
2. Средняя зарплата у нас растет дальше. Аутсорсинг потихоньку сворачивается, остаются компании, которые смогли сформировать технологический “костяк” и действительно способны делать крутые проекты “под ключ” за большие деньги. И рынок разворачивается в сторону … даже не знаю чего. Все остальные ниши очень узкие и там много народу не нужно.
Я все-таки думаю, что 1й вариант наиболее реалистичен …

Кстати, отмена ПП в текущей ситуации приведет к снижению зарплат однозначно. Нет жирового запаса у компаний (вы же видите с каким трудом компании сейчас реагируют на укрепление гривни, а ведь это 4%. И все надеются только на то, что это сезонное явление и гривна осенью упадет обратно до 5.0. А отжать 20% не сможет никто, это приведет к банкротству целой индустрии). И нет возможности повышать рейты клиентам. Так что компании удержат костяк, может даже без понижения зарплат, а менее квалифицированный персонал потеряет значительно. Начнется борьба за эффективность, то есть “готовы повысить зарплату на 10%, но работы у всех на 50% больше, так как увольняем 30% персонала”. И в этой борьбе за эффективность конечно выиграют высоко-производительные товарищи, но вот всем остальным прийдется несладко …

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

2008-07-28T13:42:00.002+03:00

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

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

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

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

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

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

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

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

2008-06-23T23:43:00.002+03:00

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

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

2008-06-14T11:10:00.007+03:00

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

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

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

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

2008-06-14T10:20:00.005+03:00

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

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

если человек договаривается работать за 100 у.е. -- это значит делать свою работу хорошо за 100 у.е. даже если все друзья получают 150 у.е. за вдвое меньшую работу. даже если работы много и она не очень нравиться. работать -- значит делать свое дело хорошо. это не означает, что нельзя поднимать вопрос о повышении ставки -- можно и нужно. но это значит, что повышения может не быть и уж точно не будет "автоматически".
мораль: умейте хорошо себя продать.
если человек договаривается работать за 100 долларов, он автоматически берет на себя риски, связанные с курсом доллара относительно национальной валюты. это совершенно не означает, что работодатель обязан индексировать зарплату работников относительно изменений курса. он может это делать, а может не делать. я, кстати, за то, чтобы не делать -- это честно.
мораль1: хотите не потерять в гривне -- фиксируйте сумму в гривне.
мораль2: хотите считать по курсу, отличному от курса банка работодателья -- получите на руки доллары и попробуйте их поменять дороже. получится -- значит Вы молодец, респект Вам и всяческая уважуха
мораль3: хитрые продавцы, у которые 1 у.е. = 5,4 гривни, идут лесом
и главное, я всегда считал и продолжаю считать, что причетания о росте цен или падении курса каких-то валют не состоятельны. не важно растут ли цены, падает ли валюта -- важно зарабатывать столько, чтобы цена отдельного товара не имела значния вовсе.

p.s. а во целом, "программисты", которые только закончили или еще учатся в ВУЗах, получают зарплаты бОльшие инженеров на государственных предприятиях. и уж на порядок больше пенсионеров. уже этот факт должен сделать любые причетания относительно "обнищания" не приличными.
p.p.s. социальное не равенство есть добро. да, я так считают.
p.p.p.s. справедливости не существует, особенно в бизнесе.

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

2008-05-16T09:15:00.011+03:00

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

вспоминая самый старт моей програмистской карьеры я каждый раз прихожу к мысли, что тогда все было иначе. ~~небо голубее, трава зеленее, девушки красивее~~ я начинал искать работу в 2000м году, сразу после того, как развалился наш студенческий стартап. мне, сначала студенту, а потом уже выпускнику профильного ВУЗа, пришлось пройти 17 неудачных собеседований за два года, чтобы устроиться на свою первую работу с кабальными условиями. чистой потогонкой была та работа, но и она была ценна. уже тем, что она была и за нее платили хорошие деньги. мы, программисты, ценили факт наличия работы, мы видели снаружи последствия краха доткомов, и 09/11, и краха Телесенса. для меня это была первая работа, и я вдвойне ценил таким трудом добытое место. я учился отвественности, и качеству, и работе по 14 часов в сутки, и быстрому обучению, и долгому саппорту. очень много мне дала первая работа, и в профессиональном и в личном плане.
а после работы, вне стен офиса, мы -- я и мои друзья-коллеги -- мечтали о том, как станем мы экспертами. как будем не мы искать работу, а она нас. как сможем не терпеть прихоти локальной администрации, а ставить условия. как будут считаться с тем, что все-таки мы -- программисты -- создаем реальные продукты. да, роль менедмента и администрации важна, но не следует относитсья к нам, как к крепостным крестьянам. бойтесь своих желаний, они имеют тенденцию сбываться.
шло время, росла моя компетенция, росла моя цена на рынке труда. менялись условия. надувался "пузырь 2.0". и вермя, о котором я мечтал 6 лет назад, пришло. мы построили рынок нашей мечты -- где программист царь и Бог, где его ищет работа и о нем заботиться начальство. и нет сейчас проблем у программиста найти работу. а у хорошего программиста есть проблема отказаться от еще одной работы. но теперь мне приходиться "пасти котов" (с), я стал представителем руководства. и когда невозможно применить сколь-нибудь жесткие меры, такой себе "кнут" в отношении подчиненных, когда руководить приходиться только с помощью "пряников"... это ужасно.
разумеется и в той ситауции, в которой находился я при старте карьеры, ничего хорошего нет. любой перекос, ведущий либо к недооценке, либо к переоценке труда каждого из сотрудников, будь они менеджеры или уборщицы, есть зло. но всегда должен быть баланс. ситуация, когда человека не соотвествующего занимаемой должности можно только "придавить" морально, когда любая непопулярная мера является риском потери ресурса в проекте -- это не нормально. люди перестали быть заинтересованными хорошо делать свою работу, мы возвращаемся в "жизнь по Жванецкому": хорошо собираешь велосипед -- тебе 120, плохо собираешь велосипед -- тебе 120, вообще не собираешь велосипед -- тебе 120 (с).
одной из мер, которая поможет восстановить баланс, я считаю возрождение или старт системы рекомендаций. когда соискатель в резюме или на собеседовании называет пару-тройку своих прошлых руководителей, которые бы могли его рекомендовать. это не обязательно должны быть руководители с текущего места работы, но кто-то, кто может рассказать, как человек ведет себя в боевых условиях. почему он ушел из конторы, как его там оценивали. это тоже субъективное мнение, и презумпция невиновности должна работать здесь. если из двух руководителей, один безмерно хвалит соискателя и расскаызвает, как тот крут и отвественен, а второй -- ругает на чем свет стоит, то скорее всего со вторым руководителем, соискательно просто не сработался. так тоже бывает.

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

2008-04-23T01:57:00.010+03:00

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

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

JavaScript tips&tricks

2008-04-23T01:28:00.009+03:00

для того, чтобы сделать быстрый 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!" + "')");
}

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

2008-04-11T09:14:00.005+03:00

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

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

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

2008-04-08T08:45:00.011+03:00

про АОП я узнал два года назад, когда я открыл для себя Spring всплыла тема АОП. но тогда у меня не было времени разбиратся с этой концепцией, тем более что она показалась мне довольно сложной и не относящейся к тому, что я тогда делал. коллеги в соседнем проекте вроде бы как использовали аспекты, но я так и не был привлечен в разработку этого проекта. а следовательно АОП осталась очередной технологией в стопке "посмотрю, когда будет время".
интерес мой проснулся спонтанно, Виктор Ронин выложил пост про локализацию ошибок. я большой поклонник использования подробного логирования программы для этих целей. однако, код логов действительно "засоряет" код программы и возможность отделит одно от другого была бы очень кстати. и тут я вспомнил про АОП.
действительно, логирование или трассировка программы -- это одна из классических задач АОП. но часто кажется, что одних средств АОП тут недостаточно и все-равно необходимо использовать логи внутри функционала, а раз так, то зачем писать что-то еще? пусть все логи будут внтури, раз нельзя их полностью отделить. на самом деле это не так. рабочую систему логирования я опишу позже, когда создам и оттестирую таковую :) пока поговорим о практических принципах применения АОП в среде Java + Spring. в документации по Spring очень много написано про АОП, фактически есть два способа реализации аспектов --с помощью Spring AOP и через AspectJ. я пока пользуюсь AspectJ аспектами, но возможно посмотрю и реализацию Spring.
итак, первое что необходимо понимать при аспектном программировании -- мы работаем с вызовами функциональности. т.е. елементарная операция для аспекта -- это вызов. мы можем описать для вызова пред- и пост-условия, обернуть выполнение метода какой-то функциональностью, котролировать метод после выброса исключения или после точки возврата. мы не можем обратиться к функционалу метода напрямую, но любой метод нашего класса есть на 90% набор вызовов других методов, а эти методы в свою очредь доступны через АОП. небольшая иллюстрация в коде, чтобы было еще понятнее:
предположим нам необходимо заполнить некторую коллекцию, пусть реализацию java.util.Map внутри класса:

package org.corwin.samples;

public class AopSample {
    private Map container = new HashMap();

    public void fillMap() {
        container.put("sample1", "something");
        container.put("sample2", "another thing");
    }
}

теперь опишем аспект, который будет контролировать AopSample класс:

package org.corwin.samples.aspects;

public class SampleAspect {
    public void beforeFillMap() {
        System.out.println("Call before Map fill with values");
    }

    public void afterFillMap() {
        System.out.println("Call after Map fill with values");
    }
}

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

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop" 
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
">
    <bean id="sampleClass" class="org.corwin.samples.AopSample"/>
    <bean id="sampleAspect" class="org.corwin.samples.aspects.SampleAspect"/>
    <aop:config>
        <aop:aspect ref="sampleAspect">
            <aop:pointcut id="mapPutCut" expression="execution(* java.util.Map.put(..))"/>
            <aop:before method="beforeFillMap" pointcut-ref="mapPutCut"/>
            <aop:after method="afterFillMap" pointcut-ref="mapPutCut"/>
        </aop:aspect>
    </aop:config>
</beans>

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

Monday hard

2008-04-01T01:22:00.005+03:00

сегодняшний, а вернее уже вчерашний понедельник, оказался действительно днем тяжелым. началось все с того, что я решил переселится сюда. несмотря на полярные мнения, я доверяю сервисам Google. и когда мне захотелось сменить площадку, то я выбрал именно эту, насколько хорош был выбор -- покажет время. я долгое время что-то подкручивал, что-то менял в шаблоне, копировал статьи той тематики, которой я бы хотел здесь видеть, из моего старого блога. а потому в офис добрался уже после полудня. как говорится ничто не предвещало беды. привычный офис, привычные лица, набор работ, запланированный заранее...
все пошло кувырком сразу после приема утреней почты, в которой оказалась задача по бизнесс-аналитике. эту задачу я успешно делегировал стразу двоим Java Developerам, с прозьбой посмотреть и определится будет ли им инетерсно этим заниматься. потом случился митинг с моим СТО по поводу деятельности отдела, затем по плану был английский, на деле -- получился минимитинг в курилке с СТО тестров, где довольно полезно и толково обсудили необходимость формализации процессов. если все пойдет хорошо, сможем наладить взаимодействие между отделами. потом таки случился английский, но не надолго -- меня выдернул менеджер проекта, на очередной митинг по статусу одного из Java проектов. весьма проблемного проекта, между прочим. обсудили причины срыва сроков итерации, впервые я увидел заинтересованность людей в признании и исправлении ошибок. понимание необходимости системных изменений в проекте. даст Бог, будет и тут продвижение.
затем я переговорил с заказчиком одного из моих основных и наиболее технологически интересного проекта. как же замечатльно работать с людьми, которые смотрят по стронам, понимают, что Head of Java Department -- это не просто "фуражка", а еще и множество обязанностей. общением с этим заказчиком я пока очень доволен. довольно редко мне получалось видеть людей открытых, понимающих и адекватных с другой стороны. может потому, что люди были другие, а может потому, что я не контактировал с этими людми напрямую, или контактировал не в полном объеме.
остаток дня (вечера, ночера) я занимался морально-технической поддержкой операции по спасению итерации нашего проблемного проекта :)
итоги дня радуют, похоже у нас получает сформировать команду и восптитать у людей отвественность за работу. это то, чего реально не хватает проекту. конечно хотелось бы это делать менее экстремальными методами, но все-таки позивный результат прослеживается. еще одним итогом митингов можно считать понимание необходимости создания технического профайла проектов, я искрене надеюсь, что это останется не просто договоренностями, но и обрете реальную форму.
а еще день поставил вопрос абсолютно неогранизованного процесса доставки сотрудников по домам после таких вот ночных посиделок. нужно эскалировать этот вопрос наверх.
самый главный итог дня для меня наверное заключается в том, что жизнь моя снова стимулирована плотным потоком событий. событий важных, нужных и целевых. ощущение, которое к моему великому сожалению начало уже забываться.

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

2008-03-31T10:12:00.016+03:00

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

все порталы, удовлетворяющие спецификации JSR-168, предоставляют стандартный механизм доступа и модификации настроек портлетов, посредством реализации интерфейса javax.portlet.PortletPreferences. в данной заметке рассмотрим способ работы с настройками портлета, реализованного с помощью технологии JavaServer Faces.
быстрое решение
основным интерфейсом связи с внешней средой для JSF технологии является класс javax.faces.context.FacesContext. параметры портлета, сведения о типе портального запроса, настройках режима и вида портлета храняться в классах-реализациях интерфейса портального запроса javax.portlet.PortletRequest. сведенья о пространстве имен портлета храняться в реализациях интерфейса портального ответа javax.portlet.PortletRespose. для связи всех этих классов и получения доступа к специфическим параметраметрам и установкам портлета реализуем утилитарный класс:

public final class PorletFacesUtils {
    private PortletFacesUtils() {
    }

    public static PortletRequest getPortletRequest(FacesContext context) throws Exception {
        Object request = context.getExternalContext().getRequest();
        if (request instanceof PortletRequest) {
            return (PortletRequest) request;
        } else {
            throws new Exception(“Portlet run outside the portal environment or portlet request class is not generic”);
        }
    }

    public static PortletRequest getPortletResponse(FacesContext context) throws Exception {
        Object response = context.getExternalContext().getResponse();
        if (request instanceof PortletResponse) {
            return (PortletResponse) response;
        } else {
            throws new Exception(“Portlet run outside the portal environment or portlet response class is not generic”);
        }
    }

    public static PortletPreferences getPortletRequest(FacesContext context) throws Exception {
        PortletRequest request = getPortletRequest(context);
        return request.getPortletPreferences();
    }
}

таким образом мы реализовали своеобразный мост между JSF-приложением и специфическими классами портальной среды. далее этот класс может быть использован для работы с параметрами и настройками портлета. также класс расширен для получения других классов, специфичных для портальной среды (например javax.portlet.PortletSession, javax.portlet.PortletContext и т.п.).
риски
некоторые фреймворки JSF компонентов (например ICEfaces) использую свои врапперы портальных запросов и ответов. эти врапперы могут не являться наследниками стандартных интерфейсов, а следовательно будут ошибочно обработаны утилитарным классом. в этом случае необходимо реализовать механизм адаптера портальной среды для конкретной реализации враппера. как это сделать, я расскажу ниже.

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

public interface PortletFacesAdapter extends Serializable {
   PortletRequest getPortletRequest(FacesContext context);

   PortletResponse getPortletResponse(FacesContext context);

   PortletPreferences getPortletPreferences(FacesContext context);
}

перенесем функциональность утилитарного класса в реализацию интерфейса адаптера:

public class GenericPortletFacesAdapter {
    public PortletRequest getPortletRequest(FacesContext context) throws Exception {
        Object request = context.getExternalContext().getRequest();
        if (request instanceof PortletRequest) {
            return (PortletRequest) request;
        } else {
            throws new Exception(“Portlet run outside the portal environment or portlet request class is not generic”);
        }
    }

    public PortletRequest getPortletResponse(FacesContext context) throws Exception {
        Object response = context.getExternalContext().getResponse();
        if (request instanceof PortletResponse) {
            return (PortletResponse) response;
        } else {
            throws new Exception(“Portlet run outside the portal environment or portlet response class is not generic”);
        }
    }

    public PortletPreferences getPortletRequest(FacesContext context) throws Exception {
        PortletRequest request = getPortletRequest(context);
            return request.getPortletPreferences();
        }
}

теперь нам необходимо реализовать JSF managed bean, который будет поддерживать механизм адаптеров:

public class AdaptableBean implements Serializable {
   private PortletAdapter adapter;

   public PortletAdapter getAdapter() {
      return adapter;
   }

   public void setPortletAdapter (PortletAdapter adapter) {
      this.adapter = adapter;
   }
}

фактически мы реализовали механизм полноценной работы JSF framework внутри портальной среды. осталось только проиллюстрировать его конфигурацию. итак реализуем простой класс JSF managed bean, который используется в портлете:

public class TestBean extends AdaptableBean {
}

и сконфигурируем портлет, для использования этим классом GenericPortletFacesAdapter адаптера:

<faces-config>
   <managed-bean>
      <managed-bean-name>portletAdapter</managed-bean-name>
      <managed-bean-class>GenericPortletFacesAdapter</managed-bean-class>
      <managed-bean-scope>application</managed-bean-scope>
   </managed-bean>
   <managed-bean>
      <managed-bean-name>testBean</managed-bean-name>
      <managed-bean-class>TestBean</managed-bean-class>
      <managed-bean-scope>request</managed-bean-scope>
      <managed-property>
         <property-name>adapter</property-name>
         <value>portletAdapter</value>
      </managed-property>
   </managed-bean>
</faces-config>

ссылки
Java Portlet API
JavaServer Faces API
статья на английском языке

Liferay + JSF + ICEfaces

2008-03-31T01:10:00.032+03:00

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

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

ошибки JavaScript, вызванные отсутсвием инициализированного объекта window.logger.

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

после решения проблемы с логгером, асинхронные обращения к серверу, посылаемые ICEface, завершаются ошибкой JavaScript.

Solution: на странице портала должен быть... только один портлет с компонентами ICEfaces. тогда все работает нормально. если поместить туда другие портлеты, возникают ошибки. на форуме ICEfaces я обнаружил, что это проблемы интеграции, связанные непосредственно с Liferay Portal. и действительно, проблема была решена в версии 4.3.1

Liferay Portal 4.3.1 & ICEfaces 1.6.0
после решения проблемы взаимодействия портлетов, содержащих ICEfaces компоненты, и других портлетов в Liferay Portal, разработке ICEfaces портлетов мешала только одна проблема: ошибка, при обработке правил навигации внутри ICEfaces портлета. причной обшибки являлось предопределенное обновление контейнера <body id="body"> после выполнения правила навигации JSF. такое поведение недопустимо внутри порталов, поскольку портлет является лишь частью HTML страницы. решением проблемы могла стать замена стандартного ICEfaces ViewHandler, на разработанный специально для исправления этой ошибки.
ссылки
статья на английском
форум компонентов ICEfaces
матрица JSF компонентов

Liferay 4.2.2 themes handling bug

2008-03-31T00:38:00.010+03:00

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

Ошибка обработки идентификаторов темы в Liferay Portal 4.2.2
для версии 4.2.2 Liferay Portal зафиксирована не корректная работа с идентификаторами портальных тем, развернутых как внешние WAR-приложения с помощью механизма автоматического развертывания компонентов портала (тем, шаблонов расположения и портлетов).
проблема
ошибка заключается в возникновении java.lang.NullPointerException (далее NPE) при обращении к настройкам вида и поведения созданного комьюнити/группы/пользователя при установке темы, развернутой как внешнее WAR-приложение (далее Тема), в качестве темы используемой по умолчанию.
после исследования проблемы, определено, что источником ошибки является не корректная работа с идентификатором темы.
причины возникновения
для всех компонентов, развернутых с использованием механизма авто-развертывания, Liferay Portal генерирует сложные идентификаторы по шаблону <theme-id>_WAR_<web.xml_display_name>. к примеру если тема имеет theme-id=foo, определенный в liferay-look-and-feel.xml, и display-name=bar, определенный в web.xml, то конечный идентификатор Темы в Liferay Portal будет foo_WAR_bar.
стандартная документация описывает изменение параметров, установленных по-умолчанию, с использованием идентификатора темы в том виде, в котором он определен в liferay-look-and-feel.xml (для примера приведенного выше -- foo). однако, API портала не обрабатывает идентификатор для Тем и использует его значение из portal(-ext).properties без изменений. таким образом, происходит попытка обращения к несуществующей Теме и возникает NPE.
решение
для решения данной проблемы необходимо определять идентификатор темы в portal(-ext).properties с учетом его автоматической модификации внутри портала. иными словами, значение параметра default.theme.id должно быть не theme_id, а <theme_id_WAR_<web.xml_display_name>. дла описанного выше примера соотвественно -- не default.theme.id=foo, а default.theme.id=foo_WAR_bar.
для использования произвольной Темы, в качестве темы по-умолчанию, будет полезна следующая инструкция:
1. развернуть Тему следуя стандартному процессу.
2. авторизоваться в Liferay Portal как пользователь с правами администратора и установить Тему в качестве темы любого доступного компьюнити.
3. открыть базу данных портала в любом SQL-клиенте.
4. выполнить select themeId from layoutset where groupId = (select groupId from group_ where name = )>, где community_name - имя комьюнити, где использована Тема.
5. использовать выбранный идентификатор, как значение параметра default.theme.id
область распространения
проблема выявлена для версии портала 4.2.2 и не тестировалась на других версиях. не исключено исправление ошибки в старших и отсутствие в младших версиях.
для предустановленных тем портала стандартный механизм работает корректно.
ссылки
комментарий на форуме Liferay Portal(англ.)

once upon time....

2008-03-31T00:29:00.002+03:00

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