MBP 2016, 15" with TouchBar, заметки на полях.

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

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

Где-то зимой этого года мой старый MacBook Pro 15" стал чувствовать себя не очень хорошо:  у него раздуло аккумулятор, а после традиционного для меня варварского вскрытия,  и извлечения этого самого аккумулятора, оказалось что без батарейки он как-то протормаживает. Не знаю с чем связано, может опечален.  Хотя в принципе он верой и правдой прослужил чуть более трех лет,  посему не особо жалко.  Кстати, насколько я помню, у самого первого моего мака через те же три года случилась такая же проблема с аккумулятором - даже интересно, может я что-то делаю не так. Преимущественно ноутбуки у меня воткнуты в розетку, полных циклов заряда/разряда, если верить счетчикам, обычно даже меньше сотни набегает за три года, может быть это само по себе не очень хорошо. Ну там MacBook осознает что он может работать на батарейке как минимум пол рабочего дня, а то и весь день, а тут его все время кормят энергией. И в итоге этот незадействованный потенциал перерастает в глубокую депрессию, он начинает жрать как не в себя, и его раздувает. Совсем как у людей.

Так или иначе встала проблема покупки нового мака,  и поскольку за пару месяцев до этого линейка MacBook Pro существенно обновилась, то... выбор был очевиден. Вернее по сути выбора не особо было:  либо 13" с TouchBar, либо 15" c TouchBar.  13" без TouchBar - какой-то уж слишком слабый, 15" в старом корпусе - тоже не "bleeding edge" вроде как.  Выбор между тачбаровыми 13" и 15" тоже не то чтобы есть: в идеале меня бы устроила старшая 15" модель в 13" корпусе, можно без второй видеокарты - мне от нее  ни холодно, ни жарко.  Совсем в идеале, хотелось бы 32 или даже 64 Гб RAM, но это видимо не раньше чем через год.  Но, мечты-мечтами, а по факту: кастомную 13" у нас фиг купишь, в некастомной 8Гб RAM, что немного маловато, если надо держать запущенными пару прожорливых мессенджеров, пару прожорливых браузеров, виртуалки, IDE, и так... по мелочи. Не то чтобы совсем невозможно, но комфортным такое положение вещей назвать нельзя. Поэтому как бы мне не нравился форм-фактор 13",  15"-наше фсьо. Впрочем, я думаю на 13" я таки себя уломаю: валяться с ней на диване  удобней :)

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

То что я втыкал в старый MacBook Pro каждый день, приходя на работу:  питание, куда ж без него, Ethernet (через Thunderbolt переходник) и наушники, плюс, достаточно часто второй монитор через HDMI, и гораздо реже третий монитор через Thunderbolt-адаптер.  Дома и того проще: единственный провод - это все тот же кабель питания. Ну и от случая к случаю: SD-карточка чтобы скинуть фотки, и флешки - чтобы записать на них очередную iso-шку с очередным Linux'ом, если хочется поиграться в Linux на другом компутере. Что изменилось с приходом USB-C? Теоретически питание, ethernet, наушники и второй монитор - это может быть один провод, воткнутый в USB-C разъем. Практически тоже почти так же. Прям как в презентации первого iPhone, там где "телефон", "плейер" и "комуникатор" - один девайс.

Почему "почти" - потому что девайсов/переходников которые нормально умеют эту комбинацию через один провод, все еще, не так много.  Фактически, зимой единственным что было совместимо с MBP 15" 2016 -  было нечто от CalDigit. И то, вроде как питания для 15", если он будет загружен под самую завязку, может не хватит.  Пользуюсь этим счастьем я где-то с апреля,  и в принципе "питание" - было единственной проблемой с ним - блок питания просто сгорел: не знаю виной тому я, проблемы с электричеством у нас в офисе, или плохое качество самого блока питания.  Купленный на замену - пока работает.  Судя по отзывам на Amazon, на новых маках у него были проблемы с драйверами, но на момент покупки драйвера были уже в порядке. Все работает как задумано: втыкаешь один кабель и тут тебе сеть, питание, монитор и при желании звук.  Если вы большой ценитель - звук может не понравится, поговорить по скайпу - вполне ок. Не могу сказать что рекомендую, но мои лимитированные потребности оно покрывает вполне неплохо. Да и альтернатив не так уж и много. Вроде Belkin еще разродился наконец-то таким девайсом, но как-то сильно дороже.  В любом случае: идея мне нравится, в моем случае проводов втыкаемых в мак каждый день стало явно меньше, что удобно, а иметь в хозяйстве пару переходников, для каких-то исключительных случаев, не видится мне большой проблемой. Впрочем, если жонглировать флешками, внешними винчестерами, SD-картами, мышками, и чем там еще можно, по 10 раз в день - то возможно все не так уж и позитивно. Но тут каждому свое.

