В Кишинёве эти машинки продаются свободно, бо никому особо не нужны.

А красящие ленты для них в Кишиневе не продаются. Их нет, потому что они вообще никому не нужны.

А без красящей ленты пишущая машинка не работает.

(мрачно) Ха-ха-ха.

Почему две:

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

Но, как водится, случился случайный случай, после чего необходимость в «трака-така»-машинках отпала. Ну да, ну да…

«Кого ты хотел удивить?»

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

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

Ход клавиш огромен, «порхать» по ним невозможно, между кнопками зияют коварные пропасти, неподготовленные пальцы проваливаются куда-то вглубь страшной механизмы, и чтобы нажать следующую клавишу, надо палец сперва поднять «на исходную позицию» — точно так, как написано в старых учебниках по набору текста…

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

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

А ещё было удивительно сложно осознать невозможность редактировать что-либо на бумаге — кмх… Клавиша Backspace есть, но… Кхм… да, это было неожиданно.

А ещё выяснилось, что эта штука правильно называется «пишущая машинка», а не «печатная машинка», но всем как всегда…

И что-то подумалось навскользь о том, что сам Роберт Хайнлайн когда-то набирал тексты на вот таких пишущих печатных машинках… Прожил он долго, с 1907-го до 1988-го, а значит, застал начало эпохи персональных компьютеров. Была ли у него возможность набора текстов на персональных компьютерах? Щупал ли он тот же TeX?

Кнут сделал “TeX” в 1978-м и даже полностью переписал в 1982-м году. “LaTeX” появился в 1984-м. “Apple II” появился в 1977-м.

Вполне мог… бы… наверное.

Да работал ли мэтр вообще на компьютерах?

Оказывается — да, был такой опыт. Но прежде всего надо учесть контекст. Если бы у Хайнлайна в самом начале писательской карьеры был персональный компьютер, то он, наверное, и не женился бы…

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

• АВМ («ана́логовая вычислительная машина»; не путать с ЭВМ, которая «электронная вычислительная») в Массачусетском технологическом институте (MIT)
• МВУ (механическое вычислительное устройство) “Z1” Конрада Цузе, модель пробная и в практической работе не использовалась. И даже “Z2” в дело не пошла, а вот “Z3” немецкая военщина взяла на вооружение в 1941-м и начала фигачить расчёты вибрационных характеристик крыльев и оперения в проектируемых военных самолётах для Люфтваффе.

Жалко, но в те времена никаким писателям никаких компьютеров никакие Люфтваффе не предоставляли. Сиди и делай «трака-така» на пишущей машинке.

Дас “Z3” в естественной среде обитания. Клавиатура есть, но на ней только кнопки с цифрами

Однако же Хайнлайн таки кое-что понимал в работе тех больших, тёплых, ламповых компьютеров. Во время WWII Хайнлайн числился в ВМФ США бывшим морским волчистым офицером, списанным на берег по состоянию здоровья, поэтому он, вместе с Айзеком Азимовым и Лайоном Спрэгом де Кампом (ВНЕЗАПНО оба такие же писатели-фантасты, публиковались иногда в одном и том же номере одного и того же журнала — Astounding v28n02 [1941 10]!) работал на благо своей американской родины в научно-исследовательской лаборатории ВМФ в Филадельфии, где разрабатывали методы борьбы с обледенением самолётов на больших высотах, аппаратуру для слепой посадки и компенсирующие гермокостюмы для пилотов — предтечу скафандра для космоса. А компьютеры в той исследовательской лаборатории были (вояки же), и пройти мимо них Хайнлайн, конечно, не мог.

Хайнлайн, де Камп и Азимов на работе работают работу (1944)

Авиация тех времен постоянно развивалась, и оказалось, что на больших высотах у пилотов начинаются проблемы с дыханием — «кислородное голодание» отключает организм чуть менее, чем полностью. Одни только кислородные маски ничего не решали, бо на высоте 15 км давление выделяемого легкими углекислого газа превышает атмосферное давление и сделает дыхание невозможным. А выше 19 км в организме начнут кипеть все биологические жидкости. Поэтому военные начали придумывать специальные лётные костюмы, которые обеспечивают и шланг с кислородом, и давление, при котором человек может жить, работать и пулять ракетами по супостатам. Или, например, летать над «старым добрым мирным» СССР и бесплатно фотографировать крестьянок и прочие военные объекты. Вот к этому делу Хайнлайн и подключился.

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

Опыт щупанья древних компьютеров, конечно, показательный, но с последствиями. В повести «Астронавт Джонс» (1953) экипаж мегасупермежзвёздного корабля «Асгард» (и он — корабль, а судно — это то, что под койкой у бывшего лихого моремана; и вообще у англичан это She, вот так вот) переносится от одной планеты к другой прыжками через гиперпространство. И прыжки эти надо рассчитать по-математике, и это можно сделать или вручную, с помощью таблиц Брадиса с данными для астронавигации, которые переплетены в виде толстых книг, или с помощью компьютера. И Хайнлайн втиснул в тесный «Асгард» компьютер, который был ему знаком и понятен.

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

Вот такой компьютер и был предоставлен мэтром письменной словесности смелым астронавигаторам будущего, и они не отказались:

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

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

Келли диктовал: «…двоичный натуральный логарифм от ноль точка восемь семь ноль девяносто два, умноженный на…». Макс услышал голос Ногучи, переспросившего данные. Ногучи рылся в книге, ища нужную страницу, но намного раньше, чем он успел ее найти, страница появилась перед мысленным взором Макса. Он бессознательно нажал клавиши, не дождавшись Ногучи.

— Поправка, — прозвучал голос Келли. — Слушай, ты, тупица, тебе не надо вводить те цифирки, которые я говорю, ты вводи те цифирки, которые тебе Ногги скажет. Ну сколько тебе раз повторять?

— Но я же… — начал и осекся Макс. До этого момента никто на борту «Асгарда» не догадывался, что он обладает такой непристойно странной памятью.

— Что «ты же»? — Келли хотел было сбросить последние данные, введенные Максом, но приостановился. — Если подумать, ты же не мог ввести в эту штуку десятичные цифры. Так что же ты, интересно, сделал?

Макс знал, что прав, и очень не хотел, чтобы думали, будто он ошибся.

— Я ввел те цифры, которые Ногучи собирался мне продиктовать.

