Сайт для изучения agile-методик

Коллеги прислали ссылку на великолепный сайт по изучению agile-процесса : http://scaledagileframework.com/. Картинки кликабельны и позволяют прочитать описание и детали каждой части. Читать и ещё раз читать !

Загрузка ресурсов из WEB-INF/lib/jar-ов

Проблема

    При попытке доступа к ресурсу из каталога веб-приложения WEB-INF/lib (а именно к jar-библиотеке), по URL полученному из ServletContext-а не получается создать объект класса JarFile. На данный момент проверено под Tomcat 7.x (позже проверю под OAS и WLS)

Решение

    Для того, чтобы ресурс мог потом быть доступен через JarFile (например для чтения описания readme.txt из файла внутри jar-а), необходимо использовать хак :

1. Добавить к строке, полученного url-а ресурса "jar:" впереди и "!\" позади. 
2. Использовать url.openConnection()

Пример

// получить список ресурсов в WEB-INF/lib

Set<String> jarLibPaths = servletContext.getResourcePaths("/WEB-INF/lib");




for (String jarPath : jarLibPaths) {




  // так будет неправильное преобразование типа ClassCastException, т.к. открытое соединение не JarURLConnection

//  URL urlBad = servletContext.getResource(jarPath);  

//  JarURLConnection conn = (JarURLConnection) urlBad.openConnection();




  // так будет FileNotFoundException

//   URL urlBad2 = servletContext.getResource(jarPath);  

//   JarFile jarFile = new JarFile(urlBad2.getFile());

//   JarFile jarFile = new JarFile(urlBad2.toString()); // та же проблема




//  URL urlBad3 = new URL("jar:" + servletContext.getResource(jarPath).toString() + "!/");  

//  JarFile jarFile = new JarFile(urlBad3.getFile());   // снова ошибка




  

  // а так всё будет работать

  URL urlOk = 

      new URL("jar:" + servletContext.getResource(jarPath).toString() + "!/");  

  JarURLConnection conn = (JarURLConnection) urlOk.openConnection();

  JarFile jarFile = conn.getJarFile();

}

Управление временем. Конспект.

• Начало

• Инструменты : бумага, ручка, потом ежедневник, outlook(?)

• Сгрести все задачи в одно место - общий список

• Принять факт, что нельзя делать 5 задачь одновременно !!! Только одну

• Расстановка приоритетов: всего два парметра срочность и важность : приоритет = срочность + важность (в процессе происходит переприоритезация)

• Группы по времени

• Месяц (планируем 1 раз в месяц)
• Неделя (планируем 1 раз в неделю)
• День (утром) - СЕГОДНЯ

• Планирование : Выбор из общего списка задач на день

• "жёсткие" : обязательно к определённому времени (разговор с директором)
• "мягкие" : надо, но не очень срочно
• список "кайросов" - очередь задач, которые требуют творческого подхода, т.е. если вдруг "попёрло", то надо знать, что именно делать в первую очередь (должен быть список таких задач)

• Планирование дня

мягкое, т.е. оставлять "зазоры" времени между задачами. на всякие непредвиденные (но как показывает практика ВСЕГДА случающиеся внезапные звонки, разговоры и т.п.)

• Классификация задач

• "слон" : большая - не укладывается в 1 день, не укладывается в голове 

• декомпозировать

• начинать с понятного

• "лягушка" : неприятная, делать не хочется

• составить список таких задач
• каждый день по одной

• "конфета" : то, что делать приятно и хочется

• оставлять на потом
• без "лягушек" не есть

• Качество времени

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

• Отдых

• ритм : 1 час работы/5 минут отдыха
• переключаться между разноплановыми задачами

• Дополнительные замечания

• review в конце недели, по итогом которого составляются цели на следующую неделю
• 1 раз в неделю Цели --> Задачи
• Постоянный пересмотр приоритетов

Oracle WLS и springframework

Спасибо "суровому челябинскому программисту" за подробное описание как включить и настроить интеграцию SpringFramework и консоли администрирования Oracle WLS.
http://samolisov.blogspot.ru/2012/11/spring-framework-weblogic.html
Существенно может помочь в эксплуатации. Будем пробовать.