Если наличие исключительно USB-C портов меня в принципе не особо смущало изначально:  несмотря на много букв в прошлом абзаце, я вполне осознаю, что особого желания втыкать в мак хоть что-то окромя питания у меня точно нет, то отсутствие физической клавиши Esc - звучало аки проблема. Во-первых, потому что мой основной и практически единственный редактор - это vim, даже в IDEA у меня включен vim-режим, во-вторых, и это я осознал в первые же дни пользования новым маком, пытаясь "нащупать" Esc на тачбаре, - окромя vim'а есть дофига ситуаций когда машинально жмешь "сбежать", и таки "сбегаешь" :) Как оказалось: перемапить Esc на CapsLock - вполне здравая идея, CapsLock у меня все-равно стоял без дела, привыкнуть достаточно легко, более того, получается даже очень удобно:  теперь к Esc даже особо не нужно тянуться.

F-клавишами я в принципе никогда особо не пользовался, ни как F-клавишами, ни как кнопками для регулировки звука/яркости и всего остального. Разве что в vim  присутствует иногда нужный биндинг, но Fn+F2 на тачбаре, или вынесение группы F1-F4 на тачбар для терминала эту проблему решает полностью.

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

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

Если вы много пользовались F-клавишами, у вас на них были забиндены какие-то кастомные функции, вы на них нажимали вслепую, CapsLock - ваша любимая кнопка и вы не можете представить Esc на ее месте - вероятно все эти TouchBar'ные свистелки и перделки не покажутся вам такими уж привлекательными, скорее наоборот.  В моем случае: ряд клавиш которые в основном грустно пылились, потому что на них нажимали раз в год, сменился пространством в которое я тыкаю пальцами гораздо чаще.  Что в целом наверное повышением комфортности можно назвать.

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

В сухом остатке: обновление как обновление.  Не могу сказать что революционное, так.. пустили струйку свежего воздуха, что в принципе, в случае в целом "замершего" рынка ноутбуков, на котором ничего особо интересного ждать не приходится, уже неплохо.  Хотелось бы больше RAM, конечно, тем более что это не выглядит таким уж невыполнимым. Переходники - да, сейчас как-то не все хорошо, правда большой проблемы все равно не вижу. Можно представить что сам MacBoook стоит на 100 баксов дороже, и купить на них пару переходников. Fair enough.  Если надо ехать, а не шашечки, или количество кликов на видео/статью "почему Apple обосрались с макбуками?!!!!1111", то вполне покатит.

Шото с памятью моей стало.

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

Парадоксально, но факт, в *nix'овом мире всякие мониторилки очень популярны еще и потому, что средства предоставляемые системой, легко ответить на вопрос "все плохо или все хорошо?" не позволяют, а требуют дополнительной работы мозга. Например, в самых дружелюбных *nix'ах статистика по памяти в системном мониторе выглядит вот так:

Не говоря уже о том что этот самый системный монитор может рассказать про память используемую процессом:

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

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

$ free -m
             total       used       free     shared    buffers     cached
Mem:          2048       1820        228          0        174       1205
-/+ buffers/cache:        440       1607
Swap:         2086          0       2086


Правда конечно стоит помнить, что "по настоящему used" и "по настоящему free" находятся во второй строчке. Потому как память, еще доступная приложениям, это по-сути free + buffers + cached, ну и соответственно buffers и cached, хотя и used, но система их освободит, если будет нужно. Если эта арифметика еще не задолбала можно конечно добавить трешачка, и посмотреть в /proc/meminfo