— Повтори-ка это снова, — Келли смотрел на него не отрываясь, — ты что, читаешь мысли?

— Нет, но цифры я ввел правильные.

— Хм… — Келли нагнулся над пультом. — Повтори-ка, Ногги, — Вычислитель выдал длинный ряд нулей и единиц, двоичный эквивалент зачитанного Келли выражения; Келли проверял нажатые клавиши, губы его слегка шевелились. Он выпрямился. — Как-то раз один парень при мне тринадцать раз подряд выбросил семь очков, причем кости были честные. Это что, Макс, тебе просто повезло?

— Нет.

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

В конце концов Келли сказал:

— О’кей, крутни-ка ему хвост. — Макс щелкнул тумблером, подавая сигнал, по которому машина заглотила программу и мгновенно ее переварила; ответ выразился в огоньках: горит — не горит, машинном эквиваленте двоичных чисел.

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

— Попью-ка я кофе, — тихо сказал он и отошел.

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

Ну, а мы эту пару слов произнесём. Полноценный, многопалубный, шикарный космический корабль они делать уже умеют, искусственную гравитацию они делать умеют, и прыгать через подпространство они уже умеют, и кофе у них есть, и налаживать бесперебойную гравитацию в космосе они умеют, и вообще в космосе могут путешествовать все, от богачей до обслуги, никому «по здоровью» в полёте не отказывают. И компьютеры на их кораблях есть, правда, без дополнительного набора таблиц Брадиса в космос не летают, но — всё надёжно, всё работает… Кто полетел бы в неведомое космическое пространство з таким обладнанням?

Я.

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

Мда, старые времена… В погоне за оптимизацией некоторые писатели писали тексты сразу на машинке (Хемингуэй, Сименон, etc). Которые уже состоялись — нанимали для этого наборщиц. Которые победнее — брали наборщиц в жёны. Естественно, Хайнлайн тоже апгрейднулся от карандашей сперва до пишущей машинки, а затем и до третьей жены.

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

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

А тут как раз произошёл исход семидесятых — начинается явление персональных компьютеров американскому народу. Уже продавались компьютеры Commodore и RadioShack, за ними уже подтянулись Apple II и Atari . Появились очень ценные для тогдашних пользователей дисководы (флопаки на пять дюймов), программы для набора текста и для уже привычных нам электронных таблиц — возможно, самое ценное в быту, бо бюджеты, отчёты, налоги и всё такое прочее эксельное. Было они все в принципе дорогими, «горячими», ненадёжными и по нашим меркам работали медленно, со сбоями, но это было только начало, поэтому все или терпели, или делали всё то же самое без компьютеров — old-school way.

Роберт и Вирджиния Хайнлайны (1980)

И вот на этом исходе семидесятых на сцене появляется Вирджиния Герстенфельд, третья супруга Роберта Хайнлайна — лейтенант ВМФ США в отставке, профессиональный химик, фигуристка (высший любительский уровень), знала джиу-джитсу, латынь и ещё пять-шесть других языков, прекрасно готовила, была способна самостоятельно освоить любую технику, два года учила русский язык для того, чтобы сопровождать Хайнлайна в путешествии по СССР в 1959—1960-м (Москва, Киев, спортивные стадионы). Она не редактировала его произведения, но полностью участвовала в менеджменте публикаций, так что без неё вся эта история не была бы историей.

К тому моменту Джинни (а её все так называли, так позволим себе это и мы) уже видела, как лихо управляется с одной из первых машин «Atari» Мэрилин Нивен, супруга писателя-фантаста Ларри Нивена. Полагаю, что это была модель «Atari 800». И говорят, что Мэрилин приходилось эту шнягу то и дело самостоятельно чинить.

Atari 800. Сперва привыкни к клавишам, потом приходи со своим телевизором

Как и большинство тогдашних персональных компьютеров, упомянутый Atari представлял собой толстую клавиатуру, в которой было спрятано, собственно, всё то, из чего состоит компьютер. Просто подключи это всё, если получится, к какому-нибудь современному телевизору и be happy.

В 1993-м в компьютерном классе бывшего кишиневского дома пионеров были «Yamaha КУВТ» (Комплект Учебной Вычислительной Техники), которые больше интересовали нас, тогдашних школьников в плане «пошпилять в игрушки после занятий», чем «творить творения на BASIC», но всё-таки. Желто-зеленые мониторы, BASIC, goto, все дела. До Windows 95 ещё было несколько лет.

Но у нас на клавиатурах были отдельные, здоровенные кнопки управления курсором, а на Atari 800 (и других похожих на него компьютеров) эти «стрелки» были кнопками второго уровня, до которых можно было добраться только через Shift. Не сказать, что это мозголомка, привыкнуть можно. Но ептыть же!

И Джинни правильно оценила апгрейд от пишущих машинок до персонального компьютера:

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

Вот это было бы апгрейдом всех апгрейдов процесса создания текстов! В тартарары эти наши/ваши аналоговые машинки. В бездну.

Вирджиния выбрала ЭВМ совмещённый с экраном — «Zenith Z89».

Так выглядел Zenith ’Z89’ (его флоповод отвалился за древностью лет)

Справа от экрана отсек для всякого, например, для дисковода, внутри процессор Z80 с тактовой частотой 2 МГц, 48 КБ ОЗУ и несъёмная клавиатура, которая отличалась высоким качеством сборки и необычным количеством клавиш специального назначения: REPEAT, ESC, TAB, CAPS, CTRL, SCROLL, RESET, BREAK, BACK SPACE, LINE FEED, DELETE, REPEAT и две с красными и синими квадратиками! И над всем этим — 12-дюймовый, выпуклы, монохромный, мерцающий ЭЛТ-экран, на котором помещалось 80 × 25 символов. Ндя.

В наше время такие компьютеры чаще упоминаются под названием “Heathkit H-89”, потому что изначально их делала компания Heath:

Стоил он $2.295 и это таки было дорого (половина нового Кадиллака с рулём и пепельницами), но Хайнлайн, как бывало нередко, пошёл вразнос и взял сразу два экземпляра — для себя и для Джинни. Он взял да и быстро освоил текстовый редактор «Magic Wand», и после волшебного выполнения «поиск-замена по тексту» сделал эпохальное заявление:

Это освобождает меня от тирании машинисток! ©

