День 71. Переговоры, переговоры и еще раз переговоры

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

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

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

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

Всем  доброй ночи. 

День 70. Deadline и 50 отжиманий

Прошло 2 трети срока. Сегодня закрыл 2 промежуточных цели.

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

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

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

Ну и вторая достигнутая цель - 50 отжиманий. Теперь нужно сделать самое сложное, нужно поддерживать этот уровень. Я занимаюсь 3 раза в неделю, значит на последнем занятии должен снова отжатся 50 раз минимум.

Всем доброй ночи. 

День 66. Расширение модели и книги для развития

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

Собственно хочу озвучить еще одну цель поставленную себе на предновогодние 100 дней. Это полезное чтиво для развития. Всего 5 книг:

• Deadline. Роман об управлении проектами
• Человеческий фактор. Успешные команды и проекты
• Путь менеджера. От новичка до гуру
• Вальсируя с медведями. Управление рисками на проекте
• Жизнь на полной мощности

На сегодня я осилил ровно половину из задуманного. Застрял на "Deadline". Прочитал более простую и популистскую половину книг - "Жизнь на полной мощности" и "Путь менеджера". Книги честно говоря так себе, я не оценил. Читаются быстро но и при этом остаток небольшой.

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

З.Ы. По спортивной цели сегодня началась последняя неделя. Отжался 45 раз, еще 5. Главное, что мозг при этом разгружается и появляются новые идеи.

Всем доброй ночи. 

Memory Managment Framework. Постановка задачи

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

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

1. Что бы дало наличие такой библиотеки
2. Какие возможные неудобства и ограничения она бы принесла
3. Какие требования могут быть к такой библиотеке

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

• Различные виды аллокаторов памяти. Если вы до сих пор работали с памятью в стиле ПК (т.е. используя стандартные операторы new/delete), то обязательно найдите кого-то, кто работал на консолях и расспросите его. Многие SDK для консолей уже содержат реализации нескольких видов аллокаторов, которые часто работают эффективнее стандартного. 
• Дальше такая библиотека дала бы больше возможностей для контроля и отладки расхода памяти: создание дампов, проверка ликов, запись логов и возможность получать карту памяти приложения в любой момент времени и т.д. 
• Намного более жесткий контроль за выделением памяти. Для многих программистов это является хорошей школой, особенно в наш век Java и C#. Слишком многие свысока относятся к гигабайтам свистящим у виска. Такой контроль позволит установить константный объем памяти, которая будет необходима вашему приложению. 

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

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

• Скорее всего придется отказаться от стандартных операторов new/delete, а ново введенные не будут обладать той же лаконичностью и красотой.
• Возможно придется определять работу с памятью для каждого класса, т.е. переопределять операторы new/delete для каждого класса.
• Вам понадобится затратить время на обучение всей команды новым правилам работы с памятью. Причем нужно будет донести не только новый синтаксис, но и понимание новых принципов выделения и освобождения памяти. Иначе счастья не будет. 
• Могут возникнуть проблемы со сторонними библиотеками и фреймворками. Особенно, если у вас нет их исходников.

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

• Надежность - любыми способами необходимо гарантировать, что функционал библиотеки под любыми нагрузками будет работать только так, как задумано и описано в документации.
• Скорость - скорость работы для стандартного аллокатора в релизе должна быть как минимум такой же, как и у стандартной реализации операторов new/delete. 
• Многопоточность - библиотека должна работать из нескольких потоков. На самом деле это очень интересный момент, с кучей своих кейсов и ньюансов. 
• Низкая точка старта - по умолчанию библиотека должна работать как стандартные операторы new/delete и не требовать сложной настройки. Естественно все инструменты также должны подхватываться сразу, а не после недели танцев с бубнами.

Прикольные:

• Кроссплатформенность - большая часть кода библиотеки платформонезависима. Но есть несколько точек, где не избежать взаимодействия с конкретной системой: захват памяти у системы и ее освобождение. Также некоторые платформы имеют несколько типов памяти и могут по-разному с ними работать. 
• Интеграция с популярными IDE - тут опять подключаем фантазию. Можно представить красивые графики в VisualStudio или Eclipse.

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

