А пофиг!

Как полюбить что-то?

2012-01-30T19:15:00.000+02:00

Чтобы что-то полюбить надо делать это. Как полюбить не попробовав? Не попробовав не узнаешь. Попробовав, есть шанс что не так понял. Только эксперименты под присмотром мастера помогут сделать как надо. А на мастерство надо время. Со временем привыкнешь. Потом станешь экспертом. Будешь видеть то, что никто не замечает. Полюбишь.

Итак, пробуй долго и тебе вскоре полюбится. Любишь не вещь, а время проведенное с ней.

Вот пример, есть 5 кухонь: украинская, японская, русская, итальянская, французская. Как минимум надо попробовать каждую из них, чтобы определиться, что нравится больше. А если некому тебе приготовить? Тогда будешь готовить сам. Взял рецепт - приготовил, попробовал - не понравилось. Нельзя же сказать, что именно кухня не понравилась? Не понравилась твоя реализация этой кухни. Если даже взять повара в ресторане - не факт, что он делает это так как надо. Вывод? Пробовать чаще и в разных местах, а еще лучше - на родине этой кухни.

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

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

Зачем мне блог?

2012-01-30T18:22:00.003+02:00

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

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

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

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

В блоге можно получить бек по теме среди тех, кто интересуется ею и имеет свое отличное от твоего мнение. Супер! Причем не надо всем подряд говорить о теме - это неэффективно работает с не целевой аудиторией. Теперь достаточно написать в блог и тут же попросить фидбек.

Что тут можно писать? Да абсолютно все, чем хочется поделиться с миром. Ты в своем блоге автор и к тебе приходят гости. Если кому-то не нравится он уходит и больше не приходит. Если нравится остается. Гугл делает твой блог видимым для ребят извне. А если ты научишься писать красиво и полезно - сработает другой принцип - сарафанное радио, и линк пойдет по рукам. Но это случится не скоро и тогда, когда польза будет для масс. Естественный отбор.

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

По твоему блогу тебя узнают. Бывало такое, что на конференции мне сказали - читал твой блог - полезно. Очень приятно, потому как понимаешь - человек тебя не знал, но узнал и сказал, что ты ему помог. А сколько писем личных приходят на почту - "спасибо, очень помогли". То же касается комментов в посте (просто кто-то предпочитает 1-to-1). Когда понимаешь, что блог с твоими бреднями (это я так свои мысли) помогает кому-то. Вау! Круто! Буду еще.

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

Блогом я часто пользуюсь чтобы вспомнить то, что знал когда-то но долго не использовал. Ну не собирал я кубик рубика 2 года, и что? Забыл все. Хотя когда-то рекорд был меньше 2х минут. А так оп и вспомнил как это делается...

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

Когда у тебя уже есть наработки в блоге - их можно повторно использовать. Как?

Например тебя пригласили сделать доклад. Думаешь, а что бы выбрать? А иди в свой блог и подбери несколько постов на тему.

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

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

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

Блог отнимает много времени? Поначалу да, но когда придет привычка в задавать вопрос "как мне ускориться", то наверняка ты найдешь такие инструменты как фрирайтинг, слепой 10-пальцевый метод набора текста или такой совет как "во время работы над чем-то оставляй следы". Например:

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

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

- или вообще можно записать видео с рабочего стола и выложить его (как я например сделал для демонстрации того, как делается TDD)

- написал что-то в mind map - выложи его, пусть другие посмотрят - мало ли пригодится (пример)

- сделал code review? Расскажи его не устно а в доке, который так же потом можно выложить с блог (пример)

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

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

- можно просто выложить фотки с похода в блог (пример).

- можно постить информацию не в твиттер и на стену фейсбука, вконтактов и прочих соцсетей, а открытьновый пост и постить все самое интересное туда. Будет рубрика - свалка, но свалка того, что ты отфильтровал (пример 1й такой подборки, пример такой 53й подборки).

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

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

Кстати, чтобы работать со статистикой надо поставить на свой блог счетчик посещаемости. Там можно увидеть кто (IP), сколько времени, по каким страницам ходил; а так как это статистика, то можно увидеть много других срезов: сколько хостов в день, средняя время на сайте, количество просмотренных страниц, интенсивность по времени, какая аудитория...

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

Бежать за поездом или подождать следующий?

2012-01-30T14:39:00.000+02:00

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

Когда все получается само собой, тогда и результат будет суперский (по личным наблюдениям). А кто не любит суперские результаты?

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

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

Если же тебя чаще драйвит сетапить систему - значит роль стоит сменить с исполнителя на организатора исполнителей.

Как-то так.

Напиши свое будущее

2012-01-28T01:00:00.001+02:00

Оказывается писать свое будущее очень просто.

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

Мне понравилась идея фильма Секрет, мне нравилось читать книгу Джона Кехо "подсознание может все". Но чудеса стали происходить тогда, когда я стал писать свое будущее.

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

В школе учили писать сочинения на тему "как я провел лето" - полезный навык, только писать надо "как я провел лето в будущем". Фантазировать от души и писать в прошедшем времени.

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

Просто не могу не поделиться этим инструментом.

Что делать, если вдруг появилось свободное время?

2012-01-24T13:24:00.001+02:00

Вдруг отменили 4х-часовой ивент который я планировал? Это че получается - у меня вдруг на ровном месте появилось 4 часа свободного, ничем не занятого, времени. Не я ли говорил недавно "... хочу, но на это нет времени сейчас..."?

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

Ап ту ми...

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

Никогда не знаешь к кому обратишься за помощью

2012-01-24T12:44:00.001+02:00

Не брезговать новыми знакомствами. Никогда! Не оценивать людей по одежке. Никогда!

Вообще не оценивать ничего! Любая оценка работает в этом пространстве-время и не работает через миг после.

Никогда не знаешь, куда занесет тебя жизнь.

Быть может она заставить пройти собеседование у парня, которого ты собеседовал (Вика привет!). Вопрос в том, как ты его собеседовал.

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

Никогда не знаешь где и когда. Но будешь приятно удивлен - это факт! Вот такая вот она, иррациональная жизнь.

Пока вижу такие этапы отношения:
|) Как я могу использовать этого человека?
||) Чем этот человек может быть полезен мне? Что я ему могу дать взамен?
|||) Как мы можем вместе достичь взаимовыгодных результатов?
||||) Как я могу быть полезен этому человеку, чтобы и мне было по пути?
|||||) Как этому человеку могу быть полезен?

Эволюция нас такими сделала

2012-01-24T12:34:00.000+02:00

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

Видимо эволюция наше мышление так устроила.

Что из этого извлек? Как минимум на каждый негативный фидбек давать два позитивных, таких же по силе.

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

Музыка - это точная наука

2012-01-23T01:24:00.001+02:00

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

По очереди. Школу можно нагуглить по словам "вечерняя муз школа Киев". Далее идем в школу спрашиваем где можно найти преподавателя по фортепиано, находим его и задаем ему вопрос "хочу учиться, что для этого надо сделать?". Приблизительно потом он скажет все то, что сказали мне (или что-то другое). Диалог приблизительно таков:

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

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

Учебник я нашел на rutracker.org - благо их там сотни. Выкачал все что было, а потом стал выбирать что больше по восприятию подходит. Мне понравилось "Абелян Л. Забавное сольфеджио" и А.Николаев, В.Натансон, Л.Рощина "Школа игры на фортепиано". В первой в ненавязчивой форме рассказывается про нотную грамоту а со второй книги на странице 183 я взял распальцовку гамм.

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

Для начала есть белые клавиши и есть черные. Пианино все видели.

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

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

Первая до в гамме - называется тоникой (последняя кстати тоже). Там еще много всяких названий, но я их всех не запомнил - видимо не время еще....

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

Вот попробуй.

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

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

Единственный способ это сделать - играть гамму так:

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

Картинка для фа казалось бы должна быть такой (аналогия уже должна прослеживаться)

Но не то (позже разберемся почему). А вот для фа диез.

Идем дальше - соль

Еще дальше - ля

Теперь си

Отакое. Теперь вопрос, почему так?

Ответ прост, если знать мантру "тон, тон, полутон, три тона, полутон". Что бы это значило?

Немного теории. Одна октава состоит из 12 клавиш (черные и белые). Каждая клавиша звучит на какой-то основной частоте.