Он даже письма начал писать только на компьютере. Говорят, что цифровой архив Хайнлайна, в отличие от бумажного, так и хранится в Калифорнийском Университете на исходных носителях — древних пятидюймовых флоппи-дисках.

Если это правда, то жить им осталось недолго и архив, наверное, можно считать утерянным.

Первым текстом, который был набран полностью на “Z89”, был «Фрайди» (который я впервые прочитал в поезде между Молдовой и Украиной в 1994-м или 1995-м и с тех пор… ммм, впрочем, неважно), и с тех пор пишущие машинки в быту Хайнлайнов не фигурировали. Всегда проще иногда выковыривать кнопки и быстро прочистить контакты на клавиатуре, чем вызывать механика и ремонтировать уходящую вразнос пишущую машинку и искать в Киеве красящие ленты для неё.

И если сам Роберт Хайнлайн использовал свой компьютер только в качестве текстового процессора, то Джинни пошла дальше и (в том же 1981-м году) изучила «Basic». А ей было уже 65 лет.

Начинаем ныть о том, что возраст мешает…

Вместе с компьютерами Хайнлайны взяли страшную вещь — дисковый принтер «Sprint Qume». Это такая себе сверхпродвинутая печатная машинка, где вместо множества штанг с литерами перед бумагой постоянно (бешено!) крутится диск с буквами. В нужный момент по соответствующей букве происходит резкое стуканье, на бумаге остаётся оттиск буквы и каретка уносится на один символ влево. Такая машинка с высокой скоростью печати работала с повышенной шумностью, причём настолько, что во время работы её прикрывали звукопоглощающим чехлом. Ну так а шоподелать…. И она тоже требовала возни с бумагой и красящую ленту, которая сегодня в Кишиневе нигде не продаётся (БЛЕАТЬ!).

Дисковый принтер «Sprint Qume»

Так что ответ да — Хайнлайн на персональном компьютере клавишами тарахтел и нам велел.

Послесловие про специализацию

Раз уж речь зашла про компьютеры и Хайнлайна, упомянем его меметичный пассаж про специализацию из «Достаточно времени для любви, или Жизни Лазаруса Лонга» (1973):

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

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

Автор цитаты — Лазарус Лонг — кагбэ, старейший человек, он прожил на момент действия романа более 2000 лет (действие происходит в 4325 земном году). Он повидал настолько много всякого, что может в любой момент выдать афоризм на любую тему, с контекстом или без. Характерные примеры его ВНЕЗАПНЫХ высказываний:

«Если ты не любишь себя самого, другие тебе тоже не понравятся».

«Демократия основывается на предположении, что миллион человек умнее одного».

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

«Мой ей ноги».

Собственно, сам Хайнлайн программировать не умел, и вообще там сказано не только про необходимость умения программировать. Там предлагается уметь резать свиней… и сонеты писать. На смерть свинье и вкусным биточкам.

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

I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:

(1) everybody knows what “bug” means;

(2) the standards are inconsistent with one another and with themselves in the definition of “fault,” “error,” and “failure”;

(3) according to the Oxford English Dictionary, the usage of “bug” the way we use it, contrary to popular belief, predates its entomological use by centuries—the first written reference to “bug” = “goblin” is from 1388, but its first use to mean a small, six-legged creature with a hard carapace dates from 1642;

(4) I prefer short, strong, Anglo-Saxon words to effete Norman words. The genesis of “bug” as a computer problem being derived from a moth fried on the power bus of an early computer, thus bringing the system down, is apocryphal. “Bug” is an ancient and honorable word (Welsh bwg) and not newly coined jargon peculiar to the computer industry.

Software Testing Techniques, Second Edition

by Boris Beizer (1990)

ISBN: 1850328803

Apocryphal — это от слова апо́криф (от др.-греч. «скрытый, сокровенный, тайный») — произведение религиозной литературы (иудейской и христианской), преимущественно посвящённое событиям и лицам ветхо- и новозаветной и церковной истории, не включённое в канон. Апокрифы являются запрещёнными для чтения в церкви. Чертей Клириков, которые используют их для чтения в общественном месте, полагается лишать сана.

С одной, непонятно какой именно стороны, можно посчитать заявление Бейзера заносчивым и пафосным.

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

В бытность мою главным спiвпрацювальником по підготувальні тестувальників Astound Commerce, в 2018-ом году, произошёл удивительный казус, без которого наша насыщенная и пресная айтишная жизнь была бы совершенно пресной.

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

Кандидатушкой?

Кандидаторкой?

В общем, «Что вы читали про тестирование ПО?» 

Девушка говорит, что про тестирование читала книгу Лупана. Который, как я знаю, книг не писал.

— Вы… уверены?

— Да-да-да!

Уверенность однозначна. Она читала книгу Лупана. Упомянутый Лупан сидит перед ней неестественно ровно и смотрит на неё… неестественно внимательно.

Вот так смотрел: 0_о

Забегая вперёд…

Впрочем, не будем забегать вперёд. Забежим назад.

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

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

Ну… да.

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

Ну и я, конечно, начал орать и сучить ножками 48-го размера. Бо как зафиксировать на бумаге всё то варево в моей голове, из которого только изредка капали здравые идеи и взрывались всёпроясняющие инсайты?!

Никак.

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

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

Назвал я этот файл с небольшой претензией на (тут сами подберите какое-нибудь слово, бо я хз):

«Практика тестирования программного обеспечения.

Курс лекций для тренера интересующихся тестированием ПО»

Приятно было сознавать, что если я всё-таки умру из компании (что и случилось в 2019-ом), кто-то другой найдёт в моём файле всё для того, чтобы go-go-go дальше.

А неприятно было сознавать то, что этот файл НЕЛЬЗЯ отдавать джунам.

Презентации бывают двух типов:

1. те, которые можно читать самостоятельно,
2. и те, которые сами по себе не имеют смысла, они только оттеняют и иллюстрируют речь докладчика.

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

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

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

Поэтому в самом начале было указано, что

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

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

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

Вернёмся в 2018-й, в Винницу. Я открыл на весь экран pdf, развернул ноут к заявительнице.

— Эта книга?

— Да, она!!!

Титлепейдж «Практика Тестирования» 2014

Неееее можеееет быыыыть!

Забегая вперёд…

Впрочем, не будем забегать вперёд. Забежим вбок.