• А есть ли уже готовые решения данной задачи (после 15 минут в гугле почти ничего не нашел)?
• Как работают стандартные реализации операторов new/delete?
• Какие решения сделаны в рамках различных игровых движков (OGRE, Torque, Unreal, CryEngine и т.д.)?
• Насколько сложно самому реализовать текую библиотеку и зачем оно мне нужно?

Если можете поделиться информацией буду премного благодарен.
Всем доброй ночи

Perforce: edit, add, delete в командной строке

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

1. Удаление локальной версии;
2. Копирование на ее место новой, только собранной версии клиента;
3. Добавление на чекаут измененных файлов;
4. Добавление новых файлов;
5. Коммит изменений на сервер.

      Как видим удаления нет. Некоторое время это было не критично, но вот пришлось править.
      Недолго думая я решил, что после чекаута измененных файлов необходимо вставить код, который будет удалять в депоте файлы, отсутствующие локально. Вроде все просто. Добавил команду, между 3 и 4 шагами, и... обломался. Не было удалено ни одного файла, хотя пару кандидатов на примете у меня было.
      Причина оказалась банальна. На 3 шаге был вот такой вот код:
   
            p4 edit \\depot\client\...
            p4 revert -a -c
       
      Т.е. сначала на редактирование брались тупо все файлы, а потом делался реверт тех файлов, которые не были изменены. Особенность perforce (да наверное и любой другой системы контроля версий ) такова, что при реверте локальный файл восстанавливается. Другими словами, даже если в сборке и не хватало файлов, то после этой команды они восстанавливались из депота и мой шаг по удалению ничего не находил.
      Вот эту штуку и пришлось править. В perforce есть хорошая команда, которая позволяет отобрать уже только измененные файлы и взять на редактирование только их. Она же позволяет находить файлы, которые нужно удалить в депоте.
      После небольшой правки скипт стал выглядеть примерно так:

            echo "DELETE MISSED FILES"
            p4 diff -sd \\depot\client\... | p4 -x - delete
         
            echo "CHECKOUT CHANGED FILES"
            p4 diff -se \\depot\client\... | p4 -x - edit
         
            echo "ADD NEW FILES IN PERFORCE"
            cd /d D:/p4/client
            dir /b /s /a-d | p4  -x - add -f

      Все просто и наглядно.
      Ну а потом делаем коммит на сервер. Референс на все команды perforce можно глянуть тут: http://www.perforce.com/perforce/doc.current/manuals/cmdref/index.html
      Всем доброй ночи.

Анализ дня: недостаток perforce, мобильная разработка на Unity

    Всем привет.
    Сегодня снова две темы дня. И более практических, чем обычно.
    Начнем с Perforce. С этом системой я проработал больше 3-х лет и, за все время, особых нареканий у меня не было. Хотя периодически были проблемы. Так сложилось, что последний год я просидел на паре Svn, Mercurial и только месяц назад пришел на проект, где используется Perforce. База на проекте уже огромная - под сотню гигабайт. Файлы самые разные по размерам, от нескольких байт до пары гигабайт. Самое главное, что их много, очень много. Думаю за полмиллиона уже перевалили.
     Оказалось, что Perforce справляется с таким репозитарием очень туго. Тормозит, появляются ошибки. Например файл регистрируется в базе, но на сервер не попадает. И все, кто пытается обновится, получают предупреждение о том, что файл отсутствует.
     На фоне данной проблемы и вылез, как мне кажется, главный недостаток Perforce по сравнению с остальными системами - Perforce требует подключения к серверу и ответа от сервера для выполнения любой команды. Абсолютно любой.
     Во время работы программист наиболее часто выполняет 3 операции: обновление с сервера, коммит на сервер и чекаут файла. Так вот, если у вас тормозит сервер, то вы можете обновляться и коммитить файлы, пусть и со скрипом. Это не такие частые операции, пару раз в день, а у кого-то и реже. Но вот чекаут файла это жизненно необходимая операция, без нее работать чуть хуже чем никак. SVN берет эту заботу на себя и не требует подключения к серверу, Git и Mercurial вообще не требуют сервера, а вот Perforce требует ответа от сервера.
     Итог грустен: невозможность взять файл на чекаут тупо блокирует работу, срывает настрой и вдохновение.

     Вторая тема более жизнерадостная. Как я уже писал, Unity раздает лицензии на мобильные платформы бесплатно. Я воспользовался возможностью и получил свою лицензию. На выходных начал писать аж две программки для Android. Первая это порт игры Smash Aliens (линк на youtube), а вторая - это программа для тренировок, я назвал ее TrainerBoo.
     В данном случае, можно воспользоваться одним из плюсов Unity и погонять оба моих не доделанных приложения через браузер. Вот Aliens, а вот TrainerBoo.
     Собственно меня теперь волнуют два вопроса:

1. Размер финального приложения - apk файл для Aliens занимает больше 10MB, а для TrainerBoo - больше 6MB (там вообще нет моих ресурсов, только Unity) 
2. Производительность на Unity

     По ходу развития проектов поделюсь тем как ведет себя Unity.

     Всем доброй ночи. 

Kata - ежедневная мантра программиста

    Привет всем.
    Сегодня я хотел поговорить об одном приеме настроя на работу, с которым познакомился во время тренинга по ТДД.
    Я снова взялся за преподавание и неделю назад стартовали занятия в группе по программированию на С++. Еще при работе с предыдущими группами я пришел к выводу, что для начинающих программистов очень полезно писать код, поменьше учить разные паттерны и побольше практиковаться. Писать, отлаживать, снова писать. Со стартом группы я задумался над тем какое-же придумать им мучение упражнение, чтобы они писали код каждый день. Вот и вспомнил об упражнении Ката TDD.
    Что такое ката можно глянуть в вики. Вкратце это просто некий набор движений в боевых искусствах. Изучение на базе ката сводится к повторению этих движений многие тысячи раз.
    Так и здесь. Ката TDD - это задание написать StringCalculator. Выполнять его нужно в начале каждого рабочего дня. Затрачивать на ката от 15 до 30 минут, не более. Задание идет итерациями, добавляя все новые возможности в StringCalculator и здесь важно соблюдать эти итерации. Т.е. даже если вы знаете как написать самый общий код на все случаи жизни, все равно необходимо идти по шагам постепенно наращивая функционал и рефакторя код.
     Учить студентов TDD, естественно я не собираюсь, поэтому не буду и требовать написания кода в стиле TDD. Но даже само по себе это упражнение думаю будет очень полезно.
     Для тех же зубров, которые могут выполнить ката за полчаса, и, кому становиться скучно писать каждый день одно и то же, я могу предложить путь развития ката, который использует сам ее автор. Нужно ставить себе ограничители и дополнительные условия на выполнение. Например: написать ее без использования стандартных библиотек, или с использованием специфических библиотек, написать ее на языке, который хочется выучить, написать ее без использования циклов и т.д. и т.п.
     Чтобы было по-честному я вместе со студентами буду выполнять ката каждый день. Сегодня успел за полчаса сделать только до пункта 3.1. Позор на мою голову.
     На этом пожалуй все.
     Всем доброй ночи.

Анализ дня: книга Continuous Delivery

    Всем привет. После краткосрочного прогула я снова на связи.
    Пару недель назад купил книгу "Непрерывное развертывание" (Continuous Delivery на английском). Времени на чтение от корки до корки так и не нашел, пока прочитал только первую главу. Чтобы все-таки отбить деньги выложенные за книгу, решил немного по-другому к ней подойти. А именно, выписать сначала конкретные вопросы, на которые хочу найти ответы. Ну а после уже читать только те части, которые могут помочь получить ответы. Вопросов смог сформулировать 2 и третий на подходе:

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

    Раньше у меня не было проектов с таким диким количеством конфигов. Конфиги клиента, сервера (у каждого разработчика свой сервер), конфиги инструментов и т.д. В результате все это либо висит на чекауте в ченджлисте с именем "don't commit", либо правится локально после снятия флаг read only. Естественно такой подход приводит к тому, что либо конфиг забывают залить когда нужно, либо наоборот заливают когда не нужно. Изысканиями и результатами поделюсь. 

    Кстати а как вы храните конфиги и работаете с ними? 