$ cat /proc/meminfo
MemTotal:      2097152 kB
MemFree:        233448 kB
Buffers:        178372 kB
Cached:        1234100 kB 
SwapCached:         20 kB
Active:         957732 kB
Inactive:       611532 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      2097152 kB
LowFree:        233448 kB
SwapTotal:     2136636 kB
SwapFree:      2136592 kB
Dirty:             460 kB
Writeback:           0 kB
AnonPages:      150672 kB
Mapped:          17888 kB
Slab:           214924 kB
PageTables:       4720 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   3185212 kB
Committed_AS:   301808 kB
VmallocTotal: 34359738367 kB
VmallocUsed:      1292 kB
VmallocChunk: 34359737055 kB

В принципе первые четыре строки нам знакомы по выводу free, а остальные: тема для отдельной беседы. Как посчитать процент занятой памяти? - Например вот так:

awk '
BEGIN{total=0;free=0;buffers=0;cached=0} 
/^MemTotal/{total=$2} 
/^MemFree/{free=$2} 
/^Buffers/{buffers=$2} 
/^Cached/{cached = $2} 
END{printf "%4.2f",(total - buffers - cached - free )/total*100}' /proc/meminfo

Для тех кто не знает awk:  блок BEGIN выполняется вначале работы, блок END - в конце, остальные - на каждой строчке файла. В нашем случае, на нужной строчке просто сохраняем соответствующие числа в переменные, и потом считаем. В принципе, ничего сложного. Каково же было мое удивление, когда xmobar начал выдавать отрицательные значения процента используемой памяти:

Причина как оказалась достаточно банальна. В новых Linux'ах в /proc/meminfo добавили еще одну строчку:

$ cat /proc/meminfo
MemTotal:         949328 kB
MemFree:          542568 kB
MemAvailable:     870912 kB
Buffers:           22636 kB
Cached:           321972 kB
SwapCached:            0 kB
Active:           216328 kB
Inactive:         163272 kB
Active(anon):      35100 kB
Inactive(anon):      448 kB
Active(file):     181228 kB
Inactive(file):   162824 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:        102396 kB
SwapFree:         102396 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         35004 kB
Mapped:            36504 kB
Shmem:               560 kB
Slab:              15724 kB
SReclaimable:       9540 kB
SUnreclaim:         6184 kB
KernelStack:        1352 kB
PageTables:         1096 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      577060 kB
Committed_AS:     146536 kB
VmallocTotal:    1105920 kB
VmallocUsed:        4636 kB
VmallocChunk:     864076 kB

И что-то пошло не так. По-сути awk'шный скриптик который выше все еще работает как нужно:

$ awk 'BEGIN{total=0;free=0;buffers=0;cached=0} /^MemTotal/{total=$2} /^MemFree/{free=$2} /^Buffers/{buffers=$2} /^Cached/{cached = $2} END{printf "%4.2f\n",(total - buffers - cached - free )/total*100}' /proc/meminfo
6.59

хотя теперь можно и как-то так:

 awk 'BEGIN{total=0;available=0} /^MemTotal/{total=$2} /^MemAvailable/{available=$2} END{printf "%4.2f",(total - available)/total*100}' /proc/meminfo
8.30

Разница в результатах небольшая, но есть, потому что  

MemAvailable != MemFree + Buffers + Cached

почти, но, не совсем. В принципе для целей "увидеть когда все плохо" - разница несущественна.  То есть, как бы, если предполагать, что человек который писал xmobar адекватен, то никаких проблем в принципе не должно было бы быть. Поскольку xmobar написать на Haskell, то ожидать неадекватного автора сложно, все-таки порог вхождения поболее будет, и php-набыдлокодить не получится. А вот и получится:

fileMEM = readFile "/proc/meminfo"