Может быть, я слишком сильно перегибаю уже перегнутую палку, и не всё так стрёмно?

Вероятно да, но вот вам другая история о том, как в том же 2014-ом (или 2015-ом?!) я встретил в Киеве первую в моей жизни девушку, которая прочитала свою первую в жизни книгу про тестирование так внимательно, что распечатанные горизонтально листы бумаги были чуть менее, чем полностью исчирканы маркерами и карандашами — такое редко встретишь, имеем респект.

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

Давайте сперва посмотрим, что это за книга так внимательно прочитана… ааах, да-да-да, знаю — Артур Коробейник «Краткие основы тестирования программного обеспечения», Киев 2012. Ой-вэй…

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

Если очень надо понять, о чём, всё-таки, речь: https://vk.com/wall-35156109_10741 Ваши страхи и ваши риски.

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

Ага. Вот передо мной человек, который/ая от пострадал от прочтения текста, который был для него не предназначен.

С чего начать?

Что объяснить?

Как предложить забыть всё и начать заново?

Мы поговорили, но был фэйл. Вероятно, мы потеряли адекватного тестировщика и ей пришлось пойти учить фронтэнд девелопмент, увы. А по прошествии лет я ещё и забыл, как её зовут. Дабл фэйл.

Ещё раз — не все тексты надо оформлять в виде книг и раздавать кому попало. Это может быть очень вредно. Гуманность uber alles же!

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

И вот теперь, когда забегать уже некуда, сразу переходим к финалу.

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

А перевзволновавшаяся конкурсантка на самом деле читала книгу сэра Романа Савина, и отреагировала «лупаном» из-за названия каталога и своей общей излишней взволнованности.

Слава молдавскому Аллаху, это уже конец этой истории, почтенный посетитель рынка, собиратель историй. Победила восторжествовала.

Но это не конец всей истории!

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

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

Ой бляяяяя… Кракен хэз бин релизд.

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

Запретить его читать? Никак.

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

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

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

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

А музыка получается у каждого по-разному.

То есть, вредный он-то вредный, но не разрушительный же?!

Ок, файл «Практика тестирования программного обеспечения» принародно объявляется несостоятельным и ненужным. Я им не управляю и не смогу донести ответственность за вероятные последствия его использования. Читать его не возбраняется но и не рекомендуется. Вместо него, если английский позволяет, рекомендую глянуть мой же «Software Testing Glossary».

Он тоже когда-то начинался как служебная записка, которая должна помочь быстро и точно объяснить тот или иной термин из тестирования заказчикам проектов (глоссарий ISTQB для этой цели ВНЕЗАПНО совершенно не подходит), но в корпоративных документах нельзя свободно выражаться и использовать слова stupid или whiskey, поэтому его содержимое было, как следует корпоративным нормам, выглажено и деперсонифицировано, а мой изначальный текст ушёл жить самостоятельно.

А я, пожалуй, возьму из этой «Практики» какие-то идеи и примеры да смешаю их с толкованиями терминов из этого «Glossary». Может получиться… короче, посмотрим, что получится, бо это такое дело, иногда получается, а иногда нет.

Ещё раз: файл «Практика тестирования программного обеспечения. Курс лекций для тренера интересующихся тестированием ПО» — это фу, это бяка, это данунах.

Вас пердупердили.

Мелкий PS про технику этого дела

Файл был полностью набран/оформлен в LibreOffice. В то время я ещё не освоил LaTeX на полную, а то я бы, конечно…

Но оказалось, что нативный LibreOffice — сила, особенно если добавить к нему плагины (нативно либофис в автозамене слабее мсворда, когда надо цепануть концы строк, бо он работает сугубо построчно). Набор текста в режиме разметки first, а оформление опосля — на, всё на хоткеях. Разные типы содержимого (краткое, расширенное, полное) — на. Встраиваемые значения в поля — на. Контроль содержимого в навигаторе — на, и удобнее, чем в MS Word. Свои стили — на на всю катушку. Учёт изображений и таблиц — на. Список литературы в отдельной БД с подсосом значений из неё в файл — на. Обновление ссылок на внутренние сущности — на.

А действительно, чего это мне кажется, что разница между верификацией и валидацией всем понятна без примера?

Нужен конкретный пример. А то без примера каждому… парню кажется, что его принимают за идиота.

Например, здравствуйте, дети, вот это револьвер Смит и Вессон. Им можно решать разные задачи на поле боя. А ещё из него программист может выстрелить себе в ногу несколько раз. Сейчас я вам это покажу на конкретном примере. Ну, чья нога послужит хорошим, конкретным примером? Кто из вас знает C++?

Если пример непонятный — садись и слушай. Однажды, давным-давно…

Глава первая, вступательная в зыбкое болото терминов

Верификация — проверка соответствия приложения прописанным требованиям.

Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.

Ну, и чо?

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

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

Верификационные тесты, с отсылками к требованиям, программисты принимали, не каркая.

А валидационные запросто отклоняли, бо «тестируется сценарий, которые не предусмотрен требованиями».

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

Если в этот момент юзер решит вернуться на шаг назад — он должен передвигаться между экранами только через JS-кнопки «back» и «forward» в приложении (почти каждый современный сайт — приложение). Так написано в требованиях, так реализовано программистами.

А если нажать на кнопку [Back] в браузере — всё поломалось.

Это очевидно для пользователя? Нет.

Пользователь может нажать на кнопку [Back] в браузере? Может.

И получит белый экран, и все данные пропали? Получит. Вот скриншот. Вот видео. Давайте чинить!

Ответ: Declined (out of requirements).

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

А понимал бы я тогда разницу между верификацией и валидацией…

«…я, может, и не женился бы» © бородатый папа дяди Фёдора

Глава вторая, патетическая, в которой шахматист ВНЕЗАПНО понимает, кто придумал защиту Тартаковича

А теперь будет ход конём.

Или про шахматы тоже надо отдельно объяснять?!

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

Нет.

Это всё приходит к нам из предыдущего этапа, на котором кто-то придумывает требования.

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

И нет, тут подразумевается не покрытие требований тест-кейсами (это всё делается позже, как правило, нами), а проверка требований разными аналитическими инструментами.

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

Ещё в прошлом веке человечеству было известно, что сами требования можно и нужно тестировать с помощью — и вот этот ход конём! — тех самых понятий Verification & Validation. Ёпт!

