The Daily WTF на русском Заметка

The Daily WTF на русском

The Daily WTF - это ориентированный на программистов юмористический блог, созданный Алексом Пападимулисом и основанный на историях о разработке программного обеспечения и мире технологий. В основном это анекдоты, основанные на проблемах проекта, примеры кода и смешные истории, связанные с ИТ. На сайте собрана обширная коллекция таких случаев из реальной жизни от многих разработчиков, которые делятся своими странными и забавными встречами на работе, как техническими, так и личными, но всегда связанными с технологиями.

Трэд заметок

Дэвид Си, который пишет код на C++ для программной анимации, признался, что писал код, не уделяя первостепенного внимания качеству, из-за его одноразового характера. Однако одна конкретная строка кода заставила его пересмотреть свой подход. В этой строке использовалась передача параметров, в значительной степени основанная на массивах, что привело к неразборчивым именам переменных. Например, length4_3_3, по-видимому, попытка создать переменную, описывается как выражение диапазона размером в единицу. Такая конвенция именования не передает смысл данных, которые она содержит. Хотя код предназначался для временного использования, Дэвид признает, что код редко бывает по-настоящему одноразовым. Он размышляет о тенденции повторного использования кода в разных проектах. Автор предполагает, что даже одноразовый код может иметь долгосрочные последствия. В конечном итоге он советует читателям стремиться к лучшему качеству кода.
TruStage, компания по страхованию жизни, столкнулась со значительным инцидентом в области кибербезопасности 10 июля 2026 года, при этом основные бизнес-функции оставались частично доступными спустя месяцы. Компания все еще работает над выяснением масштабов взлома и не определила, какие данные были скомпрометированы или когда услуги будут полностью восстановлены. Были затронуты ее страховые операции, в то время как системы, поддерживающие кредитные союзы для банковских операций, остались работоспособными. Этот инцидент привел к многочисленным судебным искам и подчеркивает сложную посредническую роль в страховой отрасли.Страховой процесс часто включает в себя множество партнеров, таких как Ethos, которая использует ИИ для подбора клиентов и полисов, и Family First Life (FFL), которая сотрудничает с такими компаниями, как TruStage. Неспособность TruStage обрабатывать платежи из-за инцидента с кибербезопасностью приводит к аннулированию полисов. Это аннулирование приводит к потере комиссионных для агентов и обратным платежам для партнерских компаний, таких как Ethos и FFL.Президент FFL Шон Мейк публично раскритиковал Ethos на отраслевой конференции, назвав их "самым слабым звеном" в их партнерских отношениях и потребовав извинений. Публичное унижение Мейком сотрудника Ethos Дилана Каммингса рассматривается как особенно неловкий момент. Вся эта ситуация демонстрирует серьезный сбой в области кибербезопасности и аварийного восстановления со стороны TruStage, негативно влияющий на клиентов и создающий хаос в отрасли. В конечном итоге, инцидент выявляет институциональную некомпетентность TruStage и проблематичную бизнес-модель для стартапов в сфере страхования на базе ИИ, которые в значительной степени полагаются на одного эмитента.
Автор размышляет о стремительном развитии ИИ, отмечая переход от человеческих насмешек над ограничениями ИИ к будущему, где ИИ может высмеивать человеческие. Подборка юмористических наблюдений за прошедший год выделяет различные особенности и разочарования, связанные с ИИ. Тимоти У. кратко заявил: «Всё сложно», саркастически приветствуя владыки ИИ. Айнонимус сожалел о нежелательном распространении функций ИИ на их телефоне. Зверь в чёрном раскритиковал инструмент классификации изображений ИИ, утверждая, что ему не хватает интеллекта. Мариус Б. поделился забавным старым скриншотом странных предложений Бинга для «владельцев медведей». Оливье указал на забавную ошибку перевода ИИ, где ИИ предложил помощь, но затем запросил базовую информацию. Общее настроение — это забавное и лёгкое недоумение по поводу нынешнего состояния ИИ и его быстрой эволюции. Эти анекдоты запечатлевают момент времени, когда ИИ одновременно впечатляет и комично несовершенен. Юмор возникает из неожиданного поведения ИИ и развивающегося взаимодействия человека и ИИ.
CdXz5zHNQW_E0zl3oCQqd.png
Автоформатирование кода является стандартной и необходимой практикой для поддержания читаемости. Нет никаких веских причин не использовать какую-либо форму автоформатирования, будь то встроенная в редактор или запускаемая как шаг сборки. Даже многие IDE, такие как Visual Studio, весьма активно автоматизируют этот процесс. Это делает пример кода из старого приложения ASP.Net особенно озадачивающим. Функция Page_PreInit полностью содержится в одной строке, сразу за ней следует объявление Page_Load. Такое форматирование вызывает значительную путаницу относительно того, где вызывается функция Logic(). Исходный разработчик также реализовал проверку пользовательского агента на наличие "Safari" в строке браузера. Если "Safari" обнаружен, Page.ClientTarget устанавливается в загадочное значение "uplevel". Это демонстрирует сочетание плохих соглашений об именовании, проверки пользовательского агента и использования строк там, где могли бы быть более уместны перечисления. Наиболее тревожным аспектом является то, что этот проблемный шаблон повторяется на нескольких страницах приложения. Это говорит о том, что разработчик намеренно выбрал этот запутанный и нечитаемый стиль и считал его жизнеспособным решением для повторного использования.
Скрипт предназначен для вывода всех активных пользователей Active Directory и времени их последнего входа, но использует неэффективный и запутанный подход. Он перебирает каждую букву алфавита для фильтрации учетных записей пользователей, что не гарантирует полной алфавитной сортировки. Для каждой буквы создается новый объект DirectorySearcher, явно запрашивается только свойство 'name', а затем находятся все соответствующие учетные записи.Впоследствии, для каждого полученного имени скрипт создает еще один DirectorySearcher. Этот новый поисковик используется для запроса конкретной учетной записи пользователя с целью получения всех ее свойств. Хотя для поиска по имени пользователя ожидается только один результат, используется метод FindAll(), возвращающий массив.Это требует ненужного цикла для перебора массива из одного элемента. Наконец, выводится имя пользователя и время последнего входа, объединенные запятой. Дизайн скрипта крайне неэффективен из-за повторного создания поисковиков, избыточных запросов и нелогичного метода фильтрации. Несмотря на недостатки, его способность генерировать CSV для менеджеров делает его "критически важным" в организации.
Грета, работая в старой среде разработки на Pascal, столкнулась с ошибкой, из-за которой ее программа сообщала о несуществовании файлов, несмотря на их наличие. Она отследила проблему до функции FileExists из системной библиотеки. Эта функция полагается на FileAge, которая извлекает временную метку последней модификации файла. FileAge, в свою очередь, использует FileTimeToDosDateTime для преобразования форматов времени. Критическая ошибка заключается в том, как FileAge обрабатывает возвращаемое значение FileTimeToDosDateTime. FileTimeToDosDateTime возвращает булево значение для индикации успеха или неудачи и устанавливает код ошибки при неудаче. Однако FileAge не проверяет это булево возвращаемое значение. Если FileTimeToDosDateTime терпит неудачу, FileAge продолжает возвращать -1. Следовательно, FileExists интерпретирует это -1 как отсутствие файла. Первопричиной конкретной ошибки Греты было то, что процесс, записывающий файлы, не устанавливал "время последней записи". Без действительного времени последней записи FileTimeToDosDateTime терпит неудачу, заставляя FileAge возвращать -1, и таким образом FileExists ошибочно сообщает об отсутствии файла. Это подчеркивает распространенную проблему в системных библиотеках, где незначительные ошибки в обработке ошибок приводят к значительным функциональным сбоям.
Текст освещает несколько случаев, когда "ноль" представлен в негативном или невыгодном контексте. Дмитрий К. получил от The North Face "страшную синюю кнопку", что подразумевает вознаграждение в виде ничего. Ренан выражает разочарование 0% скидкой на Final Fantasy от Steam. Рейнир Б. жалуется, что нидерландские железные дороги должны ему 2,25, но заявляют, что возврат произойдет "около 0", что вызывает путаницу. Филип считает свои отношения с Office Depot невыгодными, так как на его счету 0 долларов после закрытия местного филиала компании. Баллы вознаграждения в приложении для поездок анонимного пользователя истекут в эпоху Unix, фактически став бесполезными. Эмили, столкнувшись со сложным преобразованием баллов вознаграждения, задается вопросом, не останется ли у нее -0,01 балла, подчеркивая разочаровывающий характер этих расчетов. Общая тема заключается в том, что ноль часто означает отсутствие, истечение срока действия или запутанные финансовые сценарии. Эти примеры иллюстрируют, как нулевое значение может восприниматься как недостаток, а не как нейтральный или положительный результат. Разнообразие ситуаций подчеркивает общую неудовлетворенность невыгодными вознаграждениями.
CdXz5zHNQW_L7qyl0OcGp.jpeg
Тип записи CAA в DNS позволяет владельцам доменов указывать, какие эмитенты сертификатов уполномочены выдавать сертификаты для их домена. Изначально определенный в RFC6844 и позже обновленный в RFC8659, основная концепция остается прежней. Ключевой особенностью записей CAA является флаг "Issuer Critical", предназначенный для того, чтобы эмитенты проверяли запись перед выдачей сертификата.Этот критический флаг был разработан как бит 0 маски битов флагов, что означает, что для его включения следует использовать значение 128. Однако распространенное недопонимание привело к тому, что многие использовали значение 1, интерпретируя бит 7 как критический флаг. Это неверное толкование широко распространено среди пользователей, которые не читали RFC внимательно.Эмитенты сертификатов, такие как Let's Encrypt, столкнулись с дилеммой: строго придерживаться спецификации и отклонять некорректно настроенные записи, или учитывать распространенную ошибку, чтобы сохранить функциональность. Они выбрали последнее, фактически приняв значение 1 как псевдоним для критического флага. Это решение признает практическую реальность пользовательских ошибок в ущерб строгому соблюдению первоначальной спецификации.Представленный фрагмент кода на Go для filterCAA демонстрирует, как это обрабатывается на практике. Он фильтрует по тегам "issue" и "issuewild", а также проверяет наличие неузнанных критических тегов. Примечательно, что код проверяет, установлен ли флаг в 128 (правильное значение) или 1 (часто используемое, неправильное значение), чтобы определить, присутствует ли неузнанный критический тег. Эта инклюзивность обоих значений отражает учет распространенной пользовательской ошибки в отношении критического флага.Автор ставит под сомнение целесообразность использования масок битов для таких флагов, когда это приводит к путанице и ошибкам, предполагая, что более простые механизмы флагов могли бы быть более читаемыми и менее подверженными ошибкам. Признавая полезность масок битов, этот анекдот подчеркивает, как их сложность может привести к значительным операционным проблемам в реальных реализациях. Взаимодействие между техническими спецификациями, пониманием пользователей и практической реализацией является повторяющейся темой.
Вала — это язык программирования, разработанный для Gnome, с функциями, похожими на C#, и производительностью, близкой к C. Он поддерживает асинхронное программирование с семантикой async/await, позволяя функциям передавать управление. Многие функции библиотеки ввода-вывода в Вала являются асинхронными, например, make_directory_async. Однако в основной библиотеке отсутствует асинхронная версия create_directory_with_parents, которая синхронно создает цепочки каталогов. Это упущение, вероятно, связано со сложностью обработки асинхронных состояний гонки. Автор, Эри, столкнулся с этой проблемой и реализовал собственное асинхронное решение. Первоначальный подход Эри заключается в попытке создания каталогов от конечного узла вверх, собирая недостающие родительские каталоги в массив. Затем он проходит по этому массиву в обратном порядке для создания каталогов. Этот метод считается неэлегантным, поскольку использует обработку исключений для управления потоком. Эри признает сложность проблемы, особенно управление асинхронными состояниями гонки. Представлена немного улучшенная версия основного цикла, но подход остается сложным. Несмотря на свою неуклюжесть, решение Эри эффективно устраняет недостающую функциональность библиотеки. Автор предполагает, что реализованная функция должна быть скрыта после того, как она будет работать правильно.
Автор, приближаясь к пенсии, получил предложение о работе в области специализированного программного обеспечения с отличной зарплатой. Процесс адаптации сначала был медленным, первые шесть месяцев ушли на ожидание доступа. Интервьюер, Фред, был высококвалифицированным специалистом и нашел общий язык с автором. Фред поручил автору проанализировать основное программное обеспечение компании, чтобы понять его и, возможно, модернизировать.Не успел автор представить свои выводы, как Фред неожиданно скончался. Это событие вызвало хаос в компании, и подрядчики, такие как автор, были в значительной степени забыты. В течение следующих восемнадцати месяцев автора в основном игнорировали, а время он использовал для создания среды разработки. В этот период он работал вместе с коллегой, который постоянно критиковал руководство.Новый менеджер автора был враждебен и пренебрежителен, неохотно давая задания. Казалось, компания состояла из пожилых сотрудников, защищающих свою систему, и новичков, пытающихся внедрить автоматизацию, что было нежелательно. В этот застойный период автор вносил свой вклад на сайт TDWTF. В итоге автора уволили, без обид с его стороны. Теперь он работает почтальоном последние несколько лет перед выходом на пенсию. Автор подчеркивает, что риск умереть от стресса, связанного с работой, является реальной опасностью.
CdXz5zHNQW_tmcjJ0Qed6.jpeg
В этом тексте обсуждается создание предметно-ориентированного языка (DSL) для определения спецификаций "источника". Эти спецификации включают в себя функции и иерархические шаги, подобно сложной грамматике. Вместо использования XML со схемами для лучшей структуры и ясности, предыдущая реализация выбрала менее надежное решение. Было создано правило XML-схемы, которое полагалось на обширное регулярное выражение для проверки данных. Это длинное регулярное выражение, состоящее из 1310 символов, предназначалось для обеспечения соблюдения грамматических правил. Автор подчеркивает, что такой подход оказался проблематичным и привел к ошибкам. Одна конкретная ошибка потребовала исправления, и автор с юмором ссылается на негативные последствия таких сложных регулярных выражений. Оригинальная грамматика вместе с правилами ее проверки представлена на английском и немецком языках. В тексте предполагается, что более структурированное представление XML с надлежащими схемами было бы лучшим, более поддерживаемым подходом. В конечном итоге попытка "сэкономить труд" с помощью сложного регулярного выражения оказалась неэффективной и подверженной ошибкам.
Редактор признает личную ошибку в запоминании дат, побуждая читателей поделиться похожими "календарными сбоями" с различных веб-сайтов. C_Chell столкнулся с проблемой ввода даты на IHG.com, что помешало завершить форму для дат прибытия в отель. Dragoncoder047 сообщил об ошибке "У вас осталось -1 месяц(ев) для заказа!" от GradImages, компании, уже известной плохим обслуживанием и навязчивыми письмами. Майкл Р. обнаружил проблему "дизайна пользовательского интерфейса времени Стэнстеда", показывающую время "00:06 завтра" для прибытия, что подразумевает временной парадокс. Кроме того, Майкл Р. отметил "Навигационную путаницу" на веб-сайте аэропорта Стэнстед. Наконец, Slaoput выделил форму, в которой было заявлено "Дата рождения не обязательна", но затем она стала обязательным полем при отправке. Эти анекдоты иллюстрируют общую тенденцию проблем с дизайном и функциональностью веб-сайтов, особенно в отношении обработки дат и времени.
CdXz5zHNQW_wgjGOXc7mY.png
Системы «мини-сплит» пользуются популярностью при модернизации старых домов благодаря своей экономичности и энергоэффективности, однако их зависимость от ИК-пультов дистанционного управления затрудняет интеграцию с системами домашней автоматизации. Частая проблема возникает из-за логики преобразования температуры в этих системах, особенно при пересчете между градусами Цельсия и Фаренгейта. Проект с открытым исходным кодом, направленный на интеграцию мини-сплит-систем в системы домашней автоматизации, выявил несовершенство метода преобразования температуры.В коде проекта используются таблицы перевода для преобразования из градусов Цельсия в градусы Фаренгейта и наоборот. Эти таблицы содержат конкретные, зачастую неточные сопоставления, что приводит к расхождениям по сравнению со стандартными формулами преобразования. Например, 18 °C неверно сопоставляется с 65 °F вместо более точного значения 64 °F (при округлении). Структура этих таблиц поиска свидетельствует о попытке приблизительного преобразования, а не о точных математических вычислениях.Изначально автор полагал, что это была наивная оптимизация, характерная для любительского проекта, но комментарий в коде поясняет, что речь идет о «прямых сопоставлениях, основанных на данных пульта». Это указывает на то, что неточности происходят из самого пульта дистанционного управления. Вероятно, пульт использует таблицы пересчёта из-за ограничений встроенного микроконтроллера, который, возможно, не способен эффективно обрабатывать вычисления с плавающей запятой.Следовательно, когда пользователь устанавливает на пульте температуру, например, 72F, пульт внутренне преобразует её в приблизительное значение в градусах Цельсия (например, 22,5C) перед отправкой команды на устройство. Это приближение, хотя и «достаточно хорошее» в большинстве случаев, создаёт несоответствия при точной автоматизации. По мнению автора, основная проблема заключается не в коде этого любительского проекта или в самом пульте, а в том, что во всем мире по-прежнему используются нестандартные единицы измерения (Фаренгейт), что вынуждает прибегать к таким неточным преобразованиям.
Рэйчел присоединилась к новой команде, где ее начальник, Зейн, настаивал на подходе, основанном на метриках, сфокусированном на максимизации производства виджетов при минимальных затратах. Автоматизированная производственная линия включала сложное программное обеспечение, изменения в котором проверялись только в реальном производстве из-за ограничений тестирования. Первоначальной задачей Рэйчел было обновление дашборда метрик в Google Sheets, который извлекал данные из шести баз данных, несмотря на то, что пользователи всегда предпочитали Excel. Команда отслеживала только выходные метрики, такие как "количество произведенных виджетов за единицу времени", без подробных данных для объяснения поведения системы или узких мест. Например, автоматический сканер контроля качества не записывал причины отклонения виджетов и даже количество отклоненных изделий напрямую.Изменения в программном обеспечении оценивались по общим выходным метрикам, что затрудняло проверку, поскольку эти метрики были "шумными" и подвержены внешним факторам, не связанным с самим программным обеспечением. Попытки Рэйчел внедрить изменение для записи отклоненных виджетов изначально были затруднены регрессиями метрик, вызванными экологическими проблемами, а не ее кодом. Простые изменения могли занимать недели для проверки из-за ограниченного количества тестовых запусков и необходимости учитывать регрессии метрик. Рэйчел начала добавлять инструментарий в код для сбора более подробных данных, надеясь построить полезную модель системы.Однако Зейн оставался одержим немедленными улучшениями ключевых выходных метрик. Он отвергал ценность сбора данных для понимания того, почему эти метрики вели себя так, как они вели, заявляя, что такие диагностические данные не являются "ключевыми метриками". Это создало фундаментальный конфликт между желанием Рэйчел понять систему и сосредоточенностью Зейна на основных показателях эффективности. Рэйчел нашла компромисс, гарантируя, что любые изменения, которые она вносила для улучшения основных метрик, также включали инструментарий для объяснения поведения изменения. Эта стратегия позволила ей как удовлетворить требования Зейна по улучшению метрик, так и постепенно повысить наблюдаемость системы. В конечном итоге, понимание сложной системы оставалось низким приоритетом по сравнению с продвижением основных метрик без всестороннего понимания их движущих сил.
Бразильской компании-разработчику программного обеспечения было поручено создать цифровую систему для полиции до Чемпионата мира по футболу 2014 года. Проект был значительно недооценен для имеющейся инженерной команды, требуя нереалистичных сроков. Руководство наняло множество неквалифицированных сотрудников, создав "проблему человеко-месяцев". Чтобы компенсировать это, инженеров заставили работать в режиме интенсивного аврала, проводя чрезмерно долгие часы, чтобы уложиться в срок. Предложенная функция для граждан по отправке фотографий происшествий получила прозвище "энциклопедия пик-пик" и была сочтена слишком рискованной. Критическая система отслеживания полицейских автомобилей страдала от ошибки, связанной с ненадежными сотовыми соединениями в фавелах. Отладка этой проблемы включала в себя рискованную поездку в опасном районе. В конечном итоге, поставленная система оказалась ниже стандартов и превысила бюджет. Компания столкнулась с судебными исками по этому и другим подобным проектам, едва не обанкротившись. Рассказчик покинул компанию из-за неоплаченных сверхурочных и проблемной реализации проекта.
CdXz5zHNQW_Y9omGHV0Uz.jpeg
В этом посте блога описывается проблемный PHP-код. Автор, работая в одиночку, делится им для катарсиса и черного юмора. Для обеспечения конфиденциальности код обобщен, что может привести к несоответствиям. Код извлекает данные, перебирает их и получает детали, используя динамический доступ к свойствам для локализации. Затем он форматирует затраты на основе переменной категории, обращаясь к массиву $mot с произвольными индексами. Присутствует обширная манипуляция строками HTML, включая генерацию блоков выбора количества. Код декодирует JSON для данных времени, указывая, что даты хранятся в виде строк. Списки раскрывающиеся создаются с использованием значений массива $mot. В конечном итоге обработанные данные вставляются в шаблон. Процесс повторяется для дочерних элементов, что приводит к почти дублирующемуся коду. Кроме того, дочерние элементы также могут иметь братьев и сестер, что требует еще одной итерации с аналогичной логикой кода. Автор выражает надежду, что первоначальный программист в конечном итоге научится использовать методы и функции. Предоставленный фрагмент кода демонстрирует начальный цикл извлечения и обработки данных для основных и дочерних элементов. Он включает сложную условную логику для расчета и форматирования затрат. Подчеркивается динамический доступ к свойствам для локализации и валюты. Также отмечается введение фрагментов HTML для выбора количества и времени. Повторяющийся характер кода для основных элементов, дочерних элементов и братьев и сестер делает кодовую базу неэффективной.
Предоставленный фрагмент кода на C++ демонстрирует обработчик исключений для исключения Deadlock. При перехвате этого исключения код пытается выполнить retry. Однако retry не является стандартным ключевым словом C++ и, скорее всего, является макросом. Автор предполагает, что этот макрос реализован с использованием оператора goto.Основная проблема заключается в предположении, что retry разрешит взаимоблокировку. Взаимоблокировка возникает, когда два или более потока бесконечно заблокированы, каждый из которых ожидает ресурс, удерживаемый другим. Чтобы retry был эффективным, он должен был бы освободить ресурс, удерживаемый в данный момент заблокированным потоком.По словам Кевина, автора кода, макрос retry не освобождает никаких ресурсов. Вместо этого он просто переходит обратно к началу блока catch. Это означает, что поток остается в состоянии взаимоблокировки.Кевин отмечает, что система уже страдала от многочисленных взаимоблокировок. Был нанят консультант для решения этих проблем путем изменения порядка доступа к ресурсам и выявления проблем, связанных с мьютексами. Реализация retry консультантом, по-видимому, непреднамеренно привела к большему количеству взаимоблокировок. Кевин в шутку предполагает, что консультант мог намереваться добавить свои собственные взаимоблокировки.
Отладка кода часто приводит к появлению в производственной среде странных и иногда бессмысленных выражений. Один из таких случаев связан с SQL-запросом, содержащим необычное условное предложение. Проблемная часть запроса выглядит так: WHERE (некоторые условия) AND (1 = 0 OR (1 = 1 AND (другие условия))). Такая структура позволяет переключаться между всегда возвращаемыми строками или возвращаемыми строками на основе основных условий, манипулируя частью "1 = 0". Также возможно настроить его так, чтобы он никогда не возвращал строки, хотя его полезность сомнительна. Автор предполагает, что это, вероятно, остатки отладочных флагов, которые так и не были удалены. Такие оставшиеся флаги указывают на недостаток наблюдаемости кода. Как и многие подобные флаги, они не документированы и, похоже, присутствуют с момента выпуска кода. Запрос, вероятно, возник как временный инструмент для аналитика, прежде чем стать постоянной хранимой процедурой. Наличие этих "мертвых" флагов указывает на более широкую проблему в практике разработки и развертывания.
Какистократия, правление худших и наименее квалифицированных, представлена как актуальная концепция. Учитель по имени Джаред Б. делится своим опытом работы в ed-tech компании, основанной профессором машиностроения по имени Гарри. Гарри разработал интерпретатор C и построил вокруг него компанию, предлагая учебные программы для K-12 на основе программирования на C. Его программное обеспечение включало веб-IDE и локальную версию для Windows с демоном для удаленного выполнения кода C.Однако этот демон не имел аутентификации и был привязан к 0.0.0.0, что позволяло любому домену или компьютеру в той же сети выполнять произвольный код C. Эти критические уязвимости безопасности существовали годами, незамеченные исключительно нанятыми Гарри разработчиками из числа аспирантов. Программное обеспечение было установлено на тысячах школьных компьютеров.Джаред сообщил об этих проблемах Гарри, который выпустил обновление, сославшись на "улучшения безопасности", но не проинформировал IT-руководителей о важности обновления. Джаред также обнаружил эксплойт для кражи файлов cookie и уязвимость внедрения кода на другом сайте Гарри. Последняя уязвимость раскрыла тысячи незашифрованных записей о транзакциях по кредитным картам. Несмотря на эти значительные недостатки безопасности и утечки данных, компания Гарри продолжает работать и получила признание. Комментатор противопоставляет эту ситуацию человеку, которого он знал, который застрял на устаревших технологиях, но не подвергал опасности образовательную систему.
CdXz5zHNQW_B1k6IsjyP4.png
Автор противопоставляет разочарования от плохой документации к программному обеспечению еще большим трудностям, связанным с плохо написанными техническими описаниями аппаратного обеспечения. Нахождение точной и полной документации для интегральных схем имеет решающее значение для разработчиков. Технические описания часто бывают неполными, неточными или даже на разных языках. Сложность современных чипов требует подробных технических описаний, но некоторые поставщики предоставляют недостаточную информацию, вынуждая пользователей проводить обратное проектирование функциональности. Расхождения между техническими описаниями и фактическим поведением чипа могут привести к критическим ошибкам, таким как неправильное определение выводов питания и повреждение компонентов. Хотя некоторые поставщики производят превосходные технические описания, соображения стоимости в области встраиваемых систем часто приводят к плохо документированному аппаратному обеспечению. Автор рассказывает о конкретном случае, когда в техническом описании чипа был описан "Регистр включения суперпользовательской фантастической функции". Этот регистр был с юмором сокращен до "SUFFER" (страдать), отражая опыт разработчика с трудными встраиваемыми проектами. Включение этой функции предназначалось для опытных пользователей, чтобы изменять поведение отладки. Значение сброса для этого регистра было всеми единицами, что указывало на то, что он был включен по умолчанию. Название регистра "SUFFER" точно отражает ощущение от работы с такой сложной документацией.
Matlab предпочитают ученые и исследователи, но многие программисты его не любят. Команда, использующая Matlab, столкнулась с проблемой генерации изображений, специфичных для участников, для хранения и последующего использования. Существующие ограничения затрудняли выполнение этой задачи в их текущей конфигурации. Программист по имени Джуд предложил обходной путь для решения этой проблемы. Предоставленный код Matlab предназначен для обработки данных экспериментальных триггеров. Он использует оператор switch внутри цикла for для перебора различных типов триггеров. Код пытается реконструировать предполагаемый шаблон, подсчитывая стимулы и обрабатывая различные сценарии ответов и отсутствия ответов. Комментарии в коде подчеркивают сложную логику и потенциальные проблемы с повреждением данных. Один комментарий явно упоминает пометку целых испытаний для удаления из-за неопределенности в отношении правильности данных. Было обнаружено, что значительная часть предоставленных журналов представляла собой различные, неизвестные эксперименты.
Автор описывает миграцию данных с одной платформы Microsoft на другую, которая столкнулась с неожиданной проблемой. Изначально извлечение и загрузка данных выполнялись с помощью SSIS, но автор переключился на PowerShell для большего контроля. Целью была миграция документов клиентов и метаданных из SharePoint on-premises в базу данных SQL Server. Ключевое поле, номер клиента, хранилось в SharePoint как тип Number. В SharePoint поля типа Number представлены как Double, что достаточно для точного хранения десятизначных чисел. Однако, сгенерированная SSIS схема SQL Server использовала тип данных 'float' для этого поля. Автор ошибочно предположил, что тип '.Net' 'float' в их скрипте PowerShell идеально совпадет с типом 'float' SQL Server. Это несоответствие произошло потому, что 'float' в SQL Server по умолчанию имеет двойную точность, но автор не осознал эту разницу в представлении. В результате, при передаче и преобразовании чисел, большие номера клиентов теряли последние несколько цифр из-за потери точности. Хотя тестировщики сначала не заметили ошибку, она была обнаружена во время полной загрузки данных. Команде пришлось идентифицировать поврежденные номера и вручную исправлять их после миграции.
CdXz5zHNQW_ElgNsoYbYY.jpeg
Разработка программного обеспечения требует различных вспомогательных инструментов, помимо редакторов и компиляторов. Система контроля версий является ярким примером такого необходимого инструмента. Однако многие важные инструменты разработки, возможно, не являются "хорошими", а лишь "достаточно хорошими". Системы сборки — одна из таких категорий, в которой отсутствуют по-настоящему превосходные варианты. Инструменты управления задачами и тикетами также попадают в эту проблемную категорию, причем Jira является особенно критикуемым примером. Привлекательность Jira для компаний заключается в ее обширных функциях, которые, к сожалению, приводят к сложности и требуют от пользователей программирования пользовательских рабочих процессов. Это может привести к бесконечной настройке со стороны менеджеров проектов вместо фактического прогресса по проекту. Jira позволяет определять рабочие процессы тикетов как конечные автоматы, включая автоматическую маршрутизацию между членами команды. Далее текст знакомит с Клинстеном, который столкнулся со сложным рабочим процессом Jira. Отображаемый пример рабочего процесса является двуязычным (голландский и английский) и чрезмерно сложным. Такое избыточное количество состояний и переходов подрывает его цель по упорядочиванию работы для команды. Автор выражает разочарование, сравнивая этот опыт с желанием закрыть вкладку браузера. Сложность рабочего процесса Клинстена затрудняет его понимание и эффективное использование.
CdXz5zHNQW_LSUkNG7WkF.png
CdXz5zHNQW_uBCiJ4y90s.jpeg
Мачей, фрилансер, часто сталкивается с устаревшим PHP-кодом, требующим поддержки. Он обнаружил проект с отсутствующими ключевыми функциями, в частности, механизмом HTTP-запросов для периодического заполнения данных. Предыдущие попытки реализовать это потерпели неудачу. Оригинальный разработчик многократно копировал и вставлял похожие блоки инициализации и конфигурации cURL по всему коду. Эти блоки, содержащие множество вызовов curl_setopt, предназначались для выполнения HTTP-запросов. Одна из таких опций, CURLOPT_TIMEOUT, была установлена с использованием переменной $interval, что, возможно, указывает на неправильное понимание ее функции. Основная проблема заключалась не столько в неправильном использовании CURLOPT_TIMEOUT, сколько в том, что данные, полученные curl_exec, так и не были использованы. Несмотря на то, что запросы, казалось бы, работали, полученное содержимое сохранялось в переменной $s, а затем игнорировалось. Это упущение заставило Мачея предположить, что предыдущий разработчик, возможно, начал работу, но потерял интерес, а не не смог заставить запросы работать. Хотя проект содержал и другой сложный код, это неиспользуемое извлечение данных было особенно заметно Мачею.
Индика просматривала комментарии к своему пул-реквесту, когда к ней подошел ее начальник, Билл. Билл отчитал ее за отправку пул-реквеста, заявив, что это противоречит политике команды. Он настаивал, что она не прочитала руководство для разработчиков. Индика прочитала общекорпоративное руководство, но у Билла было свое отдельное руководство для его команды, которым он никогда не делился. Это руководство запрещало ветвление и слияние, выступая за прямые коммиты в основную ветку. Индика подтвердила у коллеги, Элизы, что эта политика действительно существует. Элиза объяснила, что команда избегала ветвления и пул-реквестов, когда Билл был рядом, но в остальное время использовала их для поддержания хороших практик. Несколько недель спустя Индика в частной беседе спросила Билла о его политике в отношении ветвления. Билл объяснил свою логику, основанную на многолетнем опыте, утверждая, что ветки создают конфликты и устаревший код. Он считал, что они не нужны для внутренних команд, сравнивая это с тем, что разработчики отвлекаются на новые блестящие игрушки. Индика, обдумывая его слова, смотрела на белок, играющих на ветках деревьев.
Разработчик обнаружил несоответствие в коде обработки параллелизма API. В комментарии к свойству статуса было указано, что оно должно быть приватным во избежание злоупотреблений. Однако определение свойства было объявлено как публичное. Такое публичное определение позволяет внешним потребителям изменять статус, что противоречит намерению, выраженному в комментарии. Автор подчеркивает иронию ожидания от пользователей API чтения документации и соблюдения предполагаемой конфиденциальности публичных методов. Такое расхождение особенно тревожно в API параллелизма. Подчеркивается потенциал злоупотреблений и последующего хаоса. Несмотря на риск, код остается общедоступным, и только комментарий служит предупреждением. Это подчеркивает распространенный недосмотр, когда документация и реализация расходятся.
Рассказчик, сотрудник техподдержки, решил уволиться из компании, отказавшись от повышения. Вскоре после этого новый глава отдела кадров, Лейла, отправила рассказчику электронное письмо с приглашением на исполнительный этаж, что вызвало нервозность и любопытство. Рассказчик встретился с Лейлой, которая выразила соболезнования по поводу смерти наставника рассказчика, Агги. Лейла сообщила, что уволила проблемного менеджера, на которого жаловался рассказчик, установив таким образом доверительные отношения. Затем она предложила рассказчику руководящую должность в новой команде по управлению изменениями, со значительным повышением и возможностью набирать сотрудников внутри компании. Рассказчик, несмотря на заманчивое предложение, решил придерживаться своего первоначального плана — начать работать фрилансером с друзьями. Лейла с достоинством приняла решение, предложив поддержку и выразив сожаление по поводу ухода рассказчика. Затем рассказчик сообщил своим друзьям, Меган и Рейнальдо, о предложении Лейлы, но они также были привержены своим планам на фриланс. Санджай также присоединился к их фриланс-проекту, а бывший коллега, "Дракула", предоставил им первую рекомендацию клиента. Рассказчик и друзья основали компанию "RD IT Solutions" с плоской иерархией, покрывающую расходы, и начали справляться с трудностями предпринимательства. Рассказчик почувствовал возрождение цели, облегчение от прошлых тревог и более здоровый образ жизни. Их первый клиент поставил неожиданную задачу, запросив код веб-сайта по факсу.
В этом посте с юмором рассматриваются несколько случаев некорректного обращения технологий со временем, приводящих к абсурдным ситуациям. Роберт получил электронное письмо от OnePlus с указанием даты доставки "Вчера", что подразумевало, что водителю придется путешествовать во времени. Kinkster обнаружил интересный баг на Fetlife, где фотография профиля нового участника, казалось, была опубликована за час до его присоединения к сообществу. ERIC P. поделился фотографией своего Ford 2008 года, который столкнулся с ошибкой переполнения даты GPS, из-за чего на дисплее отображалась дата 1024-недельной давности. Marc Würth наблюдал за странной статистикой сканирования на Netvibes, показывающей, что лента была получена на 261 год в будущем, прежде чем нормализоваться. Анонимный пользователь в шутку сообщил, что получил посылки до завоевания Британии римлянами, причем общая дата уведомления по умолчанию была установлена на эпоху Unix. Эти анекдоты подчеркивают распространенные программные сбои, связанные с расчетами даты и времени. Пост связывает эти, казалось бы, случайные ошибки с темой путешествий во времени. Он подчеркивает, как часто код, обрабатывающий время, может давать сбои неожиданным образом. Приведенные примеры охватывают различные типы программного и аппаратного обеспечения. Каждый случай представляет собой легкий взгляд на проблемы программирования.
CdXz5zHNQW_YVzQh2u0YS.png
Грета испытывает проблемы со своей IDE "Ancient Development Environment". Важнейшая функция IDE — сообщать пользователям об ошибках сборки. Однако отображение ошибок в IDE Греты проблематично. Ошибка непоследовательна, не объясняет причину и не предлагает решений. Основной аспект "WTF" — это метод отображения. Она появляется как произвольное всплывающее окно во время процесса сборки, при неизвестных условиях. Сообщение об ошибке не содержит информации о том, что пошло не так. Оно представлено в нечитаемом для пользователя формате XHTML, показывая необработанный разметку вместо отрисованной страницы. Эта разметка отображается в странном древовидном представлении, где каждая строка исходного кода является отдельной строкой. Более того, сама разметка XHTML некорректна. Текст лишен сглаживания, что указывает на устаревший набор инструментов для работы с окнами. Одна кнопка, "Получить последние заголовки C++ Builder Direct из Интернета", не работает, являясь пережитком эпохи, когда веб-интеграция была новинкой. Интересно, что другая кнопка, "Информация о C++ Builder Direct", предлагает ностальгический взгляд на веб-дизайн 90-х с базовыми инструкциями CSS.
CdXz5zHNQW_y9bbMWp6RY.png
Фредерик А. делится проблемой проверки на null в методе IsCalling класса ConferenceService. Этот метод пытается определить, активна ли веб-конференция, обращаясь к IsWebRTCConnected через потенциально нулевую цепочку объектов: m_ConnectionService.Core.State.IsWebRTCConnected. Исходный код использует блок try/catch для обработки возможных исключений NullReferenceException, возвращая false, если какая-либо часть цепочки равна null. Этот подход эффективно маскирует основную проблему неинициализированных объектов. Фредерик предлагает использовать оператор нулевого слияния C# (?.) в качестве прямого исправления, которое лаконично вернет false, если любой объект в цепочке равен null, например: m_ConnectionService?.Core?.State?.IsWebRTCConnected ?? false. Хотя это функциональное решение, автор утверждает, что оно не является фундаментальным исправлением более глубокой архитектурной проблемы. Основная проблема заключается в управлении состоянием соединения, предполагая, что оно должно обрабатываться надлежащей машиной состояний. Опора на глубокую цепочку объектов с булевыми флагами для критически важной информации о состоянии указывает на плохой выбор дизайна. Хотя полная реализация машины состояний была бы более надежным решением, автор признает, что это требует значительной реструктуризации. Однако этот пример служит сильным напоминанием разработчикам о необходимости тщательно продумывать свои стратегии управления состоянием, чтобы избежать подобных сложностей с проверкой на null.
Предоставленный фрагмент кода демонстрирует неправильное использование типов Optional, даже для частого отправителя. Он проверяет, не является ли строка пустой, а затем оборачивает не-null dto в Optional.ofNullable. Эта практика сводит на нет предполагаемую выгоду от Optional, которая заключается в корректной обработке потенциально null значений. По сути, это позволяет избежать использования удобного синтаксического сахара, который Optional предоставляет для упаковки типов. Хотя сама по себе эта практика не является проблематичной, она широко распространена по всей кодовой базе. Автор отмечает, что типы Optional разбросаны повсеместно, даже в функциях, которые не возвращают nullable типы. Такое широкое и некорректное применение Optional не улучшает качество кода и не уменьшает количество ошибок. Вместо этого оно способствует появлению ошибочного и подверженного ошибкам кода. Автор выражает скептицизм относительно вероятности того, что эта проблема когда-либо будет исправлена. Это подчеркивает распространенную проблему, когда мощные языковые средства неправильно понимаются и применяются. Чрезмерная упаковка и распаковка добавляет ненужную сложность. В конечном итоге это сводит на нет цель использования Optional для предотвращения исключений нулевых ссылок. Этот пример служит предостережением о неправильном внедрении современных конструкций программирования.
Базы данных в виде плоских файлов, распространенные на мейнфреймах, хранят данные в полях фиксированной ширины. Типичная запись, например "JOHN SMITH 12343rd St", предполагает, что "JOHN" занимает 8 символов, "SMITH" — 8, и так далее. Такая жесткая структура делает модификации, например добавление второй буквы имени, чрезвычайно сложными, часто требующими создания новой таблицы, миграции данных и обновления всего использующего программного обеспечения.Чтобы смягчить это, умные разработчики ввели "дополнение" (padding), резервируя дополнительные символы в записи. Например, запись может заканчиваться 16 символами неиспользуемого пространства. Когда требуется новое поле, например вторая буква имени, его можно вставить, уменьшив дополнение, избегая изменений общей длины записи. Этот метод, хотя и неэлегантный, предотвращает дорогостоящие переделки схемы и перемещение данных.Дополнение часто распределяется по всей записи, позволяя новым столбцам занимать эти зарезервированные пространства. Хотя со временем дополнение может закончиться, эта стратегия значительно продлевает срок службы схемы плоских файлов без крупных переработок.Команда Бренды поддерживала мейнфрейм-систему, использующую такие плоские файлы VSAM, что требовало извлечения данных в современную реляционную СУБД. Был создан процесс ETL, а команда мейнфрейма предоставила "копибук" с описанием структуры файла.Однако разработчики ETL неправильно обработали дополнение, разделив поля таким образом, что части дополнения были восприняты как отдельные элементы данных. Поначалу это казалось безобидным, поскольку символы дополнения удалялись из отчетов, а реконструкция работала путем конкатенации полей.Критическая ошибка заключалась в тестировании только на производственном мейнфрейме, где отсутствовали функции, использующие дополнение "на лету". Когда эти функции были запущены на производственном мейнфрейме, отчеты, сгенерированные процессом ETL, оказались испорчены посторонними данными из теперь используемого дополнения.Поскольку разработчики ETL были подрядчиками, а их решение "работало как задумано" на основе их ограниченного тестирования, они отказались его переделывать. В результате команда мейнфрейма была вынуждена искать альтернативные поля дополнения, чтобы не повлиять на существующие отчеты.
Один человек выражает сильное предпочтение фрикаделькам IKEA перед их мебелью. Другой человек, Ян, демонстрирует такую же, неизмеримую преданность шведскому мега-магазину. Джефффи нашел процесс выбора мест на концерте Рика Спрингфилда на удивление трудным и остался с неразрешенными вопросами. Ричард Х. столкнулся с неожиданной и расстраивающей ошибкой при написании электронного письма, ставя под сомнение тестирование программного обеспечения Microsoft. Анонимный пользователь оставил оскорбление, указывая на негативный опыт с чем-то неуточненным. WeaponizedFun отмечает иронию в том, что компания OnSolve инструктирует пользователей защищать свое имя пользователя, отказываясь при этом раскрывать его им. Понятие истинной тайны определяется как нечто, известное только одному человеку. Это напрямую иллюстрируется политикой OnSolve в отношении имен пользователей. Наконец, реклама предлагает бесплатное руководство по уверенному планированию миграции на .NET 9.
CdXz5zHNQW_QV21qPl6qy.png
Windows Presentation Foundation — это фреймворк пользовательского интерфейса для Windows, который позволяет привязывать элементы управления к данным. Это означает, что текстовое поле может быть связано с числовым полем в классе модели. Фреймворк требует инструкций по преобразованию пользовательских типов, и здесь на помощь приходит интерфейс IValueConverter. Этот интерфейс имеет два метода, Convert и ConvertBack, которые можно использовать для преобразования данных между типами. Класс, реализующий этот интерфейс, может, например, использоваться для преобразования цвета в кисть. Однако API этого интерфейса не очень популярен, а соглашение об именовании может сбивать с толку. Представленный Фредрикой материал освещает проблему со встроенным преобразователем, который не преобразует пустые строки в null при привязке текстового поля к полю типа double. Для решения этой проблемы был написан пользовательский преобразователь, но его реализация не идеальна: переменные названы плохо, а логика неясна. Преобразователь приводит значение к типу double при преобразовании и к типу string при обратном преобразовании, что может вызвать путаницу. Общий подход к использованию преобразователей в WPF не очень популярен, и эта реализация не помогает прояснить ситуацию. Использование преобразователей для обработки пустых текстовых полей как null-значений также может привести к проблемам в будущем. В целом, API преобразователя и его реализация в данном случае плохо спроектированы и могут привести к путанице и потенциальным проблемам.
Рассказчик с трудом справляется с внезапной потерей своего друга и наставника, Эгги Шоу, которая умерла от внезапной болезни. Рассказчик подавлен горем и не может вернуться к обычной работе, несмотря на ожидания начальства. Он начинает использовать оплачиваемый отпуск, чтобы справиться со своими эмоциями и примириться с потерей. Подруга рассказчика, Меган, связывается с ним и предлагает встретиться, предлагая столь необходимую возможность выговориться и утешение. Во время встречи рассказчик делится своими чувствами и разочарованиями в работе, а Меган предлагает им создать собственную IT-группу с равными партнерами. Рассказчик вдохновлен этой идеей и начинает изучать варианты, в том числе фриланс и открытие нового бизнеса с Меган. Исследуя и планируя, он обретает чувство цели и энтузиазм, несмотря на риски и неопределенность. Рассказчик возвращается на работу, но только для того, чтобы подать заявление об увольнении за две недели и начать строить планы на новое будущее. Он находит в старом кабинете Эгги символ ее присутствия – резиновую уточку, которая дает ему чувство связи и мотивацию двигаться вперед. Рассказчик полон решимости оставить свою прежнюю работу и начать новую главу в своей жизни, с Меган рядом. Решение рассказчика уйти с работы – это не просто попытка избежать сложной рабочей обстановки, а поиск нового смысла и удовлетворения.
Мошенники настаивают на том, чтобы пользователи досматривали контент до конца, что в сегодняшнем выпуске "Error'd" юмористически представлено как долгосрочное обязательство. Amazon недавно вызвал широкую обеспокоенность, отправив тысячам клиентов счета со значительно завышенными ценами, что вызвало немалую тревогу. Один из клиентов, Вилли, выразил беспокойство по поводу внезапного роста цен на Amazon и ожидал финансовой проверки. Дэйв А. отметил нерешительность программной подсказки, задаваясь вопросом, является ли действие необязательным или обязательным. Анонимный пользователь обнаружил уникальную систему рейтингов из 5 звезд, отображаемую по осям X и Y для компании по чистке крыш, юмористически отметив, что это "вне крыши". Ричард Х. столкнулся с подозрительным письмом от QuickBooks, ссылающимся на случайно сгенерированный номер счета, что убедительно указывало на мошенничество. Б. Дж. Х. получил необычно многословное и тревожное системное сообщение, вызывающее опасения по поводу чрезвычайных протоколов, если такой текст считался "нормальным". В выпуске также была реклама руководства по миграции на .NET 9, обещающего облегчить трудности миграции.
CdXz5zHNQW_k8sU0XsDKx.png
Реми в шутку предлагает укрыться в темной, непроветриваемой пещере из-за неприятной погоды. Это чувство перекликается с прошлой рабочей обстановкой, где менеджеры мирились с эксцентричными разработчиками программного обеспечения. В конце 90-х, с бумом в сфере ИТ, менеджеры привыкли к необычному поведению своих разработчиков. При найме Стена, который имел блестящие рекомендации, Барри и его команда готовились к эксцентричности.В первый же день Стен попросил рабочее место без естественного освещения и с закрывающейся вентиляцией. Барри обнаружил кабинет Стена в подвале, где Стен вынимал люминесцентные лампы, чтобы затемнить помещение. Стен говорил исключительно в третьем лице, называя себя "Стен" и путано используя местоимения. Он также потреблял большое количество витаминов и странно пахнущий чай.Стиль кодирования Стена был столь же своеобразен: он использовал женские имена для всех переменных и методов, названных в честь его предполагаемых девушек. Хотя существовали некоторые соглашения об именовании, они были недокументированы и трудны для расшифровки. Ревью кода превратились в витиеватые повествования, затрудняющие понимание реальной логики.Несмотря на его эксцентричность и стиль кодирования, главным недостатком Стена была его низкая производительность. Он не мог угнаться за требованиями команды, что привело к его увольнению. Позже Барри дал осторожную рекомендацию другой компании, предложив им попросить Стена объяснить свой код. Эту компанию Стен не нанял, а Барри получил в подарок корзину с благодарностью.
Техники сталкиваются с повторяющимися проблемами из-за плохо обслуживаемой инфраструктуры и нестандартных решений. Одна из распространенных проблем возникает из-за недостаточно мощного кондиционера, что требует предупреждения о необходимости следить за препятствиями для спотыкания возле открытой двери серверной. Другой техник столкнулся с факсимильным аппаратом, который работал только время от времени в сырую погоду, несмотря на обширное устранение неполадок и тестирование линии. Проблема в конечном итоге была связана с открытым телекоммуникационным колодцем, где кабели остались незащищенными, что привело к быстрому устранению после отправки фотографий руководству.Еще одно тревожное открытие касалось накопителя "резервного копирования вне площадки", небрежно размещенного на деревянной серверной стойке в компании-разработчике программного обеспечения. Другие примеры импровизированных решений включают использование нестандартной проводки, отклоняющейся от стандартных электротехнических практик, с предпочтением открытых соединений вместо надлежащей установки. В отеле на Манхэттене сетевое оборудование свисало в опасной близости от кабелей в общественной лестничной клетке, совершенно незакрепленное. В Китае коммутатор был найден прикрученным на высоте нескольких метров к колонне в металлическом цеху, что свидетельствует о более необычных установках в промышленных условиях.Эти инциденты подчеркивают повсеместное отсутствие профессиональных стандартов в управлении ИТ-инфраструктурой в различных средах. Они предполагают модель импровизации и пренебрежения, а не соблюдения передовых практик.
CdXz5zHNQW_LC8T1Da23x.jpeg
Реми рассказывает об инциденте, связанном с проблемой производительности платформы VXML, с которой столкнулся Адам С. Система выходила из строя при минимальной нагрузке, а проект уже отставал от графика. Адам, не знакомый с VXML, начал с изучения журналов приложений в поисках подсказок. Он неоднократно находил сообщение об ошибке: "При записи журнала ошибок возникло исключение". Это загадочное сообщение озадачило Адама, поскольку оно сообщало об ошибке в самом ведении журнала. Погрузившись в исходный код, он обнаружил глубоко ошибочную реализацию ведения журнала. Код использовал внешнюю команду для записи ошибок, вместо того чтобы использовать существующие фреймворки ведения журнала, такие как log4j, или даже простое System.out.println. Адам счел этот подход неэффективным и плохо продуманным. Хотя этот конкретный код не был первопричиной проблем с производительностью, он был быстро удален. Анекдот подчеркивает распространенный тип технического долга, встречающийся в устаревших системах.
Статья возвращается к классическим примерам кода во время летних каникул, начиная с обсуждения исходного кода. Автор, Кристиан, отмечает, что на немецком языке «quellcode» напрямую переводится как «исходный код». Он с юмором придумывает новый термин «quäl-kot», который сочетает немецкое ругательство с «исходным кодом», чтобы описать особенно вопиющий код. Этот выразительный термин вдохновлён плохо спроектированным интерфейсом, встречающимся в коде.Проблемный интерфейс представлен в виде фрагмента кода на C#. Он называется ITableSelector и содержит чрезмерное количество методов выбора таблиц. В частности, существуют методы, такие как selectTable1(), selectTable2(), а также множество вариантов таблиц, таких как 4a/4b, 7a/7b, 9a/9b, 14a/14b/14c/14d и 21a/21b. Интерфейс продолжает перечислять методы вплоть до selectTable31(). Этот обширный и повторяющийся список подчёркивает конструктивные недостатки интерфейса. Огромное количество подобных методов указывает на отсутствие абстракции или плохо структурированное решение. Такой интерфейс указывает на возможные проблемы с поддерживаемостью и расширяемостью.
Сэм предполагает, что Disney+ мог тестировать биллинг по факту использования из-за ошибки. Однако более распространенное объяснение, вероятно, существует. На сайте онлайн-покупок отображалась нелогичная цена, предлагающая скидку на товар с нулевой ценой. Харрисон заметил, что в супермаркете товар был отмечен с обратным изменением цены: первоначальная цена составляла ноль, а новая — 99 долларов. Скидка парадоксально описывалась как минус бесконечность процентов. Dragoncoder047 столкнулся с моджибаке на виджете Game Center своего iPhone, несмотря на то, что устройство было настроено на английский язык. Эвелин сообщила об аномалии в отслеживании посылки, когда товар был зарегистрирован в июле, отправлен в январе, а затем возвращен в июль. Эта временная несогласованность не объясняется простыми проблемами с часовыми поясами. Эти примеры освещают различные онлайн и реальные сбои. Ошибки варьируются от возможных проблем с биллингом до абсурдных цен и ошибок отображения. Они демонстрируют неожиданные цифровые и логистические аномалии, с которыми сталкиваются пользователи.
CdXz5zHNQW_dTcL1Jd4qx.jpeg
Карен столкнулась с нестабильностью в своих спецификационных тестах, которые давали сбой несколько раз на тысячу запусков. Эти сложные, чувствительные ко времени тесты иногда завершались неудачей, несмотря на щедрые временные окна и успешно пройденные модульные тесты. Проблема заключалась в функции setTimeout в JavaScript, которая, вопреки своей документации, предполагающей, что она может ждать дольше, на самом деле может вызывать колбэки до истечения указанного времени в Node.js. Простая функция ожидания Карен изначально использовала setTimeout для внесения задержек. После обширной отладки она обнаружила, что эта временная несогласованность является основной причиной ее нестабильных тестов. Чтобы решить эту проблему, она переписала функцию ожидания, чтобы она непрерывно проверяла прошедшее время каждую миллисекунду. Эта новая функция гарантирует, что операция завершится только после достижения целевой продолжительности, предотвращая преждевременные тайм-ауты. Хотя это решение эффективно, оно считается неэффективным и подчеркивает проблемную временную чувствительность функциональных тестов. Оно также указывает на недостаток гарантий планирования в среде выполнения Node.js. Автор выражает сожаление по поводу необходимости такого обходного пути.
Кодовая база в основном написана на C, где возвращаемые значения функций обычно указывают на коды состояния. Стандартное соглашение заключается в проверке того, является ли булево возвращаемое значение истинным для обозначения успеха. Однако давний разработчик ввел запутанный альтернативный идиом. Этот разработчик проверяет, является ли булево возвращаемое значение ложным, чтобы обозначить ошибку. Эта практика стала преобладающей конвенцией в проекте из-за стажа разработчика. Следовательно, любое потенциальное условие ошибки включает проверку того, равно ли переменной с именем 'error' значению FALSE. Хотя эта конвенция последовательна в рамках своего собственного фреймворка, она формально не документирована. Новые разработчики часто сначала придерживаются стандартного шаблона. Однако огромный объем существующего кода с нестандартным шаблоном влияет на них. Эта устоявшаяся кодовая база обладает сильной инерцией, которая формирует новый код. Существующий код фактически диктует стиль разработки, а не разработчики, изменяющие код.
Предоставленный код на Ruby определяет функцию с именем bv, что является сокращением от "boolean value" (логическое значение), и используется для красивого вывода логических значений и их преобразования в строки. Функция принимает четыре параметра: prop, tv, fv и nv, которые представляют имя свойства, значение "истина", значение "ложь" и значение "null" соответственно. Функция использует метод send для доступа к члену класса по имени, что является идиомой Ruby, позволяющей метапрограммирование с помощью строк. Такой подход может привести к потенциальным проблемам, таким как возврат "Не указано" для полей, не являющихся логическими, что может вводить в заблуждение. Утверждается, что попытка использовать функцию для поля, не являющегося логическим, должна вместо этого вызывать исключение. Поведение функции может быть неожиданным, поскольку она вызовет исключение, если свойство не существует или если доступ к нему осуществляется через функцию, принимающую параметры. Документация Ruby рекомендует иметь хороший список допустимых логических значений, чтобы избежать этих проблем. Однако использование метапрограммирования во время выполнения путем передачи строк все еще может привести к неприятностям и затруднить поддержку кодовой базы. Автор текста выражает свое неприятие такого подхода и предпочитает использовать шаблоны C++ для метапрограммирования, которые, по его мнению, проще и понятнее. Автор считает, что нетривиальные кодовые базы на Ruby часто становятся не поддерживаемыми из-за использования метапрограммирования. В целом, код и его подход считаются проблематичными и склонными к ошибкам.