О серъёзных цифрах.Очень весело.

Макс Дорофеев, человек чрезвычайно известный своими докладами о серьёзных вещах (в области управления ПО) с несерьёзными картинками "от руки"  картинками от руки, жжёт "об ошибках, совершаемых при принятии управленческих решений". Да-да, именно жжёт. Умеет человек рассказывать. Просто супер !!! http://www.slideshare.net/Cartmendum/shewhart-6sigma-and-snowflakemen

Коротко о психологии групп...

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

Читать целиком (Из блога Людмилы Петрановской, известного практикующего психолога)

Снова про лидерство : 11 армейских принципов

Лидерство в армии - вопрос жизни и смерти. Совершенно в прямом смысле. Если ты плохой командир, то есть, твои бойцы не считают тебя крутым перцем командиром не только по званию, то кто пойдёт за тобой в смертельный бой ? Наверное поэтому в любой армии вопросам лидерской подготовки командного состава уделяется много времени и сил. Американские военные про это даже пишут и делают доклады для гражданских  :)


Некий командир американского кадетского корпуса, Alex Sniffen, рассказал об 11 армейских принципах лидерства :


Знайте себя и планируйте своё развитие
Будьте технически подкованы
Берите ответственность на себя
Принимайте решения вовремя
Будьте примером
Знайте своих людей и заботьтесь о них
Доносите информацию до своих людей
Развивайте в своих людях чувство ответственности
Убеждайтесь в ясности поставленной задачи 
Занимайтесь построением  команды
Направляйте команду на решение тех дел, на которые она лучше всего способна


Источник (англ.): http://www.pisd.edu/news/documents/2010_MLK_Principles_of_Leadership.pdf

Думаю, эти принципы вполне применимы к любой, не только военной, области деятельности.

Про обучение : Цикл Колба

Если вкратце, то «Цикл Колба» заключается в следующем. Для того, чтобы взрослому человеку обучиться какому-либо сложному навыку максимально эффективно, то он должен пройти по четырем стадиям:

1. Непосредственный опыт (concrete experience). Человек должен иметь некоторый опыт в том, чему хочет научиться или просто улучшить свои способности. Кроме того, человек должен знать, к каким результатам он обычно приходит, используя свой имеющийся на этом этапе опыт.
2. Наблюдение и рефлексия (observation and reflection). Человек обдумывает и анализирует то, что уже есть у него в опыте.
3. Формирование абстрактных концепций и моделей (forming abstract concepts). На этом этапе необходимо обобщить информацию, полученную опытным путем, до какой-то модели, которая бы описывала этот опыт. Таким образом происходит выстраивание взаимосвязей внутри опыта, добавление новой информации, генерация идей относительно того, как это работает.
4. Активное экспериментирование (testing in new situations). И только на этом этапе необходимо поэкспериментировать и проверить пригодность созданной концепции для того, чтобы работать по ней дальше. Соответственно, после этого этапа, человек получает новый «непосредственный опыт» и круг замыкается.

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

Цитирование отсюда :  http://www.grafsky.ru/blog/kolb-cycle.htm

Ничего не откладывать !

Из блога Радислава Гандапаса (человека, которого я чрезвычайно уважаю, но с частью взглядов которого совершенно не согласен :)). Однако в конкретном случае могу лишь горячо поддержать. Перенёс к себе из-за чертовски замечательной формулировки.

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

Отсюда следует совет, который я не устану повторять: «Никогда ничего не откладывать!» Этот рецепт перевернет жизнь любого человека, кто будет пользоваться им каждый день. Пришла мысль, пришла идея — тут же бери и делай! Тут же! Два процента участников обращаются к записям, сделанным в процессе моих тренингов! Всего два процента! Остальные довольствуются полученными впечатлениями.

Для огромного количества людей слово «потом» становится девизом. Никогда ничего не откладывать! Решил развестись — подойди к супругу или супруге и начни разговор. Как только ты произнесешь первые слова, — а они могут быть любыми, — станет легче. Нет ничего труднее, чем откладывать важный разговор на потом. Подумал позвонить маме — бери телефон и звони! А мы начинаем искать отговорки: устал, некогда, поздно и тому подобное. Захотел написать любимому человеку СМС или сделать для него что-то необычное — делай! Никогда ничего не откладывать! Это совет для читателей журнала Chief Time, это совет для людей, которые посещают мои тренинги, это совет для всех, кто хочет что-то изменить в своей жизни.

 

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

Попалась интересная статья о введении нового человека в процесс командной разработки. У Фаулера в блоге есть ссылка на неё, так что для меня это достаточно авторитетно. Ну и просто изложенные мысли показались достаточно разумными. Главная мысль в том, что agile-методы ориентированы в первую очередь на уже устоявшуюся команду, а не на время её формирования (включения нового человека). Предлагается обратить внимание на процессы, позволяющие упростить себе жизнь во время когда приходит новый человек и/или когда команда не стабильна. Как и всё в agile - просто, естественно и требует постоянства :). Вот эти методы (перевод вольный и скорее так, как отложилось у меня в голове) :  

• Preparation Email(Подготовительное письмо) - пошлите письмо счастья новому разработчику о том, что за проект, какие технологии используются, организационные моменты конкретного проекта 
  
• Big Vision Business Problem (Общее видение проекта) - объяснените новому члену команды общего взгляда на проект; что, зачем, специфика, в глобальном смысле 
  