Об этом подробно написано в книге Karl Wiegers „Software Requirements“ (third edition) на стр. 331.

Где взять эту книгу — а проверь свои гигабайты скачанных, но не прочитанных книг, наверняка она там есть. Или глянь Amazon.

Кстати, эту книгу перевели на русский язык, но сделали это очень по-уебански*, поэтому надо смотреть только в первоисточник.

* Не дёргаемся, это единственно точное слово для описания того перевода.

В той же книге Вигерса на стр. 347 написано про Validating requirements with acceptance criteria. Знакомый термин? Он тоже кажется сугубо тестировщицким? 🙂

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

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

Тестировщику надо уметь прорабатывать требования? Надо.

Для этого надо быть аналитиком? Нет.

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

Совершенно ненужный эпилог

«Мы считаем сумасшедшими тех, кого не понимаем, и дураками тех, кто не понимает нас.

Поэтому сумасшедшие считают всех дураками, а дураки – сумасшедшими» ©

You know it’s sad but true.

Ну, как книга. Современные преподаватели сделали для своих студентов 1-го курса видеолекции. Если собрать тексты всех этих выпусков в один массив = кагбэ, да, книга. И оформлена по-современному — её можно читать только в браузере, текст перемежается с видео. Формат противоречив и работает только в определённых условиях.

Общий стиль присущ всем кратким учебникам и текстам для видео — короткие заявления.  И даже объяснения преподносятся в виде коротких заявлений. Видео, особенно обучающие, по-другому делать нельзя. Точнее, можно, но не нужно.

А некоторые темы ещё в процессе написания.

Но это всё ерунда. Оказывается, тестированию ПО учат в старейшем (основан в 1842 году) и крупнейшем техническом университете мира, там более 16 000 студентов и 2600 научных сотрудников (включая 200 профессоров)! Хоррэй!

Какие темы они рассматривают: автоматизация тестирования в целом, тестирование с помощью моделей, тестовая пирамида, TDD, мутационное и фаззинг тестирование и др.

Код появляется уже в «Chapter 1 — Why software testing?» Короче, там не про ввод всякой няшной ерунды в поля для ввода всякой няшной ерунды. Смотрим в код и начинаем его покрывать.

Рассуждения о разнице между Failure, Fault and Error (типа такого — Разница между ошибкой (багом) и дефектом (тоже багом)) появляются уже в «Chapter 3 — Testing Principles».

Правда, про verification and validation выдали что-то не совсем то:

Verification is about the system behaving as it is supposed to according to the specification. This mostly means that the systems behaves without any bugs, like it is said it should behave. This does not guarantee that the system is useful. That is a matter of validation. We can summarize verification with the question: Are we building the system right?

Validation: Are we building the right software? Validation concerns the features that our system offers and the costumer, for who the system is made. Is the system that we are building actually the system that the users want? Is the system actually useful?

Увидели ошибку? costumer вместо customer же.

Нет, не она. Это чинится быстро.

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

Пример же.

Конкретный.

А Любомир Геревич не знает, кто дядя Боб. Так вот, это один из тех семнадцати чуваков, которые собрались в феврале 2001-го в Snowbird ski resort в Юте для того, чтобы потрындеть о том, как можно было бы обустроить жизнь программистскую.

На этом фото Роберт Мартин третий слева.

К тому времени уже оформилось несколько устойчивых и обоснованных мнений о том, что и как надо было бы делать, чтобы было «правильно», поэтому необходимость в общем словаре уже назрела.

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

Книга воспринимается как трёхсоставная:

1. общий обзор
2. технарные штучки
3. менеджерские дрючки

и для простоты можно говорить только про первую часть. Меня первая часть затянула полностью. Было сложно читать, бо я постоянно офигевал по двум векторам:

1. Да! Именно так! А я говорил! Да!
2. Неужели!? Неужели я настолько ошибался? Нет!

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

Контекст важнее всего. Непонимающие контекст и желающие перенимать только практики (best practices only!) — долбанные придурки с излишним запасом энтузиазма, блеать.

Контекст

важнее

всего.

Контекст определяет содержание и способы решения задачи.

У тех, кто собрался у той доски, понимание контекста было ну прям нутрянное. Им было важно и нужно упростить сотни вариантов до общих принципов. Они это и сделали.

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

В общем, нет никакого противопоставления Agile vs Waterfall. Сегодня всё точно так же, как было раньше, когда молодой дядя Боб фигачил код на старых компьютерах. Иногда получается. Иногда нет.

In 1970, I was 18 years old, working as a programmer at a company named A. S. C. Tabulating in Lake Bluff, Illinois. The company had an IBM 360/30 with 16K of core, an IBM 360/40 with 64K of core, and a Varian 620/f minicomputer with 64K of core. I programmed the 360s in COBOL, PL/1, Fortran, and assembler. I wrote only assembler for the 620/f.

We wrote our code on coding forms using pencils, and we had keypunch operators punch them onto cards for us. We submitted our carefully checked cards to computer operators who ran our compiles and tests during the third shift because the computers were too busy during the day doing real work. It often took days to get from the initial writing to the first compile, and each turnaround thereafter was usually one day.

What process did we use during those days? It certainly wasn’t Waterfall. We had no concept of following detailed plans. We just hacked away on a day-to-day basis, running compiles, testing our code, and fixing bugs. It was an endless loop that had no structure. There was no discipline in the way we worked. It was just code and fix, code and fix, day after day, month after month.

I first read about Waterfall in a trade journal sometime around 1972. It seemed like a godsend to me. I felt the power of the concept. I wanted to believe it. Because, if it worked, it was a dream come true.

Apparently I wasn’t alone, because many other programmers and programming shops caught the bug too. And, as I said before, Waterfall began to dominate the way we thought.

It dominated, but it didn’t work. For the next thirty years I, my associates, and my brother and sister programmers around the world, tried and tried and tried to get that analysis and design right. But every time we thought we had it, it slipped through our fingers during the implementation phase. All our months of careful planning were made irrelevant by the inevitable mad dash, made before the glaring eyes of managers and customers, to terribly delayed deadlines.

Вот и Agile сегодня dominated, but it didn’t work. Точнее, и не должен работать. Это же не метод, с чего бы ему работать? Это набор принципов, которые просто помогают понять, что правильно, а что нет. Подменять процесс принципами — ой, всё…