Фишка в том, что расстояние между двумя соседними клавишами (черная-белая, белая-черная или белая-белая {когда нет между ними черной}) - всегда константа. Вот эта разница частот и называется полутоном. Два полутона вместе дают 1 тон. То есть если мы возьмем любые две клавиши стоящие рядом - они отличаются на пол тона (1-2, 2-3, 3-4, 4-5, 5-6, 6-7, 7-8, 8-9, 9-10, 10-11 и 11-12).

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

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

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

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

Ответа в сети не нашел - оставим это на потом....

Что касается практики, то есть еще такое понятие, как какими пальцами какие клавиши нажимать. Каждый палец правой и левой руки нумеруется по своему.

Мизинец - 5, большой палец - 1.

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

Но об этом позже...

Большое спасибо Автору этой статьи - очень хорошо и доходчиво описано.

Место, где работа и хобби - синонимы

2012-01-22T23:51:00.000+02:00

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

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

Дело в выборе и осознанности. Знать бы, где есть это место - можно было бы попробовать выбрать его. Это моя еще одна внутренняя моделька-ценность. Хочешь верь, а хочешь нет, но в моем мире - $ = t☺². Деньги это результат того, что ты занимаешься своим хобби. И чем больше у тебя комфорта, чем тебе веселее и жизнерадостнее на работе, тем больших денег ты получишь за свое это веселье.

Доказательство простое. Если ты занимаешься тем, что тебе нравится - ты естественным образом будешь развиваться в этом. Никакой мотивации и стимуляции - все происходит естественно. Со временем ты станешь узким специалистом в этой области. Чем более узкий специалист ты есть, тем больше стоит твоя экспертиза.

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

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

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

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

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

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

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

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

Что-то не нравится? Самое время прокачать мозг!

2012-01-22T20:01:00.000+02:00

Иногда нужно залезть руками в какашку, чтобы найти что-то ценное.

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

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

Заметил такую штуку. Если что-то тебе не нравится - значит действуют Кулоновские силы отталкивания, но стоит подойти максимально близко к предмету ненависти, как начнут действовать другие силы - ядерные. Оооочень сильные. Там уже не видишь кривой интерфейс - там понимаешь идею всего сайта и используешь его по назначению. А интерфейс, поменяют. Или не поменяют - но тебе уже пофиг, ты привык к тому, что в мире есть корявые интерфейсы и тебе в равной степени удобно с ними всеми работать...

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

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

Хобби-блог

2012-01-22T19:24:00.000+02:00

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

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

У тебя есть такой блог? Его "надо реанимировать"? Чтобы реанимировать свой хобби-блог достаточно написать туда всего лишь один новый пост. Всего на два абзаца и хобби-блог жив!

Никогда не знаешь где и когда, но твой хобби-блог тебе еще поможет.

Школа, какой она могла быть

2012-01-21T21:20:00.001+02:00

Какими были бы школы, если бы оценки ставились учениками учителю и его теме (а не наоборот, как обычно):
2 - тема ученику оказалась не интересной
3 - проявлял интерес к теме, прилагал некоторые усилия
4 - было интересно, тему усвоил самостоятельно
5 - было так интересно, что помог усвоить тему коллеге, заинтересовав его

Тут "2" - было бы поводом для перевода ученика в другую группу/на другой урок/другому преподавателю. Он сам поставил двойку теме, он сам может сделать выбор в пользу более интересного предмета. А учителю бек - не заинтересовал темой.

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

А все остальное как обычно - журналы, подсчет средней оценки ученика, оценка за четверть, за год :)

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

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

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

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

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

Но он мне нужен был к тех темах, в которых я не видел смысла, в которых не был заинтересован. Он мне очень был нужен, чтобы показать, что писать сочинения - это не нудотень, а еще один способ самовыражения. Кто знал, что мне нравится писать сочинения? Узнал я это только после того, как завел свой личный блог. Быть может и книг по литературе читал бы больше, если бы мне помог учитель. А он ставил "двойку за поведение" и выгонял из класса... А история?.. Интересная штука,как оказалось - почему у дискавери получилось сделать то, что не получалось у моих учителей истории - захватить мое внимание на 2 часа?

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

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

А что, если у одного учителя стоит 5ка а у другого по той же теме 2ка? Что (или кто) оценивается в этом случае? А если учителю приложить усилий и заинтересовать? А если заинтересуют одноклассники?

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

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

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

Может спросить у него, что тебе, сына, интереснее?
А может школу поменять?
Источник проблемы может быть и глубже...

Тренинг по отработке навыков Test Driven Development

2012-01-19T20:23:00.002+02:00

Бла бла бла.... :) Сколько уже этого Test Driven Development вокруг. Дофига. И вот еще один. Сейчас этим подходом никого не удивить.... Ладно, не буду долго говорить о TDD - и так понятно. Скажу лишь только, что поменялось в тренинге со времен проведения прошлого.

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

У нас с Сережей есть наш внутренний acceptance критерий. Поделюсь им. Test pass когда на второй день достаточно будет всего лишь фасилитации - группа все сделает сама. Конечно, это только критерий - мы в равной степени уделим внимание как первому, так и второму дню. Практика мастер-класса Ирины Синчаловой показала, что именно на второй день случается все самое-самое вкусное. Мы подготовим для вас вкусняшки, не сомневайтесь.

Что еще поменялось? За время, с момента проведения последнего тренинга по TDD мы с Сережей провели ряд внутрикорпоративных собраний техтолков, получили обратную связь от ребят с которыми трудимся. Мы работали в паре с разными людьми и помогали им прокачаться в этом, на первый взгляд, простом инструменте: TDD на Common Lisp, TDD на Flex... Все неудобные вопросы, которые мы получали от Вас - все они проработаны, а ответами на них мы поделимся на нашем следующем тренинге 2.0.

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

Рассказывал я про TDD специалистом в области проведения тренингов. Судя по фидбекам ребят, за 10 минут у меня это получилось.

Хочу так же отметить, что в это время параллельно с нами будут проходить и другие, не менее полезные мастер-классы. А днем позже, мы с удовольствием посетим с Сережей Agile Base Camp конференцию, на которой особое внимание уделим eXtreme Program stage.

Java for fun: Assert That по принципу FEST

2012-01-10T00:53:00.005+02:00

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

Теперь перейдем к тому, как можно расширить эту библиотечку на своем DOM. Если интересно научиться создавать подобные assertThat методы, кликни на меня...

Сразу оговорюсь, цель этого поста не законченный фреймворк, который точно работает (я его разрабатывал не через TDD и не могу гарантировать 100% работоспособности). Цель в другом - показать подход. Но если ты найдешь ошибку, поделись fail-тестом и я ее исправлю. Так же в проекте не все может идеально с внутренней структурой. Цель в другом - показать как красиво оно может выглядеть снаружи.

Допустим, есть у нас список мероприятий

package dom;

import java.util.Arrays;
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;

public class EventList implements Iterable<Event> {
    private List<Event> events = new LinkedList<Event>();

    public EventList(Event...events) {
        this.events.addAll(Arrays.asList(events));
    }

    public void add(Event event) {
        this.events.add(event);
    }

    public Iterator<Event> iterator() {
        return events.iterator();
    }
}

Список состоит из конкретных мероприятий

package dom;

import java.util.Iterator;

public class Event {
    private String name;
    private Place place;
    private String date;
    private ParticipantList participants = new ParticipantList();

    public Event(String description, String date, Place place) {
        this.name = description;
        this.place = place;
        this.date = date;
    }

    public String getName() {
        return name;
    }

    public Place getPlace() {
        return place;
    }

    public String getDate() {
        return date;
    }

    public Iterator<Participant> participantsIterator() {
        return participants.iterator();
    }

    public void addParticipatns(Participant... participants) {
        for (Participant participant:participants) {
            this.participants.add(participant);
        }
    }
}

Мероприятие состоит так же их списка участников

package dom;

import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;

public class ParticipantList implements Iterable<Participant> {

    private List<Participant> participants = new LinkedList<Participant>();

    public void add(Participant participant) {
        this.participants.add(participant);
    }

    public Iterator<Participant> iterator() {
        return participants.iterator();
    }
}

А вот и описание участника

package dom;

public class Participant {

    private String name;
    private String email;

    public Participant(String name, String email) {
        this.name = name;
        this.email = email;
    }

    public String getName() {
        return name;
    }

    public String getEmail() {
        return email;
    }
}

Так же мероприятие содержит ссылку на место проведения

package dom;

public class Place {

    private String address;
    private String details;

    public Place(String address, String details) {
        this.address = address;
        this.details = details;
    }

    public String getAddress() {
        return address;
    }

    public String getDetails() {
        return details;
    }
}

Вот пример классического теста

