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


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

воскресенье, 27 декабря 2009 г.

SEO оптимизация: Повышаем информативность заголовков для читателя

Я вел свой блог лично для себя. Что-то появлялось в голове и тут же оцифровывалось в пост. Сейчас в блоге накакано около 300 постов. От совершенно бесполезных, до таких, которые могу быть кому-то полезны. Вот об этом сегодня я и задумался. Кому мой блог может быть полезен? Ответа не последовало. Тогда я забрался с другой стороны. Об этом хочу рассказать.

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

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

Чтобы увидеть то, что видит потенциальный читатель к примеру на Google, стоит ввести в нем имя сайта с приставкой "site:" (без кавычек, для меня это site:apofig.blogspot.com) и нажать поиск. Я на большинство своих заголовков не кликнул бы.

Вот список из тем нескольких моих первых постов (перечеркнуто), комментариев к ним (написано курсивом) и то к чему я пришел в результате перечитывания поста (подчеркнуто):
+ Чувственный тимворк - что такое тимворк? слово заморское и непонятно. 

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

+ Если вантуз не помогает - снова какая-то заметка, которая понятна только мне самому. Я то знаю в чем тут дело. А эндюзер? Вот как лучше Как прочистить забитый туалет, если вантуз не помогает

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

+ Язык и строитель - вообще нифига непонятно, это скорее набор тегов а не название для поста. Так называть не стоит. Заменил на Насторожись при виде строителя, который просто сидит 

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

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

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

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

Спасибо Юра за твои рекомендации. С твоей подачи это все.

суббота, 26 декабря 2009 г.

Конверторы на все случаи жизни

http://www.ph4.ru/web-20_convert.ph4

Игра под названием Рефакторинг: Метод в ООП. Extract Method. (часть 1)

Этой статьей начинается серия статей про рефакторинг [1] - изменение кода без изменения того, за чем этот код написали. Статья рассчитана на читателя, который наслышан про рефакторинг от более продвинутых напарников но сам никогда не использовал его или использовал но крайне редко; для тех, кто хотел бы копнуть вглубь и попрактиковаться; для тех, кто хотел бы добавить рефакторинг в арсенал инструментов "на каждый день". Автор основывается на двух довольно известных книгах [1, 2] с дополнением знаниями, полученными им в процессе практических экспериментов с рефакторингом. Чтобы заразить идеей потенциального читателя, предлагаю перед углублением в текст статьи посмотреть видеоролик, в котором Автор записал сеанс одного из своих рефаткорингов.

Мое знакомство с методом началось с замечания, что он должен помещаться на экран: «метод, не помещающийся на экран — плохой метод». На вопрос "почему?"я получил ответ "чтобы было удобно читателю". С тех пор прошло несколько лет. И теперь я не согласен с этим утверждением. Попробую в этой статье раскрыть этот вопрос.

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

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

Слава Байту, в моей жизни появился Рефакторинг. Он то и поставил все на свои места. Если оставлять мост между процедурным и ООП стилем, то метод — это процедура, делающая одно действие и обрабатывающая при этом данные своего объекта. Следом объявилось новое свойство методов - они выделяются не только с целью устранения дублирования [2]. Это было ценное открытие для меня. Моя эйфория по этому поводу была предметом многочисленных споров с сотрудниками во время парной разработки. «Зачем создавать метод который никогда не будет использован?!!» А затем, чтобы сделать нечто, что будет просто осуществлять одно действие и больше ничего. Если уж метод не будет востребован — сделай его приватным.

Цель этой статьи - продемонстрировать, что можно вытворять с большими методами делая процедурный код более объектно ориентированным с помощью Рефакторинга. На словах что-то объяснить сложно. В работе мне помогает парное программирование. Тут же на примере я попробую продемонстрировать базовый тип рефакторинга — выделение метода (Extract method). Я всегда ленился делать это руками, но когда я узнал, что в IDE (любой) присутствует подобная функция - я влюбился в этот тип рефакторинга. Итак, вначале был экстракт метод (Extract Method). Он же самый, как мне кажется, используемый — дорога в увлекательный мир ООП, шаблонов, рафакторинга и архитектуры.

Суть Extract Method — часть сложного метода сделать отдельным полноценным методом, после использовать делегацию (старый вызывает новый). Подобным образом мы устраняли дублирование в процедурах. Наш исходный метод (для простоты понимания выбирался довольно простой метод):

public void foo(List<String> answers) {
    for (int index == 0; index < this.size; index ++) {
        this.answer = answers.get(index); 
        if (this.answer == Answers.DEFAULT_ANSWER) {
            this.count = this.count + SOME_CONSTANT;
        } else {
            this.count = this. count - SOME_CONSTANT;
        }
        this.saveAnswer();
    }
}


Первый шаг - опишем что же метод делает на родном языке. «Проходясь по всем answers, выбирает и устанавливает каждый его элемент в this.answer, а потом сравнивает это свойство с чем-то. Основываясь на результате сравнения определяет - уменьшать или увеличивать значения this.count. После выполняет некое сохранение».

Второй  шаг — выделим из описания все действия (все формы глаголов).
Проходясь по всем answers, выбирает и устанавливает каждый его элемент в this.answer, а потом сравнивает это свойство с чем-то. Основываясь на результате сравнения определяет - уменьшать или увеличивать значения this.count. После  выполняет некое сохранение.
Итого: проходится, выбирает, устанавливает, сравнивает, основываясь на чем-то определяет, уменьшает, увеличивает и выполняет сохранение. 7 действий на 1 метод. Многовато, если вспомнить, что наша цель - не более одного действия/глагола на метод.

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

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