parseMEM :: IO [Float]
parseMEM =
    do file <- br="" filemem="">       let content = map words $ take 4 $ lines file
           [total, free, buffer, cache] = map (\line -> (read $ line !! 1 :: Float) / 1024) content
           rest = free + buffer + cache
           used = total - rest
           usedratio = used / total
       return [usedratio, total, free, buffer, cache, rest, used]

 Переводя с непонятного: берем первые четыре строчки файла, предполагаем что на первой лежит total, на второй free, и так далее. Без всяких проверок. Знаете почему так? Потому что Haskell фигово связан с реальным миром(зато идеологически правильно),  и поскольку язык скорее экспериментальный, красота кода, важнее практического результата и стабильности, тем более что стабильность частично обещается компилятором. В итоге трахаешься час шобы получить красивую строчку, и пофигу шо она делает только половину того шо должна. Конечно, в более поздних версиях автору пришлось потрахаться еще чуть-чуть:

fileMEM = readFile "/proc/meminfo"

parseMEM :: IO [Float]
parseMEM =
    do file <- br="" filemem="">       let content = map words $ take 8 $ lines file
           info = M.fromList $ map (\line -> (head line, (read $ line !! 1 :: Float) / 1024)) content
           [total, free, buffer, cache] = map (info M.!) ["MemTotal:", "MemFree:", "Buffers:", "Cached:"]
           available = M.findWithDefault (free + buffer + cache) "MemAvailable:" info
           used = total - available
           usedratio = used / total
           freeratio = free / total
           availableratio = available / total
       return [usedratio, freeratio, availableratio, total, free, buffer, cache, available, used]

Правда, более поздняя версия в Debian'е еще недоступна.

Стыд и SCRUM

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

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

Собственно, почему я вспомнил эту историю, которой возможно никогда не было. Это известная штука в мире, назовем это так, “духовных практик”: одного проколбасило, остальные тусуются рядом, вдруг тоже поколбасит. Религии так не возникают, но что-то попроще - вполне. Когда в интернете кто-то неправ и заходит речь про Agile и с Agile’ом связанные штуки, вплоть до того же TDD, иногда возникает ощущение что спор идет между какими-то сектантами и атеистами. Начиная от истории возникновения, и заканчивая банальной лингвистикой: говорят о Agile-практиках, и опыте, как о некоторой сакральной сущности: аналогия про монаха с яблоком напрашивается сама собой.

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

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

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

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

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

Философия SCRUM'а, де-факто базируется как раз на том, что в процессе взаимодействуют разные люди, с разными целями и задачами, и взаимодействие это, с одной стороны движет к поставленным целям, с другой - позволяет осуществлять относительно ненапряжный обмен тараканами. Ключевыми элементами этой игры являются собственно не события(типа SCRUM-митингов) и не артефакты, а роли, вернее даже не столько роли, сколько система коммуникаций между ними. То самое:

"Individuals and interactions over processes and tools"

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

Например, известный ритуал по оценке историй, scrum poker, и всьо такое. Product owner рассказывает "а че делать нада", команда задает вопросы, потом команда посредством полутайного голосования пытается оценить сложность. Обсуждают чего ждать, насколько все сложно, можно ли разделить проблему на более мелкие, потом ставят оценки сложности и опять обсуждают. Главных целей этого общения две: команда должна узнать от первоисточника все что требуется, а так же должна выставить свою оценку сложности. В качестве бонуса product owner может проникнуться сложностью исполнения его хотелок. В принципе все круто, но есть одно но.

Допустим product owner - где-то там, чистокровный буржуй, работает на компанию с десяток лет и вообще очень уважаемый в глазах своих друзей и коллег человек, возможно даже искренне преданный делу. А команда где-то тут, обычные аутсорс-рабы, работают на буржуев через третьи руки, по статусу в parent company - где-то между обслуживающим персоналом и локальными Junior'ами. То есть проговорить что-то типа "нам тут предлагают немного поредактировать творчество неизвестного индусского брата, который писал эту хрень укуренный в жопу, левой пяткой правой руки, представляя себя как минимум Шивой"  - нельзя вопщем такое говорить. Если вы сидите в одной комнате, и вообще по социальному статусу примерно такой же буржуй как и ваш product owner, -  ради бога, поржете вместе. Если вы раб из страны третьего мира, лучше положить трубку, обсудить индусское народное творчество в узком командном кругу, а всем желающим выдать результат в виде story points. Цели коммуникации вроде как соблюдены, и никто не оскорблен в лучших чувствах.