Анализ дня: С++ и python

    Всем привет.
    Для начала немного рутинной отчетности. День прошел вполне успешно, основная задача на день была реализована.
    Теперь собственно переходим к наиболее интересному. Меня перекинули на новый проект где-то недели три назад, проект очень большой и идет уже больше года. По объективным причинам (т.е. из-за собственной лени и изворотливости) я еще не занимался программированием на проекте. Было больше задач на ресерч, менеджмент и администрирование. А вот сегодня после обеда уперся в то, что нужно садится програмить, причем на Python. Изучить новый язык не проблема. Добыл книгу Марка Лутца "Программирование на Python" и завтра же начну грызть гранит науки.
    Немного смутило меня другое. Несмотря на то, что мой блог называется "Native language C++" я перестал писать на С++ примерно в то время, когда блог был создан. Парадокс. Я помню год назад даже задумался о том, чтобы сменить название. Сейчас я еще раз пришел к той же мысли что и год назад. Не раз озвучивал уже эту идею своим студентам и просто хочу еще раз записать и проговорить ее для себя.
    Я благодарен моей программистской звезде, за то, что начал программировать именно с С++. За все время работы я стал в некоем роде универсалом. Приходилось писать проекты на C#, Java, Perl, Lua, English. Но именно основу полученную во время кодинга на  С++ я считаю залогом достаточного легкого переключения на любой язык и своего поступательного движения вперед.
    С++ действительно стал моим родным языком. Пусть я не пишу и не говорю на нем, но думаю я по прежнему на С++ и он меня еще ни разу не подвел.
    А что вы считаете залогом вашего продвижения, ваших профессиональных успехов?

    Пожалуй на этом хватит. Всем доброй ночи.

Анализ дня: мы все-таки сделали это, новые темы для статей

    Начнем с шаблонных фраз. Всех с прошедшим праздником весны. Лично я очень ждал ее прихода, капризная зима как-то не радовала в этом году.
    А теперь можно спокойно продолжать. Сегодня был замечательный день на работе. Мы отправили первый патч для нашей игры, победив всю ту магию, которая обычно проявляется в законе Мерфи. Заодно я составил диаграмму и план в Jira, которые, очень надеюсь, позволят нам избежать подобной магии в следующий раз. Осталось дело за малым - написать и отладить код. Задача сегодняшнего дня выполнена в полной мере.  
    Также заметил, что более частое написание статей и их обдумывание открывает путь и для новых тем. Казалось бы, что все должно быть наоборот, а нет. Вот и пришло в голову две темы, раскрыть которые будет полезно. И мне, чтобы обдумать их более глубоко, и надеюсь тем, кто решится все-таки прочитать эти писульки.
    Первая тема - это собственно описание нашей идеи с реализацией Continuous Delivery. Правда, если я все-же решусь написать, то будет это через неделю-другую. Утром код - вечером статья, как говориться.
    Ну а вторая тема касается mercurial. У меня появился опыт использования данной системы на реальном проекте, а не в домашних условиях. Вот можно и поделиться.
   
    На сегодня все. Ага, напоследок еще одна новость. Порадовали разработчики Unity. Они раздают бесплатно лицензии на Android и iOS версии. Я себе уже получил. Сделать это можно на их официальном сайте unity3d.com

    Всем доброй ночи

Анализ дня: парный дизайн

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

    День как специально выдался в лучших традициях релизного дня: постоянные отвлечения, срочные вопросы и прочее. Т.е. часам к 4-м я понял, что начинаю пролетать со своей задачей дня. Опять ничего не сделаю. 

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

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

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

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

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

    Всем доброй ночи.