Возьмем исходный метод и оценим отдельные его составляющие:

public void foo(List<String> answers) {
    for (int index == 0; index < this.size; index ++) {   
        this.answer = answers.get(index);     
        if (this.answer == Answers.DEFAULT_ANSWER) {   
            this.count = this.count + SOME_CONSTANT;   
        } else {   
            this.count = this. count - SOME_CONSTANT;   
          
        this.saveAnswer();   
    }   
}


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

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

Выделим низкоуровневый код:

private boolean isDefaultAnswer() {
    return this.answer == Answers.DEFAULT_ANSWER;   
}

priavte void increaseCounter() {
    this.count = this.count + SOME_CONSTANT;   
}

priavte void decreaseCounter() {
    this.count = this.count – SOME_CONSTANT;   
}


исходный метод немного преобразится:

public void foo(List<String> answers) {
    for (int index == 0; index < this.size; index ++) {   
        this.answer = answers.get(index);     
        if (this.isDefaultAnswer()) {   
            this.increaseCounter();   
        } else {   
            this.decreaseCounter();   
        }   
        this.saveAnswer();   
      
}


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

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

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

private void changeCounter() {   
    if (this.isDefaultAnswer()) {   
        this.increaseCounter ();   
    } else {   
        this.decreaseCounter ();   
    }   
}

public void foo(List
<String>
answers) {
    for (int index == 0; index < this.size; index ++) {   
        this.answer = answers.get(index);     
        this.changeCounter();   
        this.saveAnswer();   
    }   
}


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

Еще раз (это важно): название метода должно отвечать на вопрос ЧТО делает метод и содержать ОДИН глагол. Методы с названием типа doSomething1AndSomething2 – это не методы, а процедуры.

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

В самом конце стоит пересмотреть имя для исходного метода foo - теперь эта задача решается программистом в разы легче.

public void processAnswers(List<String> answers) {
    for (int index == 0; index < this.size; index ++) {   
        this.answer = answers.get(index);     
        this.changeCounter();   
        this.saveAnswer();   
    }
}


Кстати, изменения названия метода (Rename method) так же частый гость, и в ИДЕ, с большей долей вероятности, она так же автоматизирована.

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

Выделение метода — отправная точка к другим типам рефакторинга. В результате у нас образовалось некоторое количество новых методов, которым, возможно, не место в этом классе (как это определять и что с этим делать расскажу в «Где моя тачка, Чувак?»).  Кроме того у нас остался исходный метод processAnswers. Его как раз и предлагаю еще поковырять. 

Воспользуемся для установки значения поля this.answer его сеттер (если его нет, то создадим):

public void processAnswers(List<String> answers) {
    for (int index == 0; index < this.size; index ++) {
        this.setAnswer(answers.get(index)); 
        this.changeCounter();
        this.saveAnswer();
    }
}


Т.к. цикл проходится по всем элементам списка, то воспользуемся его сокращенной версией (ведено в Java 1.5):

public void processAnswers(List<String> answers) {
    for (String answer : answers) {
        this.setAnswer(answer); 
        this.changeCounter();
        this.saveAnswer();
    }
}


Вот теперь намного лучше.

После таких обработок можно заметить, что результирующий метод не использует данных исходного  класса непосредственно, а значит есть шанс, что он является либо его расширением, либо частью другого класса использующего этот. Он может быть и частью исходного класса, но это должна позволять его метафора (про метафоры напишу в статье «Безымянный класс»). Все же я бы пересмотрел интерфейс изменяемого класса на всякий случай. 

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

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

Список чтива:
1. Мартин Фаулер "Рефакторинг"
2. Стив Макконнелл "Совершенный код"

пятница, 25 декабря 2009 г.

Самая лучшая в мире собака!

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

Вот собрал все что нашел.

А вот Ксюха сделала видеоролик.

Песня о снежинке (Чародеи)

Еще одна песня, и снова настроение++.


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

Смотри с надеждой в ночную синь,
Некрепко ладонь сжимай,
И всё, о чём мечталось, проси,
Загадывай и желай.

И новый год,
Что вот-вот настанет,
Исполнит вмиг мечту твою.
Если снежинка не растает,
В твоей ладони не растает,
Пока часы двенадцать бьют.
Пока часы двенадцать бьют.

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

Затихнет всё и замрёт вокруг
В преддверии новых дней,
И обернётся снежинка вдруг
Жар-птицей в руке твоей.

Новый год,
Что вот-вот настанет,
Исполнит вмиг мечту твою,
Если снежинка не растает,
В твоей ладони не растает,
Пока часы двенадцать бьют.
Пока часы двенадцать бьют.
Пока часы двенадцать бьют.
Пока часы двенадцать бьют.

Доминик Джокер feat Хатуна - Если это любовь

Услышал по телику, и стало легче.


Еще с тех самых давних пор, когда деревья казались большими
И я учился выговаривать свое имя
Казался мир огромным городом, где прячутся новое чего боятся нету повода
Гораздо интереснее всё узнать самому
У взрослых очень странная реакция на некие «почему?»
А мне так важно знать ответы и времени нету
И значит надо разбираться самому
Я становился старше, менялись ценности
Первая любовь, первая проверка смелости
Вкус первой капли крови на губе разбитой
Я выиграл в драке, но проиграл в более важной битве
Я не хотел чтобы родители меня увидели
Я победил в бою, но не был победителем
Моя любовь мне в ответ сказала: «нет»
Я дружу с Денисом, у него велосипед
Я брел домой слезами скрывая кровь
Мне было наплевать на пару ран и синяков
Но мама всё поняла, и сказала пару слов:
«Любовь всегда возвращается, если это любовь»

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

Но в детстве всё довольно быстро теряет яркость
В душе детей нет места, чтобы носить и боль и радость
Наверно очень скоро и моя обида
Как берег за кормой постепенно пропала из вида
Я шел по жизни думая, что ко всему готов
Считая другом тех, кто не попал в число врагов
И никогда не верил в бред полупьяных подруг
Друзья не могут предать, ведь друг на то и друг
Я обжигался, я падал вниз
И каждый раз вставая думал: «Есть ли в этом смысл?»
Верно сказано: «Нет страшнее наказания
Чем исполненные Богом собственные желания»
Скучно видеть этот мир черно-белым
Лучше сделать и жалеть, чем так же жалеть, но не сделав
Я всегда верил в силу этих слов
Любовь всегда возвращается, если это любовь

Прошло немало лет, с тех пор всё изменилось
Но мамины слова слава Богу не забылись
Бывало у судьбы я впадал в немилость
А удача и счастье просто меня сторонились
Но я не верил происходящему
Любовь не вернулась назад, значит не настоящая
И я дождался, путь проделав длинный
Моя любовь стала мне женой и подарила сына
Теперь я знаю, что скажу ему когда-то
Что в яркой жизни бывают и темные пятна
Не надо в трудные минуты прекращать шагов
Любовь всегда возвращается, если это любовь

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

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

Гороскопчик прочитала мне любимая...

...а я его в гугле нашел! :)
Овен


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

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

Мы не только слышим, что нам говорят, мы так же видим это. Эффект Мак-Гурка

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

И это блин удивительно. Вот видеоролик. Предлагаю прокрутить его трижды:
1. Посмотреть с включенным звуком. Запомни что слышится.
2. Только послушать (закрой глаза). Запомни что слышится.
3. Только посмотреть (выключить звук). Запомни что видится.
Во всех трех случаях "слышно" разное.

Метод 360 градусов

Вот хорошее описание ЧтоГдеКогдаЗачемПочемуСколько.

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

Список интересующих вопросов составил сам. Вот они:
1. командная работа (как работалось/что можно выделить из "+" и "-"/какие напутствия?)

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

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

4. технический уровень (как в общем/изучение нового/уровень базы/уровень ядра/уровень презентации/дизайн/на что обратить внимание?)

5. коммуникативные навыки (как в общении? что хорошо, что не очень? на что обратить внимание?)

6. вклад в Компанию (что/как было сделано такого, что можно считать личным вкладом в Компанию?)

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

8. возможно что-то не попало ни в одну из категорий, но очень-очень-очень важное, что? и почему?
Когда фидбек был готов я с нетерпением его прочитал. Потом прочитал еще раз, потом еще. Странное двоякое чувство. Т.к. дока отредактирована одним человеком, кажется что фидбек давал один человек. Но на самом деле их было 5. И вот это непонятное: вроде похвалили, вроде поругали, вроде с пренебрежением и в тот же момент с любовью и благодарностью. Супер! Фидбек просто супер!

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

А вот из за чего весь сыр бор:
Підтримка команди з тех сторони — добре. Покращити підтримку команди в стресових ситуаціях, брати відповідальність. Багато допомагав, направляв, намагався налагодити роботу в компанії, беручи до уваги особисті принципи, бачення, досвід багатьох книг. Спочатку відчувався командний дух, бажання зробити для команди буквально все. Останні місяці відчутне бажання усамітнитись і складалось враження про абсолютну байдужість до того, що робиться в проекті. Дуже різкий контраст між тим, що було раніше і зараз. Працелюбний, відповідальний, безкорисливий. Намагання самовдосконалитись, спроби зробити умови праці кращими, боротьба за справедливість, бажання допомогти (не важливо по роботі чи в житті). Цілеспрямованість. Недостатня відкритість, образливість (інколи через дрібниці). Намагання примусити інших працювати так, як працюєш сам. Деякі шишки потрібно набити самому. Завжди пропонується вудочка замість того, щоб вказати рибне місце. Питання через аську замість живого спілкування. Впертість, небажання іти на компроміс. Технічний рівень достатньо хороший, звернути увагу на тонкощі технологій+бази. Є великий потенціал до вивчення і засвоєння нового матеріалу. Дизайн — трохи гірше. Звернути увагу на різницю між браузерами (.js) Готовий до фідбеку, покращити живе спілкування, відкритість. Залежить від настрою, може бути дуже цікавим співрозмовником, намагається не грубити і бути терпимим до чужих образ. Звернути увагу на образливість, не варто сприймати всерйоз нападки оточуючих, вони теж люди і часом тебе не розуміють. Розвиток QA. Підвищення якості коду. TDD і рефакторинг. Звернув увагу компанії на особисті потреби працівників. Генерація ідей. Якщо говорити про соціальне — великий вклад, для багатьох ковток свіжого повітря, нові патерни, погляди на проектування, парне програмування, тестування, архітектура. Дякую за гарне програмування. Саня, не йди, нам буде тебе не вистачати!
Еще раз спасибо.

четверг, 24 декабря 2009 г.

Зарплатная игла

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

Расходы растут вместе с доходами и могут расти бесконечно. Захотел телик? Захотел плазму? Захотел домашний кинотеатр? Захотел свой личный кинотеатр? Захотел 3d кинотеатр? Сам захотел снять фильм? Инвестируешь фильм? Ну как-то так.

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

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

Потому сокращай свои расходы максимально. Получилось? Еще сократи.

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

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

Как получить больше удовольствия при просмотре фильма в кинотеатре

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

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

Такая рельефность изображений зависит не от свойства самой ленты, как часто думают, а от места, где помещается зритель. Кинематографические снимки хотя и производятся с помощью весьма короткофокусных камер, но проектируются на экран в сильно увеличенном виде, — раз в сто, — так что их можно рассматривать двумя глазами с большого расстояния (10 см * 100 = 10 м). Наибольшая рельефность наблюдается тогда, когда мы смотрим на картины под тем же самым углом, под каким аппарат “смотрел” на свою натуру при съемке. Тогда перед нами будет естественная перспектива.

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

Для кинематографических снимков обыкновенно пользуются камерами с фокусным расстоянием 35 мм, 50 мм, 75 мм, 100 мм, в зависимости от характера съемки. Стандартная ширина ленты 24 мм. Для фокуса, например, в 75 мм имеем отношение:

(искомое расстояние/ширина картины) = (фокусное расстояние/ширина ленты) = 75/24

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


"Занимательная физика" Перельман Я. И.


Кстати фотографии и журналы так тоже можно смотреть и так же все преображается.

Обходим очереди

Вчера пришлось постоять в очереди в банке и стоять, причем, долго. Наученный прошлым опытом я до того, как стать в очередь спросил у кассирши - я могу в вашем окошке сделать то-то и то-то? Да можете. Ок - тогда стоим. Но спустя 15 минут я пришел к другой фишке. Мне надо было снять денег с карточки. Я не утруждал себя запоминанием пин-кода, а взял с собой паспорт. Подошла моя очередь и мне говорят - вводите пин. А я не знаю. Ну тогда извините - говорят мне. Я спросил - а как мне снять денег без пина? Идите к специалисту - прозвучало в ответ. Ну ок, иду. Подошел - объяснил ситуацию и мне через минуты две дали бумажку на которой было написано сколько мне надо заплатить. Я без очередь подошел на кассу и получил свои деньги.

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

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

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

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

среда, 23 декабря 2009 г.

Впервые за три года свободен

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

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

Ну ладно, освободили, так освободили. Теперь стоит решать другого рода задачи - где найти денег, причем так, чтобы не тусить в офисе с 9 до 18. Неа, не так. Что мне сделать такого, чтобы я мог обеспечить запросы семьи, при этом был свободен для семьи и для своих многочисленных хобби? О! Так лучше.... В всплыло первое слово - фриланс. А опыта нифига не имею... А вот кто имеет...

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

Удачи мне!

пятница, 18 декабря 2009 г.

Как Петя с требованиями работал

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


Жил был Петя. Жил не тужил. Игрался с компьютером. У него это получалось. Решил попробовать заработать на новый компьютер. Ничего другого не умел делать и пошел Петя программистом в компанию. Он не знал что такое коммерческий мир. Взяли Петю на работу и очень скоро Петя стал полноценным членом команды. Команда, в которой работала еще девочка Настя, мальчик Коля и дядя Юра работали над проектом уже 8 месяцев, а до этого проект писали индусы где-то год или полтора, или может не индусы то были совсем. И нашему Пете пришлось потихоньку, изо дня в день, изучать проект вместе с Настей, Колей и дядей Юрой, которые хоть и знали проект лучше Пети, но всего лишь на 8 месяцев. Был у них еще заказчик заморский, который этот проект где-то у кого-то выиграл за игрой в покер. Неважно. А индусов уволили. Бедняжки? Ничего, они потом резервные копии подняли и быстренько проект продали еще пару раз, конкурентам. Был там среди них индус Амба - его идея. На вырученные деньги он выехал заграницу и открыл там свою компанию, а через год семью к себе забрал. Но не об этом сейчас. И вот работают эти молодые бойцы и их заморский заказчик над проектом день и ночь. А все почему? Да потому что неясно что делать, вернее все думают что ясно, но заказчик-то заморский, и через три месяца получается что ничего не ясно совсем. Что-то сделали, и даже хвалятся - мол в срок успели, Петя даже премию получил и жену повел в ресторан и купил ей книгу. Она любит читать. Тем временем заказчик поглядел поглядел на проект и подумал, что-то ребята перепутали и всех уволил. Дядя Юра спился, а Настя и Коля устроились в другую компанию. Им сразу дали новый проект и они его завалили. А все потому, что думали что ясно им, а заказчик-то заморский снова попался. А Петя наш, пока работал, хорошо с заказчиком подружился. Ну очень он хотел купить себе новый компьютер. Петя не плохой, нет, он уже в первый месяц работы говорил своим напарникам - ребята мы плохо поняли заказчика, но они его не слушали. Умные все были, с многолетним опытом работы и всякими сертификатами. Не слушали, ну и ладно. А натолкнула Петю на мысль его жена, она всегда говорила - Петя! Ты у меня такой умничка!!! И он поверил. Как то раз он захотел стать еще большей умничкой пришел на работу и открыл гугл. Ввел там "как стать еще большей умничкой" и нажал "мне повезет". Гугл отправил его на блог одного бородатого дядьки. Очень похож он был на дворника местного и Петя наш решил прочитать весь блог до конца. Узнал Петя много интересного и на утро проснулся вдвойне умничкой. А как общаться с заказчиком он случайно по радио услышал, когда готовил новое блюдо по рецепту бородатого блогера. Идея была проста как двери. Спросите у заказчика чего ему надо уже сейчас и сделайте это за две недели. И тут Петя расплакался... Он просто лук нарезал. На следующий день Петя поговорил с заказчиком и предложил ему новую идею. Заказчик был старой закалки и не сразу въехал в новую идею. Но жена его была тоже умничка и посоветовала ему попробовать. Он велел Пете собрать команду и начинать. Петя связался с безработными Настей и Колей. Коля вроде работал, кажется, официантом. Нашли дядю Юру и подшили его - вроде держится. Наняли еще тестировщика и пару программистов. Тестировщик был странный, но работу делал свою превосходно. Собрались все они в комнате на совещании и к обеду придумали слово Скрам. После пошли обедать. У Насти заболел живот и ее отпустили домой пораньше. А все остальные собрались над компьютером и ознакомились с тем, что у них было. Написали заморскому заказчику и спросили, что нам тебе сделать в первую неделю? Заказчик ответил. Они сели подумали и нарисовали как это будет выглядеть. Отправили заказчику и он добавил некоторые исправления. Они немного подправили и снова отправили. Заказчик сказал, хорошо. Собрались наши программисты и разобрали что да как будет работать. Рисунок он ведь не говорит о действии. Появились вопросы, ответов на которые не было у них. Написали заказчику. А пока он отвечал начали делать то, что уже понятно. Заказчик ответил, когда освободился. Он со своей женой ехал на пару дней к теще, не знаю какие у них там тещи, но наверное хорошие. Приехал он полон идей и вспомнил что ему предлагал Петя - раз в две недели можно будет добавлять новые новшества. Обрадовался он жутко и открыл свой почтовый ящик, который на gmail.com держал.Посмотрел туда и увидел там пару вопросов от команды. Часть своих идей (или то тещины идеи были? она тоже какой-то бизнес делала, лопухи продавала вроде) рассказал сразу им, а часть оставил на потом (вернее он все им сразу расписал, а программисты уже решили что касается текущей работы, а что потом сделают). Прошло две недели и программисты отправили результат клиенту. Он посмотрел на это и сказал, хорошо. Конечно не все было так как он хотел, а еще, за две недели его кузен попал на банановом бизнесе и больше не надо будет вот той кнопки и этого окна. Ну ладно. Подсчитал заказчик сколько он потерял и успокоился. С индусами больше попадал, да и прошло тут всего две недели. Он написал письмо программистам в котором рассказал про свое новое видение. Программисты расстроились немного, потому что они уже построили долгосрочные планы на бананы, кто-то даже провел анализ всех банановых сайтов в интернете в свое свободное время. Но программисты справились с потрясением, и, от поставки к поставке, научились не ожидать и не гадать, что будет потом. Они перестали писать код на будущее и делали ровно столько, сколько надо было заказчику. Код писался, выкидывался, переписывался, снова выкидывался. А так как реализация была простой, то программистам было просто это делать. Кроме того они узнали про рефаткоринг от бородатого дворника - его сын учился в университете, а там преподавали новые заморские методики. Вот так вот они слушали заказчика, пытались понять что он хочет, делали как поняли, показывали ему результат, а потом снова слушали. В городе, котором они работали было 30 компаний. И большая часть из них работала по другому. Ну и ладно. Главное чтобы заказчик был доволен. А наш заказчик было доволен. И с нетерпением ждал когда пойдут две недели. Иногда он конечно вмешивался посреди, но программисты придумали список простых правил, одно из которых гласило - делать и думать только про то, что было решено в начале, и ничего лишнего. А еще программисты работали по двое за компьютером. Это им снова дворник посоветовал. А сын его выпустился и пришел в компанию Пети и показал еще много всяких интересных штук. Хорошо, что Петя и его команда был легок на подъем. Через год у них работало уже 200 человек. Каждый вел свой личный блог по теме работы и их всех очень уважали в мире айти. И Петя наш компьютер модный купил, и не только себе, но и в школу, в которой учился, и дворнику бородатому и сыну его и преподавателям университета. Конец.

Как перейти от классического программирования к парному?

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

"Тим, прошу прочитать эту статью, как вводный курс в эти дебри :) Статья наверное самая стаящая что я читал по этой теме (всего где-то 20) но длиннная.
http://www.google.com.ua/url?sa=t&sourc ... bRV1GGCn0Q
Если нету времени или же по каким-то другим причинам не удается этого сделать, то ничего не поделать - риллайф.

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

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

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

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

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

А можно пойти дальше и сделать так.
Нас честверо кодеров + пара дизайнеров. Наталка, Тоха, Коля и Я.
Андрей и Сережа ссори что не внес в список - вы очень заняты чтобы решить задачу о программинге парами тривиально.
Ирка и Артур вы сами можете решить как вам взаимодейтвовать, я незнаю как работают дизайнера и возможнно ли применить парную разработку в вашем деле.
Кстати QA: Жека и Винни тоже могут попробовать тестить парой. Но это надо обсудить с ними.
Так вот что касается 4х основных разработчиков: работаем парами. Каждый день формируется одна пара. Например Коля + Наташа утром до обеда работают над задачей Коля а потом после работают над задачей Наташи. Типа: "ты мне я тебе". На следующий день пары меняются. Коля уже может быть с Тохой.

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

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

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

Что касается самого парного программинга, то тут могу предложить только то, что мы успешно опробовали с Тохой.
Роли две: 1. кто непосредственно кодит подзадачу. 2. кто ведет лог подзадач и смотрит за тем что делает первый стараясь не вмешиваться до тех пор, пока все идет пучком.
При выполнении всех подзадач - таск можно сдавать КьюА.
Если какая-то подзадача появляется (баг/фича) - ее тут же заносят в список и продолжают прерванную подзадачу.
Когда кто-то утомляется от его роли или малокомпетентен в данной области, то можно поменяться местами.
При завершении подзадачи она вычеркивается из списка и после возможного совместного перерыва на выполнение поступает следующая подзадача с наивысшим приоритетом.
Список потом можно дать КьюА как контрольный, а можно написать приемочные тесты.
Если ктому-то что-то непонятно то разработка прерывается и устранябтся все разногласия.
Если подзадача занимает много времени, или кто-то начинает зевать - верный знак что пошли не тем путем. Перерывчик и снова в путь.
Самое сложное - не спорить. Спор занимает много времени и скорее всего не приведет к нужному результату. Спорный таск посжно отложить и обсудить на перерыве.

Вроде как все. :) Спасибо что дочитал до конца.