Упражнение на дикцию.

Читать вслух каждый день.

В четверг четвертого числа в четыре с четвертью часа
лигурийский регулировщик регулировал в Лигурии,
но тридцать три корабля лавировали, лавировали, да так и не вылавировали, а потом протокол про протокол протоколом запротоколировал, как интервьюером интервьюируемый лигурийский регулировщик речисто, да не чисто рапортовал, да не дорапортовал дорапортовывал да так зарапортовался про размокропогодившуюся погоду что, дабы инцидент не стал претендентом на судебный прецедент, лигурийский регулировщик акклиматизировался в неконституционном Константинополе, где хохлатые хохотушки хохотом хохотали и кричали турке, который начерно обкурен трубкой: не кури, турка, трубку, купи лучше кипу пик, лучше пик кипу купи, а то придет бомбардир из Бранденбурга — бомбами забомбардирует за то, что некто чернорылый у него полдвора рылом изрыл, вырыл и подрыл; но на самом деле турка не был в деле, да и Клара-к крале в то время кралась к ларю, пока Карл у Клары кораллы крал, за что Клара у Карла украла кларнет, а потом на дворе деготниковой вдовы Варвары два этих вора дрова воровали; но грех — не смех — не уложить в орех: о Кларе с Карлом во мраке все раки шумели в драке, - вот и не до бомбардира ворам было, и не до деготниковой вдовы, и не до деготниковых детей; зато рассердившаяся вдова убрала в сарай дрова: раз дрова, два дрова, три дрова — не вместились все дрова, и два дровосека, два- дровокола- дроворуба для расчувствовавшейся Варвары
выдворили дрова вширь двора обратно на дровяной двор,
где цапля чахла, цапля сохла, цапля сдохла; цыпленок же цапли цепко цеплялся за цепь; молодец против овец, против молодца сам овца, которой носит Сеня сено в сани, потом везет Сеньку Соньку с Санькой на санках: санки- скок, Сеньку- в бок, Соньку- в лоб, все- в сугроб, а Сашка только шапкой шишки сшиб, затем по шоссе Саша пошел, Саша на шоссе саше нашел; Сонька же — Сашкина подружка шла по шоссе и сосала сушку, да притом у Соньки-вертушки во рту еще и три ватрушки —
аккурат в медовик, но ей не до медовика —
Сонька и с ватрушками во рту пономаря перепономарит, - перевыпономарит: жужжит, как жужелица, жужжит, да кружится: была у Фрола — Фролу на Лавра наврала, пойдет к Лавру на Фрола Лавру наврет, что — вахмистр с вахмистршей, ротмистр с ротмистршей, что у ужа — ужата, а у ежа- ежата, а у него высокопоставленный гость унес трость, и вскоре опять пять ребят съели пять опят с полчетвертью четверика чечевицы без червоточины, и тысячу шестьсот шестьдесят шесть пирогов с творогом из сыворотки из-под простокваши, - о всем о том около кола колокола звоном раззванивали, да так, что даже Константин — зальцбуржский бесперспективняк из-под бронетранспортера констатировал: как все колокола не переколоколовать, не перевыколоколовать,
так и всех скороговорок не перескороговорить, не перевыскороговорить; но попытка — не пытка.

Рецензия-mindmap на книгу.Панасюк.Как победить в споре

Прочитал замечательную и очень содержательную книгу по технике спора. Так понравилось, что даже mindmap-ы нарисовал. Рекомендую.
https://sites.google.com/site/pevgen/knigi/a-u-panasuk-kak-pobedit-v-spore

А.Ю.Панасюк. Как победить в споре

Отличная книга.  Последовательно, сжато и при этом достаточно коротко объясняются основы спора, с точки зрения психологии риторики. На примерах показаны рациональные  и иррациональные аспекты спора. Как правильно выстраивать аргументацию, как  психологически  помогать противнику перейти на свою сторону, как бороться  с манипулятивными приёмами. Сделал для себя mind-map-ы.

spring-jdbc или mybatis

Несколько плюсов и минусов при сравнении spring-jdbc и mybatis