Анализ дня: задача дня, бранчи и снова бранчи

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

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

    Вторая тема более практична.
    На проекте, как и у всех, у нас есть транк (основная ветка) и бранчи, созданные по разным причинам. Один из этих бранчей называется stable. Работа строится следующим образом: две недели набиваются фичи в транк, после чего готовые вещи интегрируются в ветку stable и мы еще неделю тратим на стабилизацию данной ветки. После стабилизации собирается клиентский билд и прямо из ветки идет обновление сервера.
    Естественно скрипт обновления сервера работает по head ревизии и естественно, если кто-то во время стабилизации stable случайно дернет этот скрипт, то всем поплохеет.
    Собственно, чтобы обезопасить себя, неделю назад добавили ветку stable_candidate. Расчет прост - стабилизация билда идет в новой ветке, а потом по готовности все это интегрируется в stable. Но не все идет так как хочется. После недели терзаний и мыканий поняли, что все равно остается открытым два критичных вопроса:

1. То что стабилизировали stable_candidate, не гарантирует что stable будет рабочим после интеграции
2. Некоторые фичи и процессы просто невозможно протестировать в stable_candidate. Соответственно возвращаемся к исходной проблеме - stable ветка какое-то время все равно будет в неопределенном состоянии

    Решение пришло одновременно двоим и оно до банальности простое. Новый бранч нужно делать не до стабилизации, а после.

    Всем доброй ночи

Анализ дня: цели и условия Continuous Delivery, "аутсорсовый" подход

    Всем привет.
    Продолжаю издеваться над собой.
    Ковыряясь все над тем же CD (Continuous Delivery) ушел немного в сторону философии. Какова цель CD, в чем она выражается и как измеряется. Вроде все просто. Цель - обеспечить бесперебойную и быструю поставку фичей из головы геймдизайнера непосредственно на компьютер рядового игрока. Но если моя фича попадает раз в три недели это достаточная скорость? Или раз в год? Сроков то не оговорено.
    Идем дальше. Условия для достижения данной цели я смог придумать два:

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

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

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

    Придется убаюкивать завтра диаграммами и тоннами кода. 

    На этом мой философский выпуск завершен, пошел практиковать. 

   

    Доброй всем ночи.

Анализ дня: TeamCity, встроенные скрипты

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

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

    Вот такие вот грабли.

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

    Всем доброй ночи.

Анализ дня: делай сразу, GO и Artifactory

    Весна как известно время перемен. Вот и я сегодня в честь первого дня весны решил попробовать новую для себя штуку.
    Замечаю за собой нежелание подводить итоги недели, просто анализировать прошедший день. Поэтому решил поставить эксперимент. Каждый вечер буду писать о тех новых вещах, которые узнал за день. Ну а, если ничего не узнал, значит так и пишем, а потом ставим в уме минус, пожирнее.
    Вчера слушал интервью Радислава Гандапаса и он сказал, что одной из его сильных сторон является привычка делать все сразу. Не разводить сомнения, не продумывать мега хитрые планы,  а просто действовать ибо "опыт дороже знаний". Попробовал сегодня проследить за собой. Остался недоволен. Даже на протяжении одного дня было много моментов, когда тупил, ленился, и придумывал чтобы такое сотворить, чтобы ничего не делать.
    Уже в конце дня решил прочитать-просмотреть статью о Continuous Delivery, которая висела у меня в браузере несколько дней. Глаза выхватили две тулзы, требующие более пристального внимания. Это GO - сервер для continuous integration от ThoughtWorks Studios и Artifactory от JFrog. По идее Artifactory позволяет сохранять все артефакты билд системы и потом предоставлять к ним доступ всем желающим. Поскольку я сам сейчас активно занимаюсь настройкой continuous delivery то тулзы эти нужно будет рассмотреть более пристально. Кстати сама статья вот: http://java.dzone.com/articles/continuous-delivery-using Тоже рекомендую ознакомится.
    На сегодня все.
    Всем доброй ночи.

Учимся читать заново

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

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

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

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

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

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

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

Всем доброй ночи.