"Одна голова хорошо, а две лучше"
У нас все получится. Если, конечно, мы готовы к экспериментам."

Демо и фидбек по результатам деливери

Удивительно как быстро прошло демо. 20-30 кликов мышкой и все :) А сколько писали его.

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


"Враження в цілому позитивні. Хочу вказати на кілька моментів, що свідчать, що парне програмування все-таки ефективне.

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

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

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

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

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

Особисто я багато дізналась про ейджібі та можливості екліпса. В результаті таск, який я б, навіть із зараз уже здобутими знаннями, робила б напевно тижнів зо три (і не факт. що всі моменти було б враховано), було зроблено за тиждень.

З негативних вражень - то тут тільки фізично зразу важко працювати в такому темпі. Через кілька днів звикла. І трошки психологічно - досить часто відчувала себе як на екзамені - ти щось пишеш і наперед не знаєш як тебе оцінять, відмінність лиш у тому, що оцінюють зразу і виправляють зразу, а отже і помилок робиться менше."


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

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

Спасибо Оля (так зовут напарницу), за такое замечательное деливери.

четверг, 17 декабря 2009 г.

Толковый словарь кодера

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


Кодер - coder - кодировщик, программист

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

Тим - team - команда
Сборище кодеров завязанных на чем-то одном - они кодят вместе.

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

