Роман Химов

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

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

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

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

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

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

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

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

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

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

Что, впрочем, не отменяет примат реальности и если реальность иная, то и структура будет иная.

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

Интереснее ситуация становится чуть позже, когда, например, нужно освоить велосипед. Объяснить что нужно делать для того, чтобы ехать, тоже практически невозможно, необходимо некоторое тонкое чувство баланса сопряжённое с работой телом и руками (ну ещё педали иногда покручивать полезно). Но практическая ценность всех слов приблизительно равна нулю, поскольку пока обучаемый не почувствует баланс, все слова бесполезны.

Та же самая ситуация с плаванием. Речь не о спортивных стилях, конечно, а о банальной возможности держаться на воде и хоть как-то двигаться. Здесь даже чуть-чуть лучше, в плавании есть очень большой, но очень простой секрет — вода держит. То есть, можно очень легко, ничего не делая, просто держаться на воде, чисто в силу физики плотности тела. А уже начать из этого состояния совершать направленные движения совсем несложно. Но интерес как раз в том и состоит, что повторить большой секрет на уровне слов можно хоть 500 раз, а плавать всё равно получится только тогда, когда этот секрет перейдёт на уровень личных ощущений водной среды. Если этого ощущения нет, все рассказы о том, как двигать руками и ногами, бесполезны в принципе.

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

Конечно, барьеры могут быть не только физическими.

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

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

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

Поэтому особенно интересно видеть, когда люди чувствуют барьеры и ломают их. Взять, например, недавний выход спецификации ВебЮЭсБи, с инженерной точки зрения проблема вполне понятная — прокидывание одного протокола поверх другого. Не сказать, что тривиальная, но понятная. А вот с точки зрения снимаемых барьеров штука весьма серьёзная, например, сейчас для некоторых возможностей портала Госуслуг необходима установка плагина, что невыполнимо для большинства пользователей, а с новым протоколом ничего уже не нужно, всё просто будет работать (вопросы безопасности я намеренно опускаю).

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

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

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

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

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

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

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

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

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

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

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

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

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

Будьте здоровы.

Вчера сайт ОСРЦ был переведён в статическую архивную форму (вместе с КаталогОСом). Поскольку делалось это, в первую очередь, по соображениям безопасности, заранее об этом ничего не писал. С точки зрения доступности материалов ничего не поменялось — всё на своих местах, даже старые ссылки должны работать (что потребовало некоторого времени, но).

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

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

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

Когда-то я покупал заметную часть чая просто в супермаркетах, сейчас я там вообще ничего интересного не вижу. Когда-то чай по 3–4 рубля за грамм казался дорогим, такой можно было покупать иногда, сейчас это практически минимальная планка. Дошло до того, что в прошлом году я «на попробовать» брал чай по 10 рублей за грамм. То есть, понятно, что дорого, но отказаться нет никаких сил. А самое ужасное, что по результату пробы этот чай того явно стоил и я за ним ещё вернусь.

В какой-то мере этому, конечно, поспособствовало падение рубля, но всё-таки цены выросли (в среднем, так-то от сорта зависит) менее чем в два раза, а траты выросли более чем в два раза. И предела этим тратам не видно, более того, видны отличные перспективы увеличения, например, давно существует магазин тов. Потемкина или какая-нибудь «Формоза» — там от 10 рублей за грамм всё только начинается.

Поэтому, когда мне приходит спам типа «чай от алкогольной зависимости», я всегда задаю встречный вопрос, а нет ли алкоголя от чайной зависимости?

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

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

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

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

Что ещё хочется отметить, так это всё-таки вордпресс. Хоть я на него когда-то и ругался, но это было совершенно напрасно, потому как надо обратить внимание на главное — данный бложик работает под управлением вордпресса уже больше десяти лет и он работает. Сколько раз он обновлялся (в том числе автоматически!) не сосчитать, а всё равно всё работает. В сравнении с этой фичей, всё остальное полная ерунда.

Австралийская НИКТА в лице тт. Хейзера и Элфинстоуна некоторое время назад выкатила отличную работу, описывающую двадцатилетнее развитие микроядер Эльчетыре. Очень люблю такое — видно, с чего начали, какие проблемы в разное время возникали, как они решались, к чему пришли. Интересно даже не само микроядро (хотя с Фисташкой я даже непосредственно сталкивался лет так семь назад), а наблюдение за реальной эволюцией системы.

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