the other side

понедельник, 9 марта 2015 г.

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

Я, как пользователь, или как администратор, операционной системы, местами, весьма заинтересован в том чтобы иметь представление сколько памяти занято, и не начала ли система вылазить в 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'е еще недоступна.


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

Стыд и 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(будь проклят тот день когда из укропа и петрушки решили готовить наркотики!), и этот адский писец вгоняет меня в депрессию, вчера лечился от депрессии мультиками, сегодня попробую еще раз сделать с этим шо-нить разумное".

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

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

четверг, 3 октября 2013 г.

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' быдлокодеров.

вторник, 10 сентября 2013 г.

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

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

Не так давно вышел 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

суббота, 17 августа 2013 г.

Имею скафандр - готов путешествовать.

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

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

Если среди ночи, три амбала с пулеметами вытащат ортодоксального линуксоида с постели, увезут в лес, вручат ультрабук с Windows 8 и 3G-свистком и заставят настраивать Apache в далекой заокеанской губернии - это будет то еще развлечение. Лес и пулеметы сами по себе причиняют некоторый дискомфорт,  а тут еще и Windows 8 в придачу, которая аки vim в руках неофита - бибикает и в лучшем случае ничего полезного не делает. Есть, конечно, состояния психики и варианты перехода между разными рабочими окружениями, когда сохранять работоспособность на должном уровне не составляет особого труда, но это отдельная история.

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

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

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

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

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

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

Ну и на последок немного про себя любимого. Содержимое "походного" рюкзака от обычного отличается наличием фотоаппарата. В целом все просто:
* MacBook Pro, по нынешним меркам уже достаточно старый - 2010-го года выпуска. Сейчас в нем несколько больше памяти и SSD-диск. Соответственно OS X 10.8. Плюс два блока питания - один короткий, один длинный. Работает от батареи где-то в районе 3-5 часов, зависит от того чем заниматься.
* iPhone 3GS, все еще со старой iOS 5.1.1, cо старыми гугловыми картами.  Старый, потрепанный, с треснувшим корпусом и отлетевшей кнопкой регулировки звука, но все еще, как ни странно, работающий :)
* мягко говоря древняя цифрозеркалка - Nikon D40, с прикрученным 35 мм. фиксом.
* собственно всё :)

Как это все готовилось к поездке? - да никак не готовилось. Закрыл крышку, запихнул в рюкзак и поехал. Приехал на место, открыл крышку, продолжил с того момента где остановился. Единственная проблема - я не смотрю на маке видео, поэтому никакого видео там не оказалось, пришлось довольствоваться ютубом.  Конечно проклятая проприетарщина, конечно анальное рабство, ну и конечно все отлично работает, в самых разных ситуациях. В качестве приятного бонуса - в случае отсутствия WiFi, но присутствия 3G, iPhone вполне способен устроить свой WiFi с блэкджеком и всем причитающимся, правда, батарейку садит сильно.