• Visible Architecture(видимость архитектуры) - нарисуйте архитектуру проекта, чтобы все видели что с чем связано и как устроено 
• Transparent Project Debt(фокус на улучшениях) - обращайте внимание на то, что можно улучшить, на то какие вещи запланированы, на приоритетах задач  
• Tiny Tasks(крошечные задачи) - разбивайте большие таски на мелкие, чтобы (особенно) новому человеку было понятно что надо сделать без дополнительных объяснений; не забывайте объяснять, как эти маленькие задачи являются частями большого целого 
• Tech Huddles(технические тусовки) - устраивайте еженедельные тематические встречи разработчиков, чтобы они могли делиться знаниями и новыми найденными фичами
• Student to Teacher(от ученика к учителю) - дайте возможность новому члену комманды побыть в роли учителя, когда именно он будет объяснять другим членам команды как сделать что-то только ему известным способом  
• Respect Individual Needs (уважайте особенности) - усройте процесс ввода человека в комманду так, чтобы ему было удобно учиться  
• Letting Go(право на ошибку) - (!) создайте человеку среду, где он сможет учиться на своих ошибках - это очень эффективно; только эта среда должна быть ограничена так, чтобы разработчик ошибаясь не ломал кайф рабочий процесс всей команде

Заметка Мартина Фаулера о OpportunisticRefactoring

Заметка Мартина Фаулера о OpportunisticRefactoring (в моём смысловом переводе - "рефакторинг при любой возможности"). На английском, но понятно. Собственно, за простоту изложения я этого корифея очень люблю :) Основные мысли : - в любое время, когда кто-то видит "плохо пахнущий" код, он должен его улучшить, при этом не надо делать всё и сразу - лучше немного, но постоянно. - перед исправлением ошибок и внесением новых фич, сначала делайте маленький рефакторинг. - если вы в процессе изменения, и не можете сделать рефакторинг сразу, то сделайте его как только сможете после - не откладывайте далеко - максимум один-два дня.

Краткая рецензия на книгу "Алекс Паттакос.Пленники собственных мыслей"

Добавил в свои книги ещё одну небольшую заметку о прочитанном : "Алекс Паттакос.Пленники собственных мыслей (Смысл жизни и работы по Франклу)"

Аннотации в mybatis 3

Периодически приходится сталкиваться с mybatis. Перешли в проектах на версию 3.x и в некоторых местах на аннотации. А документация по ним ... мягко говоря... не очень. И поэтому детали приходится часто выискивать в старых проектах, тестовых примерах и т.п. (гугл в помощь понятно, но всё-равно муторно) Я был уже готов сам написать этакий краткий перечень основных примеров использования, да вот встретился мне отличный обзор с примерами. Спасибо автору. Ссылку в копилку : http://www.objectpartners.com/2011/04/05/using-mybatis-annotations-with-spring-3-0-and-maven/

Про заказчиков и скидки (из рассылки Сергея Бережного)

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

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

Заказчик просит скидку в счет «будущих покупок». Говорит, если вы сейчас мне сделаете скидку, то я отдам вам проект в 2 раза больше. ... «Хорошо, я дам тебе скидку, но на второй проект. Все деньги, которые ты мог бы сэкономить на этом проекте я вычту из следующего». Работает безотказно. Если Заказчик пришел с серьезными намерениями, то он согласится, если же нет, то вероятность того, что в твою команду отдадут второй проект – маленькая...

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

Узелки. Ссылки на посты про управление

Узелки на память. Разные аспекты управленческой жизни. От Ивана Селиховкина : 11 главных менеджерских несчастий Артефакты для менеджера Карьера в проектном управлении – о пользе саморазвития От Сергея Бережного Реакция на жалобы Клиентов

Добавил заметку о бизнес-книге "Доставляя счастье" Тони Шей

Закончил читать книгу Тони Шей "Доставляя счастье". Про очередную историю успеха. Интересно и не занудно :) В свою "библиотеку" добавил заметки : Тони Шей. Доставляя счастье.

Про оценку людей (серия постов от Александра Орлова)

С белой завистью большим уважением отношусь к деятельности Александра Орлова (Happy-PM.com). Наверное не в последнюю очередь через его посты открываю и расширяю для себя (и для своего окружения) новые грани менеджерского дела. Посему на этой страничке привожу список ссылок на его заметки про оценку людей (взято из рассылки) :

• Всевидящее око менеджера
• 360 фидбэки: что и как
• Ни одно доброе дело не должно оставаться безнаказанным
• Кого повышать, кого журить
• Ценности компании как инструмент менеджера
• Использование 360 фидбэков в жизни

Дети и управление

В силу того, что скоро я стану папой, часть книг, которые я читаю, относится к области педагогики. И, недавно, совершенно неожиданно, я открыл для себя тот факт, что управление людьми в коллективе и педагогика - фактически одна и та же наука - с мотивацией, конфликтологией и прочим. Этим открытием спешу поделиться с окружающими, и очень рекомендую книгу Ю.Б.Гипенрейтер. Общаться с ребёнком. Как ?. Только вместо слова "ребёнок" подставляйте "коллега", "подчинённый", "начальник" - кому что нравится.

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

Ничего не напоминает ?
При этом всё с кейсами примерами, доступным языком и очень ясными рекомендациями.
Коллеги, наслаждайтесь :)

Книги, которые меня окружают

Книги в моей жизни играют большую роль. Я люблю учиться, а хорошая книга - это всегда учитель. Лишь одно меня печалит в чтении - хороших книг много, а время, увы, ограничено (и не надо мне рассказывать про управление временем - 24 часа в сутки ещё никто не отменял). Обычно, встречая книгу, которую мне хотелось бы прочесть, я записываю её на листочек и... (ну, думаю рассказывать как эти листочки теряются никому не надо). Что ж, подумалось мне, соберу-ка я их в одном месте. И сделал простую страничку в инете : Библиотека Она пока очень простая и книг там самая малость. Но, я надеюсь её поддерживать и даже, иногда :), писать свои заметки о прочитанном. Даже сделал ссылку на эту страницу с книгами в этом блоге :)

Игорь Ашманов. Кризис роста в ИТ