import static assertions.DomAssertions.assertThat;
import static org.junit.Assert.assertTrue;

import dom.Event;
import dom.EventList;
import dom.Participant;
import dom.Place;
import org.junit.Before;
import org.junit.Test;

import java.util.Iterator;

public class TestTest {

    private Participant vasia;
    private Participant petia;
    private Participant masha;
    private Place vasiaHome;
    private Event vasiaBitrthday;
    private Event pairProgramming;
    private Place office;
    private EventList events;

    @Before
    public void setup(){
        petia = new Participant("Петя Васечкин", "petia@gmail.com");
        masha = new Participant("Маша Пупкина", "pupkina@mail.ru");
        vasia = new Participant("Вася Пупкин", "super@mail.ru");

        vasiaHome = new Place("Киев, ул. Лабораторная 12/34е", "На домофоне 123");
        office = new Place("Киев, ул. Охотничья 43/123",
                "На рисепшене охраннику скажешь, что пришел ко мне");

        vasiaBitrthday = new Event("День рождения Васи", "2012-01-10", vasiaHome);
        pairProgramming = new Event("Собрались попилить вместе проектик",
                "2012-01-15", office);

        vasiaBitrthday.addParticipatns(vasia, petia, masha);
        pairProgramming.addParticipatns(petia, vasia);
        events = new EventList(vasiaBitrthday, pairProgramming);
    }

    @Test
    public void classicTest(){
        assertContainsParticipantWithEmail(events, "pupkina@mail.ru");
    }

    private void assertContainsParticipantWithEmail(EventList events, String email) {
        boolean found = false;
        for (Event event : events) {
            Iterator<Participant> participants = event.participantsIterator();
            while (participants.hasNext()) {
                if (participants.next().getEmail().equals(email)) {
                    found = true;
                }
            }
        }

        assertTrue(String.format("email '%s' не найден", email), found);
    }
}

Кто не писал такие пользовательские ассерты? Я писал... :)

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

Чаще, все же, методы очень специфические, а потому не стоит раздувать модель такими методами - они используются только в тестировании. А еще бывает, что модель никак нельзя пофиксить - не мы писали ее.

Какие альтернативы?

Представь, что можно написать такой тест:

@Test
    public void assertThatTest(){
        assertThat(events).hasEvent().withName("День рождения Васи");
        assertThat(events).hasParticipant().withEmail("pupkina@mail.ru");
        assertThat(events).hasPlace().withAddress("Киев, ул. Лабораторная 12/34е");
        
        assertThat(vasiaBitrthday).withName("День рождения Васи");
        assertThat(pairProgramming).withDate("2012-01-15");
        assertThat(pairProgramming).hasParticipant().withEmail("petia@gmail.com");
        assertThat(vasiaBitrthday).hashPlace().withDetails("На домофоне 123");

        assertThat(vasiaHome).withAddress("Киев, ул. Лабораторная 12/34е");

        assertThat(vasia).withEmail("super@mail.ru");
        assertThat(vasia).withName("Вася Пупкин");
    }

Удобно? Мне да...

Как создать такой assert-фреймворк? Идея проста. Для начала стоит написать assertThat(someObject).somecheck(someExpected) и реализовать метод assertThat. Вот пример для моих объектов модели.

package assertions;

import dom.Event;
import dom.EventList;
import dom.Participant;
import dom.Place;

import java.util.Arrays;
import java.util.List;

public class DomAssertions {

    public static EventListAssertion assertThat(EventList events) {
        return new EventListAssertion(events);
    }

    public static EventAssertion assertThat(List<Event> events) {
        return new EventAssertion(events);
    }

    public static EventAssertion assertThat(Event event) {
        return new EventAssertion(Arrays.asList(new Event[]{event}));
    }

    public static ParticipantAssertion assertThat(Participant participant) {
        return new ParticipantAssertion(participant);
    }

    public static PlaceAssertion assertThat(Place place) {
        return new PlaceAssertion(place);
    }
}

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

А вот реализация всех проверяльщиков содржит уже методы проверки.

package assertions;

import collectors.Collector;
import dom.Event;
import dom.Place;
import org.fest.assertions.Assertions;

import java.util.Arrays;
import java.util.List;

public class PlaceAssertion {

    private List<Place> places;

    public PlaceAssertion(List<Event> events) {
         // это так же мой самописный колектор, который ходит по спискам 
         // и собирает подколлекции, онем чуть позже. 
         // Сейчас достаточно знать, что в результате селекнутся все места
         // описанные в списке мероприятий
         places = Collector.fromEvents(events).places().list();
    }

    public PlaceAssertion(Place place) {
        places = Arrays.asList(place);
    }

    public void withDetails(String details) {
        // Я тут воспользовался родным FESTAssertion assertThat 
        // методом для работы с коллекцией объектов. 
        // Зачем изобретать велосипед?
        Assertions.assertThat(places)
                .onProperty("details")
                .contains(details);
    }

    public void withAddress(String address) {
        Assertions.assertThat(places)
                .onProperty("address")
                .contains(address);
    }
}

Аналогично и для другого ассертора :)

package assertions;

import collectors.Collector;
import dom.Event;
import dom.Participant;
import org.fest.assertions.Assertions;

import java.util.Arrays;
import java.util.List;

import static org.junit.Assert.fail;

public class ParticipantAssertion {
    private List<Participant> participants;

    public ParticipantAssertion(List<Event> events) {
        participants = Collector.fromEvents(events).participants().list();
    }

    public ParticipantAssertion(Participant participant) {
        this.participants = Arrays.asList(participant);
    }

    public void withEmail(String email) {
        Assertions.assertThat(participants)
                .onProperty("email")
                .contains(email);
    }

    public void withName(String name) {
        Assertions.assertThat(participants)
                .onProperty("name")
                .contains(name);
    }
}

И третьего...

package assertions;

import dom.Event;
import org.fest.assertions.Assertions;

import java.util.List;

public class EventAssertion {
    private List<Event> events;

    public EventAssertion(List<Event> events) {
        this.events = events;
    }

    public void withName(String name) {
        Assertions.assertThat(events)
                .onProperty("name")
                .contains(name);
    }

    public void withDate(String date) {
        Assertions.assertThat(events)
            .onProperty("date")
            .contains(date);
    }

    // тут можно увидеть странные методы
    // но они нужны для того, чтобы можно было сделать так
    // assertThat(events).hasEvent().hasParticipant().withEmail("pupkina@mail.ru");
    public ParticipantAssertion hasParticipant() {
        return new ParticipantAssertion(events);
    }

    public PlaceAssertion hashPlace() {
        return new PlaceAssertion(events);
    }

}

И еще один

package assertions;

import dom.Event;
import dom.EventList;

import java.util.LinkedList;
import java.util.List;

public class EventListAssertion {
    private List<Event> events;

    public EventListAssertion(EventList events) {
        this.events = asList(events);
    }

    public EventAssertion hasEvent() {
        return new EventAssertion(events);
    }

    // Это чудо для перегонки Iterable в List. Чую, велосипед :)
    private <T> List<T> asList(Iterable<T> iterable) {
        List<T> result = new LinkedList<T>();
        for (T t : iterable) {
            result.add(t);
        }
        return result;
    }

    public ParticipantAssertion hasParticipant() {
        return new ParticipantAssertion(events);
    }

    public PlaceAssertion hasPlace() {
        return new PlaceAssertion(events);
    }
}

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

package collectors;

import dom.Event;

import java.util.List;

public class Collector {

    private List<Event> events;

    public Collector(List<Event> events) {
        this.events = events;
    }

    public static Collector fromEvents(List<Event> events) {
        return new Collector(events);
    }

    public ParticipantCollector participants() {
        return new ParticipantCollector().fromEvents(events);
    }

    public PlaceCollector places() {
        return new PlaceCollector().fromEvents(events);
    }
}

И два сборщика

package collectors;

import dom.Event;
import dom.Place;

import java.util.LinkedList;
import java.util.List;

public class PlaceCollector {
    private List<Place> places = new LinkedList<Place>();

    PlaceCollector fromEvents(List<Event> events) {
        for (Event event : events) {
            fromEvent(event);
        }
        return this;
    }

    PlaceCollector fromEvent(Event event) {
        places.add(event.getPlace());
        return this;
    }

    public List<Place> list() {
        return new LinkedList<Place>(places);
    }
}

package collectors;

import dom.Event;
import dom.Participant;

import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;

public class ParticipantCollector {
    private List<Participant> participants = new LinkedList<Participant>();

