Поймал У в ситуации вроде бы уже изученной досконально - спасибо Алексею Пахунову за обучение (blog.not-a-kernel-guy.com/2016/05/20/1826). Дано: обычный коммит и нужно его откатить. Но ведь откат коммита - это тоже коммит, а, значит, можно потом при нужде сделать откат отката и восстановить оригинальный коммит. Это ведь такой простор для маневра даёт...

Сильно напомнило ощущения от ответа Торвальдса о понимании указателей с расшифровкой (http://grisha.org/blog/2013/04/02/linus-on-understanding-pointers/).

отзыв о "Scrum and XP from the tranches"

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

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

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

Т.е. вместо фразы "надо делать так", читатель получает "надо делать так, потому что", "а ещё можно вот так" и "в целом так вроде бы и надо по стандарту, но не рекомендую, потому что"

Стоит так же отметить, что данная книга сосредоточена на тех вещах, которые изначально закладывались в него Джефом Сазерлендом, а не на вещах которые привносились в него евангелистами от IT. Т.е. книга фокусируется не на процессах Скрама, которые делают его инженерным фреймворком, а на процессах, которые делают его организационным фреймворком. Т.е. на процессах планирования и ретроспективы, сбора требования и наличия готового продукта, а также на коммуникации. А ведь именно эти процессы и позволяют использовать Scrum как в организациях(скрам скрамов), так и личной жизни(вот пример с адаптацией Скрама для управления временем http://s-kalinin.blogspot.com/2015/10/scrum.html)

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

В целом книга является must-read для тех кто думает о внедрении, внедряет или уже внедрил Scrum на проекте или в компании как опорная книга и пинок для ретроспективы накопленого опыта.

P.S.

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

P.P.S.

Электронная версия доступна бесплатно www.infoq.com/minibooks/scrum-xp-from-the-trenches-2. На русский переведена только старая редакция :(

книга API design for C++

Прочитал в августе API design for C++ by Martin Reddy, книгу которая оставила после себя странное впечатление. Осмысление этого впечатления заставило отложить написание отзыва на 2 месяца.

У книги есть как явные плюсы: например то, что автор опирается на свой опыт работы в различных проекта, так и явные минусы: например то, что книга была написана перед выходом стандарта C++11, слабо учитывает новые решения, которые появились с этим стандартом и судя по всему не получит новой редакции, которая адаптирует её к новым стандартам C++11 и C++14.

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

Глава 1 является чисто вводной и объясняет что такое API, какая специфика его в C++, чем мы платим и за что. Содержит довольно большое количество "воды", но основные моменты выписано чётко, что очень радует.

Глава 2: Качества. Тут автор описывает качества хорошего API почти не останавливаясь на специфике для C++. Встречал я и более краткие и более смысло-плотные раскрытия этой темы, а потому эта глава выглядит больше как дань научной степени полученной автором в своё время. По крайней мере, шаблон подачи материала классический для диссертационной работы и "воды" опять же много...

Глава 3: Паттерны проектирования. А вот эта глава от воды по сути избавлена. Разбираются только шаблоны, которые активно используются в API, и рассматриваются только специфика их C++ применения. Т.е. pimpl, singleton, factory, proxy, и т.п. При этом каждый паттерн разбирается со всех сторон - что получаем, чем платим, возможные варианты применения и альтернативные решения. Для меня эта глава стала основной ценностью этой книги.

Глава 4: Архитектура. Мартин Редди пересказывает принципы проектирования архитектуры программных систем. При чём эти принципы не являются специфичными для C++ или для API design. Странная глава, которая так и не позволила понять зачем она в этой книге... 

Глава 5: Стили. Короткая глава, которая вводит класификацию API и предлагает некоторые неочевидные варианты. По хорошему должна быть в первой тройке глав.

Глава 6: Использование C++ и Глава 7: Производительность. Комбинация style guide'ов и знаний, которыми человек, который взялся за проектирование C++ API уже должен обладать. Главы ни о чем и полезны разве что списком утилит, которые можно использовать для анализа производительности.

Глава 8: Версионирование. А вот эта вот глава довольна неплохая, хотя и содержит сколько-то воды. Раскрывает подходы к построению версий, выделению веток и рассматривает процесс разработки API в течении длительного периода времени, т.е. не только на этапе новой разработки, но и на этапе maintenance. В целом она является одной из опорных глав этой книги.

Глава 9: Документация. Смысл в главе есть, но зачем так много примеров и воды?!

Глава 10: Тестирование. Довольно неплохая глава, которая даёт представление об основных фреймворках, подходах в тестировании API, ограничениях налагаемых языком и методами их обхода. Заодно объясняет зачем это делать надо и даёт обзор связанных областей(coverage, continuous build, bug tracking etc)

Глава 11: Скриптование. Интересная глава, которая внятно объясняет зачем нам поддержка других языков в C++ API, чем мы за это платим, как это получить в C++ различными методами и какие преграды есть на этом пути и способы их обхода.

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

Если свести все впечатления воедино, то:

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

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

Целиком эту книгу я бы не рекомендовал никому, разве что избранные главы...

Забавные пересечения анализа организаций и теорий командного взаимодействия

Прохожу сейчас в неторопливом ритме курс "Организационный анализ" на coursera.
Постоянно замечаю пересечения между материалом курса и различными теориями командного взаимодействия.

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

Интересно, что будет дальше... :)

О частоте релизов

После прочтения continuous integration, delivery и иже с ними выкристаллизировалось:

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

Хотя выстроить процедуру частых релизов - это все ещё искусство... ;)

Stroustrup и 16 способов положить кота в стек

Прочитал статью Страуструпа о стеках и кошках: 

http://isocpp.org/blog/2014/03/sixteen-ways

Казалось бы, написана она ещё в 1990 - что нового можно в ней почерпнуть?.. 

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

Но, при внимательном прочтении, начинаешь замечать мелочи, которые играют важную роль. Для меня такой мелочью стал внутренний класс stack_id: 

class stack
{
public:
    class id
    {
        friend stack;
    private:
        int i;
    };
    ...
}; 

Казалось бы мелочь, а ведь сколько проблем доставляли мне в свое время типы идентификаторов, определённые через typedef базовых типов... 

А тут:

• раз, и логическая привязка к основному классу;  
• два, и неприводимость к базовому типу(int/string/etc); 
• три, и неизменяемость его наружными классами, а только передача между различными функциями.  

Красиво же!  

Пара мыслей о Канбане

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

Забавно, что поход с пареньком Херби из "Цели" Голдрата можно рассматривать как пример Канбана, потому что остальные дети вытягивали только то, что он проходил. А вот ситуация со станком "Херби" уже не может быть рассмотрена как подобный пример, потому что ресурсы не вытягивались к станку по мере необходимости, а выталкивались на основании прогнозов о том, когда они ему понадобятся. Но "цель" и "дао тойота" пересекаются очень интересно...

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

Adrenaline Junkies and Template Zombies - отзыв

Если кратко, то эта книга описывает различные шаблонные состояния внутри команды, либо внутри проекта, когда идёт взаимодействия команд, либо даже внутри компании, которая выполняет этот проект.
По мере прочтения узнавал кучу ситуаций, с которыми уже сталкивался в процессе работы. И книга с точки зрения описания ситуаций очень хороша. Но вместе с тем у неё есть 2 недосказаности, которые вместе не дают внести её для себя в список "рекомендовано к прочтению".
Первая недосказаность - это отсутствие "способов лечения" ситуаций. Но учитывая, что все команды разные, то расписывание всех вариантов лечения в каждом случае, увеличило бы размер книги в лучшем случае в 3 раза. Так что это скорее не недостаток, а мелкая придирка с моей стороны.
Вторая недосказаность - это отсутствие описания последствий: "А что будет, если мы не будем это лечить?" Ведь не у всех же такой опыт как у членов "The Atlantic Systems Guild", и вполне возможно что при анализе последствий будет что-то упущено. Или же с точки зрения выгоды для себя и для людей, условному мне будет выгодно засушить ситуацию, чтобы она пришла к ожидаемому условно негативному варианту... И вот отсутствие этого анализа даёт послевкусие неокончености книги. Как, если бы из дипломного проекта на защите было доступно только введение.
Честно говоря, было странно читать такую "незаконченную" книгу от авторов Deadline и Peopleware. Итого - хорошая, но необязательная к чтению книга.

Упрощенное GTD

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

Делюсь своей наработкой для отслеживания задач.
У неё есть определённая специфика - ориентирована только на рабочие задачи. Я не хотел видеть в списке рабочих задач личную жизнь(мухи отдельно, котлеты отдельно).

IT-People Pecha-Kucha: первые впечатления

Впечатления от IT-People Pecha-Kucha, прошедшем 1-го декабря.
Disclaimer: это не анализ, это впечатления по быстрому... ;)  

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

