Тренинг "Почему плохо быть эгоистом"

Все смотрели фильмы про воров и убийц.
Почему Вы никогда не оказывались среди них? Задумайтесь. Риск? А как же барыши? Т.е. риск - возможно не самое главное (раз есть несколько уравновешивающий фактор). Так в чем же дело? Плохо кончить? Потерять себя? Ну, последнее, конечно же, есть, но Вы сейчас об этом не задумываетесь (возможно тоже можно чем-нибудь "уравновесить"). Еще у нас осталось "плохо кончить". Почему же - возможно ведь наоборот - остров, песчаные пляжи, коктейль с соломинкой... Т.е. пока мы такого "фактора" не нашли. Вспомните, что Вас напрягает, когда Вы смотрите бандитский фильм. Наверное - не совсем здоровая атмосфера, в отношениях. Грубые выкрики, заточка как символ опасности и постоянной борьбы за жизнь среди себе подобных. Т.е. сама "атмосфера"? Контингент? Лица, ко всему этому причастные? Ну вот мы и докопались, возможно, до главного. А почему Вас напрягает этот контингент, вернее - какой фразой можно охарактеризовать отношения (человеческие) с ним? - "Низкая планка социальной ответственности"? - А теперь смотрим заголовок, тему - речь про эгоистов. Можно ли про них сказать тоже самое - "низкая планка социальной ответственности"? - Вполне возможно, что сразу в нескольких плоскостях (видения) это и характеризуют их. К чему мы пришли? А пришли мы к низкой планке социальной ответственности (Н.П.С.О.) и тем свойствам, которыми она обладает:

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

2) Карнеги выделяет 3 краеугольных камня в жизни каждого человека - семья, работа, друзья. Если у Вас все 3 камня развивались в соответствии с Н.П.С.О, то жена Вас скорее всего бросит (появится головная боль - дети, помимо того что у самих детей будут проблемы), с работы Вас уволят, а друзья Вас оставят. Выгодно ли так? Практично ли? Постарайтесь заранее купить что-нибудь револьверо подобное, ведь Карнеги пишет, что утрата СРАЗУ всех 3-ех камней - будет для Вас ОЧЕНЬ серьезным ударом. Чтобы дальше не мучиться (а Вы долго способны терпеть боль?) - просто купите и все.

3) Вы можете вполне радоваться самым низменным желаниям - поесть, украсть (обмануть), ну и не терзаясь совестью - обмануть любимого человека. Не забудьте посмотреть документальный фильм про шимпанзе (эти приматы по уровню интеллекта практически "достают" до человека) - Вам уготована жизнь их уровня развития. Не нужно слез, попыток разглядеть что-то в себе - водитесь с себе подобными, не забывайте про револьвер (интересная анология - "обезьяна с гранатой" - это про Вас, да, да), те ресторанные блага, которыми Вы, возможно, гордитесь - это все лишь та жа самая трава, подножный корм, просто ловко приготовленный другой обезьяной. Если Вы добьетесь рекордов в жизни (в метании гранат, лазании по деревьям, громкому крику в ночи) - о Вас останется память потомкам - пара зазубрин на могильном камне, пара байт в логах чата далекого, покоящегося в веках (с точки зрения потомков) 21-го века. Можете стихи написать. 3 стиха вполне достаточно, чтобы почувствовать в себе "отголосок" Ахматовой или Шекспира. Можете сценку поставить - Вы с другой бабуинкой спасаетесь от бабуинов соседнего племени. -- Если начнете кидать гранаты или палить из пистолета - получится вполне приличного вида боевик или вестерн. Почаще кричите с вершины деревьев - вдруг в Вас заложен дух великого композитора?