И нет у всей этой философии задачи ускорить деплой. Ускорение — это наблюдаемый, даже желаемый, но косвенный результат.

И сегодня на эту тему дядя Боб сделал твит:

Agile is not about going faster. Agile is about destroying hope. The data produced by a good agile team provides a cold dose of reality to the managers — in time for them to — manage.

Делать замеры метриками, да ещё и менеджерскими — нельзя.

Warning

Test coverage is a team metric, not a management metric. Managers are unlikely to know what the metric actually means. Managers should not use this metric as a goal or a target. The team should use it solely to inform their testing strategy.

Double Warning

Do not fail the build based on insufficient coverage. If you do this, then the programmers will be forced to remove enough assertions from their tests in order to get the coverage numbers high enough. Code coverage is a complex topic that can only be understood in the context of a deep knowledge of the code and tests. Don’t let it become a management metric.

Не надо называть итерации спринтами (нагугли, что такое «спринт» в спорте). Разработка ПО — это марафон, тут нужны стайеры. Иногда получается. Иногда нет.

An Agile project begins with analysis, but it’s an analysis that never ends. The first thing you know is the date. We subdivide that time into regular increments called iterations or sprints.

Sprint is the term used in Scrum. I dislike the term because it implies running as fast as possible. A software project is a marathon, and you don’t want to sprint in a marathon.

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

Но это так же глупо, как верить в то, что часы отсчитывают время.

Ничего они не отсчитывают.

Если часы остановятся (или мы их поменяем), то что, время перестанет отсчитываться?

Если положение стрелок поменяем, то что, солнце быстрее уйдёт за горизонт?

Но часы нужны, чтобы ориентироваться относительно времени.

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

— Но ведь нам нужен Product Owner! — тонко заскулили из-под шконки. — А если не вовлекать закащщика в нашу кухню, то аджайла не будет!

Вот пример того, до чего доводит это скулёж: эффективные чуваки додумались нанять Product Owner:

Так все же, где найти PO?

Нанять нового? Он продукта не знает, его долго искать и потом вводить в курс дел, а начать делать задачи нужно уже сейчас; и не факт, что он впишется в команду, потом заново искать нового PO.

Может, тогда назначить на эту должность кого-то из уже существующих сотрудников? А кто же тогда на его месте будет? И как он на новом месте вообще справится, он ведь практически ничего о владении продуктом может и не знать? Кто будет его обучать?

Ну не пиф-паф ли?!

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

Но одно дело — замерять и понимать скорость, и другое дело — замерять и заставлять эту скорость выдерживать и доезжать в пункт назначения ровно в %какое-то время%.

Если же тыкать в заказчика этим нашим аджайлом, то придётся очень упрощённо объяснять, что это такое, придётся это всё продавать. И будет вот это вот всё «Ну, это когда быстрый деплой. Всё будет очень быстро. И вам не нужны будут тестировщики. И после каждого спринта у вас будет работающий продукт» с очень далекозаползающими последствиями. Упрощение же. Для дебилов.

Работающий продукт ≠ Хорошо/правильно работающий продукт.

Остальное додумывайте сами.

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

Без звука. Автор видео — Жека Козлов.

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

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

Бо если не понять, почему всё именно так, то и не понять, как сделать иначе.

О, а кто это?

А это тот самый чувак, который когда-то написал на Хабре статью «Когда я говорил»:

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

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

Когда я говорил, что нельзя всех подряд называть «синьорами», вы продолжали их создавать. Теперь у нас куча 23-летних синьоров и все равно х*р его знает, чем абстрактный класс отличается от интерфейса».

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

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

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

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

Делает обобщающие утверждения в стиле «дела обстоят так и эдак», не расписывая доказательства, даже если, кхм, в формате статьи доказательства вроде бы некуда совать, но в действительности — есть куда их совать и класть и даже ложить.

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

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

Ещё он автор участник и спикер многих конференций, таких как Microsoft DevCon, Microsoft SWIT, DevConf, MDDay, Mobile First, TEDx Винница. Неоднократный выступатор, в общем, молодцом.

Ну, и собрал он немного-немного своих статей, и положил их под одну обложку.

В бумаге печатается on-demand и стоит очень дешево, а epub и pdf раздаются бесплатно.

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

Не всё, что получает номер ISBN, является книгой. Вот и тут, получилась не книга, а действительно всего лишь — ВНЕЗАПНО! — сборник статей, логически разбитый на три большие части:

— высшее образование,

— найм,

— быт.

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

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

Читать его газетные вещи — очень интересно.

Но читать их сразу одну за другой — очень утомительно, нет контекста, не всё подразумевается и очевидно, многое в репортажном стиле письма просто не нуждается в доказательствах, и сообщается как «очевидный факт же!».

Не видел ещё человека, который прочитал то же его классическое собрание сочинений в четырех томах. Я на втором томе начал издыхать, хотя в то время для меня, начинающего журналиста, Гиляровский был как Велимир Хлебников для поэтов, а кто такой Хлебников я не буду объяснять, ибо озверею…

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

PS

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

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

PPS

Найденные баги в epub-файле «Когда я говорил» простые:

• глава «Парадокс предсказателя» недописана,
• глава «Благодарности» и пуста, и вставлена среди других глав.
• а у какой-то главы не был указан год выпуска, зато указано время (hh-mm).

Баги в pdf-версии глобальнее — там текст представлен изображениями (походу, слайды из препринт собраны в pdf). Вообще нет оглавления. И да, контент беднее, в epub больше текста, чем в печатной версии.

Давайте мы не пойдем на очередной тренинг по тестированию методом замученного поиска в аджайл.

Никуда это от нас не денется просто потому, что это не для всех и не для каждого.

Все равно ведь «Было очень интересно; вопросы появятся после практического освоения полученого материала; но поскольку в нашей компании это будет будет невозможно внедрить, то практического освоения полученого материала не будет; поэтому вопросов нет и не будет…» Фубля!

Давайте мы возьмем, купим, скачаем, нагуглим, разъяндексуем хотя бы книжицу ‘A Practitioner’s Guide to Software Test Design‘ за авторством Lee Copeland (он еще жив).

Там есть целый раздел «Black Box Testing Techniques», и содержимое его такое:

• Equivalence Class Testing
• Boundary Value Testing
• Decision Table Testing
• Pairwise Testing
• State-Transition Testing
• Domain Analysis Testing
• Use Case Testing