Ситуация казалось бы простая и прозрачная, что может пойти не так? Допустим, посовещавшись и поговорив о странной психиатрической подоплеке, подвигшей автора некого куска кода выразить свои мысли именно так как это было сделано, команда, на с виду простой таск поставила слишком много story points. Product owner, с удивлением пишет мол "чуваки, че так много?". Переводя с языка матерного на язык дипломатический команда может ответить мол "сами мы не местные, этот код видели полтора раза, и он показался нам несколько сложным, поэтому предвидим сложности в имплементации и тестировании вышеозначенных хотелок" - "а, ну ок" - ответит product owner, возможно предварительно сбегав к местной братве, которая ему расскажет про индусов, грибы и почему их не стоит смешивать.

И все было бы хорошо, но эту шаткую конструкцию легко порушить. Достаточно заиметь еще одного персонажа в этой истории, которого как бы в SCRUM-процессе нет, а по факту вот он тут бегает:  скажем менеджер, который приглядывает за парой тройкой местных аутсорс команд.  Может прочитать письмо от product owner'а и подумать, а, ну ок, чуваки разберуться не в первый раз, возможно перед этим спросив у кого-нить "чо за фигня", а может... КЛИЕНТ НЕДОВОЛЕН, АХТУНГ, СВИСТАТЬ ВСЕХ НАВЕРХ! Обнаглевшей команде "вставляют и проворачивают", с определенным уровнем жестокости, а product owner'у сообщают что мол да, произошла накладка, больше такого не повторится, а чтобы как-то загладить нашу вину, мы тебе запилим эту фичу в кратчайшие сроки, буквально до завтра все сделаем. Видя такой аттракцион невиданной щедрости(было не к спеху, спринт-другой терпело, но завтра так завтра), product owner, как человек воспитанный говорит "спасиба чуваки, я в вас верю!",  и записывает себе в черный блокнотик "если свербит левая пятка, можно просить почесать".  Таски  на команду начинают сваливаться в обход процесса чаще и чаще, команда звереет, а SCRUM... а что SCRUM, SCRUM закончился пару предложений назад.  

Или вот, ежедневная пятиминутка ненависти: daily stand-up. На самом деле ничего страшного: поскольку в этой игре ответственность за результат общекомандная, а не индивидуальная,  то поговорить пару минут на тему "шо у нас как" - вполне себе светлая мысль. Хотя бы для того чтобы понять мы вообще успеваем закончить то что обещали вовремя, или нет. А может кому помощь нужна, а может перегруппироваться нужно. Как отдельный ритуал, daily stand-up, очень полезен в случае с вновь созданными командами или для команд которые в принципе мало общаются внутри в течении дня. Тогда принуждение к разговору очень даже нужно. В остальном: если команда знает что такое daily stand-ups,  и что от них нужно команде, то эти самые daily stand-ups имеют привычку появляться тогда когда они нужны и исчезают когда можно и без них. Часть магии хорошо сработавшейся команды.

Итак, собирается команда, и немного обсуждает "где мы есть и где мы будем есть".  Полезность этого ритуала можно убить разными способами, самый простой:  так или иначе свести все исключительно к формальному ответу на три сакральных вопроса. Формальный ответ выглядит так: "Вчера я работал над тикетом за нумером 113245, сегодня планирую заниматься тем же, пока никаких проблем нет".  Если 113245 - это не история с душком, то номер никому ничего не скажет о том что на самом деле происходит, равно как не будет особо понятно - два/три/пять дней  работы - это вообще ожидаемо, или надо начинать волноваться потому что можем не закончить? Формальные ответы на сакральные вопросы в принципе такой информации не дают, и тут или появляются дополнительные вопросы, или действо теряет практический смысл для команды и проводится с целью "шобы було".  Усугубить ситуацию может присутствие на действе дополнительных персонажей, которые ограничивают то что может быть сказано. В особо веселых случаях, которые воспринимают происходящее как ежедневный отчет по проделанной работе. В таких случаях иногда появляются даже два, три или четыре стэндапа. Один - внутри команды, один - для команды и какого-нить локального менеджера, один для команды, локального менеджера и сочувствующих на том конце мира, и последний для всех желающих. SCRUM'ом это перестает быть в тот момент, когда на daily stand-up'е вы не можете сказать: "я смотрю на 113245(будь проклят тот день когда из укропа и петрушки решили готовить наркотики!), и этот адский писец вгоняет меня в депрессию, вчера лечился от депрессии мультиками, сегодня попробую еще раз сделать с этим шо-нить разумное".

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

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