С большим уважением отношусь к взглядам и рабочим подходам Игоря Ашманова. Его публикации Жизнь внутри пузыря , Правила Ашманова , словари ненормативной лексики и т.п. обошли всю сеть и актуальны как всегда. На днях обнаружил его недавний доклад посвящённый росту ИТ-компаний. Очень толково и разумно. Говорю спасибо за то, что человек делится подобными мыслями с окружающими.
Ссылка на доклад : http://vimeo.com/26868924

Рефлексия по поводу эффекта Даннинга-Крюгера

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

Список видов тестирования

Хорошая, на мой взгляд, подборка определений различных видов тестирования :
http://quality-lab.ru/publication/2010/01/18/publication_10.html

Обратная связь и камень за пазухой

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

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

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

Друзья, давайте относиться друг к другу с уважением.

Проблема или расходы ?

Если проблему можно решить за деньги, то это расходы, а не проблема.
                                                                                                                                  Цитата из твиттера

4 вопроса для движения вперёд

Что нужно инженеру менеджеру  человеку, чтобы расти ? личностно, карьерно, ещё как-нибудь... :)  Интересные вопросы, которые можно задать себе и другим, чтобы определиться (по материалам конференции стратоконф-1 А.Орлова и В.Панкратова) :

1. Чего я хочу ? 
(цели, которые было бы отлично выписать на бумажку)

2.Почему для меня это ценно и важно ? 
(бабосы, престиж, потому что Пупкинс уже там)

3.Что я готов для этого сделать завтра сегодня ?
(от чего готов отказаться... например, как насчёт поработать в НГ...)

4.Как я пойму, что этого достиг ?
(типа измеримые критерии)

О принципах конструктива

У Александра Орлова в блоге была заметка о конструктивном общении в Tвиттере. Для себя осмыслил так :

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

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

- Наличие данных и фактов. Обращаем внимание на реальные факты, имеющие место, а не абстрактные "там всё плохо".

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

И ещё в эту же тему интересная статья "Преодоление конфликтов: конструктивное общение"

S.M.A.R.T. "Вижу цель, не вижу препятствий"

S.M.A.R.T. - это принцип, на соответствие которому полезно проверять поставленные цели. Согласно ему, ЦЕЛЬ должна соответствовать набору критериев :

    * S (specific) - конкретность
    * M (measurable) - измеримость
    * A (achievable) - достижимость
    * R (result-oriented ) - ориентированность на результат
    * T (timely) - ограниченность во времени

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

Надо заметить, что в разных источниках существует разная расшифровка аббревиатуры, хотя все они в целом говорят об одном и том же : http://agileguru.ru/AgileWiki/SMART

8 способов гарантированно завалить проект

Скопировал от Ивана Селиховкина. Очень, на мой взгляд жизненно :)

• Не общаться с заказчиком по мере выполнения работ
• Не фиксировать требования вначале проекта
• Планировать проект в одиночку (вдвоем, втроем)
• Не отслеживать своевременность выполнения работ
• Работать с рисками в одиночку или вообще их не учитывать
• Пренебрегать конфликтами или жестко их пресекать
• Проводить сдачу работ «методом большого взрыва»
• Делать работу «по уму», забив на контракт без согласования с заказчиком

Убить троля...

О троллинге и борьбе с ним написано и наговорено достаточно много. Однако в момент "попадания" часто всё это не работает, и приходится махать кулаками уж после драки.
Учитывая, что главная задача для троля - это получение внимания, то отличным способом борьбы, например на совещании, будет дать это внимание тролю на 2-3 минуты, а потом отобрать и больше уже не давать, мотивируя тем, что он уже говорил, а теперь очередь других.

Немного о командной работе

Команду (по Берну) определяет   
- внешняя граница (круг)
- внутренний круг власти

Нарушения границ кругов (ввод нового человека в команду, перераспределение власти,...) приводит к конфликтам.

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

Как создать команду:
1.Собрать
2.Назвать (внешняя граница)
3.Дать цель и задачи
4.Запустить (пережитой, завершённый опыт)
5.Отойти (и не мешать)

По мотивам выступления Славы Панкратова

Техники позитивных обсуждений

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

(мысли из/от подкастов Александра Орлова)
- "Да,и..." : соглашаешься с говорившим и добавляешь свои ПОЗИТИВНЫЕ моменты
- "Perfect Game" :
   1. Оценка по 10-ти бальной шкале
   2. Разница между 10 и моей оценкой - есть количество идей, которые я должен озвучить, как улучшить предложение выступающего
      (например, если я говорю, что моя оценка 7, то должен предложить ещё 3 улучшения)

Про книги о том КАК мыслить : Г.Альтшуллер. "Найти идею" (Введение в ТРИЗ — теорию решения изобретательских задач)

Доступ к файлам журналов Log4j

Log4j позволяет записывать журналы логов в файлы. Настройка этих файлов (имена, каталоги, перезапись и т.п.) обычно происходит в конфигурационных log4j.properies или log4j.xml. Иногда требуется получить доступ к файлам журналов внутри самого приложения - например, чтобы по запросу взять их и передать куда-то вовне (допустим, с сервера на клиент). Приведённый пример показывает как получить доступ к таким журналам Log4j :

@Test

public void testLogFilesAccess() throws Exception {

    Logger logger = Logger.getRootLogger();

    //  все appender-ы

    Enumeration allAppEnumeration = logger.getAllAppenders();

    while (allAppEnumeration.hasMoreElements()) {

        Appender app = (Appender)allAppEnumeration.nextElement();

        // отбираем только те, что с файлами  

        if (app instanceof FileAppender) {

          System.out.println("Appended File="+((FileAppender)app).getFile());

        }

    }

}

Восемь правил хорошего управления от Google

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