Что для Вас значит "великий"? - Тот, кто покрошил народы десятков стран (Македонский, Чин Гиз Хан)? Или тот, кто построил самый высокий памятник? Или тот, кто изобрел самую губительную гранату? Имевший много власти? - Т.е. умеющий работать локтями? - Поздравляю! Вы достигли права жить в самой роскошной пещере и выбрать самую упругую самку! -- Счастливы? Ну и покойтесь с миром. Вождь обезьян, предводитель вот тех, да, да - тех 3-ех скал, в лучшем овраге на ближайшую пару километров. Вы счастливы? Какое-то сопливое счастье получается. Неумытое. С накрахмаленной повязкой на бедрах (или модным галстуком), выделяющим Вас среди других обезьян.

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

Кто прав?

Диалог из фильма "Правосудие Стоуна. Никакого раскаяния":

-- Почему Вы соврали?

-- Я никогда не вру.

-- Ладно. Почему Вы создали ошибочное впечатление?

-- Джейси Стоун, мы никогда не говорим о том, о чем говорим на самом деле. И потом - Вы отвечаете за Ваше впечатление от нашей беседы.

Почему нужно ждать ответа только 2 дня

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

Итак, в чем же причина? Сайт hh.ru провел опрос среди HR, чтобы разобраться.

Agile, Scrum и прочие ангелы и демоны

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

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

Вообще сразу хочется написать "как правильно", и хорошо иллюстрирует это - разработка фреймворков у JBoss.

Выделить можно следующее:

1) JIRA. Или любая другая баг-трекинговая система. В принципе - это самая главная вещь, в технологии постановки процесса. Все должно упираться в нее (подробнее - далее).

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

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

4) Наверное еще могут быть списки рассылок, титульная страница проекта, новости проекта, публичный доступ ко скачиванию из SVN и т.д.

Организация людей:

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

2) Грамотно оценить сроки выполнения, сроки исправлений - сможет только Team Lead (априори самый технологически подкованный человек в команде разработчиков). В его же обязанности входит разработка самых сложных подсистем проекта.

Любая разработка должна последовательно, ИТЕРАЦИОННО, проходить через следующие этапы:

- Объектно-ориентированный анализ (общение с заказчиков, составление use cases)

- Объектно-ориентированное проектирование (блок-схемы, диаграммы классов и т.д.)

- Объектно-ориентированное программирование (само программирование)

Каждая из итераций должна включать ВСЕ ТРИ этапа и длиться от 1 до 2 недель. Для некоторых проектов может быть по другому, здесь - для подавляющего большинства.


3) Объектно-ориентированным анализом занимаются аналитики требований. Или эту обязанность берет на себя "менеджер" из п.1.

4) Объектно-ориентированным проектированием - архитектор проекта (возможен и выделенный архитектор СУБД) + программисты + Team Lead. Обычно это делается на совещаниях-планерках, а так же на своих рабочих местах (рисование диаграмм для Википедии).


О вертикали власти в IT.

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

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

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

Во втором случае мы имеем полу-профессионала в обоих областях. С вытекающим отсюда полупрофессиональным управлением.

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

Понимаете, в чем тут удобна JIRA - ? -- Все, кто должен ставить требования - должны ставить задачи там (возможно после обсуждения с Team Lead). Все, кто должен исправлять/выполнять - брать задачи от туда.

В эту же схему отлично вписываются тестировщики. А так же отдел дизайна (или привлекаемые специалисты, в том числе и HTML-верстальщики).

А если имеется "вертикаль", то:

1) Постоянно будет непонимание "бизнеса" и "технологий". Это выливается, особенно - в планирование бизнесом затрат на разработку. А это означает, что постоянные проблемы в понимании - приводят к постоянным проблемам в разработке. С поиском крайнего и т.д. Кому это нужно?

2) Постоянное "отлынивание" различных отделений фирмы. Если от "бизнеса" поступило всего 3 пункта в JIRA в месяц - значит директор, отдел маркетинга - ПРАКТИЧЕСКИ НЕ ПРИНИМАЮТ УЧАСТИЯ. Перекуры по 30 минут, прятание за необходимостью куда-то ехать и подписывать договора и т.д. и т.п. А так бы, в JIRA если - все видно за месяц! И за пол года! Какое участие, кто там виноват, что так поставлен процесс в отделе маркетинга - начальник там не следит за специалистами, или что или как. Без JIRA всего этого не видно ВООБЩЕ. (Смягчающим фактором может быть только постоянное участие в планерках с программистами, но в этом случае, в конечном итоге - мы получили бы пункты в JIRA).