    ParticipantCollector fromEvents(List<Event> events) {
        for (Event event : events) {
            Iterator<Participant> participants = event.participantsIterator();
            while (participants.hasNext()) {
                this.participants.add(participants.next());
            }
        }
        return this;
    }

    public List<Participant> list() {
        return new LinkedList<Participant>(participants);
    }
}

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

А вот и исходники (Maven проект, но на всякий либа FEST Assertions внутри).

Приятного аппетита!

---------------------------------------

Хорошая мысля приходит опосля :)

Теперь если немного переделать void методы в ассерторах

...
public class PlaceAssertion {

    ... 

    public void withDetails(String details) {
        Assertions.assertThat(places)
                .onProperty("details")
                .contains(details);
    }

    public void withAddress(String address) {
        Assertions.assertThat(places)
                .onProperty("address")
                .contains(address);
    }
}

на

...
public class PlaceAssertion {

    ... 

    public PlaceAssertion withDetails(String details) {
        Assertions.assertThat(places)
                .onProperty("details")
                .contains(details);
        return this;
    }

    public PlaceAssertion withAddress(String address) {
        Assertions.assertThat(places)
                .onProperty("address")
                .contains(address);
        return this;
    }
}

то можно написать так :)

assertThat(events).hasEvent().hashPlace()
            .withAddress("Киев, ул. Охотничья 43/123")
            .withDetails("На рисепшене охраннику скажешь, что пришел ко мне");

Но это не совсем гуд, потому как по тексту кажется что условия проверки места по адресу и описанию объединенные в AND, а на практике можно написать

assertThat(events).hasEvent().hashPlace()
            .withAddress("Киев, ул. Охотничья 43/123") // это с одного Place
            .withDetails("На домофоне 123"); // a это с другого Place

и такой assert тоже пройдет, хотя строки - кишки разынх Place объектов.

Выход? Есть. Еще немного усложняем :)

package assertions;

import collectors.Collector;
import dom.Event;
import dom.Place;
import org.fest.assertions.Assertions;

import java.nio.channels.Selector;
import java.util.Arrays;
import java.util.List;

public class PlaceAssertion {

    protected List<Place> places;

    public PlaceAssertion(List<Event> events) {
        places = Collector.fromEvents(events).places().list();
    }

    public PlaceAssertion(Place place) {
        places = Arrays.asList(place);
    }

    public PlaceSubAssertion withDetails(String details) {
        // проверяем, что соблюдается первое условие
        new PlaceSubAssertion(places).andDetails(details);

        // выделяем всех найденных по этому условию
        List<Place> subList = Collector.fromPlaces(places).withDetails(details).list();

        // даем возможность првоерить второе условие клиенту
        return new PlaceSubAssertion(subList);
    }

    public PlaceSubAssertion withAddress(String address) {
        new PlaceSubAssertion(places).andAddress(address);

        List<Place> subList = Collector.fromPlaces(places).withAddress(address).list();
        return new PlaceSubAssertion(subList);
    }
}

А остальное в другом классе :)

package assertions;

import dom.Place;
import org.fest.assertions.Assertions;

import java.util.List;

public class PlaceSubAssertion {
    private List<Place> places;

    public PlaceSubAssertion(List<Place> places) {
        this.places = places;
    }

    public void andDetails(String details) {
        Assertions.assertThat(places)
                .onProperty("details")
                .contains(details);
    }

    public void andAddress(String address) {
        Assertions.assertThat(places)
                .onProperty("address")
                .contains(address);
    }
}

Вот как то так :) Еще сложнее, зато можно написать теперь так:

assertThat(events).hasEvent().hashPlace()
            .withAddress("Киев, ул. Охотничья 43/123")
            .andDetails("На рисепшене охраннику скажешь, что пришел ко мне");

И тут уже валидация будет так доктор прописал...

Если интересно посмотреть на исходники второго варианта - они тут.

Цель этого поста не

Надеюсь продолжение следует...

Java for fun: #3 Пишем Web проект на Java в Eclipse для Tomcat. Билдим Ant. Проверяем Hudson. Тестим jUnit + EasyMock + jWebUnit. Коммитим в Svn.

2012-01-09T06:33:00.004+02:00

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

Во второй части мы начали делать login page и почти закончили ее.

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

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

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

Если стоя курсором на имени нажать комбинацию клавиш Alt-Shift-R то Eclipse предложит заменить имя. После нажатия Enter - все места, где встречается упоминание этого класса так же будут обновлены....

Теперь используем CopyPast подход для клонирования теста. Новый класс назовем UserServiceFileTest...

В сердце его будем использовать новую реализацию (которой еще пока нет) некоторого интерфейса (его тоже пока нет)....

Создадим их!...

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

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

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

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

Пишем код игнорируя ошибки а потом причесываем его...

Еще одна правочка от меня...

Теперь нам надо создать файл с описанием пользователей...

Имя должно соответствовать тому, которое мы указали ранее...

Добавляем нового пользователя...

Чик! И все зазеленело...

Я набрался смелости и воспользовался параметризацией тестов (фича jUnit4) с тем, чтобы тестировать для разных пользователей...

добавим теперь этих разных пользователей...

Чик! И тесты работают...

Научим тест создавать этот файл с необходимым набором пользоватльских данных...

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

Но вот неожиданная ошибка!...

Перепишем логику загрузки файла и все пройдет...

Еще раз все тесты...

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

Часть тестов перестала работать...

Но мы добавим файл с пользователями...

И все пройдет!...

Напишем еще одно требование но для другого пользователя...

После добавление этого пользователя - тест стал зеленый...

и ничего более не поломалось...

Пока писал одно пришла идея как сделать другое - для удобства копирования...

Вот как это выглядит в браузере...

Сохраняемся!..

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

Мы можем сделать CopyPast инфраструктуры...

Но я все же предпочитаю другой вид повторного использования кода...Выделим (Extract) в новые методы все места, в которых используется поле server. Это метод startServer...

и stopServer...

Я вначале думал сделать еще один метод, для получения порта...

Но позже передумал и объединил два метода startServe и getServerPort вместе. После я перенес их в новый класс ServerRunner, который настроил как Singleton. В этот же ServerRunner я добавил еще один метод join и некоторую примитивную проверку. На результат можно глянуть тут:

А вот как изменятся его клиенты...

А от оставшейся части дублирование (инициализация tester на основе server) я избавлюсь с помощью наследования... Мне почти ничего не надо делать в ручную - все сделает Eclipse...

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

Вот и все :)...

А вот зачем мы все это делали...

Теперь можно написать новое требование...

Которое естественно не пройдет потому что нет еще того что требуется...

Старой страничке дадим новое имя в соответствии с новой ролью...

И заменим все ссылки по имени на нее....

Внимание! С заменой во всех местах стоит поосторожнее, а потому я сузил поиск выралв галочку CaseSencetive и просмотрел все изменения...

Вот, собственно, все места, в которых прошла замена ...

Картина не поменялась - значит ничего не поломал лишнего (последнее требование не в счет - мы сейчас над ним работаем)...

Легким движением руки...

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

Изменения простые..

И все работает....

Сохранимся!...

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

Естественно требование провалится...

Но мы добавим новый контроллер...

И теперь сообщение об ошибке немного другое...

Оказывается есть два способа общения между сервером (servlet) и клиентом (browser) - POST и GET. Мне стоило реализовать get обработчик...