Фича - feature - представлять, характеристика.
Какая-то часть функциональности системы, которую хочет кастомер. "Добавте мне тут розовую кнопочку, чтобы она выводила какой-то списочек" - обычное описание фичи от кастомера.

Таск - task - задача
В результате декомпозиции (разбиения на части) фичи получаются мелкие задачки, время реализации которых не более 4х часов. Вот они называются тасками.

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

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

Багфикс - bug fix - исправление ошибок
Кодер кодит код. Думает что правильно, но КьюА ему доказывают обратное. В результате кодер сидит со списком багов на руках и начинается багфикс. Кастомер не любит баги и не любит багфикс - в єто время кодеры ему не дают новых фичей.

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

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

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

Еще один день в паре: конец деливери и все сделано

Сегодня последний день деливери и доска выглядела так. Красным обведена область New и Developing нашей фичи - там пусто и все таски в зоне Testing и Done. Это значит что мы все сделали!!! Не побоюсь сказать - это одна из лучших деливерей за последний год, точно. Давно так кайфово не заканчивали - пол дня занимались мелким багфиксом, ведь мы успели реализовать весь функционал и даже немного помогли с тасками еще одной напарнице, которая, к сожалению, всю деливери работала в одиночку.

Нас в команде пятеро: я, две девушки, КьюА тестировшик и продактовнер на 1/3 времени - супер команда. Вообще-то в начале деливери я предупреждал команду и продактовнера, что стоит подыскать еще одного командного игрока, чтобы было две пары, но людей нет! Ладно. Местами казалось, что мы ее бросили, хоть и сидели все время на расстоянии 2 метра. Видно было как она скучает и в одиночку справляется со своими тасками. Но я сознательно ничего не сделаю. Чтобы заинтересовать чем-то надо просто этим с удовольствием заниматься, окружающие втянутся. Если оно им надо конечно. Поглядим...

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

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