spring-jdbc
+Удобно вызывать функции Oracle, возвращающие значения
+Удобно(просто) вызывать простые запросы
-Создавать сложные объекты (с коллекциями связанных объектов) можно только "вручную"
-Не очень хорошее логирование (обещают сделать в v.3.2)

mybatis
+Сложные объекты, с коллекциями связанных, создаются через описание
-В определённых случаях поведение сложных объектов не соответствует ожидаемому (например, если разные машины содержат одинаковый груз, то этот груз - фактически один объект, и следовательно, при изменении данных одного груза, изменятся все остальные)

Вывод
Идеал не достижим :) - для разных случаев использования, удобнее пользоваться разными библиотеками. Там, где простые объекты - spring-jdbc, где сложные - mybatis (с осторожностью и тестами)

Измерения метрик в разработке (перепост)

Взято отсюда : Кому же нужны метрики ?

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

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

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

    Безразличие, или мне(нам) это не надо, и вообще о чем это.Встречается там, где и так все нормально, т.е. заказчик и руководство довольны (или думают что все хорошо  , и поэтому довольны), существенных проблем нет, или к ним относятся очень снисходительно. Хорошо настроенных рабочих процессов тоже нет, но т.к. компания молодая, или небольшая, то все на виду и все вопросы можно преспокойно решать ручным управлением. Или же все настолько благоденствуют (я без сарказма, такое тоже бывает), что напрягаться по поводу метрик и не надо. И действительно, зачем (опять же без сарказма  )? Но это обычно долго не длиться, рано или поздно возникают вопросы типа: Почему вы так медленно работаете? Почему у вас столько дефектов? Да у вас же на устранение дефектов уходит больше времени, чем на разработку! Почему вы никогда не можете более-менее точно спрогнозировать, когда же вы закончите? И тому подобное. А возразить-то особо нечего, т.к. непонятно как это все объяснить.
    Мягкий отпор, или мы тут работу работаем, нам не до метрик. Это следующая ступень после первой. Итак, посыпались вопросы, проблемы. Их надо решать, а то заказчик платить перестанет. К сожалению, обычно мы боремся с последствиями, а не с причинами, и в таком состоянии зависаем. И боремся экстенсивными методами, такими как внеурочная работа, выкидывание «ненужных» видов работ (тестирование, ревью кода, специфицирование и т.п.). Просто педалим. Тут действительно не до метрик. Но вот здесь уже 100% нужно задумываться если не о метриках как таковых, то о базовых шагах по решению проблем. Рецепт прост как тот факт, что солнце каждый день всходит и заходит (исключая полярные дни и ночи J). И по счастливой случайности он совпадает с основными условиями внедрения метрик. А именно, для наведения порядка нужны 3 вещи:
        Процессы. Они вообще-то должны быть, формализованные в удобном для использования виде. Повторяемые, независимо от того, кто делает.Взаимосвязанные друг с другом, например, на выходе кодирования должен быть чистый работающий код, который расположен в оговоренном месте, снабженный релизной запиской, и обо всем этом должны узнать тестировщики. Соответственно, у тестировщиков должно быть понимание как этот код запустить, по отношению к какой версии требований тестировать и т.п. Видите, сразу идет связка таких инженерных практик и специальностей как бизнес анализ, кодирование, ревью кода, юнит тесты, тестирование, создание тестовой документации, и т.п.
        Инструментарий. Тут все просто, это поддерживающие вашу работу таск-тайм-баг трекеры и прочий автоматизирующий инструментарий. При правильной настройке полей и workflow данные собираются и отображаются без особых усилий.
        Люди. Должны быть достаточно профессиональны, чтобы в правильном порядке и виде использовать инженерные и управленческие практики, подточить их под нужды проекта. А также выбрать и настроить инструментарий, или хотя бы грамотно использовать существующий. При определенной инициативе можно переходить к метрикам, т.е. к следующему уровню.
    Осторожная заинтересованность, или вот ведь как еще можно делать.Тут, и в следующих уровнях работать со слушателями одно удовольствие, т.к. мы настраиваемся на одну волну, и в процессе тренинга приходим к решению конкретных задач слушателей. Пусть и не сразу речь заходит о метриках, но вырисовываются причины проблем. Чаще всего ими бывают или ненастроенные процессы, или инструментарий, или просто не хватает подготовки у людей в области процессов, измерений и улучшений.
    Одобрение и продуктивное обсуждение. Вот тут уже хорошо чувствуется профессиональная зрелость слушателей. Или же явно видно, что есть какие-то проблемы, для решения которых недостаточно просто капать на руководство, заказчика или кого-то еще. А требуются именно цифры и факты, на основании которых могут приниматься качественные управленческие решения. Т.е. тренинг является именно тем катализатором, который побуждает к внедрению измерений и, как следствие количественному управлению. Так, в одном из случаев, элементарный сбор статистики о причинах возникновения дефектов (defect origin), побудил к совершенствованию работы именно проблемного подразделения (наконец-то), и отставил претензии к подразделению-пользователю этих проблем.
    Полная поддержка и обмен опытом по внедрению измерений. В этом случае слушатели или уже внедрили и пользуются метриками или тут же на тренинге обсуждаем, как именно улучшить уже работающую систему измерений. В этом случае идет продуктивный обмен опытом использования метрик. Люди убеждаются на опыте коллег и материала, что идут в правильном направлении. И мне тоже практически всегда есть чему поучиться у слушателей такого уровня.

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

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