И сообщенеи поменялось с ошибки (красная иконка возле имени - сообщает о возникновении Exception в тесте) на warning (синяя иконка - в целом тоже ошибка, но когда слетает один из assert'ов теста)...

Сделаем переход на страничку с вопросом...

Создадим эту страничку...

Допишем туда свой контент...

Тест прошел!..

Можно проверить в браузере...

Чтобы работала последняя форма - надо реализовать обработчик POST...

Создать соответствующую страничку...

Наполнить ее контентом...

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

Я проверю руками...

Вроде как работает.

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

Готово!...

Надо расширять контроллер, чтобы он принимал решение сдал или нет...

И результирующую страничку....

Тест работает!...

Сохранимся...

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

Все же я поменяю требования, но только в мелочах. К примеру я хочу выделить Hello world! везде, так как это название экзамена и отдельная константа...

Немного поменяю заголовок...

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

Пошли исправляться...

Один работает...

Дальше фиксим...

Все чисто!...

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

Первый тест afterSuccessfulLoginUserCanSelectOneExam рабочий, а значит мой финт удался мне, но поломалось много других тестов и я уверен что именно по этой причине (две минуты назад ведь все работало)...

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

Тест попрежнему остался рабочим, а значит этим шагом я ничего не поломал...

Исправим мок в соответствии с новыми правилами...

И его тест использующий его так же прошел (осталось всего 3 поломанных теста из 5)! Следующий шаг...

И осталось 2 из 5...

Еще усилие...

Все работает!

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

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

Если константы убрали со странички, то контроллер их должен устанавливать...

С JSTL все намного проще...

Чик и все зеленое!...

Так же я заменю все конструкции <%= bla bla %> на другие , говорят что первые конструкции грех использовать. Не верьте им - все сами проверяйте...

то же на другой страничке...

Проверка, может где еще есть "грешная" конструкция...

Еще хочу навести порядок в новом контроллере и выделить три метода. Do list...

Do result...

и Do Question...

Тесты как и прежде работают, значит рефакторинг удался...

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

Переделал под общую идею и работу с страничкой результатов...

Это все мне позволить сделать следующий рефакторинг... Согласись, так лучше чем раньше.

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

Продолжение следует...

Test Driven Development: Что делать, если тест изначально зеленый?

2012-01-01T23:17:00.003+02:00

Могу поделиться своим алгоритмом работы с тестами.

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

Алгоритм прост как двери. Если я о чем-то беспокоюсь - я вношу это в TODO-список и на время успокаиваюсь. Позже я извлекаю заметку из TODO и проверяю свою гипотезу с помощью нового теста.

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

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

Основная цель - устранить беспокойство - реализована.

Другой бы не парился по этому поводу - и ладно. Ну не было бы у него этого теста. Главное, чтобы я не парился на счет своего кода. Если мозг парится, то он делает ошибки и тупит. А я не хочу чтобы мой мозг тупил :)

Кто-то может сказать об избыточности - мол много тестов, которые тестируют одно и то же; много кода, который надо поддерживать; дублирование наконец! И я понимаю эту позицию. Что я делаю для этого? Я удаляю тесты. Но не сразу.

Удаляю тесты в двух случаях:
1) Глядя на него с намерением удалить (и мыслью, что потом буду рефакторить код без этого теста) я не ощущаю никакого внутреннего дискомфорта - проще говоря мне не страшно, если этого теста не будет в сьюте.

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

С комментарием:

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

согласен на 100%

Но давай немного переиграем. Представим две версии пространства-времени:
1) В одном я делаю большие шаги и имею на пути разработки ряд изначально зеленых тестов.

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

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

И что тогда получается? Делаешь мелкие шажки и все 20 тестов валидные. Но если делаешь шаги побольше, то часть из тех же 20 тестов уже лишние (потому что они изначально зеленые).

Я бы так же рассмотрел такую штуку, как ожидание автора. Тут тоже можно поделить на две части:
1) Бывает так, ожидаешь, что тест пройдет и все равно его пишешь - просто осознаешь, что где-то сделал большой шаг и в будущем без этого теста рефакторить будет беспокойно. Пофиг, что он зеленый - мне без него будет не комфортно потом.

2) Бывает так же так, что вовсе не ждешь зеленой полосы, а тут она на тебя бумц! Имеем фидбек о том, что недостаточно знаем систему. Но что от этого? Тест не перестает быть тестом. Знал бы систему, сделал бы мельче шаг - был бы вынужден написать этот тест. И он бы остался...

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

Как-то так.

Java for fun: Утиная типизация в Java

2011-12-30T22:06:00.012+02:00

На написание этого поста меня вдохновила статья "Утиная типизация в Java" (автор Yaroslav Pogrebnyak).

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

Исходный код можно скачать тут, а все ревизии в SVN репозитории - тут.

Итак, лог разработки про то, как создавался ProxyFactory на TDD:

Ну что, если бы я делал проксик, то наверное хотел бы видеть его API как-то так

А вот и интерфейсы

Как помощники при тестировании, кроме jUnit на благо нового метода трудятся FestAssertions и Maven

Если мы запустим этот тест, то увидим что он не работает

"

По всем правилам TDD простой фикс, который можно сделать чтобы код компилился и работал – это

Тест пройдет

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

Мне понадобится Mock-фреймворк Mockito

А вот и сам тест

Естественно он перестанет работать (я исправил старый)

Но небольшой фикс поможет

Идем дальше – меня интересует, что для других типов уток все будет работать!

Вот и тест

Он идентичен прошлому, с той лишь разницей, что в метод object передается объект другого класса...

Тест естественно не пройдет

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

А потом сделаем фикс

Тесты? Зеленые! Коммитимся

А теперь проверим, что наши чудо утки приводятся к другим интерфейсам тоже

А вот новый тест

Его основное отличие в типе интерфейса к которому приводится объект

И он не работает :)

Но фикс поможет!

Не пугайся, тут я воспользовался одной библиотечкой (1) fest reflect – чтобы не играться с ужасным api java.reflect.*

Так же тут используется прокси-класс (2), который обернет любой интерфейс и перенаправит все вызовы на метод invoke класса ObjectProxy (3)

Тесты проходят, а пока не сильно испортил код – лучше закоммичусь. Сложновасто уже :)

Дальше я хочу проверить как на совместимом интерфейсе вылетит Exception. Вот он интерфейс

А вот и тест.

Странно, но он проходит сразу – не верю!

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

Вот, это уже другой разговор!

Пошли его фиксить

Все, коммитимся

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

А вот и тест, ничего нового, квакнули на прокси, проверили что монстр квакнул, мукнули на прокси, проверили что монстр мукнул...

Странно, но и это работает. Не верю!

А потому поломаю, добавив временный код. Увижу, что слетело и успокоюсь...

Ну ладно, проверю на всякий еще что-то...

Теперь можно сделать как было и проверить, что все работает

Коммитимся!

Но теперь давай сделаем другого монстра, который умеет еще и гавкать

Проверим что к его типу нельзя привести простого монстра...

Блин, опять все работает!

Не верю! А потому заремарю код проверяющий это и успокоюсь, когда увижу, что код слетел как я ожидал

Потом все верну как было, еще раз запущу и закоммичу, если зеленое

А теперь давай проверим кейсы с методами с параметрами

Вот и тест

Ну хоть тут тест слетел! :)

А фикс достаточно простой

И все! :) Зеленое – коммитимся!

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

Вот и тест

Ура! Это еще не реализовано!

А потому реализуем

И все работает! А потому коммитимся!

Дальше поиграемся с примитивами

Все должно быть в шоколаде

Так и есть. Но надо перепроверить!

Добавим немного тестового кода и проверим что тест поломался

А после Ctrl-Z все работает

Коммит!

Дальше потестим, что примитивы и их обертки не распознаются как одни и те же типы (как было со String и Object)

Вот тест

Все прошло. Коммитимся (на самом деле я перепроверял, ломая код, просто тут не привел, ибо демонстрировал это уже) .

И еще один кейс – то же, но задом наперед

Вот и тест (так же работает - перепроверял)

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

Хотя нет! Появилась идея. А что, если интерфейсы наследуются друг от друга. Смогу ли я представить объект в виде суперинтерфейса и интерфейса наследника?

А вот и тест.

И он проходит! (я перепроверял, через поломку)

В вот второй тест, который делает то же но для суперинтерфейса

У него суперинтерфейса нет метода bowWof а потому блок заремарен :) (я копипастил)

Все проходит, а потому commit

Ура!

Мотивация: Как обрести видение? или Следуй за своими музами

2011-12-30T15:06:00.002+02:00

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

Если видения нет, можно попробовать пронаблюдать за тем, что делать в кайф, выписывая эти таски на отдельный листик. Спустя неделю-две можно посмотреть на все эти задачи свысока и помедитировать на тему "а что бы это все значило?"

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

Дальше стоит только идти по новым рельсам сравнивая каждый таск с видением: Помогает ли текущий таск сократить дистанцию между видением и дествительностью? Нет? Драйвит ли меня выполнение текущего таска? Снова нет? Почему я его собрался делать?

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

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

Если пойдешь за музами, то вскоре получишь все. И деньги и успех...

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

Хороший вопрос на каждый день - "Что меня вдохновляет?" Этим и занимайся каждый день. Вначале по 10 минут ежедневно. Потом по пол часа. Потом по часу, потом по два...

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

А за деньги не волнуйся, и запомни простое правило $ = t☺²

P.S. Чуть позже от Друга получил на руки новый термин - "прокрастинация". Если то, что написано в статье про тебя - значит пора задуматься о том, а там ли я сейчас работаю? С теми ли людьми? Тем ли занимаюсь?