GTD'шное.

Сразу скажу: не фанат, и склонять на сторону добра не буду. Хотя, безусловно, здравое зерно в подходе есть, и если выбирать между полным Хаосом и GTD, стоит таки обратить внимание.

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

Обычный день рядового быдлокодера состоит из двух важных занятий: побыдлокодить и поговорить. Есть еще обед, но про обед напоминалки ставить нужно только в особо запущенных случаях. Причем, в отличии от буржуйских быдлокодеров, у которых каждодневное "поговорить" - это daily stand-up, происходящий утром, у наших отечественных,  этот daily stand-up может быть в достаточно рэндомное время суток, в зависимости от того когда у тех же буржуев то же утро наступает :) Например, stand-up вполне может быть где-то в районе трех часов дня, разрезая день на две части. И тогда задачи пытаешься подгонять так, чтобы что-то успеть закончить "до", и что-то начать "после", потому как даже 15-минутный "митинг" - это примерно 40 минут перерыва в работе, во время которого все-равно забудешь чего там как.  Конечно, если особо не везет, то daily stand-up'ом дело не ограничится, "митингов и петтингов" может быть великое множество, зависит от того насколько скучно вашему начальству :) - и в таком случае день получается поделенным еще на большее количество отрезков, в которые можно работу поработать.

И получается так, что вот такая вот вполне конкретная реальность рвет нафиг и в клочья весь софт со списками задач. Может быть дофига подходов с огромным количеством возможных костылей, но по-сути ни одного консистентного я не видел. Things - не исключение, а просто продвинутое и дорогое подтверждение правила. Допустим, у меня есть пул задач, допустим я выбрал из него три, которые хочу сделать сегодня, и допустим я таки в состоянии их сделать. Но "страничка", на которой будут нарисованы просто три задачи не представляет весь мой день,  рядом должен быть еще календарь с отмеченными митингами. И тут проблема: календарь нифига не знает про TODO: в него невозможно впихнуть задачу, без привязки ко времени, а списку задач пофигу на время, и если в него даже всунуть митинг - ничего полезного из этого не выйдет - это не просто "то что надо сделать", это "то что надо сделать именно в это время, или не делать вовсе". То есть вроде бы как планъ иметь можно, но только на двух разных кусках бумаги, в каждый из которых заворачивали свою особенную рыбу. Я не понимаю почему то что мне надо делать вообще, то что я хочу делать сегодня, то что я хочу делать следующим мне видеть положенно, и это мне помогает, а то что мне надо делать в два часа по полудни - иди нафиг в другое приложение.

Но даже если смириться с параллельным существованием календаря, проблема со временем все-равно не исчезает совсем. Допустим у нас есть те же таски, таски классифицируются и по проектам, и по тэгам. Таски делаются. Я радостно помечаю таск как сделанный и перехожу к следующему. Мастера GTD торжествуют, а я недоумеваю: почему программа, которая управляет тасками, не может мне выдать отчет: "за эту неделю, на "проект А" ты потратил 30 часов, а 10 тасков с тэгом #писец заняли еще 15". Обезьянке положенно отправлять сделанный таск в корзину и брать с полки банан, но не положенно анализировать результаты и продуктивность? Или разработчики этих приложений здают отчеты акционерам в виде скриншшотов из собственных версий программы, и не хотят палиться, когда вместо того чтобы пилить функционал, рубились в кваку?

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

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

Пара слов о наболевшем...

Пишу не так часто, как хотелось бы, поэтому сразу про несколько вещей :)

