Сайт The Daily WTF уже 14 лет собирает курьёзные, дикие и/или печальные истории из мира ИТ. Я перевёл несколько рассказов, показавшихся мне интересными. Все имена и названия компаний изменены. Предыдущие выпуски можно найти по метке "любопытные извращения".
История первая: «Не просто блестящая»
[Оригинал]
У всех нас были коллеги, неспособные выполнять свою работу. Джараду тоже с этим повезло.
Он работал в Initech в небольшой группе разработчиков, создававших Windows-клиент для заказчиков, которые использовали его для взаимодействия со своим сервером. Компания решила портировать приложение с .NET на Java. Самое важное руководство порекомендовало на роль руководителя проекта глубокоуважаемую ведущую Java-разработчицу Кишу из Intelligenuity. «Не беспокойтесь», — сказало руководство. «Intelligenuity нанимает только самых блестящих программистов».
На первом совещании по проекту менеджер объявил, что для Java-проекта они будут использовать Eclipse. Киша заявила: «У меня нет Eclipse. Может кто-нибудь прислать?» Джарад отправил ей ссылку. На следующем совещании он спросил её, установила ли она Eclipse. Она ответила, что не смогла скачать среду, поэтому дождалась следующего совещания, чтобы попросить о помощи. Менеджер подбежал к её машине и решил проблему, нажав на ссылку для скачивания.
Перенесёмся к следующему совещанию: Киша сообщила, что не может продолжать работу, потому что «у Eclipse какие-то проблемы с JDK, может кто-нибудь мне его прислать?» Джарад снова прислал ей ссылку. Несколько дней спустя на следующем совещании она сказала: «Eclipse не работает, потому что ей нужен jar-файл, может кто-нибудь его прислать?» А после этого «Может кто-нибудь мне прислать код примера создания классов, потому что Eclipse постоянно сообщает о NullPointerException?»
Наконец, менеджер изменил структуру совещаний. Они продолжили свои обычные совещания по Windows-клиенту, но добавили отдельное специальное совещание только для Киши. Со временем выяснилось, что она с её мужем были друзьями очень высокопоставленного руководителя и его жены. Отдельное совещание провели для «обеспечения её успешной работы»; это означало, что менеджер команды писал за неё код.
Однажды Киша сказала менеджеру, что у клиента возникла критическая проблема с веб-порталом, и что как можно скорее нужно провести совещание с клиентом, чтобы решить его проблему.
Менеджер организовал совещание с участием клиента, его самого, Киши, Джарада и проект-менеджера, чтобы решить проблему раз и навсегда. В день проведения встречи клиент был удивлён количеству сотрудников техподдержки и менеджеров. Он объяснил: «Эм… „проблема с порталом“ заключалась в том, что я попросил у Киши URL веб-портала. Достаточно было отправить его письмом».
Иногда в этом мире бывает справедливость, и Киша в результате потеряла свою работу.
История вторая: «Трёхмесячный зуд»
[Оригинал]
В мате 2016 года Иэну нужна была работа. Почти сразу после начала поисков ему повезло: он нашёл крошечный стартап, нуждавшийся в работнике со знанием архитектуры Python и навыками проектирования. «Крошечный», потому что кроме Иэна в компании было всего три разработчика под руководством её основателя Джека.
Собеседование с Иэном проводил сам Джек. После технического теста он узнал больше о проекте компании: почти завершённом прототипе приложения для iOS. Пользователь синхронизирует свой телефон с наручным пульсомером, после чего телефон должен был воспроизводить музыку, соответствующую текущим занятиям пользователя. Основной задачей приложения была помощь в достижении необходимого пульса при тренировках. Приложение также использовало акселерометры телефона для отслеживания темпа пользователя при движении. Эти данные, по утверждению Джека, должны были оказаться полезными для исследований болезни Паркинсона. Своё заявление он подкреплял научными статьями из самых лучших университетов. Джек хотел, чтобы Иэн разработал новую систему бэкенда для хранения данных и обработки запросов.
Джек был дружелюбным и харизматичным, а его энтузиазм заражал окружающих. Иэн сразу же принял предложение, и приступил к работе на следующий день. Его офис был тесным, но всё-таки принадлежал ему одному. Его задачей было создание необходимого приложению бэкенда.
Прошло две недели. Одним ранним сонным утром понедельника Джек пригласил свою команду разработчиков в переговорную. Яркий свет, бивший с его Powerpoint-презентации, обжигал сетчатку.
«Я тщательно всё обдумал. Мы — совершенно новый стартап. Никто ведь не знает о нас, правда? Нам нужно сделать что-то, чтобы повысить узнаваемость бренда. Итак, я решил: мы избавимся от музыкальной части приложения и сосредоточимся исключительно на сборе данных».
Иэн инстинктивно едва не произнёс «Что?!» Им придётся выбросить результаты двух недели работы. К тому же раньше часть, отвечающая за сбор данных, была совершенно необязательной.
Джек переключился на другой слайд, где были показаны метрики, которые он теперь хотел отслеживать у каждого пользователя. Их было так много, что пришлось использовать самый мелкий шрифт. Чтобы прочитать, Иэну пришлось прищуриться.
«Если собрать достаточно большой стог сена, в нём обязательно появится иголка!», — сказал Джек. «Мы сделаем приложение бесплатным, и работа с ним будет подразумевать обязательную регистрацию. Настоящим доходом для нас станут собранные данные».
Капитал инвесторов был потрачен на роскошный офис в деловом центре города; разработчики бесплатного приложения достойны только лучшего. Джек нанял второго iOS-разработчика, специалиста по data science и интерна.
«Но не давайте интерну никакой важной работы», — сказал Джек сотрудникам на полной ставке.
Освоившись с новой ситуацией, Иэн начал разрабатывать архитектуру новой системы, которая будет регистрировать все необходимые данные.
Три месяца спустя Джек выбросил всё в мусорное ведро. «Никаких приложений! Нам нужно новое направление развития!»
Новое видение Джека заключалось в создании веб-сайта, на котором люди должны будут указывать композиции, которые они слушают во сне, во время тренировок и занятий другими делами.
«Людям нравится говорить о себе», — сказал Джек. «Мы не должны им платить за то, что они дают нам свои данные!»
Для создания веб-сайта был нанят фронтэнд-разработчик. Вскоре после запуска сайта Джек похвастался инвесторам, что он достиг миллиона уникальных посетителей. На самом деле было всего около 300 регистраций, половина из которых создана одним человеком.
Можно уже догадаться, что случилось ещё через три месяца. Джек отказался от медленно развивавшегося веб-сайта в пользу Slack-бота, который должен был отвечать на команду "Play ${song} by ${artist}", находя композицию в Spotify и давая на неё ссылку. Виджет Spotify проигрывал бы 30-секундное превью или, если у пользователя есть аккаунт Spotify Premium — всю песню.
«И это всё? Как мы будем зарабатывать деньги?», — к этому моменту разработчики уже не сдерживались в своих претензиях.
«Подписка будет платной», — смело ответил Джек.
«За чат-бота?», — возразил Иэн. «Чтобы он работал полностью, пользователю и так нужен Spotify Premium. Если мы хотим, чтобы люди платили сверх этого, нужно дать им больше возможностей!»
«Мы разберёмся с этим позже», — ответил Джек.
Джек поручил разработку нового основного продукта компании интерну, нарушив требования того Джека, который был шесть месяцев назад. Интерн прикладывал максимум усилий, но вскоре был вынужден вернуться в школу; незавершённый код без церемоний швырнули на доработку фронтэнд-разработчику. С помощью одного из iOS-разработчиков он его закончил. А чем же занимался Иэн? Он создавал информационную панель мониторинга и логгинг, ведь Джек настаивал, что они привлекут достаточно пользователей, чтобы оправдать усилия.
Прошло ещё три месяца. Было добавлено множество «функций», например, бот навязчиво просил пользователей в канале Slack использовать его. Такое поведение нарушало условия использования Slack, поэтому приложение не допустили в магазин; Джеку пришлось самому рассылать ссылки заинтересованным людям, чтобы они устанавливали его вручную. Сначала продукт был передан 50 «очень дружественным» компаниям, которые Джек знал лично; из них только некоторые установили его, и ещё меньше продолжили пользоваться на следующий день. Затем Джек расширил рекламу на 300 «дружественных» компаний, но с тем же результатом.
Переломный момент настал для Иэна тогда, когда Джек начал настаивать на дополнительном рабочем времени, несмотря на то, что Иэн никак бы не мог помочь другим разработчикам в их задачах. Тем не менее, Джек заставил его задерживаться допоздна, чтобы «продемонстрировать солидарность». Это стало последней каплей: Иэн написал заявление об увольнении через две недели. Его последний день на работе совпал с выпуском Slack-бота, во время которого он наблюдал на панели мониторинга очень прямые линии. Когда он окончательно покинул роскошный офис, стартап всё ещё не заработал своего первого цента.
К счастью, у Джека был план. После ухода Иэна он начал всё с нуля и собрался создавать новый продукт. Нет, он не принесёт никаких денег, но им ведь нужно сначала, чтобы о бренде узнали.
История третья: «Конвейер бэкапов»
[Оригинал]
«Э-м-м… можешь взглянуть для меня на кое-что?»
Пэт оторвалась от програмирования новых функций, и увидела стоявшего возле её кубикла Милтона.
«Думаю, у меня проблемы», — добавил Милтон.
Одной из основных внутренних систем компании был конвейер обработки данных. Возможно, слово «конвейер» можно считать преувеличением, потому что на практике это просто несколько shell-скриптов и программ Python, которые достают данные из файлов, выполняют операции с этими данными и сбрасывают результаты в другие файлы, считываемые затем другими скриптами. В процессе работы люди обычно брали последнюю версию скриптов из системы контроля версий, модифицировали и настраивали их таким образом, чтобы те давали ответ на конкретный вопрос, связанный с данными. Если казалось, что этот конкретный процесс мог обладать ценностью, то они подчищали код и снова добавляли его в систему контроля версий. Если же они считали, что код им больше не понадобится, то просто выполняли reset на HEAD.
Однако некоторые, например Милтон, в основном хранили собственную копию всех скриптов. Или, как случае с Милтоном, несколько копий. Милтон лучше всех знал конвейер обработки данных, но основной объём этих знаний был заключён в его личной библиотеке скриптов.
«Я подумал, что стоит внести мои изменения в систему контроля версий», — сказал Милтон. «У меня был скрипт, вызываемый скриптом, который вызывался скриптом, и всё это зависело от кучи созданных shell-переменных, например $SETUP_DIR».
Пэт кивнула.
«Поэтому я захотел реорганизовать всё это в аргумент, чтобы кодом могли пользоваться другие люди. Я так и сделал… но перед тестированием забыл изменить вызывающие скрипты, чтобы они передавали аргумент».
В частности, скрипт Милтона содержал такую строку:
#!/bin/sh
rm -rf $SETUP_DIR/*/
Он выполнил её рефакторинг вот в такую строку:
#!/bin/sh
rm -rf $1/*/
Shell-скрипты не волнует существование этих переменных. У Милтона была среда, обеспечивающая постоянное существование $SETUP_DIR. Но $1 — это первый аргумент, и если не передать аргумент, то он будет пуст. Поэтому новый скрипт Милтона при запуске без аргументов разворачивался в rm -rf /*/, удаляя всё, к чему имела доступ его учётная запись.
В основном это привело к многочисленным попыткам удалить файлы, на которые у него не было прав. Кроме того, это означало исчезновение его каталога home с всей кучей спагетти-скриптов, которые совершенно невозможно было воссоздать, потому что они никогда не попадали в систему контроля версий.
«Это ведь можно как-то исправить?», — спросил Милтон.
«Ну да, конечно. Всё можно восстановить из твоего последнего бэкапа», — ответила Пэт.
Хотя на всех системах Windows был запущен автоматизированный инструмент для бэкапов, ни на одной системе Linux он настроен не был. Отдел поддержки посчитал, что если ты достаточно технически грамотен, чтобы работать с Linux и писать shell-скрипты, то тебе хватит знаний настроить собственную систему бэкапов. Специально для этой цели существовала доступная всем SAN.
«О, а я… так и не настроил бэкап», — прошептал Милтон. «Ну… по крайней мере, я ведь не выполнил push?»
Пэт понадеялась, что Милтон извлечёт правильный урок из этой ошибки.
История четвёртая: «Что такое плавающая точка?»
[Оригинал]
Программистов-новичков ожидает множество ловушек: разница между объявлением переменной и её инициализацией, необходимость иногда использовать для завершения строк точки с запятыми, ошибки смещения на единицу… Все мы встречали в нашей отрасли гениальных программистов-самоучек, способных создавать масштабные приложения с правильной архитектурой даже во сне, но мы видели и джуниоров-самоучек, едва освоивших основы и считавших, что это всё, что им понадобится. В конце концов, дипломы и формальное образование нужны не просто так.
Эта история началась, когда Олаф только выпустился из университета и трудился на своей первой настоящей работе в должности «программист-стажёр». Компания поставила себе цель усовершенствовать управление в государственной системе здравоохранения: каждый, кто имел сомнительное удовольствие общения с системами здравоохранения, скажет, что это благородная задача. Однако компания была основана врачом, имевшим только поверхностные знания в PHP, который он изучал самостоятельно, когда выдавалось время.
Олаф приступил к делу, намереваясь применить свои знания шаблонов проектирования. PHP легко изучить, но в нём трудно добиться мастерства; во многих примерах написанного на PHP ПО используются всемогущие объекты (god objects), а код перемешан с представлением — две серьёзнейшие ошибки, о которых, тем не менее, не говорится в большинстве онлайн-туториалов. Олаф начал отделять функцию от формы, создавать объекты, которые можно использовать многократно для минимизации копипастинга, и занимался другими подобными задачами, с радостью превращая хаос переданного ему кода в порядок.
И поэтому он очутился в офисе начальника, устроившего ему головомойку.
«Другие программисты этого не поймут!», — кричал босс. «Код слишком сложный. Зачем ты его меняешь? Он работает, нужно было оставить его!»
Обескураженный, Олаф вернулся к работе и загрузил в основную ветвь чистую версию без своих изменений. Пытаясь избежать столкновения с плохими практиками, он начал работать над багом в системе учёта, имеющим высокий приоритет и срочность, потому что он касался выставления счетов. Пользователи могли загружать на сервер файлы CSV с информацией о своих тратах, а система суммировала значения по категориям и создавала биллинговые отчёты. Однако где-то внутри закралась ошибка округления, приводящая в некоторых важных граничных случаях к неправильным суммам.
Олаф учился больше, чем его коллеги, но ни одно обучение не является всеобъемлющим. Ему быстро удалось определить, что это была математическая ошибка с плавающей точкой. Так как десятичные числа нельзя представить в двоичном виде с полной точностью, в граничных случаях возникали ошибки вычислений. Он начал искать правильные способы обработки десятичных значений в PHP. В отличие от Node или C#, внешние библиотеки в PHP подключать довольно сложно, потому что в этом языке нет встроенной поддержки управления пакетами. Он не мог разобраться, как добавить библиотеку, способную правильно выполнять математические действия. Так как ПО вычисляло только суммы, Олаф решил использовать целочисленную математику: считать значение, избавиться от десятичной точки (чтобы значение 10.50 $ представлялось в виде 1050), выполнить вычисления, а при отображении снова добавить десятичную точку.
Ещё одному из джуниоров понравилась эта идея. Сениор-разработчик одобрил её, но начальник наотрез отказался от предложения. Как же он это аргументировал? «Это не ошибка вычислений с плавающей точкой. Она возникает из-за слабой типизации PHP, программа пытается суммировать значения как строки, а не как числа».
(Для тех, кому любопытно: для конкатенации строк PHP не использует оператор "+". Вместо него используется ".". Результатом "hello " . "world" станет "hello world".)
В результате сениор-разработчик реализовал такое решение: отделить целую часть от дробной, чтобы 10.50$ превратились в 10.00$ и 0.50$, а затем суммировать каждую часть по отдельности.
Олаф не стал задерживаться, дожидаясь, когда они выяснят, что баг по-прежнему на месте, ведь дробную часть с центами программа всё равно обрабатывала как число с плавающей точкой. Он нашёл работу получше с языком получше, и ушёл из компании.
История пятая: «Калькулируемая безопасность»
[Оригинал]
В конце 80-х Карл какое-то время работал в фирме по разработке ПО, которая занималась системами авионики и глобального позиционирования для военных и гражданских заказчиков. По рабочим делам он часто посещал Schlockdeed Corp — заказчика с контрактом на разработку нового поколения реактивных истребителей для американской армии. Из-за строгой секретности их работы очень важно было обеспечивать безопасность.
Каждый раз, когда Карл входил или выходил с предприятия, ему приходилось проходить через отдел службы безопасности. Там тщательно проверяли его портфель, куртку, коробку для ланча и почти всё, кроме полного исследования полостей тела. Несмотря на педантичность ежедневных проверок в Schlockdeed, некоторые их «меры безопасности» граничили с абсурдом.
В эту эпоху передачи информации через "флоппинет" программисты частенько брали с собой на работу и уносили с неё коробки с гибкими дисками. В Schlockdeed действовала довольно расслабленная политика перемещения дисков, несмотря на то, что это был простейший способ кражи их секретов. Подрядчикам наподобие Карла после проверки биографических данных выдавали «пропуск на носители». Это была карточка, позволявшая им без вопросов выносить и заносить в здание любое количество гибких дисков.
Работа Карла ничем не омрачалась, пока он не решил принести в офис свой любимый калькулятор HP-41CX. Они работали над сложными алгоритмами, и запись уравнений на доске занимала слишком много времени, поэтому Карл надеялся ускорить процесс. Во время утреннего осмотра охранник Билл вытащил HP-41CX и на его лице сразу же появилось обеспокоенное выражение.
Билл потянулся за рацией на плече: «Поли, ты нам нужен. У нас тут сложная ситуация». Карл очень растерялся. Неужели 41CX когда-нибудь использовали в бомбах? А может, это розыгрыш на первое апреля? «Сэр, нам нужно отправить вас к нашему CIO. Пройдёмте сюда», — сказал Билл.
Лицо Карла вспыхнуло, он пытался понять, какие проблемы у него возникли, ведь эти «проблемы» легко могут вылиться в наручники и тюремное заключение. Ещё он не понимал, зачем руководителю информационной службы (Chief Information Officer) проводить дополнительный осмотр. Билл привёл его в офис Поли, в котором находился дородный человек с усами в стиле 80-х. Табличка на его столе гласила, что это Calculator Inspection Officer.
«Приятель, мне нужно будет посмотреть на твою машинку для сложения», — сказал Поли, протянув руку. Билл передал ему HP-41CX. Поли внимательно осмотрел его и заявил: «Мне придётся его конфисковать. Видишь ли, в нём есть внутренняя память, поэтому его потенциально можно использовать для кражи секретов. В конце дня я его тебе верну, но даже не думай снова попадаться мне с этим!» Билл отвёл Карла обратно в главный отдел безопасности, уже без калькулятора.
По пути Билл объяснил, что программируемые калькуляторы строго запрещены в здании. Поли должен был следить за исполнением этой политики и относился к своей работе очень серьёзно. Если Карлу нужно было принести калькулятор, то допускались самые простые модели. После одобрения Поли на него наклеивался ярлычок AC (Approved Calculator), позволявший заносить калькулятор. Обескураженный потерей своего HP-41CX, он смирился с тем, что весь срок работы с Schlockdeed ему придётся дышать меловой пылью. Но, по крайней мере, у него есть «пропуск на носители» для свободного вноса и выноса флоппи-дисков.
Автор: PatientZero