1. Будьте хорошим наставником.
- Ваши оценки действий подчиненных должны быть конкретными и конструктивными.
- Соблюдайте баланс между критикой и похвалой.
- Регулярно встречайтесь с сотрудниками с глазу на глаз, предлагая решения проблем с учетом сильных сторон конкретного работника.
2. Доверяйте своей команде и не докучайте мелочной опекой.
– Давайте своим подчиненным свободу, но будьте доступны, чтобы к вам могли обратиться за советом.
- Доверяете подчиненным решение серьезных задач, чтобы они «росли над собой».
3. Проявляйте интерес к успехам сотрудников и их личному благополучию.
– Интересуйтесь, чем живут люди, в том числе и вне работы.
- Помогайте новичкам освоиться.
4. Не будьте «добряком». Будьте требовательным в достижении результата.
– Сосредоточьтесь на том, к каким коллективным результатам стремятся сотрудники и как они могут их достичь.
- Помогайте расставлять приоритеты и используйте власть для устранения препятствий.
5. Умейте слушать.
– Общение – двусторонний процесс: вы оба слушаете и делитесь информацией.
- Следите, чтобы общие собрания были направлены на достижение целей команды.
- Поощряйте открытое обсуждение и прислушивайтесь к тому, что волнует ваших сотрудников.
6. Способствуйте карьерному росту сотрудников.

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

Источник (перевод), где описывается как Google пришёл к таким результатам : http://www.rb.ru/career/knowledge/growth/2011/03/15/155843.html

О "нервной" обстановке в проекте ...

Байка от Вячеслава Панкратова :


Приходим. Ноуты, галстуки и прочая лабуда, которая, как мне тогда казалось, обязана присутствовать в облике консультанта. То что мне 25-26 лет и доверия как процессный консультант я не особо внушаю, видимо, должно было компенсироваться внушительным внешним обликом
Нас представили всему департаменту, разослали письма с нашими фотками, чтобы народ не шугался нашего появления и решили мы нарисовать стрелочками на большой бумаге как ходят задачи по департаменту, кто кому рапортует, какие системы где используются, что на входе, что на выходе, где какие цепочки явно затянуты ну и чего еще найдем.
Прихожу в группу тестирования, представляюсь, народ даже улыбается, кивают, мол «Слышали, читали». Подсаживаюсь к товарищу внушительного вида, знакомимся: его зовут Леша. Прошу рассказать и показать, кто ему ставит задачу, что он с ней делает, где чего лежит из документов. Леша без проблем начинает рассказывать и показывать.
В департаменте установлена система трекинга задач и ошибок + есть версионный контроль, в котором лежат и документы по тестированию и требования.
— Вот как раз упала задача от моего менеджера по тестированию Татьяны. Сейчас все и покажу.
Леша кликает на ссылку в почте, открывается страничка в системе учета задач, хорошее описание задачи, ссылка на последнюю версию тест-кейсов и на репозиторий с требованиями. Я отмечаю себе наличие самих систем, их провязку в систему постановки задач, тихо радуюсь. Леша тем временем говорит задаче «in progress», ставит в соотв. поле примерное время выполнения, открывает по ссылке в теле задачи документ с требованиями. При этом система запрашивает у него причину: отдельная формочка, в которую Леша вводит код задачи, а его имя уже подставлено автоматом. Открывает требования, читает, что-то отмечает в блокнотике. Открывает документ с тест-кейсами, аналогично отмечает в рамках какой задачи от к нему обращается. Что-то исправляет в одном из тест-кейсов. Я начинаю размякать: контроль на лицо, елки! В этот момент в аську кто-то стучится. Леша открывает аську и проговаривает:
— А вот как раз Татьяна, по поводу этой задачи.
Далее диалог из аськи:
— Леша, ты уже взялся за задачку #1234567?
— Конечно, разбираюсь, вроде есть один тест, который надо поправить и потом пойду по тестам.
— Давай ты ее пока отложи, а возьми лучше задачку #9876543.
— Не вопрос, Тань, сейчас сделаю.
Далее как в анекдоте про бабашку и кошелку. Леша сохраняет документ с требованиями, сохраняет документ с тест-кейсами заполняя поле «Изменения», чтобы хранилась история изменений. Заходит в задачу, ставит ей статус «Остановлено», пишет комментарий почему остановил задачу. Заходит в новую задачу, открывает ее, вникает, ставит «in progress», ставит в соотв. поле примерное время выполнения, открывает по ссылке в теле задачи документ с требованиями, открывает документ с тест-кейсами, начинает вникать в новый кусок функционала.
Звучит «о-оу», от аськи. Снова Татьяна:
— Леша, ты уже начал делать #9876543?
— Да, Таня.
— Я тут подумала, что она короткая и простая, я ее перекину Сереже, а ты вернись плз на задачу #1234567.
— Не вопрос, Таня, конечно.

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

Шоу продолжается. Леша сохраняет документ с требованиями к задаче #9876543, сохраняет документ с тест-кейсами к задаче #9876543. Заходит в задачу #9876543, ставит ей статус «Остановлено», пишет комментарий, почему остановил задачу. Заходит обратно в задачу #1234567, открывает ее, ставит «in progress», ставит в соотв. поле примерное время, которое осталось на ее выполнение, открывает по ссылке в теле задачи документ с требованиями, открывает документ с тест-кейсами, начинает заново вникать в тот же кусок функционала, с которым он работал ранее.
Я понимаю, что это может быть просто случайность, прошу Лешу уделить мне 5 минут, говорю спасибо за демонстрацию работы с системами и уточняю насколько часто его перебрасывают с задачи на задачу. Выясняется, что Татьяна не единственный менеджер, который может его куда-то перекинуть, что иногда прибегают аналитики и тащат его на «срочный митинг с заказчиком», чтобы потом он мог быстрее вникнуть в новый функционал. Бывает, приходят лично или звонят менеджеры проектов, которые хоть и не являются его непосредственными шефами, но могут влиять на приоритеты задач в его списке.
Леша — один из ведущих специалистов по тестированию. Человек, который реально знает практически всю логику нескольких систем, которые разрабатывает и использует его компания. И он чертовски спокойный человек.
Возвращаемся к столу Леши, я прошу его аккуратно выяснить у Татьяны, почему, мол, мечемся. У меня в голове есть твердое убеждение, что менеджер просто так ведь ничего не делает. А если возникнут вопросы, то можно валить на меня, я пойду говорить дальше. Леша впервые за день улыбается и дословно вбивает мой вопрос в аську.
— Тань, слуш, а чего мы сегодня мечемся-то? Ну, с задачами этими?
Я аж записывать перестал, честно говоря. Леша человек спокойный и с интересным чувством юмора
Ответ менеджера появляется под барабанную дробь:
— Потому что у нас обстановка в проекте нервная!
Вопрос «Кто создает такую нервную обстановку в проекте?» повисает в воздухе.