Собственно сами впечатления:
Выступление Дмитрия Миндра. Само по себе выступление было неплохим для вводного, но выбор темы был просто непонятен - в кафе и так собрались люди, которые не "сидят на попе ровно" (с)Панкратов. Так что идея о необходимости убеждать пришедших, что стоит вкладываться в самообразование, networking и делать работу качественно, - вызывает сомнения.
«Роль менеджера в гибкой разработке» - внятные впечатления просто не формулируются... Аджайл всегда такой аджайл...
Тим Евграшин и Сергей Бережной - просто качественные презентации. Правда понимание того, что стоит за этим "просто" и "качественно" заставляет снять шляпу перед авторами - хоть сейчас утаскивай это "просто и качественно" как опорный конспект для действий.
Презентация BABOK - прикольный анонс киевской группы BA, сделано весело и так чтобы привлечь внимание, но это пока не в области моих интересов.
Был человек, которому микрофон мешал выступать :) Очень зажигательно, очень быстро - впечатление как от китайской пиротехники: Вспышки, взрывы...Трах-бах! Бздыщ!! Но в конце вопрос: "что ЭТО было??!!" Может поэтому и не запомнил как его зовут?
"Просто и качественно" можно сказать и о Квантоновом скачке Панкратова, но от него ожидал подспудно большего.
Вика Придатко с "Техническим интервью с человеческим лицом" и выступление Орлова - лучшие для меня презентации на этой PechKucha и новый пункт в моё must view для TL или ПМ.

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

Update:
Андрей Анпилогов начал выкладывать записи с мероприятия на youtube

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