А завтра сутра будет демо....

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

Вывод есть. Если вы матюкаетесь на чужой код - сделайте доброе дело, а? Приведите код в порядок. И пускай следующий разработчик не скажет "что за чудики писали ЭТО?&!". Когда код привели немного в порядок, то с гордостью дописали в заголовке классов свои имена.

среда, 16 декабря 2009 г.

Еще два дня в паре: 1) мы успеваем 2) мне тоже есть чему учиться 3) как показать эффективность?

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

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

Так же мы выявили, что после обеда, где-то с 15 до 16 (обед у нас заканчивается в 14:30, а скрам дейли проходит в 14:45) продуктивность минимальна за весь день, а ближе к 18:00 она обратно увеличивается. Возможно мозк в это время занимается перевариванием пищи, кто знает? Решили, что в это время будем давать передышку друг другу и расходится по углам комнаты (наши рабочие места находятся в двух диагонально противоположных углах комнаты).

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

Мы успеваем! Это наверное самый классный показатель. Кроме тог омы сегодня еще ускорили разработку в будущем. Что раньше приходилось тестировать, делая деплой на удаленный сервак раз в день, теперь мы можем тестировать на локали - мы исключили узкое место привязанное к тому серваку, в случае, если в базе в таблицы свойств находится запись debug.testing.mode = "on". Естественно все сделано секьюрно, дабы никто посторонний не мог воспользоваться этим для своих целей. Оба довольны, потому как кадый из нас по отдельности хотел это реализовать давно, а решились лишь вдвоем и сделали это за час.

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