Заметки о РИТ 2011

25-26 апреля мне довелось посетить конференцию интернет-технологий РИТ2011. Полезность-интересность оказалась процентов 30-40, что на мой взгляд очень неплохо.
Зная за собой любовь к записям, которые потом "ловким движением руки" превращаются в мусор, на сём мероприятиии записывал только отдельные слова :), чтобы потом
чтобы в дальнейшем, в спокойной обстановке их погуглить и изучить внимательнее.
собственно, эти записи здесь и приведены.

С.Панкратов.Управление через коучинг
Коучинг - содействие развитию; создание и поддержка долгосрочных отношений.
Эрикссоновский гипноз.
Базовые принципы

1. У людей всё хорошо (решать вопрос, а не человека)
2. Люди всё знают (всё, что им надо)
3. Люди делают всё наилучшим образом (наилучшим способом из доступных/известных им на данный момент)
4. Всегда есть положительное намерение
5. Изменения будут всегда

Вопросы к оппоненту
А как ты сам думаешь ?
А что ты уже пробовал с этим сделать б

Тренд на HTML5.
HTML5Doctor.com
web-standards.ru
html5.js (для отображения в IE6)

Рисуем интерфейсы
- ТЗ, как набор картинок-прототипов для GUI-интерфейса
- инструменты (balsamiq)

GWT 2.x
Тяжёлая, но работающая технология для построения enterprise-приложений в облаке ()

"Эльба - электронный бухгалтер"(http://www.e-kontur.ru)
Новая облачная технология, как альтернатива 1C

KPI от яндекса
Главные вопросы - почему и зачем.
- самоанализ
- оценка ресурсов (есть/надо)
- бонусы
Критерии (27 штук с примерами)
- сложность разработки
- участие в развитии системы, сверх решения основных задач (модули, компоненты)
- работа с контролем версии (просмотр результата после коммита)
- коммандная работа (обучение, ...)
- дисциплина
Как
- стоимость критерия в баллах ("стоимость" того или иного критерия)
- простота учёта
- автоматизация учёта (2 мин/день на учёт, 15 мин/квартал на расчёт)
Заметки
- KPI и их критерии должны быть озвучены, т.к. фактически меняются правила игры
- !? прикинуть оценку по KPI при приёме на работу, т.к. они не зависят от личного отношения

Нагрузка
- мониторинг приложения, а не железа
- не "тупая" оптимизция - анализ сценариев работы пользователей и приложений
- memcashed (noSQL хранилище для кэширования. ! посмотреть !)
- RRDTool

Тестирование JS
- phantomJS и вообще...

Google Closure
- ! посмотреть !

К юбилею полёта Юрия Гагарина. 100 правил NASA

Сто правил руководителей проектов NASA
http://www.iteam.ru/publications/project/section_40/article_1585/

Первый опыт использования utPLSQL

Ссылка на первые шаги в документации : http://utplsql.oracledeveloper.nl/doc/fourstep.html

1.Устанавливаем utPLSQL.
Устанавливаем как сказано в разделе "Step 1. Install utPLSQL". Я ставил в отдельного пользователя UTP. Тут важно не забыть прописать отдельно право "GRANT EXECUTE ON DBMS_PIPE TO UTP" (мне сначала прав не хватило, и пакет UTPPIPE не скомпилировался) 

2. Пишем тестовый пакет к собственному пакету.
Тест как в примере "Step 3. Build a test package." Имя тестового пакета =  префикс "UT_" + имя рабочего пакета. Например, рабочий PNX_ENQUERY, тестовый UT_PNX_ENQUERY. префикс можно поменять в настройках. В тестах можно(и нужно) использовать набор утверждений из пакета utAssert, например utAssert.eq(...)

3. Запуск теста
"utPLSQL.test('PNX_ENQUERY',recompile_in => FALSE);". Заметьте, что PNX_ENQUERY - имя рабочего пакета.
Засада :
В документации написано так, что я полтора дня угробил пока понял как это запускать после внесения изменений. Итак, если править тестовый пакет, и без выхода из сессии(сеанса) пробовать запустить тесты, то будет всё-время ошибка на уровне пакетов utPLSQL. Поэтому, логично будет править в обычном режиме - и рабочий и тестовый пакеты, а вот для запуска я написал простенький скрипт, который запускает отдельную сессию SQLPlus и выполняет тесты в ней, отписывая результаты в локальный файл.
Вот так, например :
bat-ник:
sqlplus scott/tiger@(DESCRIPTION...) @splus_exec.sql
splus_exec.sql:
set serveroutput on
spool c:\Temp\aaa.txt
exec utPLSQL.test('PNX_ENQUERY',recompile_in => FALSE);
spool off
exit

4. Анализ результатов.
В файле результатов, полученном на выходе, будет большими буквами SUCCESS или FAILURE, и детали, с указанием мест ошибок (и хороших результатов тоже)
Например вот так                                                                              
>    SSSS   U     U   CCC     CCC   EEEEEEE   SSSS     SSSS                    
>   S    S  U     U  C   C   C   C  E        S    S   S    S                   
>  S        U     U C     C C     C E       S        S                         
>   S       U     U C       C       E        S        S                        
>    SSSS   U     U C       C       EEEE      SSSS     SSSS                    
>        S  U     U C       C       E             S        S                   
>         S U     U C     C C     C E              S        S                  
>   S    S   U   U   C   C   C   C  E        S    S   S    S                   
>    SSSS     UUU     CCC     CCC   EEEEEEE   SSSS     SSSS                    
SUCCESS: "PNX_ENQUERY"                                                         
> Individual Test Case Results:                                                
>                                                                              
SUCCESS - PNX_ENQUERY.UT_GETUNITS: EQ "Всё ок..." Expected "1" and got "1"

Выбор инструмента тестирования для PL/SQL

Конечный выбор : utPLSQL



Выбирал из utPLSQL(free), PLUTO(free), Quest Code Tester for Oracle (595$/1лицензия), Oracle SQL Developer(free)

Пойду от плохого к хорошему :

Oracle SQL Developer : обзор почему этот инструмент ещё не дозрел - http://www.fuzzy.cz/en/articles/unit-testing-plsql-code-in-sql-developer-problems/

PLUTO : очень мало документации, корявое использование объектов

Quest Code Tester for Oracle : отличная штука - её делает тот же разработчик, что ранее написал бесплатный utPLSQL, но теперь это ещё и GUI-среда, и автоматическое создание тестов и т.п. Немного сложно сначала от обилия возможностей, но в дальнейшем, думаю, должно себя оправдать. Есть триал, на котором я тренировался. Один недостаток - платная :)