4 вопроса себе, прежде чем перейти на мат

Когда нам говорят неприятные вещи, это неприятно :) В том смысле, что хочется сразу перейти на личности и мат, и вообще объяснить собеседнику почему он не прав и куда ему идти. Вот только не всегда это возможно. Особенно на работе. Можно, конечно, сменить работу. Или взять биту и встретить коллегу в тёмном переулке. Или принять "позу" перед начальством - или я или он. В общем простых и понятных вариантов можно придумать много :) Но есть ещё один, не совсем плоский, но зато позволяющий ситуацию с критикой прояснить и вывести на созидательный уровень. Об этом в статье Александра Орлова "Как слушать противную критику: 4 полезных вопроса на каждый день"

Выдержка для себя на память. 4 вопроса себе :


Что происходит? 
Здесь вы пытаетесь услышать факты. Они могут быть для вас неожиданными. И тут вы можете сказать: «Спасибо, что рассказали. Для меня это новость, буду разбираться.»
Я помню, как в самом начале проекта Happy PM, я писал письма своим подписчикам в жестко-гербалайфном стиле. Мне казалось, что это очень весело, потому что мне тогда очень надоел сухой корпоративный текст, в котором я отработал 8 лет. Пока мне не написал один подписчик со словами «Александр, это ужасно…»
Я очень благодарен этому человеку за то, что он раскрыл мне глаза на это. Благодаря этому я изменил стиль писем.
Поймите меня правильно, я не говорю, что нужно слушать всех и делать всегда так, как они говорят. Как делать – это ваше решение. Но слушать всех имхо очень полезно, чтобы принять это решение.


В чем это выражается? 
Иногда люди говорят неконкретно: «Ваши тестировщики ведут себя безответственно!» Что это значит? Они бросают жен и детей? Или тесты забывают прогнать?
Именно здесь я пытаюсь понять, о чем конкретно мы говорим. Чтобы потом перейти к следующему вопросу:


Чем это плохо? 
То, что тестировщики забыли прогнать тесты – само по себе, не хорошо и не плохо. Это некий факт.
Почему это стало настолько неприятно моему собеседнику, что теперь он пытается меня душить? Он не выполнил свои обязательства перед заказчиком или начальством? У него возникло чувство, что он не контролирует ситуацию? Почему этот факт давит ему на мозоль, и на какую именно мозоль он давит?
Все это мне нужно узнать, что в итоге договорить то того:


Что должно быть в идеале? 
И здесь вы точно также можете задать еще один вопрос: «А чего хотелось бы?» или: «А как правильно?»
Несколько лет назад ко мне в почту постучался читатель моего сайта с жалобой на дизайн сайта Happy-PM.com. Там был стандартный вордпрессовский дизайн – такой синенько-беленький. Он мне очень нравился, я был очень горд собой, что смог установить настоящий вордпресс. После предыдущего гербалайфного варианта это был качественный скачок.
И тут мне пишут: «Александр, вас так интересно читать, но что ж у вас дизайн-то такой уродский?» Я аж вскипел от негодования, а потом ответил честно: «А я просто не знаю, как менять дизайн. Буду очень благодарен, если расскажете или покажете.» В ответ я получил: «А давайте я вам сам прикручу новый дизайн». Так мы познакомились со Славой Панкратовым. :) И, честно сказать, наверное, та моя коммуникация была самой удачной за всю мою карьеру. Если, конечно, не считать знакомства с женой. :) 

Сервера-снежинки

Мартин Фаулер. Пост о "серверах-снежинках".
О том, как сложно иметь много разных конфигураций на рабочих серверах, об их сопровождении и вообще, что с этим делать. Совершенно наш случай.
Узнал о целом пласте ПО для управления конфигурациями - SCM (Server Configuration Managemrnt). Интересно, ребята из системного отдела об этом слышали ?

"Пульс рынка" от Ивана Селиховкина

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

КОНСАЛТИНГ И ИТ-МЕНЕДЖМЕНТ – «ПУЛЬС РЫНКА» В РОССИИ И ВНЕ ЕЕ – МАЙ 2012

Открытые библиотеки для тестирования Enterprise приложений.

Этот пост сделан "по мотивам" интересной презентации "Как тестировать промышленные java-приложения" (Alex Soto Bueno). Суть её в том, как на стеке JS+Java+DB выстроить систему тестирования.
Почему для меня это близко ? Потому что именно с таким набором технологий мы и работаем. Это, конечно не всё, что мы используем, но бОльшую часть потребностей закрывает. Что-то из перечисленного мы уже пробовали, что-то используем сейчас, а о чём-то я услышал в первый раз.

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

1.Модульные (юнитные) тесты

На уровне Client-Side, который построен на JavaScript :

 - JSTestDriver (фрэймворк для модульного тестирования JS)
 - Sinon.js : моки для JS

На уровне ServerSide, который построен на Java :

  - как база, JUnit или NGUnit
  - Hamcrest (т.н. matcher, позволяющий писать выражения тестов в более читаемой манере : assertThat(x, is(3)); часть его включена в JUnit с версии 4.4)
  - Mockito (моки, достаточно понятные, ну и вообще мохито с тёмным ромом вполне приличный напиток :))

На уровне БД

  - DBUnit (динамичное создание/удаление/изменение структур в БД и тестовых наборов данных)
  - использование различных in-memoty databases

2. Интеграционные тесты

  - Arquillian (платформа от JBoss для интеграционных и функциональных тестов)

3. Приёмочные тесты

  - UserSory в форме :  «Как <роль>, мне необходимо <поведение>, чтобы получить <ценность бизнеса>»
  - UserSory - конкретные примеры («Как администратор компании, мне необходимо иметь возможность устанавливать программы на удалённые рабочие столы по сети, чтобы не тратить время на перемещение по офису и не отвлекать сотрудников».)
  - Thucydides (средство для автоматизации приёмочных тестов и связки их с тестами модульными)

Как с помощью JIRA можно сделать...

Интересная статья, как с помощью JIRA можно сделать :

- интеграцию с HelpDesk-ами (возможность приема обращений по email, принятие заявок через веб, немного SLA)
- автоматизировать бюрократию (согласование закупок оборудования, отслеживание бюджета проекта, работу с документами и т.п.)
- почтовую рассылку
- делёж ресурсов (кто опять забрал, вашу мать, тестовый iPad)
- голосования
- тест-менеджмент
 - управление тостером :)

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

Источник : http://habrahabr.ru/post/144122/

Техника переговоров от Владимира Железняка

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

Техника "Уход от ответа: зачем и как?"