Не так давно вышел vim 7.4, в принципе без революций, изменения скорее "под капотом", хотя, возможно, кто-то найдет что-то для себя интересное. Новость на самом деле хорошая - редактор отличный, живет, развивается, ни его в systemd, ни в него systemd никто не тащит. Все было бы хорошо, если бы не одно "но", относящееся, скорее даже не к vim, а к *nix-образным вообще. Как ни странно "но" примыкает к контексту философской дискуссии "апстрим" vs. "все остальные" - за кем правда.

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

Даже, если "своя система" - это какой-нить веселый Arch'ик, в который обновления весело и беззаботно могут прийти уже на следующий день:  ок, поиграться в песочнице и разжечь аппетит получится, но привыкать к новому не стоит - нигде его еще нет.  Собирать пакеты для других систем - так себе вариант, особенно если собирать пакеты нужно для зоопарка, и вообще не вариант, если зоопарк не твой, да и работа вообще не в администрировании заключается. Плюс к тому сборка пакетов автоматически означает переведение системы, в упрощенное пакетным менеджером, но все же ручное управление. Можно еще что-то собрать у себя в $HOME - тоже удовольствие ниже среднего. В общем получается апстрим разродился новинками, а ты можешь только пооблизываться. Поэтому, в пользовательском контексте, вопрос апстрим vs. "все остальные" вообще не стоит: мы жрём что "все остальные" нам дадут.

Между делом такое положение вещей еще и добавляет лишний сантиметр в "порог вхождения" новых разработчиков в разработку открыто-свободного софта. Традиционная, до боли знакомая по описаниям схема выглядит просто: пользуюсь системой, что-то нервирует/мешает/хочется немного по-другому, беру редактор с компилятором в зубы - и давай дорабатывать, потом отдаю сообществу плоды своего творчества. Чего дорабатывать: версию X.XX.XX/1.build123 из дистрибутива, или X.XY из апстрима? Дистрибутивная ближе к телу, она то вообще и раздражала, и для нее более-менее понятно как можно потом собрать себе пакет, но изменения в нее никому нафиг не надо. Апстримовую? - Там может оказаться совсем другое и с другими глюками и  порожденными хотелками, да и тогда, по-хорошему, нужно опять вспоминать как в этом проклятом дистрибутиве пакеты билдят, не хорошо же в /usr/local все складывать, если верить надписям на заборах в интернетах.

Хаотичность и беспорядочность открытого мира, как она есть.

Ну и раз vim'ом начали, vim'ом и закончим. Не смотря на то что vim, чисто в *nix-традициях, умеет делать одну вещь, но умеет делать ее хорошо, - это вообще достаточно большая и сурьезная махина. Просто с наскоку не разберешься и не настроишь, это скорее процесс: сначала учишься как из него выходить, потом узнаешь как добиться того чтобы он бибикал поменьше и не портил все подряд, а потом можно уже и итеративно что-то настраивать-подстраивать, да при случае запоминать новые комбинации клавиш, пополняя книгу рецептов свежими заклинаниями. Парочка заклинаний, которые мне кажутся полезными(не из самой новой версии, но версия поновее чем 7.0 для некоторых все же требуется):

1. AutoComplPop - не то чтобы сверхполезная штука, но достаточно интересная. По-сути: самовсплывающий попап с автодополнением, как в Visual Studio и прочих "взрослых" IDE,  то есть не требует нажатия дополнительных клавиш типа Ctrl + N, итп. Для некоторых языков использует omni completion.  Обещают возможность скрестить с популярным нынче snipMate и с perl-completion.

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

:set backupdir=~/.vim/backup.dir
:set directory=~/.vim/backup.dir

3. При редактировании кода, часто хочется чтобы история для команды 'undo' сохранялась и при выходе из редактора. Отредактировали файл, закрыли, вернулись, и все еще можно продолжать работу с undo, как будто никуда и не уходили. В vim 7.3, как оказывается, такая возможность появилась, включается она достаточно просто, директория нужна для хранения файлов с историей редактирования:

:set undofile
:set undodir=~/.vim/undo.dir