Директора/акционеры - эти тоже не дураки по отлынивать, чуть подробнее об этом. - Практически на всех фирмах директора любят работать много. Представьте, на секунду представьте - что эта фирма - ВАША. Вы будете много работать? На СЕБЯ? Скорее всего будете. И скорее всего увлечетесь. А теперь вспомните, как много раз вам говорили о переработках, нужности их, как директор отлично замечает  ваше даже 2-ух минутное опоздание. Вспомнили? А то, что за эти 2 минуты - вы, частенько, вечером на 30 минут позже уходите - об этом вам приходится говорить ему, и все равно на многих фирмах "дерут" даже за двухминутное опоздание. Потому что ДИРЕКТОР ГОРИТ РАБОТОЙ. И вы бы горели. Если бы дело было вашим.

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

В ИТОГЕ ДИРЕКТОР РАБОТАЕТ СТОЛЬКО ЖЕ, СКОЛЬКО И ВЫ. Он сам не замечает, когда по месяцу и по два - сознательно отлынивает от процесса. Но от вас он требует переработки.

А между тем:

1) Это НЕ ВАШЕ дело (не ваш бизнес).

2) У вас своя семья! И вы ДОЛЖНЫ уделить ВРЕМЯ ДЛЯ ВОСПИТАНИЯ, например, вашего ребенка. И для походов с женой по злачным местам. Вы ДОЛЖНЫ делать это. А не сидеть до 20-00 в офисе, придя с самого утра.
И про мать свою вы должны не забыть. Или у нас не то общество, с другими ценностями?

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

Если кто-то 12 часов в день в офисе - значит он 3-4 часа из них - фактически не работает (занят другим).

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

И ВСЕ НАЧИНАЕТСЯ С ДИРЕКТОРА. Если что-то на фирме идет не так - виноват, в первую очередь - директор. Это он НЕ ПОСТАВИЛ ПРОЦЕСС, не предусмотрел. Наемные работники - под его УПРАВЛЕНИЕМ.

Спасибо за внимание. :)

JBoss AS. Светлое будущее и настоящее

К сожалению мне лениво переводить, но появившееся интервью немного любопытно. Рекомендуется только для истинных фанатов JBoss AS (как стремящихся уловить любые нюансы).

Для них же еще информация - в дополнении к книге "JBoss AS 5 Development", следом вышла книга "JBoss AS 5 Performance Tuning", в которой описываются самые разнообразные варианты использования (для разных технологий JEE), разные способы использования (более эффективные, менее эффективные) и приводятся сравнительные цифры производительности.

Например уровень логгирования может дать ощутимый прирост производительности. Есть не совсем очевидные нюансы. Высчитывать, что же лучше - вы можете сами. Или посмотрев примерные тесты производительности в книге.

3 дня до выхода нового Debian

Мне как раз нужно на одну машину поставить что-нибудь шустрое из линуксов. К сожалению на нее не поставить Oracle Linux + Unbreakable Enterprise Kernel (очень быстрая вещь), и так просто на нее не поставить и RHEL 6 (по идее тоже должна летать, потому что ядро этой же версии - 2.6.32, а не 2.6.18, как у RHEL 5 и у "обычного" Oracle Linux).

Поэтому все надежды на Debian Squeeze. Который вот-вот.

Долго ли, коротко ли

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

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

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

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

Ссылка на их пример.

Если в двух словах - вы добавляете одну аннотацию к Java-классу, который будет сервисом и добавляете еще одну аннотацию к Java-классу, который будет использовать этот сервис. Вот и все. В параметрах аннотации можно указать способ связи между ними (например JMS).