Близится конец деливери, а мы уже почти все сделали. В пятницу сутрау нас будет демо с продакт овнером по так называемм "аксепттанс историям", которые были записаны на пленнинге КьюА. Истории были такими "логинимся, видим обычный список. Создаем то-то и в результате в таком-то месте надпись меняется на. Потом жмем ту кнопку, и переодим туда-то. При всем при этом по такому линку видно то-то, но если мы нажмем туда-то то больше этого видеть не будем...." Написано так, что моя покойная бабушка могла бы разобраться. Это мы и проделаем в пятницу утром каждый по своей фиче отдельно. Чисто формально моя напарница отвечает за эту фичу. Но реально отвечаем мы оба. Я сознательно на пленнинге отмалчивался, когда продакт овнер спрашивал "кто отвечает за фичу", потому как понимал, что при нашей стратегии парного программирования отвечать будем мы оба. Кроме того за провтык фичи у нас пока не предусмотрена никакое наказание... Но это пока... Да и что говорить, если мы успеваем в срок.

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

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

понедельник, 14 декабря 2009 г.

Еще один день в паре: 1) Немного отстаем 2) Устали и 3) Необходима дисциплина

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

Для начала напомню, что при планировании я учел так называемый мной "коэффициент преувеличения". Задачи, после декомпозиции, оценивались в Саньках, и, чтобы перевести их в часы, Саньки были домножены на этот коэффициент. По последним статистическим данным 1 СанЁк равен 1.3 часа. Т.е. в среднем я оптимист, и если запланировал 10 часов на выполнение задачи, то обязательно потрачу минимум 13. Так же мы с напарницей прибавили еще 15% к общему времени на издержки парного программирования - потому, что так написано во многих источниках.

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

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

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