Это, на минуточку, основные подходы к тестированию программного обеспечения.

Это наша мамкина титька, если угодно.

Давайте эти главки прочитаем хотя бы по-диагонали.

И давайте сделаем это ПЕРЕД тем, как пойти на очередной тренинг по тестированию.

А на очередном тренинге мы будем не слушать, а выяснять и прояснять.

А если соображалки на «прочитать ДО того, как» традиционно не хватает, тогда мы не будем брюзжать, что «тренер просто пересказывает Коупленда«.

Пусть он нам хотя бы Коупленда пересказывает.

Давайте мы хотя бы Коупленда освоим.

параметры качества и дефектов

В частности:

1. в какой книге я прочитал про этот метод?
2. где я взял эту диаграмму?
3. как я применяю эту метрику в проектном быту?

Мгм…

В какой книге прочитал про этот метод?

Шоб я знал…

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

В целом я эту форму архи НЕ одобряю. Она слишком формальна, и преисполнена недостаков:

1. не все дефекты связаны с определенной функцией, как это хотелось бы отобразить на диаграмме. Бывают дефекты «на стыке», или связанные с несколькими функциями одновременно. Такие баги на такой диаграмме не отобразить.
2. диаграмма не отображает важность багов. Просто вот для фичи №17 найдено 4 бага. И что? Насколько они влияют на функционал, а следовательно, и на качество всего проекта? Если попытаться на диаграмме отобразить не количество багов на функцию, а просто указывать «вот для этой функции были найдены баги«, это будет смотреться круто, но не более. Степень удовлетворенности или неудовлетворенности она не отобразит.
3. в информации с подобной диаграммы не очень много смысла в проектной работе. Смысл ведь в том, чтобы предоставить адекватно работающую систему, чтобы все было «по нулям» или выше нуля, а не в том, чтобы ПОКАЗАТЬ, что где-то есть дефекты.

Где взял эту диаграмму?

Открыл «Excel 2003», в столбике проставил циферки, выделил сектор с циферками, нажал на иконку «Создать новую диаграмму»…

Я сделал ее для того, чтобы более внятно объяснить свое видение в определенный момент, не более.

Как применять эту метрику в проектном быту?

Ну, как…

Рисуем диаграмму, вешаем на стену, подводим к стене тех, кто ответственен за разработку функции, собравшей наибольшее количество багов, и расстреливаем.

Или предлагаем каждому написать на ней «Я больше не буду делать баги!«, но ей-богу, я бы выбрал в этой ситуации расстрел автора подобной диаграммы 🙂

Предварительно скачиваем три книги:

1. Андрей Парабеллум — «Бизнес и ЖЖизнь«
2. Андрей Парабеллум — «Бизнес и ЖЖизнь 2«
3. Вячеслав Панкратов — «Черная книга менеджера«,

Последовательно читаем.

И лишь опосля продолжаем тутошнее чтение.

Причем начинаем с места «…и немедленно выпил«.

Все зыбко и неясно

Бывают люди разные.

Некоторые — вполне газообразные, да.

Разность эта оценивается по настолько многим параметрам, что для простоты разговора нам следует всё слегка упростить.

В частности, есть люди, которые ориентированы на достижение результата.

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

Им пофигу, каким образом результат достигается.

Нужно сделать презентацию машины? Браза, не вопрос! Садись и слушай! Слайды и документы с техническими параметрами выброси, ты меня слушай!

Нужно сделать презентацию второй машины? Да не вопрос! Садися сюда, братан, поехали.

Какое ещё соответствие планетарной системы распредвальных шатунов стандарту EST-1252g по Бернской конвенции? Такое бывает? Ты в эти мелочи не влезай, нигга, ты послушай, как ревёт мотор, да?!

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

Еще лучше, если в итоге результат математически зримый и понятный.

Машина — продана.

Деньга — получена.

Движение — ощутимое.

А еще бывают люди, которые ориентированы на процесс.

Такие в продажах не задерживаются. Это отличные контролеры, например, но никак не продающие.

Таким очень важно понять, каким образом надо провести презентацию.

С чего начать.

Чем завершить.

Какие документы надо положить на слайды, а какие вручить лично.

Какие технические характеристики машины следует указать, а какие — нет.

Таким надо готовиться ко встрече с клиентом.

Таким нужны планы и инструкции.

Им важна повторяемость и планомерность.

Им нужны определенные типы клиентов.

Таким бывает пофигу, чем и когда всё дело закончится, и когда за машину будут получены деньги, и когда будет завершен финансовый год, и… Для них финансовый год никогда не завершается. Все плавно длится, и движение это завораживает, чарует, мерцает и заманивает… Это ПРОЦЕСС!

Типичное мышление представителей: Кстати, когда у нас зп выдают? Они что там, вообще не думают, что надо зп выплачивать вовремя? За кого они там нас держат? ©

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

В общем, красиво, но редко. Очень редко. Бизнес этого не приемлет.

По тем же причинам люди типа «контролер» редко становятся начальниками или (упаси Будда!) владельцами бизнеса.

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

Да, работы было много, а результат — не впечатляет…

Такой человек старается следовать всем законам и предписаниям, чтобы в итоге, собрав «правильный» пакет документов, можно было автоматически получить награду как результат.

А в итоге в ОВИР им говорят: и вот этот документ уже не обоснование, и это тоже уже не рассматриваем, и вообще, нет у вас права жить в нашей офигенной стране, у нас своих идиотов хватает…

А в итоге клиент им говорит: и вот тут не блестит, и вот эта пимпочка не такая няшная, как хотелось бы, и вот там перпендикулярные линии не так параллельны, как это принято в современном интернете, и вообще, вы же были профессионалами, за что я вам плачу…

А в итоге начальник им говорит: я, блять, плачу за, блять, работу, блять, а не за блять, блять, блять, овертаймы, блять…

Из всех типов личностей я сейчас намеренно говорю только об этих двух противоположностях, бо они чаще всего сталкиваются в ролях «Начальнег бизнеса — Манагер отдела обормотов IT».

Точнее, именно их сопоставление наиболе заметно и привычно.

Смотрим на модель компетенций технических людей и менеджеров (источник с толкованиями):

Она дает ответ на вопрос «почему некоторым людям-программистам очень сложно стать менеджерами?«. Да потому, что уровни компетенций разные.