Иногда бывают ситуации, когда мне задают “неправильный” вопрос. Теоретически,
таких вопросов быть не должно, ведь каждый вопрос важен. И ответить тоже стоит
на каждый. Впрочем, теоретически, DDoS-атак тоже быть не должно.
Давайте кратко рассмотрим, в каких случаях может понадобится уход от ответа?
* Вас троллят. Любой ответ тут же будет раскритикован
* Мало времени, а ответ ожидается большой и с нюансами
* К аргументированному ответу на вопрос нужно хорошо подготовиться

Note: Дополнительный бонус от знания этой техники - умение замечкать ее
применение у других людей. В т.ч. и неосознанное применение. Бывает очень
полезно для выявления проблемных мест заранее.
Есть хорошая стратегия для ухода от ответа, предложил ее Тимур Гагин в
основном для переговоров и для публичных выступлений, но она неплохо себя
показывает и в других ситуациях. Версия тут далеко не классическая, так как по
своему обычаю мы совместили две техники для лучшего КПД.
Итак....

Четыре этапа ухода от ответа

1. Поблагодарить за вопрос: хороший вопрос; интересный вопрос; этот вопрос
просто ставит меня в тупик; люблю провокационные вопросы; ценное замечание…
2. Технично съехать: К сожалению этот вопрос не входит в рассматриваемую тему.
3. Дать обещание заняться этим вопросом, если вопрос не решился: С
удовольствием займемся рассмотрением данного вопроса в следующий раз…
4. Поблагодарить за вопрос: Спасибо за вопрос!

Больше всего вызывает сложности обычно пункт 2. Так как он должен быть весомым
и не конфлитогенным (не порождающим конфликт).

А то вдруг прозвучит:

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

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

Отмазки

Нужны, когда мы не можем/не хотим/не желаем отвечать на вопрос или же нам
нужно время, чтобы подготовить ответ. Поэтому мы можем…
* Попросить дальнейших пояснений. Не доконца понял вопрос... Уточни плз,
почему/ что ты имел в виду .... Дает время подумать и использовать другую
отмазку.
* Переадресовать аудитории. Кто-то же рядом естьКто бы мог на это ответить?
* Переадресовать коллеге или эксперту.Этот вопрос стоит задать архитекторам
* Отправить назад. А как ты считаешь, как тут правильнее поступить?
* Сознаться в некомпетентности. Я бы ответил, но это не в моей
компетентности…. Абсолютно точного и правдивого ответа я дать не могу, а вам
вряд ли нужны домыслы и неточности… Я сомневаюсь, что смогу ответить на это
точно… Это не страшно, так как 3 и 4 пункт схемы закрывают подобную
“искренность”.
* Сказать: Об этом мы поговорим позже В этом случае 3 пункт не нужен, а вот 4
нужен.
* Дать ответ на другой, более простой вопрос. Простой не по форме, а по
содержанию. В: Что произошло с билдом? О: Он упал. Давай подумаем о введении
автотестов. Это вместо ответа на вопрос “Что именно поломалось в билде”
* Подвести того, кто спрашивал, к самостоятельному ответу. Давай подумаем
вместе... Дальше идет цепочка сократических вопросов, на какой то момент она
либо находит ответ, либо ее стот оборвать и по причине “глубины
проблемы/недостатка времени...” попросить связаться потом.
* Что-то проговорить невнятное. Да разные задачи у нас есть, о многом надо
думать, это одна из наших целей... В общем, ни о чем, но с элементами
утилизации.
* Отказаться из-за недостатка времени. Давай не сейчас Классика!!!!!
* Отказаться из-за частности вопроса, который, возможно, не интересует всех
присутствующих. Я сомневаюсь, что Джону интересны наши технические подробности.
Давай потом. Классика +1!!!!!
* Отказаться из-за коммерческой тайны. Эта тема очень близка к NDA. Тут
подумать надо.
* Перевести на иронию, смех. Шутка это здорово, но пошутить так чтобы не
сказать конфликтоген, это признак хорошего чутья на людей, и признак хорошо
подготовленого переговорщика. Тут действует правило "не уверен - не шути".
* Пропустить пункт 2 и перейти к пукту 3, без объяснений причин. Смешно, но
тоже работает. Иногда. Хотя это крайний метод.

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

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

Вывод

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

Владимир Железняк

Запоминалка. jetty embedded

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