Сегодня я меньше вклинивался в работу напарницы. Сидя рядом, когда возникала пауза в ее работе я задавал вопрос "что случилось?". Если же я не понимал что делаю, просил объяснить, что происходит. Часто у самого в работе за штурвалом возникает мысль "О! Блин! А что если так?" и начинаешь ее реализовывать как можно быстрее, забыв про напарника. Это не гуд. Оба должны понимать, что происходит - возможно уставать станем меньше.

Во время долгожданного коммита 2.5 дневной работы, мы проглянули все изменения и прикинули, сколько бы мы потратили на задачу 1) работай мы параллельно 2) работай каждый из нас по отдельности над задачей 3) ну и в паре, и каким был бы качественным результат. Все +/- сходится с теорией!

1) Параллельно мы бы сделали этот же объем работ быстрее, но не намного (где-то на 15-20%). Что касается качества, а подобный опыт уже был у нас раньше, скажу так. Раз в день/два либо я, либо напарница находили бы баги и сообщали друг другу, в связи с чем приходилось бы переписывать начатое или каким-то другим образом выкручиваться. Скорее всего количество багов и моментов недопонимания требований заказчика было бы больше, а выплывали бы они не сразу, а дай Бог, если к концу деливери. Деливери в конце призналась бы незаконченной и в следующей мы бы заканчивали то, что не успели сделать в этой. Сомневаюсь, что код был бы покрыт юнит-тестами так, как он покрыт сейчас - думаю тестов было бы на половину меньше. Архитектура! Т.к. в нашей команде за этот вопрос больше всех отвечаю я, то возможно в следующем деливери пришлось бы иметь дело с приведением кода к общей задумке. Это, хоть и не существенные изменения - но все же, есть большой шанс, что без рефакторинга не обошлось бы. Много времени уходило бы на общение и, в любом случае, в конце деливери мы объединили бы свои усилия чтобы хоть как-то спасти ситуацию. В общем - подобным оптом уже сыт по горло. Посмотрим, что происходит в других случаях.

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

3) Мы сделали это за два с половиной дня. Мы нашли приятную фичу в ИДЕ. Мы продумали совместно множество вариантов. Мы знаем о чем речь, и каждый из нас может полноценно заменить другого в случае чего. Архитектура мало того, что поддерживается - она улучшается. О ней знают двое а не один я. Код тестами покрыт хорошо. Но есть и минусы. УСТАЛОСТЬ и к концу дня хрипота - говорить приходится много - рты у нас не закрываются целый день. А если почему-то слетает процесс парного программирования, то это ведет к хаосу, из которого сложно потом вырулить - ты просто не замечаешь как погружаешься в него. Дисциплина и отдых! Думаю это поможет.

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

суббота, 12 декабря 2009 г.

Дертсерф





Вот по телику только что увидел такое двухколесное чудо. Хочу! :) Кто-то видел нечто подобное?

5 пишем 2 в уме

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

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

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

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

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

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

Вообще, сидите, Шура, и пилите, пока не перепилите. А там говорите, что перепилили.

XP / ТДД линки

Группа ТДД ВКонтакте

Роберт К. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс. Быстрая разработка программ: принципы, примеры, практика
"Роберт Мартин в соавторстве с Джеймсом Ньюкирком и Робертом Коссом предлагает вниманию читателей книгу о различных методиках быстрого (и даже экстремального) программирования. Изложение начинается с обзора основных понятий экстремального программирования и завершается готовыми программами, применяемыми на практике. В каждой главе приведены примеры кода на языках программирования Java и C++.
Книга будет полезной руководителям групп программистов, нацеленных на быструю разработку коммерческих программных проектов, характеризующихся высоким уровнем качества и минимальной себестоимостью."


Классная статья "Экстремальное программирование – реальность и мифы"

"Новые методологии программирования"
, Мартин Фаулер

пятница, 11 декабря 2009 г.

Еще один день в паре: 1) делаем чаще перерывы 2) Incremental Publish Model 3) общение с заказчиком посредством прототипов

Сутра моя напарница предложила сразу делать перерывы почаще, раз в два часа. Я предложил раз в час. Хорошо.

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

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