Time mamagement: Планируй свой сон

2011-12-30T12:46:00.004+02:00

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

...лучший сон, когда я ложусь в 22:00 и просыпаюсь сам с чувством "все, выспался!" - супер. Я не должен кушать перед сном, лучше если я лягу спать слегка голодным. Можно выпить стакан сока или съесть яблочко. Еще лучше, если будет вечерняя прогулочка, еще лучше на велосипеде а потом душ - это сразу перед сном. Никаких раздражителей не должно мешать в комнате, а форточка должна быть открытая всю ночь (свежий воздух). Я должен знать, что на сегодня я все таски сделал на работе, а завтра у меня расслабленный день, в который я могу работать, или не работать (скорее всего чуть-чуть работать). У меня нет никаких планов на завтра с семьей - типа куда-то пойти, что-то сделать - требующих физического перемещения моего тела в пространстве-времени (особенно, если это "надо" а не "хочется"). Я знаю, что могу до обеда валяться в кровати (но я высплюсь, скорее, к 6 часам утра и с этого времени буду на ногах). Никто не позвонит в первой половине дня. Никто не позвонит в двери (доставка воды, доставка книг или чего-то там еще). Я в этом уверен тогда, когда ложусь спать вечером. Утром дома скорее всего будет спокойно (не шумно), потому как все будут отсыпаться :) Еще хорошо, если днем ранее я сдам какой-то проект. Вот тогда я высыпаюсь лучше всего и день после такого сна наиболее творческий и насыщенный...

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

Какой твой идеальный сон?

Публикуемся: Как разукрасить презентацию или пост в блоге

2011-12-28T11:05:00.004+02:00

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

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

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

Как разукрасить презентацию или пост в блоге:
- ключевое слово
- загуглить картинку

Возможно не хватает еще одного ключевого слова:

Как разукрасить презентацию или пост в блоге:
- ключевое слово
-ассоциация
- загуглить картинку

Все! Первая часть поста закончена. Все остальное - вода.

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

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

Далее я выбираю более красноречивую.

Идем дальше и гуглим слово "ассоциация"...

Бывает такое, что картинки сразу нет. Так у меня случилось со словом "ассоциация". Тут можно сделать две вещи: 1) полистать по страничкам дальше (обычно я листаю до 5 не дальше). 2) загуглить синонимы или близкие по смыслу к ключевым слова. Например не "ассоциация", а "связь".

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

Например "ассоциация" я заменил на "запоминание" и получит вот что

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

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

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

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

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

Еще один ресурс,позволяющий найти места, где используется фотка - http://www.tineye.com/. Кстати так можно посмотреть не только, как часто используется фотка, а еще и кто стянул твою фотку.

Time management: Как сделать так, чтобы тебя не отвлекали?

2011-12-20T21:09:00.004+02:00

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

2 раза * 10 минут * 22 дня * 11 месяцев / 60 минут в часу = 80 часов / 8 рабочих часов в дне = 10 рабочих дней.

Если а если ты прерываешься 10 раз (что, думаю, намного реальнее в наше время). Это уже больше 2х рабочих месяцев году.

При зарплате в 500$ в месяц. Значит в год из ежедневных прерываний (по 10 раз) ты теряешь 1000$. Можно в следующий раз своему коллеге сразу сказать "эй чувак, твой этот вопрос мне стоит 1000$ в год!".

Но если копнуть глубже, то работы мы стремимся все же сделать столько сколько запланировали. А значит овертаймим. А значит не ты теряешь 1000$ а твой ребенок не видит папку этих самых 50 часов в году. Если посчитать что на общение с семьей у тебя 8 часов, то твоя семья недополучает внимания на тех же два месяца. Два месяца в году семья не видит своего кормильца из за банальных десяти: "...эй, а ты не знаешь случайно че там..." Тут уже в морду бить хочется.

Но погодь. Рано. Посчитай теперь сколько ты раз в день становишься интераптером для другого? А если всех вместе собрать? Мысль только одна: Саня, себя бить надо! Сам виноват!

И что делать? Меняться.

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

Выход есть:

1) Ты мажешь потратить больше времени и прокачавшись самостоятельно научиться добывать информацию.

2) Ты можешь завести 10 TODO списков на 10 человек (которых ты чаще всего интераптаешь) и отложить эти вопросы до тех пор, пока у вас не наметится 1-to-1 митинг. Либо, до тех пор, пока не подвернется удобный (для коллеги) момент - он к тебе сам может обратиться.

3) Ты можешь подумать и понять, что на самом деле тебе вовсе не хотелось решить что-то важное, а хотелось всего лишь поболтать с кем-то или чтобы тебя похвалили, или чтобы подбодрили. Тут другой инструмент нужен. Если тебе не хватает внимания и общения - перестань интераптать и уходи домой раньше :) - там тебя послушают и похвалят.

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

Выход есть. Отучивай. Так же как и приучил. Постепенно. Для начала очень хорошо работает правило "не отвечать на вопрос 15 минут" - этого времени вполне достаточно для того, чтобы мозг интераптора самостоятельно нашел ответ на только что написанный вопрос в скайпе. Все просто. Если напишешь вопрос в письменном виде или проговоришь его, то надо просто подождать до 15 минут, как появится ответ. Это время надо дать интераптору. Много больше пользы будет, если он поймет, что сам в состоянии решить 99% своих проблем.

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

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

Но красный скайп (или закрытие почтового ящика, странички фейсбука, твиттера, перевод телефона в тихий (не вибро!) режим) - это игнорирование проблемы. Проблема в том, что ты ХОЧЕШЬ ответить, потому что там может быть что-то более интересное, чем то, сейчас ты делаешь. Или ты просто устал и хочешь переключиться, отдохнуть. Это поять же надо решать другими способами.

Лечение - поменяй статус на зеленый. Пусть виднеется в трее, а еще лучше на taskbar'е. Но не отрывай мессенджер так долго как сможешь. Продолжай работать и видя вот это мучительное желтое пятнышко на синем фоне.

Пусть мозолит тебе глаза. Запусти таймер и ставь рекорды. За новый рекорд - плюшка - прочти все что собралось :) Потом снова рекорд. Очень скоро ты перестанешь реагировать на "вам пришло новое сообщение".

Что дальше? Дальше жестче. Говорим нет всем, кто к нам приходит. Как правило первый вопрос, который тебе задают - "Саня, ты не сильно занят?" Ответ должен быть "Сильно". С последующим, "К тебе через 15 минут подойду, как закончу, прости".

Что есть "я сильно занят?" - это когда находишься в состоянии потока и у тебя идет сверхпродуктивность. И тут надо "Ппппррррррр, Ракель" и переключаться на другое, потом снова разгоняться. Это более чем повод сказать, прости я занят сейчас.

Но! Очень важно прийти через 15 минут и дать ответ на вопрос, как обещал. Иначе это уже неприлично.

Все! Закончил. В ходе написания статьи одному коллеге пришлось сказать "Нет", потратить 53 минуты времени (знаю потому, что веду хронометраж). Сейчас пойду со спокойной душей помогу коллеге с его вопросом.

How to: Как выкачать SVN репозиторий с history через http?

2011-12-13T19:08:00.001+02:00

Если нет доступа к серверу, а есть только url на Svn репозиторий и очень надо получить у себя на локали репозиторий со всей историей коммитов, то поможет git :)

Как его установить - вопрос сюда. Под windows довольно тривиальная установка. Я себе поставил

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

Открываем Git Bash (в меню Пуск можно найти :))

И в консоли набираем

git svn clone http://host/blablabla/blabla --no-metadata

где http://host/blablabla/blabla путь к репозиторию.

Далее мы увидим, как ревизия за ревизией все подтянется на наш локальный репозиторий в GIT

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

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

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

Time management: Как проводить хронометраж? Что мне дает хронометраж?

2011-12-12T19:35:00.003+02:00

Хронометраж - инструмент, который я впервые опробовал после прочтения книги Глеба Архангельского "Таймдрайв". Торкнуло так, что теперь постоянно веду его.

Хронометраж (в моей версии) состоит из двух частей:
- Ведение засечек времени при переключении с задачи на задачу. Причем "пошел в туалет", "вышел в офис пешком", "переустановил java" - это все таски. Все задачи, от минуты и больше - все должно быть записано. Записывается время старта, время завершения, категория задачи.
- Анализ утечек времени. Раз в неделю (или раз в день), в тихой спокойной обстановке, просматриваются все записи с одним единственным вопросом "а как это можно было сократить?"