import org.mortbay.jetty.*;
import org.mortbay.jetty.nio.SelectChannelConnector;
import org.mortbay.jetty.webapp.WebAppContext;

public class Launcher {
  public static void main(String[] args) throws Exception {
    Server server = new Server();

    Connector connector = new SelectChannelConnector();
    connector.setPort(8080);
    server.addConnector(connector);

    WebAppContext root = new WebAppContext("root/src/main/webapp", "/");
    server.setHandler(root);

    server.start();

    server.join(); 

  }
}

А тут примеры из документации : http://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty 

Отличный перевод Дж.Спольски про командное управление

Спасибо Михаилу Пайсону за "адаптированный"  :) перевод статьи Дж.Спольски о командном управлении.
Как всегда несколько особо понравившихся цитат и ссылка на источник.  
Источник- перевод : Joel Spolsky - The Management Team

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

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

Команда менеджеров не принимает решения. Основная её функция – поддержка. Думаю, стоит назвать их администраторами, а не руководителями. (Возможно, это заставит их поменьше надувать щёки).

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

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

В общем рекомендую к прочтению целиком.

Книги по JavaScript

Попалась на глаза хорошая (и не очень большая :)) подборка книг по JavaScript и клиентскому программированию. http://zendframework.ru/forum/index.php?PHPSESSID=53182c34fc58119f57fbc8b96ec368db&topic=2917.msg19443#msg19443

Верните в садики продукты В НАТУРЕ ! Матом.

Особо нежных и желающих найти взвешенное решение прошу дальше не читать.

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

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

"По словам Елены Королевой (председатель комиссии по питанию экспертно-консультативного совета при департаменте образования Мос­квы), конкурсные документы департамент разместил в открытом доступе тогда, когда всерьез проанализировать их до торгов не успевали уже ни поставщики, ни общественники, ни эксперты. К тому же документация эта изначально содержала невыполнимые условия. Например, требование поставлять только охлажденное мясо для детского питания — притом что его привозят в Москву из других регионов, а потом развозят в десятки детских садов. Естественно, компании берут замороженное мясо по 160 рублей за килограмм, а деньги получают за охлажденное, специально предназначенное для детского питания, — по 380 рублей за килограмм.

Заместитель генерального директора по правовым вопросам компании «Коникс-школьник» (поставщика этих самых продуктов в детские учереждения) Владимир Мельников это отрицает. Проблема, на его взгляд, в поварах, которые «из хорошего продукта могут сделать несъедобное блюдо»."

Вот тут чётко, ясно и с подробностями :

Фото и заметки
Статья в журнале "Эксперт"

Отличная статья про реальный Agile в Лондоне

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

Вот собственно сама статья : Ненормальный Agile в финансах

Прежде, чем убеждать аудиторию, убедись сам (советы от Гандапаса)

Очередная порция простых (на первый взгляд) и полезных советах о подготовке к публичным выступлениям от признанного гуру, в области выступлений, Радислава Гандапаса.



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

1. Настрой себя на позитивный лад. Это в твоих руках.
2. Получи максимум информации о людях, перед которыми будешь выступать, «влезь в их шкуру», пойми, что их действительно волнует. Обязательно именно на этом этапе узнай, где будет проходить выступление и когда. Кто будет выступать до и после тебя.
3. Поставь четкую цель. Каких действий от людей ты намерен добиться.
4. Определи основные аргументы, которые могут их убедить. Выбери адекватный язык общения, стиль слайдов и костюма, примеры.
5. Построй план выступления. Особое внимание — вступлению и заключению.
6. Репетируй не менее трех раз. Последний раз в обстановке, максимально моделирующей реальное выступление.
7. Определи время перед выступлением, которое ты мог бы посвятить отдыху, отвлечься, чтобы в выступлении все было не только четко, но и с тем драйвом, с каким ты всегда хотел выступить.

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


Полный текст : Власть убеждения

Заметки по прочитанной книге "Дао toyota"

Книгу однозначно рекомендую к прочтению. Возможно кто-то пропустит часть глав, но в целом очень интересно. Подробнее здесь : Джефри Лайкер. Дао Тойота