«Контролеру» очень важно, чтобы код был в порядке. В добротном порядке. «Идет рефакторинг!» — рычит он. «Контроль версий! Коммит в транк!» — пугает он окружающих его менеджеров.

«Менеджеру» все эти реФАКторинги до одного коммита, он ждет и ищет работающий продукт. Как организован код продукта — ему до транка… У него директивность и настойчивость развиты, а не самоконтроль и попытка наработки экспертзы, чтобы «все было на своих местах».

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

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

Общие слова, конечно, но по-другому как сказать?

Теперь представим себе, что манагер — не только руководитель и прокси между технарем и клиентом. Манагер — еще и владелец бизнеса.

И запрем их в одной комнате два на два метра.

И послушаем их речи на тему того, как надо работать.

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

Он будет обучать технаря основам мироздания и бизнеса.

Целям, а не средствам.

Ориентированности («Возьми, блять, и сделай!«, «Возьми, блять, и предупреди заранее!«, «Возьми, блять, и скажи, блять…«, «Шо, блять, денег хочешь, как у того, кто продает? Возьми, блять, и начинай продавать!«), а не планомерности и повторяемости результата.

Переговорить этого манагера для технаря психически невозможно. На то манагер и манагер, потому что лидер. А на лидера гавкать невозможно — загрызёт.

Можно только передразнивать лидера, но это чревато.

Можно копировать поведение.

Выговаривать подчиненным «Возьми, блять, и сделай коммит в транк! РеФАКторинг твою материнскую плату!«.

Можно мимикрировать.

«Я, блять, пришел утром на работу вовремя, а вы все опоздали, да вы все д’Артаньяны, блять, а ведь мы с вами когда-то ДОГОВОРИЛИСЬ...»

Но это кончится для технаря очень, очень, очень, очень, очень плохо. Ибо если нет ясного понимания личности «кто я, что я, зачем я» — результат не будет впечатляющим.

Будут метания и переживания.

Результат будет унылым, если нет понимания, когда можно/нужно ответить на очередное «Возьми, блять, и сделай!» простым и ясным «Не буду, блять! Лучше давай сделаем вот это и это…«, и итогом будет не страшащее многих планктоновцев увольнением, а благоприятное развитие отношений.

Тут всё понятно?

Если до сих пор все понятно, тогда переходим к «менеджеру-чернокнижнику» Вячеславу Панкратову.

Точнее, к его книге.

«Черная книга менеджера» очень важна для расширения мировозрения каждого, кто вовлечен в айтишную жизнь.

Не всё то, о чем там написано, правда.

Не все тамошние сентенции адекватны.

Не все тамошние соображения должны быть немедленно переняты и использованы.

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

Не всё тамошнее «отрезвляет» 🙂

Но абсолютно ВСЁ тамошнее категорически необходимо для ознакомления, осознания и последующего просветления.

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

В его «книге» нет сюжета и его развития, нет «новостного повода», нет фабулы. Все это к его книге не подходит.

Сила этого «речитатива рассуждений» в его тематичности, чеканности, сконцентрированности.

Да, именно такой тип мышления репрезентативен для «владельцев бизнеса» в принципе.

Да, именно такая импульсивность и ориентированность на результат в ущерб организованности пугает, путает и треножит многих «начинающих» менеджеров, особенно глав IT-отделов в составе какого-то бизнеса (как указал автор, вся книга — это монологические песни-пляски владельца бизнеса перед начальником отдела IT).

Да, именно неосознание этих основ (подразумеваются основы определенного мышления) приводит к конфликтам и потерям, особенно в бизнесе.

Каждому юноше, ступающему на стезю «возьмиблятьисделальщика» следует понимать, чего от него ожидают в действительности. Ведь редко бывает, чтобы ожидания озвучивались и регистрировались в документальном виде. Мир полон подразумеваний 🙂

А на стыке «я думал, что тут имеется ввиду» и происходит самое, блять, интересное.

И уже не юношам это тоже необходимо, в кратких выражениях проясняет многое из того, о чем «бизнес» не распространяется, это же так очевидно подразумевается.

Все эти сложносочиненные выражения отражают не силу русского языка, а какую-то крайнюю степень раздражения от попыток растолковать «очевидные» вещи.

Растолковать, наверное, получилось… От лидеров-менеджеров автором были получены положительные отзывы, бо это их стихия, их соображения, их «язык» и их образы.

А вот технари-контролеры еще должны высказаться.

В общем, часа на чтение мне не понадобилось, это поглощается весьма быстро, бо это собрание слайдов. Жду её появления «в бумаге», если будет.

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

Например, меня соображения вроде «Возьми и сделай!» очень мотивируют, если это я сам себе говорю.

Про..бался по срокам — так сядь, блять, и делай, пока не закончишь, но чтобы завтра с утра этот вопрос был решен!

А вот если это мне говорят со стороны, петрушка уже совсем другими делами колосится…

— Сделай это… И кстати, менеджер направления из США уже сообщила, что all of you should be working this weekend? Well its true, be prepared.

— Не… вряд ли это будет разумно, я думаю, что…

— Кого интересует, что ты думаешь? Возьми, блять, и сделай!

— о_О

Еще подумалось, что если соображение «не планируй выпуск на день рождения ребенка подчиненного» (вольная цитата из первоисточника) перенять напрямую, то будет так:

— Итак, выпуск релиза был назначен на понедельник.

— Знаете, давайте перенесем, бо в понедельник у нашего сотрудника ДР сына…

— о_О

На вкус книга…

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

Главное ведь что?

Главное —

• суметь объяснить,
• суметь понять,
• open mind for a different view,
• не смотреть на мир в черно-белой палитре,
• не скатываться в категоричность суждений,
• не прибегать к давлению,
• находить своё место по своим возможностям и по своему ритму,
• чтобы делать своё дело с явным и хорошо ощущаемым результатом,
• чтобы была не работа, а сотрудничество, с обоюдным профитом.

Типа:

1. Сотрудничество.
2. !!!!!!
3. PROFIT!

А все остальное — прилагается со временем.

PS Всё хорошо с распространением книги, но получение файла через подписку — чертовский неудобняк, нах! Удобнее было бы «подпишись и автоматически получи письмо с вложенным файлом».

Взял бы, блять, и сделал! 🙂