utPLSQL - старая (2008) и рабочая лошадка. часть действий приходится делать вручную. но работает. Будем использовать.

О книге Д.Лазарева "Презентация.Лучше один раз увидеть"

В целом понравилось. Сжато. Просто. По делу. Запоминать советы бессмысленно - нужна практика. Думаю, надо иметь под рукой при подготовке презентации. http://www.labirint.ru/books/190955/

Слайдомент

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

Подготовка презентации
Создайте мыслительную карту (mindmap). Сначала создайте центральный образ - изображение или символ, которые передают суть презентации. Из центрального образа проведите радиальные линии-идеи. Выберите по ОДНОМУ ключевому слову для каждой вестви.

• пишите печатными буквами
• по-разному выделяйте наиболее важные слова
• придерживайтесь тактики №одно слово - одна линия"
• используйте символы-рисунки

Бумага и карандаш
Используйте стикеры и доски. Один листок = одна идея. Сначала подготовьте всё без компьютера, и только потом переносите.

Изображения
http://lazarev.biz/2008/09/19/99free/


7 основных принципов дизайна слайдов

1. Принцип соотношения сигнал/шум. Сокращение лишних элементов. Избегайте трёхмерных графиков, убирайте логотипы с каждого кадра (оставьте на первом и последнем)
2. Принцип читабельности. Выбор шрифтов и цветов. Шрифт - 30 (возраст самого старого зрителя делённый на 2 :)). Arial, Verdana, Tahoma. Используте светлый текст на тёмном фоне.
3. Принцип пустого пространства.Выделение главного элемента. Не бойтесь пустоты. Пустое пространство - это не "белое пятно", оно несёт усиление отдельных элементов.
4. Принцип выравнивания.Наличие визуальной взаимосвязи всех элементов на слайде.
5. Принцип контрастности.Демонстрация иерархии между элементами слайда. Используйте ОГРАНИЧЕННОЕ количество способов выделения (1-2) на всех слайдах презентации. Выделение жирным предпочтительно, т.к. вносит минимум "шума". Не увлекайтесь интенсивностью и количеством цветов - будет рябить в глазах.
6. Принцип повторения.Сохранение единого стиля во всех слайдах.
7. Принцип близости.Расположение взаимосвязанных элементов на слайде. Группируйте связанные элементы вместе, физически перемещая их друг к другу.

Определение качественных слайдов - слайды без презентатора бесполезны.

Донесение презентации
Два практических совета :
-сказать что будет (в чём состоит проблема, в чём важность проблемы, каково решение)
-повторить несколько раз, в различных вариантах

Стиль короткой презентации "печа куча" (20x20)

www.pecha-kucha.org:
- только 20 слайдов
- каждый слад меняется каждые 20 сеунд
 

Всё время презентации -6мин.40 сек

Удержание внимания
Не ждите неусыпного внимания - это нереально.

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

Практика

1. Готовьтесь заранее (1-2 недели)
2. Сделайте несколько "прогонов" вслух
3. Не учите наизусть
4. Используйте мыслительные карты и сценарии
5. Засекайте продолжительность выступления
6. Составьте список возможных "трудных" вопросов, особенно негативных
7. Используйте видеокамеру

И снова про менеджеров. Репост, потому что понравилось.

Про "чёрную книгу менеджеров" Вячеслава Панкратова :
http://www.kraynov.com/2011/03/25/managers-black-book/

Напоминалка: Преобразовать Java Exception стек в строку

Всё-время забываю где то уже реализовано. Вот решил записать"на память" :

Exception exc = ...
String exceptionAsString = org.apache.commons.lang.exception.ExceptionUtils.getStackTrace(exc);

http://commons.apache.org/lang/api-release/org/apache/commons/lang/exception/ExceptionUtils.html#getStackTrace%28java.lang.Throwable%29

Простой мониторинг времён с помощью JAMon и spring-aop.

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

Мне не хотелось выдумывать велосипед, поэтому я воспользовался простой библиотекой JAMon, где решение этой задачи выглядит тривиально :

Без spring-а (это когда не всё создаётся через IoC) :

Monitor mon = MonitorFactory.start("myMethod");
try {
    myMethod();
} finally {
    mon.stop();
}
System.out.println(MonitorFactory.getReport());

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