А еще сегодня мы сделали открытие в вдовем (почему оно открылось смотрим тут). Три года работаю в этом Eclipse с JBoss и только сегодня совершенно случайно нашли одну фичу. Раньше я все время думал что это бага, а оказалось фича. Идея вот в чем. Чтобы протестировать изменения в Model нужно его собрать и задеплоить в JBoss (он собирается в отдельный ear файл, отдельно собирается и View+Controller). Передеплой раньше занимал не больше минуты, но вот случилось нечто, после чего приходилось с каждым деплоем Model перезапускать весь JBoss сервер, а это уже до 3х минут. Какой тут нафиг ТДД? 3 минуты на одну итерацию это через чур. Приходилось ухищряться и уходить от рекомендаций Кент Бека не более одного теста за итерацию: пока идет перезапуск JBoss пишешь второй тест или сразу зо 5 однотипных тестов а потом реализация... В общем немного не карашо получалось.

И вот сегодня на очередной эстафете Красный-Зеленый-Рефакторинг случилось чудо. Запускаю новенький тест - он как полагается крассный. Супер! Делаю изменение в Model и сохраняю. Не знаю какой черт меня дернул запустить тест, но я его запустил без передеплоя этого самого, измененного Model. Тест прошел. Что??!! Как??!! Подсознание сразу запело песенку, тралала, тралала, тралала... Чувствую что случилось что-то супер классное, но сознание говорит - неее, это бага какая-та не ведись. Но нет. Я написал на месте исправления throw new RuntimeException("YAHOO!!!"); и сохранил. Нервно двинулся к тесту и .... Он слетел! под красной полоской красовалось "java.lang.RuntimeException: YAHOO!!!". Кайфота.

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

Банальный подсчет, сколько это знание сэкономит компании денег: на каждых 10 разработчиков, интенсивно работающих с Model и перезапускающих JBoss по 5 раз в день каждый день, тратя при этом две минуты, при этом хоть и занимающихся другими делами (перерыв, чтение почты или изучения сети) но по фату простаивающих по две минуты на перезапуск, в месяц происходит экономия 208 баксов (при средней зарплате 1000 баксов в тот же месяц).

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

Забыл самое главное сказать - эта фича начинает работать, когда в Eclipse включен удаленный отладчик для этого JBoss. Вот как его настроить:

Меню Run-Olen Debug Dialog... В диалоге на Remote Java Application нажимаем правой кнопкой мыши и выбираем из контекстного меню New. Справа в диалоге заполняем все поля и жмем Apply. После чего при запущенном JBoss в этом же диалоге нажимаем Debug и наслаждаемся. Вот как выглядит это окошко. Единственное что мне потребовалось изменить в настройках по умолчанию - это порт с 8000 на 8787.




А еще уточняли сегодня как будет выглядеть новая фича. Пользуемся для общения багтрекинг тулзой используя English. Сдовами всего не передать, потому открывается PBrush делается скриншот приложения и путем простых манипуляций дорисовывается до существующего функционала то, что понял из описания новой фичи заказчиком. Далее отправляем ему результат и ждем. И так пару раз, пока заказчик не скажет "Ok :)". Нарисовать в PBrush в 1000 раз быстрее чем реализовать фичу.

Сегодня день, точно зря не прошел. A что касается нашей 6-дневной эстафеты - все идет по плану.

Сейчас иду с другом учиться играть в покер. Пятницо пришел.

четверг, 10 декабря 2009 г.

Если твоего имени нет в гугле...

...значит тебя нет :) Как сказал мистер Фримен - "тебя еще не нарисовали".

Социализируемся!

В гугле меня можно найти используя словосочетание "СанЁк Баглай".

Принцип Питера

Случайно нарвался на интересный абзацик в Википедии.
"Питер утверждает, что для сотрудника, достигшего уровня некомпетентности, характерен специфический набор особенностей поведения, названный «Синдромом конечной остановки». Причиной появления этого синдрома является то, что сотрудник обычно осознаёт или хотя бы подсознательно чувствует свою некомпетентность. Для поддержания позитивной самооценки он пытается создать, причём не столько даже для окружающих, сколько для себя самого, хотя бы видимость компетентности, подменяя результативную работу какой-либо другой, активной, внешне легко заметной деятельностью. Одним из признаков синдрома конечной остановки является склонность к формализации работы, постоянное изобретение бюрократических правил, требование от подчинённых точнейшего их соблюдения, даже вопреки объективной целесообразности. Синдром, по мнению Питера, является причиной ухудшения здоровья, возникновения и обострения хронических заболеваний, развивающихся на нервной почве. Единственное действенное средство борьбы с синдромом конечной остановки — изменение жизненных приоритетов и перенос притязаний в ту область деятельности, где уровень некомпетентности ещё не достигнут (радикальная смена работы, «уход с головой» в хобби)." Википедия

Это приходится наблюдать вокруг очень часто - каждый Божий день.

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

Сутра вот подумал

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

А вот и видео. Тут первоисточник - там есть еще парочку демотиваторов...



И оправдать такое большое количество редко когда получается. Что завтра утром скажу себе?

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

А еще сейчас прочитаю много интересного про раскрутку сайтов, рейтинги и заработок в интернете.... Мммм вкуснятина... Завтра будет не стыдно за очередную кучу!

С коучингом как-то не вышло :) зато уже неделю в паре

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

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

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

Сегодня сутра разместили задачи в этом 6-дневном отсеке и определили 6 дедлайнов. После очистили все со стола и достали другой листочек, на котором расписали две основные задачи на сегодня более подробно и приступили.

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

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

Поглядим, что будет завтра. Давно я не получал от работы ТАКОЙ кайф...

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

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

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

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

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

Всем удачи, и нашей паре тоже. Завтра много работы.