Те, кто ведет домашнюю бухгалтерию - поймут, что дает этот инструмент. Только если деньги - ресурс восполняемый, то время вам никто никогда не вернет. Он позволяет понять, куда утекает ваше время. Важно это по одной простой причине - часов в жизни человека, дуй Бог, наберется 700 000. И каждый час это число становится меньше. Я, в своих 26 лет, уже ~230 000 часов израсходовал. Ребята, которым уже за 300 000 завалило, вплотную задумываются о том, а какого фига я достиг в этой жизни. Кризис среднего возраста называется. Это когда понимаешь, что то, о чем мечтал в юношестве и детстве - там, в мечтах и останется. Те мои знакомые, которым еще больше - частенько говорят об упущенных возможностях.

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

Как-то фрирайтинг мой занес меня в дебри :) Что из этого всего можно понять? Да то, что у меня есть 70 000 часов до, того самого, кризиса среднего возраста. Это может показаться много - 8 лет! Но с момента, когда я был студентом прошло даже больше. Не прошло а пролетело. Так что это очень немного.

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

Как я это делаю?

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

Вот так выглядит формочка:

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

Как она работает?

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

Оранжевые колонки "Начало", "Разница", "Категория", "Сумма", "%", "Часов всего" ты не трогай, потому что они подсчитываются автоматически. Разве что самая первая ячейка колонки "Начало" - ее надо будет ввести вручную.

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

Далее идет другая таблица, подводящая итог:
"Категории" - Заполняется автоматически из колонки "Категория". Выбираются все уникальные категории.
"Сумма" - Заполняется автоматически из колонки "Разница", для всех рядков заданной категории.
"%" -Дает ответ на вопрос, как много всего своего времени в % соотношении ты уделяешь этой категории. Заполняется автоматически
"Часов всего" - общее количество учтенных часов.

Траблшуттинг (или рекомендации по использованию таблиц в excel):
- не вставляй (не удаляй) никаких строк и столбцов в таблицу.
- не используй copy-past значений из одной ячейки в другую
- пиши текст только вручную
- не заполняй никаких значений в колонку F (она скрыта).
- не пиши ничего в колонках С, E, I, J, K, L - в них одни сплошные формулы.
- для тебя только зеленые колонки "Дата", "Что делал?", "Конец", "Категория"
- после каждого анализа начинай работу с нового листа (так проще)
- расширяй доку, только если понимаешь что делаешь. Хорошо бы при этом сравнить какие-то контрольные значения со значениями взятыми до правки.

А теперь не много рекомендаций при работе с хронометражом

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

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

Проводи анализ раз в день, неделю, месяц (это по началу не советую - очень отложенная обратная связь получается).

Представь, что числа эти - это не часы, а тысячи долларов, которые утекают с твоего счета. Ты есть целый завод по производству чего-то полезного. В тебе работают разные отделы. Каждый день работы стоит 240 000$. Тебе надо придумать, как эти деньги эффективнее расходовать. Ты директор!

Для версии, где час стоит 1000$ предлагаю другой шаблон, более мотивирующий :)

Вот пример.

Всего лишь надо выбрать в колонке "ЗП, $ в месяц" сколько денег ты "получаешь" в месяц (я выбрал 100 000$ :) чтобы цифры в колонке "Разница" были ощутимее).

Теперь про то, что я получил от хронометража и что можешь получить ты:
- ты понимаешь, что то, что ты думал займет 5 минут, вовсе 5 минут не занимает. Позже ты поймешь, что задач на 5 минут практически никогда не бывает - все они растягиваются на в разы и являются главным пожирателем твоего времени.
- ты понимаешь что сделал совсем не то, что хотел сделать сутра
- ты понимаешь, что на самом деле кроется за "нет времени" - эту фразу более приятнее говорить как "не те приоритеты".
- ты отказываешься от чего-то, потому что понимаешь - времени заберет огого, а пользы не так.
- ты стремишься делегировать
- ты оптимизируешь, автоматизируешь- придумываешь что угодно, чтобы сделать то же но дешевле
- ты работаешь сутра, а после обеда спишь или гуляешь
- ты делаешь частые перерывы, потому что это эффективный способ борьбы от суеты
- ты стараешься не отвлекаться на скайпы, почты, потому как все ты воспринимаешь как задачи
- каждый вечер (или раз в неделю) ты делаешь новые открытия в ходе анализа
- тебе легко заполнять всякого рода рипорты
- тебе легко сказать сколько точно времени займетта или иная задача, потому что ты знаешь насколько в среднем ты обманываешь себя, на планировании, когда говоришь "я сделаю это за X часов"
- ты управляешь своим временем, а не плывешь по течению.
- ты доволен тем, что у тебя в дне больше на пару (а может и пять-семь-30-1000!) часов времени чем у остальных.
- еще (из последних нововведений) ты легко можешь подсчитать в процентном соотношении, как и на что утекает твое время. Так же можно придумать любые другие метрики - покуда есть статистическая информация. К примеру на вкладке "Балланс" можно сгруппировать категории и увидеть в процентном соотношении на что тратится время. Очень полезно, если хочешь начать уделять семье столько же времени сколько работе.

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

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

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

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

Простой пример - этот пост в блоге находясь в общедоступном месте могут читать тысячи (ну ладно, сотни) людей. Если бы я поставил перед собой цель рассказать то, что тут написано сотне людей, то:
- я бы взял год, чтобы объяснить этом каждому отдельно
- я бы взял две недели, чтобы организовать вебинар и провести его разово для 100 людей
- я бы потратил 2 часа, чтобы описать это в блоге. Все! Больше я к этой теме не вернусь - если кому-то и надо будет объяснить про хронометраж - я скину ему линк на пост в своем блоге (а это займет 10 минут не больше). Вот так то, на что я тратил раньше час (передавая из уст в уста), теперь я трачу 10 минут (передавая линк).

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

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

В общем Enjoy!

Java for fun: Кодревьюшки #1

2011-12-12T12:07:00.001+02:00

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

Сегодня рабочее утро у меня началось с этих ревьюшек.

Это первая серия, дальше будет...

26-27 декабря: Киев, Тренинг "Test Driven development in Java"

2011-12-08T01:27:00.000+02:00

Привет!

В этом году мы еще разок дадим жару на нашем двухдневном тренинге "Test Driven development in Java", который пройдет при поддержке Scrumguides.

Сережа и я сейчас интенсивно apply'им все фидбеки, которые получили из прошлых наших тренингов на эту тему. Работы много. Новый тренинг будет не таким, каким его видели участники прошлых наших тренингов. Спасибо, Ребята, за ваши полезные замечания.

Вот что пишут про TDD некоторые из участников:

I am planning introduce this knowledge at my work. I will have to think about how I can apply this for the mobile java development. But I think TDD can give me a lot of benefits for the next project.

I have remembered pieces of JUnit. Coaches gave an answers for my principal questions and they gave a main direction for movements.

It was very useful event. I hope similar events will be appear more frequently then now. I would be say that 2-3 day events is effective than one-day event. Many thanks to coaches and organizators.

Bogdan Strelets

After the training I have started using TDD methodology in my personal software project (Bible reader application for Android) in oder to gain some initial TDD experience. Planning to use TDD while working with the C trainee in my current work project, so that the expected future developement activities on my project will benefit from the TDD appoach.

Plan to learn and practice on how to think of the software in terms of tests and how to design well testable modules. Also plan to read more about the TDD and how it applies to C-based projects.

The trainers had a strong positive impact on me. They had me convinced that the TDD approach is beneficial, and not only for the final quality of the software product but also for the developer's everyday and overall confidence in the software he/she is developing. The latter is highly valuable to me as a developer.

During the sessions the trainers have well used their obvious knowledge, experience, confidence, and sense of humor. The good presentations and practice sessions with the audience were very effective. I recommend this TDD training for teams and individual developers which need encouragement and guidance regarding improvement of the software quality. Also recommend for developers who simply need to learn that with TDD even complex software systems can be built in such a way that their future extension will be a feasible, predictable, and not risky task.

Denys Dolganenko

Тренінг по TDD підійде всім, як новачкам так і досвідченим TDD розробникам. Ті хто ніколи не працювали з TDD можуть здобути цінні знання і розуміння TDD, зразу відпадуть питання: «Для чого мені писати юніт тести?», «Звідки впевненість що мої тести працюють правильно?», «Хто напише тести для моїх тестів?» . Ті хто вже працював з TDD зможуть систематизувати свої знання.