Теперь как это выглядит с использованием spring-aop :

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

 <bean id="jamonPerformanceMonitorInterceptor" class="org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor" >
   <property name="trackAllInvocations" value="true"></property>
   <property name="useDynamicLogger" value="true"></property>
</bean>

<bean id="autoProxyCreator" class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
    <property name="interceptorNames">
        <list>
           <idref bean="jamonPerformanceMonitorInterceptor"/>
        </list>
    </property>
    <property name="beanNames">
        <list>
           <value>idBean1</value>
           <value>idBean2</value>
        </list>
    </property> 
</bean>

Всё. После этого все вызовы наших зарегистрированных бинов idBean1 и idBean2 будут фиксироваться JAMon, и как и в первом случае доступ к этим данным можно получить через MonitorFactory.getReport() (или другие полезные методы этой фабрики)


P.S.: Я использую для ряда объектов прокси CGLIB. При попытке подключить aop-аннотации, я получал ошибки, а в xml-конфигурации выше, всё отрабтало отлично. Впрочем, полагаю, что я просто что-то не докрутил с аннотациями.

P.P.S.: springframework 3.0.5(http://www.springsource.org/), JAMon 2.7(http://jamonapi.sourceforge.net/)

О работе программиста и сне

Деятельность программиста сравнивается со сном. С юмором и вполне похоже.

Это вам со стороны кажется что вы просто подошли и спросили который час.
А давайте я вас подойду и спрошу в три часа ночи который час?
Чего страшного-то? Ну и что такого что вы только что заснули?
Я просто спрошу, вы ответите и спите дальше. Чего такого-то?

Весь текст : http://alexthunder.livejournal.com/290612.html

 

Java. Как получить информацию о параметре универсального типа в runtime

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

Итак...

Задача 1

Дано :
Объект класса с методом void setMyList(List<String> param){}

Требуется :
во время выполнения, определить тип, содержащийся в списке List параметра param

Решение :

public static Class getClassName(Method method)
  Class clazz;
  Type[] types = method.getGenericParameterTypes();
  for (Type type : types) {
                // генерик
                if (type instanceof ParameterizedType) {
                    ParameterizedType pt = (ParameterizedType) type;
                    Class = (Class) pt.getActualTypeArguments()[0];
                }
                // обычный тип (не генерик)
                if (type instanceof Class) {
                    clazz = (Class) type;
                }
            }
  return clazz;
}

Как получить Method класса, я здесь останавливаться не буду, это можно почитать в статьях про reflection API.


Усложним ситуацию, и предположим, что мы инстанцировали объект, с помощью springframework, и по каким-то причинам
этот объект инстанцирован не явно, а через оболочку-прокси, с использованием CGLIB. Примером может служить создание объектов в контексте безопасности spring-security. Вобщем суть в том, что вместо объекта нашего собственного класса, мы работаем с объектом класса-прокси, и в описании метода (того самого Method) у него уже нет информации о типе генерика. Но, вода дырочку найдёт...

Задача 2

Дано :
Объект класса, инстанцированного через spring, с включённым контекстом безопасности, с методом void setMyList(List<String> param){}

Требуется :
во время выполнения, определить тип, содержащийся в списке List параметра param

Решение :
public static Class getClassNameCGILIB(Method method) {
  Class clazz;
  if (!AopUtils.isCglibProxyClass(method.getDeclaringClass())) {
     Class baseClass = method.getDeclaringClass().getSuperclass(); // исходный класс, для которого сделана заглушка
     try {
          Method baseMethod = baseClass.getMethod(method.getName(), method.getParameterTypes());
         clazz = getClassName(baseMethod);
     } catch (NoSuchMethodException e) {
         e.printStackTrace();  //TODO сделать обработку ошибок
     }   
  }
}

P.S.: Описанные методы точно работают на Sun JDK 1.6.

Разбор управленческих кейсов на happy-pm

Спасибо большое Александру Орлову и его сайту happy-pm за постоянные обновления и переработку материалов о странной :) судьбе it-менеджеров. Вот и ещё один сборный документ с разборами поведенческих кейсов http://happy-pm.com/hpm_cases.pdf

7 наиболее распространенных ошибок при установке размера Java Heap

Не могу ничего с собой поделать - люблю простые и понятные статьи :

7 наиболее распространенных ошибок при установке размера Java Heap 

Люди, как основа разработки ПО

Наткнулся на старую (1999) статью известнейшего (в области практических методологий разработки) Алистера Коуберна (его сайт http://alistair.cockburn.us/)"Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения". Читается легко и интересно. Казалось бы прописные истины, да ещё и написанные давно, но воз, что-то мне кажется, и ныне там...


Несколько цитат оттуда :

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

Я прихожу к заключению, что большинство проектов вполне можно вести, руководствуясь (верными) не очень точными описаниями: не очень точную документацию по проекту легче читать, приводить в порядок и обсуждать. Архитектуру системы, изображенную с невысокой степенью точности, легче запомнить; в таблицах с не очень точно описанными требованиями легче расставлять приоритеты и легче оценивать масштабы сделанной работы на ранних стадиях проекта. Выполненная не очень точно проектная документация лучше передает "идею" проекта, после чего читатель может начать "ориентироваться в ситуации

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

На русском лежит здесь : http://www.maxkir.com/sd/people_as_nonlinearRUS.htm (не знаю кто перевёл, но большое ему(ей) спасибо)

Давать задания и убеждать их сделать

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

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

Исходник :) : http://kika.livejournal.com/114965.html

Инструменты для работы с людьми

Известные люди в среде управления IT-проектами, Александр Орлов и Вячеслав Панкратов опубликовали бесплатную подборку видео-уроков на тему "Инструменты для работы с людьми" . Уроки короткие (несколько минут), ёмкие, интересные и с улыбкой. Всего 9 уроков. Как мне кажется, интересны они будут не только менеджерам, но и всем думающим людям.

Темы уроков :
1. Четыре причины, почему люди чего-то не делают
2. Матрица интереса и компетентности
3. Матрица осознанности и компетентности
4. Ситуационное управление
5. Конструктивность и конфронтация
6. Оценка идей и людей
7. Доверие и прозрачность
8. Результат и заметность
9. Матрица Эйзенхауэра

Зарегистрироваться и скачать можно здесь : http://www.stratoplan.ru/manager-tools.htm

Модель зрелости REST сервисов Леонарда Ричардсона (Richardson Maturity Model)

Уровень 0

Сервисы имеют единственный URI, который использует единственный http-метод (как правило, метод POST).Примерами таких сервисов могут служить большинство веб-сервисов - они используют единственный URI для идентификации точки входа и HTTP POST для передачи SOAP-пакета с данными. Службы XML-RPC и POX(Plain Old XML) используют похожие вызовы, при которых по одному URI передаётся XML, как часть http-запроса.

Уровень 1 (Resources(Ресурсы))

Такие сервисы используют несклько URI, но единственный http-метод. Разница между L1 и L0, заключается в том, что L1 выставляет много логических ресурсов, а сервис уровня L0 объединяет все взаимодействия через единственный (большой и сложный) ресурс. В сервисах уровня L1, имена операций и параметров находятся в самом URI и передаются удалённому сервису, как правило через HTTP GET.

Уровень 2 (HTTP-verbs(http-методы/глаголы))

Сервивсы этого уровня имеют много URI-адресуемых ресурсов и используют несколько http-методов для каждого ресурса. Это, как правило CRUD(Create Read Update Delete)-сервисы, где состояние ресурса представляет бизнес-сущность, которой можно управлять через сеть.

Уровень 3 (Hypermedia Controls)
(Управление гиперсодержанием (? ничего лучшего в голову не пришло при переводе)))

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

Пример запроса (уровень 3):

POST /slots/1234 HTTP/1.1
[various other headers]

<appointmentRequest>
  <patient id = "jsmith"/>
</appointmentRequest>

и ответа (уровень 3):

HTTP/1.1 201 Created
Location: http://royalhope.nhs.uk/slots/1234/appointment
[various headers]

<appointment>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
  <link rel = "/linkrels/appointment/cancel"
        uri = "/slots/1234/appointment"/>
  <link rel = "/linkrels/appointment/addTest"
        uri = "/slots/1234/appointment/tests"/>
  <link rel = "self"
        uri = "/slots/1234/appointment"/>
  <link rel = "/linkrels/appointment/changeTime"
        uri = "/doctors/mjones/slots?date=20100104@status=open"/>
  <link rel = "/linkrels/appointment/updateContactInfo"
        uri = "/patients/jsmith/contactInfo"/>
  <link rel = "/linkrels/help"
        uri = "/help/appointment"/>
</appointment>



Ссылки
http://www.crummy.com/writing/speaking/2008-QCon/act3.html
http://martinfowler.com/articles/richardsonMaturityModel.html

Русская буква «И» при формировании строки из массива байт

Дано:

При получении массива байт извне (например, через jni-буфер) необходимо преобразовать его в строку Java, с русскими буквами.  

В чём сложность:

(отличное описание взято отсюда http://www.skipy.ru/technics/encodings.html):

Символ "И" кодируется в UTF-8 последовательностью из двух байтов: 0xD0,0x98. Соответственно, при чтении в кодировке windows-1251 каждый из этих байтов декодируется по схеме данной кодировке. Так вот, я обнаружил следующее – код 0x98 не определен в наборе символов windows-1251 и, соответственно, в схеме этой кодировки. Вот схема кодировки cp1251, взятая с сайта Microsoft, а вот ее описание (взято отсюда). Как вы можете видеть, код 0x98 описан как UNDEFINED.

Проблема и решение:

Допустим откуда-то извне к нам попал массив байт, с неизвестной кодировкой. И с этим массивом надо проделать некоторые преобразования, то возможен хитрый ньюанс. Если на входе кодировка UTF-8, а в массиве есть русская буква И, то при попытке в java-коде создать строку с кодировкой windows-1251, мы получим «?»(он же - неопределённый байт) в созданной строке. При дальнейшем преобразовании в байты, этот символ просто потеряется (зачем нужны такие преобразования, я тут рассматривать не буду, но иногда такие вещи случаются :-)).

Немного кода :

// получаем правильную последовательность байт (то, что пришло нам извне)

byte[] bytes = «И-диотизм».getBytes("UTF-8");

// Создаём строку с кодировкой по умолчанию

// Напечатает «Каракули=Р?-диотизм», где видно, что один символ «?»

System.out.println("Каракули=" + new String(bytes, "Cp1251"));

System.out.println("Каракули=" + new String(bytes));  // аналогично

// Дальнейшее преобразование и потеря информации

String s1251_x = new String(bytes);

 String xx = new String(s1251_x.getBytes(), "UTF-8"); // даже в изначально правильной кодировке

// Выведет «xx=??-диотизм,len=10»

 System.out.println("xx=" + xx + ",len=" + xx.getBytes().length);

Решение :

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

// Если сразу сделать так

String sUtf8 = new String(bytes, "UTF-8");

// то и дальнейшие преобразования не потеряют информацию на входе

// Напечатает «sUtf8=И-диотизм,len=17»

System.out.println("sUtf8=" + sUtf8 + ",len=" + bytes.length);

 String s1251_2 = new String(sUtf8.getBytes(), "Cp1251");

// Напечатает «s1251_2=И-диотизм»

 System.out.println("s1251_2=" + s1251_2);

P.S.: Я эти заметки пишу для себя, и для конкретной ситуации, которая случилась в нашем коде. О глобальном подходе к кодированию/декодированию очень понятно и хорошо написано тут : http://www.skipy.ru/technics/encodings.html