Пройшовши тренінг по TDD ви отримаєте все необхідне для програмування по TDD, в результаті ви зекономите багато часу час , оскільки не прийдеться читати товсті книжки. Про «Гру в пінг-понг», яка скорочує час і екфективність розробки, навряд чи можна ще десь дізнатися окрім тренінгу.

Мені тренінг допоміг систематизувати свої знання, і я отримав відповіді на запитання відповіді на які я би міг знайти, рившись в товстих книжках, витрачаючи багато часу. Також треніг допоміг мені при захисті презентаці по TDD в університеті, я зміг відповісти на достатньо не прості питання викладача який провів в ІТ багато років.

І на кінець TDD - це всього лише інструмент, а те, як цей інструмент використовується, залежить від людини, яка цей інструмент тримає в руках. У чиїхось руках він може приносити багато користі, а в інших - багато шкоди. Якщо ви вирішили програмувати по TDD, то будьте готові до жертв: це і втрата швидкості розробки на початку, і жорстка дисципліна і самоконтроль, інтенсивне навчання і т.д. Всі ці жертви потім окупляться. Багато хто не витримує і повертається до колишнього стилю роботи. Але, на мою думку, а також на думку деяких знайомих мені TDD-практиків, як тільки розробник відчув залежність від «зеленої смуги», дізнався, що таке повний контроль за кодом, тобто став інфікованим тестами (test-infected), він уже ніколи не відмовиться від тестування. Поки що ніхто з моїх знайомих не шкодує часу, витраченого на вивчення і експерименти з TDD.

Yaroslav Balytskyy

Впринципі даний тренінг призначений для програмістів які ніколи не використовували TDD, проте ішовши на тренінг я вже мав рік досвіду роботи по TDD&XP і незважаючи на це я все одно знайшов для себе цікаві теми.

Якщо ви маєте досвід роботи по TDD то ви просто мусите послухати про TDD Anti-patterns, Unit vs Integration testing. Під час моєї роботи, в мене постійно виникало питання "Коли писати тести? Який код варто тестувати?", тепер в мене не виникає таких питаннь. Найбільший фан я отримав коли розпочалась практична частина тренінгу і ми почали грати в TDD Ping Pong. В цілому TDD тренінг був дуже цікавим і насиченим. І я з повною впевненістю можу сказати, що не дарма витратив свій вихідний день.

Igor Gordiichuk

Всем кто еще думает идит или нет. Отвечу: Идти! Замечательная тема, замечательные ребята, потрясающий результат.

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

Финансовавя сторона вопроса: Едиственная причина которая может заставит вас отказаться от такой возможности это отсутствие финансов или их крайнее наличие. Хотя меня последнее не сдержало, и я не жалею. Даже если просто прикинуть то стоимость хорошей книги сейчас не меньше 200 грв + время на ее прочтение +односторонняя связь с книгой.

Итого выходит немало трудозатрат. А если верить идее что каждая книга рано или поздно добавить +50 к уверненности, +50 к знаниям и +100 к твоей стоимости как специалиста, то уверен, что на этой встрече я прокачался на все +200 по всем параметрам, кроме ЗП - пока )).

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

Так что руки в ноги и вперед на встречу солнечному будущему без дебага))

Oleksandr Sientsov

First I have to say that when I heard about TDD I was a little bit sceptical about this methodology. Write test before real implementation? Are you kidding me? Well, it was before training.

On the beginning of the training, coaches helped me to tune the environment. After that training started. First off all we listened some theory, which by the way was supported with some funny picture( they really helped me to wake up after rought friday night:)). Trainers was nice and gladly answered our questions.

After this we had some practice. Practice was in pairs. Only one pc for two developers. At the first it was unusual, but after a little while I got used to it. And I have to say this methodology could be very effective. Like they said - "One head is good, but two better".

One thing that I did not like in the practice it is a emulation of elevator. IMHO it is too abstract task, I would rather write some "Snake" or "Tetris", maybe something simplier, but definitely something more specific. One more thing I would like to propose it is to organise some sort of little competion between students. E.g some little task and who will do it better and faster.

So, my conclusion is - training was nice. It helped me understood that TDD can be very usefull in some cases. Once again a little more practice and independent work and everything will be perfect.

Teodor Moroz

Це насправді був мій перший тренінг такого рівня. Дивлячись на те що я Automation QA, думав що буду почувати себе повним чайником на даному дійстві, адже маю більше досвіду у написанні тестових скриптів ніж у безпосередній розробці, проте як виявилось, хлопці підготували матеріал у дуже доступній формі.

Насамперед хочеться сказати, що відкрив для себе новий підхід у написанні коду, так сказати задом наперед до поставленого завдання). Тренінг цікавий, слухався на одному диханні, викладений дуже професійно та доступно, незважачи на рівень знань слухачів, що і засвідчує моє повне розуміння матеіралу після тренінгу, аже сам ше джунік).

Думаю важливу роль відіграло те, що хлопці зробили великий акцент на практичній реалізації, адже легко вчитись не коли просто слухаєш і читаєш, а коли реалізовуєш руками). Практично кожен присутній вніс якусь свою деталь у розробці контроллера ліфта(який ми практично реалізовували на тренінгу за принцибом TDD).

Побільше б таких тренінгів).

Taras Lytvyn

Раньше я слышал о TDD, но никогда не вникал в его суть. Тренинг дал понять насколько интересную и полезную технологию я упускал, а главное, быстро вникнуть в ее принцип.

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

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

Dmitry Shilov

Refactoring: Еще немного про рефакторинг

2011-11-28T21:24:00.001+02:00

Вот случайно нашел презенташку со своего техтолка "Чистый код". Планировалась серия таких презентаций. Это первая. Рассмотрел пару Фаулеровских запахов:
- дублирование
- код с комментариями
- большой метод
- завистливая функция

Продолжение следует...

Think about: Задуматься о том, что делаем с нашим домом - Землей

2011-11-28T10:15:00.002+02:00

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

А вот еще немного

Но надежда есть

После этого фильма мне захотелось посадить дерево. Пойду поищу волонтерские организации...

Java for fun: Как работать с Mockito?

2011-11-27T22:59:00.003+02:00

Не так давно, на двухдневном тренинге по TDD я решил поизучать новый mock-framework. Путем гугления выбрал самую популярную. 4 часа я вкуривал доку по Mockito v1.8.5. Читал и писал тесты, чтобы опробовать либу на деле.

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

Еще пол дня и я могу представить презенташку основанную на этих простых тестах

Пользуйся на здоровье. Надеюсь мой день не прошел даром и ты получишь ответы на вопросы:
- Как работать с Mockito?
- В чем фишка Mockito?
- Что лучше: Mockito или другой mock-framework?

29 Ноября. Воркшоп: разработка через приемочные тесты с помощью JUnit

2011-11-24T11:19:00.002+02:00

29 ноября с 18:00-20:00 в офисе GlobalLogic пройдет интересный воркшоп по легковесным ATDD-практикам.

Воркшоп бесплатный, регистрация обязательна - http://bit.ly/vTPFg3

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

Все два часа воркшопа - только практическая работа! Мы научимся определять ключевые тесты с помощью техники "Специфицирования примером" и быстро реализовывать их в виде тестов до написания кода или же параллельно. В режиме Coding Dojo мы сможем все активно поучаствовать в этом действе.

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

Воркшоп проведем вместе с Александром Якимой (www.enter-agile.com, www.yakyma.com) - независимый консультант по гибким методам разработки, работающий с командами в США и Индии по широкому кругу вопросов от масштабирования Agile-методов до внедрения гибких инженерных практик.

Как добраться до офиса GlobalLogic?
г. Киев, ул. Н. Гринченка, 2/1. Офис компании «GlobalLogic», GL-Club.

До встречи!

Мотивация: Кто-то, о чьем существовании Вы даже не подозреваете, любит Вас

2011-11-20T21:28:00.002+02:00

…А знаете ли Вы, что каждую ночь кто-то думает о Вас перед тем, как заснуть.

Для кого-то Вы означаете весь мир.

Вы особенны и уникальны.

Кто-то, о чьем существовании Вы даже не подозреваете, любит Вас.

После того, как Вы совершаете самую большую ошибку, следует что-то хорошее.

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

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

Всегда запоминайте комплименты, которые были сказаны о Вас. Но всегда забывайте грубости.

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

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

Рефакторинг: Что такое рефакторинг?

2011-11-20T20:52:00.002+02:00

Хочу сделать презенташку по Рефакторингу. Вот сел и набросал в mindmap'чик все что было в голове по этому поводу. Надеюсь кому-то пригодится.