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

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

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

Трэд заметок

Рассказчик с трудом справляется с внезапной потерей своего друга и наставника, Эгги Шоу, которая умерла от внезапной болезни. Рассказчик подавлен горем и не может вернуться к обычной работе, несмотря на ожидания начальства. Он начинает использовать оплачиваемый отпуск, чтобы справиться со своими эмоциями и примириться с потерей. Подруга рассказчика, Меган, связывается с ним и предлагает встретиться, предлагая столь необходимую возможность выговориться и утешение. Во время встречи рассказчик делится своими чувствами и разочарованиями в работе, а Меган предлагает им создать собственную 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 часто становятся не поддерживаемыми из-за использования метапрограммирования. В целом, код и его подход считаются проблематичными и склонными к ошибкам.
Рассказчик, Аноним, описывает свой опыт устранения неполадок с принтером в отделе кадров. Задания на печать перенаправлялись неправильно, что приводило к странным результатам, и подозревалось, что виновником является устаревшая, не документированная программа отдела кадров. Рассказчик и его коллега Рейнальдо обнаружили конфликт IP-адресов, когда принтер использовал тот же адрес, что и выведенный из эксплуатации сервер, который необъяснимым образом все еще работал. Рейнальдо предположил, что этот сервер кэшировал и печатал старые анонимные жалобы из забытой программы. Разработчик Меган предоставила исходный код программы, подтвердив, что это был не документированный беспорядок, созданный ушедшим на пенсию разработчиком. Меган предложила улучшить обработку ошибок программы, но ее начальник прервал ее, запретив ей работать над неподдерживаемыми проектами. Расстроенный корпоративной бюрократией, Аноним по электронной почте сообщил о своих опасениях новому руководителю отдела кадров. Тем временем Аноним договорился о встрече со своим наставником, Агги, чтобы обсудить системные проблемы, преследующие компанию. Трагически, Агги скоропостижно скончалась от сердечного приступа до того, как их встреча могла состояться. Рассказчик остался с неразрешенными разочарованиями по поводу неэффективности компании и потерей ценного наставника.
Разговор начинается с обсуждения того, как произносится FAQ, при этом Питер произносит его как "эф эх кью". Затем упоминается тест, и Питера просят создать FAQ ровно из девяти пунктов. Анонимный пользователь упоминает, что потратил неизвестную сумму денег и упустил интересное предложение на myminifactory.com из-за сжатых сроков истечения. Другой читатель выражает свое ожидание быстрой доставки, делится скриншотом и отмечает расхождение между предполагаемым временем доставки и своим местным временем. Читатель находит задержку необычной, но приветствует изменение. Майкл Р. сокрушается, что упустил шесть купонов, которые сэкономили бы ему 0%, что он считает обидным. Dragoncoder047 делится своим разочаровывающим опытом работы с игровым движком, где он столкнулся с бесполезным сообщением об ошибке при рефакторинге упаковщика спрайтов во время выполнения. Сообщение об ошибке было неясным, и Dragoncoder047 пришлось самому выяснять проблему, которая заключалась в неправильном обнаружении определенных элементов. Разговор прерывается рекламой BuildMaster, инструмента управления выпуском программного обеспечения, который позволяет компаниям уверенно выпускать программное обеспечение в желаемом темпе. Реклама призывает читателей скачать BuildMaster сегодня, чтобы воспользоваться его функциями и преимуществами.
CdXz5zHNQW_PE38MQ2etW.png
Истинная ценность менеджера проекта заключается в его коммуникативных навыках, а не только в умении планировать. Эффективные менеджеры проектов преодолевают разрыв между командой, организационными целями и руководством, управляя при этом ограничениями. Компетентный менеджер проекта бесценен, тогда как неэффективный может обойтись дорого. Теган, новый выпускник MBA с сертификатами, но без практического опыта, была назначена руководить сложным проектом. Ей не хватало основных коммуникативных навыков, необходимых для эффективного управления командой опытных инженеров. Когда ее спрашивали о критически важной информации о сроках, Теган давала расплывчатые и бесполезные ответы. Инженерные команды начали сотрудничать напрямую, минуя Теган, что вызвало недовольство руководства, которое полагалось на нее для получения информации о проекте. Не имея возможности принимать обоснованные решения из-за неопытности, коммуникация Теган ухудшилась, что привело к застою проекта. Ее последующее электронное письмо с признанием того, что она "запоносила", юмористически подчеркнуло ее неспособность двигаться вперед. В конце концов, Теган покинула проект, а ее замена, Пэм, хотя и не была выдающейся, привнесла столь необходимую последовательную коммуникацию и опыт, чтобы проект двигался вперед.
TJ унаследовал проект на NestJS с кодом от давно ушедших разработчиков. NestJS — это фреймворк на TypeScript, использующий внедрение зависимостей. Он организует код в контроллеры, провайдеры и модули. Модули могут быть вложенными, создавая гибкую структуру зависимостей. ProjectsModule в кодовой базе является примером простого, пустого модуля. Разработчики часто пишут тесты для своего кода, и для ProjectsModule существует тестовый файл. Этот тестовый файл пытается создать экземпляр ProjectsModule. Однако тест просто создает экземпляр модуля, что не является осмысленным тестом. Модули NestJS по сути являются контейнерами, а динамические модули выполняют код во время выполнения, а не во время создания. Следовательно, этот конкретный тест всегда будет проходить, не проверяя никакой реальной функциональности. Он считается "не-тестом", который не способствует покрытию кода и не проверяет компоненты модуля. Несмотря на его неэффективность, TJ отмечает наличие тестов.
Приложение 'Dragoncoder' реализует время ожидания для пользователей, которое автор не любит, но признает, что может иметь реальные обоснования. Основная проблема заключается в коде JavaScript, ответственного за отображение этого времени ожидания. Переменная minutes жестко закодирована в 12, и код демонстрирует странную логику для отображения предполагаемого времени ожидания. Независимо от фактического значения minutes, отображаемое время ожидания последовательно равно '12 минута' или '12 минут' в большинстве сценариев. Даже когда время ожидания составляет ровно 60 минут, оно отображается как '0 часов'. Автор предполагает, что вывод текста также генерируется сервером, несмотря на то, что переменная является клиентским JavaScript. Более эффективный и удобный подход заключался бы в использовании литералов шаблонов для динамического расчета и отображения часов и минут. Автор сомневается в необходимости функции времени ожидания вообще, предполагая, что она может быть удалена, если нет сильных оснований для ее существования. Страница времени ожидания кэшируется CDN после первоначального рендеринга бэкенда. Рендеринг переменной minutes на бэкенде также отмечен как менее идеальный метод передачи данных. Автор подчеркивает отсутствие обработки формы множественного числа как еще одну незначительную ошибку. Вывод кода для 60 минут как '0 часов' саркастически связан с известным фильмом. Автор предлагает более простой, динамический клиентский расчет для отображения времени ожидания. В конечном итоге автор предлагает пересмотреть необходимость функции времени ожидания.
Автор начинает историю, сравнивая Декларацию независимости с увольнением без предупреждения. Стив приходит в новую компанию на первую неделю и испытывает трудности с кодом, нуждаясь в помощи архитектора Билла. Билл недоступен из-за обязательного пятничного собрания компании. Стив предполагает, что собрание может быть неформальным, вроде вечеринки, учитывая статус стартапа компании. Однако он вспоминает, что на собеседовании основное внимание уделялось управлению временем и общению со сложными личностями. Вскоре Стив узнает, что сложная личность — это Фрэнк, босс, который отчитывает его за время, проведенное в комнате отдыха. Фрэнк чрезвычайно контролирует время и деятельность разработчиков. Во время совещания по планированию Фрэнк агрессивно отчитывает Билла за перерыв. В четверг совещание по демонстрации функции срывается из-за тирады Фрэнка по поводу персонализированного рабочего стола компьютера Стива. Фрэнк считает, что разработчики не должны персонализировать свои рабочие места, чтобы любой мог пользоваться любым компьютером. К пятнице Стиву поручают швабру для уборки, что является приказом Фрэнка. Фрэнк предписывает разработчикам самим убирать офис, не доверяя уборщикам. Этот опыт побуждает Стива искать работу в другом месте, применяя уроки Фрэнка по управлению временем, уволившись.
Deutsche Bahn подвергается критике за частые задержки и запутанную нумерацию мест, при этом один пользователь ставит под сомнение наложение мест. Другой путешественник столкнулся с монитором поезда, который неправильно отображал символы Unicode. Опечатка в итальянском новостном репортаже о авиакатастрофе забавно намекала на возвращение к 19 июля 2989 года, хотя статья также подчёркивала героическое выживание многих пассажиров. В более лёгком духе был сфотографирован модифицированный двухэтажный автобус DeLorean, что с юмором намекало на пассажиров прибыть до посадки. Эти инциденты вместе подчёркивают странные и порой раздражающие аспекты опыта общественного транспорта. Ситуация с местами Deutsche Bahn представляет собой непонятную ситуацию. Неисправный монитор поезда демонстрирует распространённую техническую проблему. Опечатка добавляет нотку научной фантастики серьёзному событию. Модифицированный DeLorean добавляет причудливый элемент транспортировке. В целом, новости недели о транспорте предлагали смесь недоумения и веселья.
CdXz5zHNQW_ReBPMTmUtv.png
Хотя обсуждения плохого кода видеоигр редки, они часто фокусируются на специализированных оптимизациях производительности, а не на проблемах с поддержкой. Выпущенная игра, несмотря на то, что является профессиональным продуктом небольшой команды, содержит примечательный конфигурационный файл, связанный с ее многопользовательской функциональностью. Этот конфигурационный файл позволяет вносить обширные коррективы в сетевые параметры.Одна настройка, net_socks_buffer_size, сопровождается предупреждением не менять ее. Другие, такие как net_max_message_size и net_max_download_frames, требуют перезапуска игры при изменении и должны быть степенями двойки. net_udp_packet_size установлен на большое значение, с заметками о рекомендуемых обрезках фрагментов и требованиях к IPv6. Дальнейшие настройки контролируют размеры буферов UDP-пакетов, включая предупреждение об отбрасывании пакетов при переполнении приемного буфера.Существует также опция для переопределения рекомендаций операционной системы по размерам UDP-пакетов, что потенциально может отключить сеть или привести к сбою игры. Решение отключить контрольные суммы UDP представлено как необязательная, вероятно, ненужная функция. Критически важно, что возможность игроков настраивать эти параметры подразумевает потенциал для проведения атак типа "отказ в обслуживании" против сетевых стеков других игроков.Конфигурационный файл в шутку предупреждает пользователей не быть "мудаками" при изменении определенных параметров. Помимо сетевых настроек, действительно тревожной является настройка sys_ignore_variable_constraints, явно помеченная как "ОПАСНО КАК ЧЕРТ". Автор в шутку выступает за добавление этого опасного флага во все игры и даже в свое собственное программное обеспечение для роботов в потенциально разрушительных целях.
Самая сложная проблема в информатике — это именование вещей, что иллюстрирует недавний пример. Был замечен метод с именем handleRSAPrivateKeyGeneration, который явно предполагает генерацию закрытого ключа RSA. Однако эта функция на самом деле принимает алгоритм в качестве параметра, что позволяет использовать различные реализации. В данном конкретном случае, казалось, она внедряла ключ для поиска реализации. Функция не генерирует исключительно ключи RSA; она возвращает действительный криптографический ключ. По умолчанию она генерирует ключ эллиптической кривой. Этот ключ возвращается в виде строки, вероятно, для отображения на веб-странице в рамках контроллера Java Spring. Отправитель посчитал, что это не "WTF", а скорее плохо названная функция, которая может вводить в заблуждение. Чрезмерная конкретность в именовании иногда может снизить ясность. Более подходящим было бы имя, например, handlePrivateKeyGeneration, поскольку точный тип ключа не всегда известен. Задача точного и ясного именования сохраняется.
Рассказчик, специалист техподдержки, сталкивается с новой проблемой: принтер в отделе кадров «печатает бессмыслицу». От Тони, автора заявки, он узнает, что проблема достаточно серьезна, чтобы требовать личного визита. По пути он ненадолго встречается с Агги, бывшим наставником, которая с тех пор получила повышение, и договаривается с ней о встрече за кофе. Его пункт назначения — отдел кадров, департамент, которого он обычно боится, но он также вспоминает Лейлу, руководителя, которая ранее помогла ему со сложным делом.По прибытии он обнаруживает пожилого мужчину, начальника Тони, пытающегося починить принтер феном, рискуя повредить машину. Рассказчик вмешивается, отключает фен и вежливо, но твердо сообщает «горячей голове» о потенциальном вреде для принтера. Затем он поручает «горячей голове» использовать другой принтер и обещает сам решить проблему, а также планирует сообщить Лейле об инциденте.После ухода «горячей головы» рассказчик осматривает принтер, обнаруживая, что он на удивление не поврежден и полностью функционален после серии тестовых распечаток. Затем он встречается с Тони, который подтверждает, что «горячая голова» — его начальник, и выражает благодарность за готовность рассказчика сообщить об инциденте новому руководителю отдела кадров. Тони уточняет, что принтер, хотя и старый, «новый здесь» для их отдела.Позже, во время перекура, рассказчик пересказывает утренние события своим коллегам Меган и Рейнальдо, показывая им распечатки «бессмыслицы». Эти страницы содержат различные анонимные жалобы в отдел кадров, такие как «Я не чувствую себя в безопасности, работая с Шерил» и «Джон постоянно смотрит на меня». Меган предполагает, что это может быть проблема с сетью, что подтверждается тем фактом, что тестовые распечатки работают нормально.Рейнальдо, сетевой администратор, узнает характер распечаток, вспоминая старую, предположительно выведенную из эксплуатации интранет-систему для анонимных жалоб в отдел кадров. Понимая, что жалобы печатаются непреднамеренно, Рейнальдо решает отследить IP-адреса, чтобы исследовать источник проблемы. Рассказчик готов помочь в решении этой необычной технической проблемы.
Разделители путей к файлам могут представлять проблему при написании кроссплатформенного программного обеспечения, и не все языки программирования имеют простой API для их обработки. До C++ 17 разработчикам приходилось использовать препроцессорную магию для обработки разделителей путей к файлам, часто используя набор библиотек Boost. Распространенным решением было определение константы препроцессора для разделителя путей с помощью директив условной компиляции. Этот подход позволял разработчикам собирать пути таким образом, чтобы они работали в соответствии с различными соглашениями о путях к файлам. Однако некоторые разработчики выбрали неверный подход, например, добавляли разделитель пути, а затем заменяли его правильным, что приводило к дублированию и ошибкам в коде. Этот некорректный подход часто копировался по всей кодовой базе, что приводило к множеству экземпляров одной и той же ошибочной логики. Код не рефакторился, несмотря на то, что им пользовались несколько разработчиков, и в некоторых случаях он по-прежнему выдавал неправильные разделители путей. К счастью, современная Windows прощает неправильные разделители путей, но это не оправдывает плохую практику кодирования. Лучшим подходом было бы определение константы для разделителя путей и ее последовательное использование во всей кодовой базе. Использование платформы управления релизами самообслуживания, такой как BuildMaster, может помочь оптимизировать процесс разработки и снизить вероятность подобных ошибок.
На этой неделе в новостях технологий освещаются несколько забавных промахов и разочарований на разных платформах. "Фифа-провал" произошел во время прямой трансляции Чемпионата мира по футболу, когда на экране неправильно отображались названия стран, несмотря на то, что ведущий устно их исправлял. Другой пользователь, WorkerNumber29200, выразил удивление внезапным "расширением" Франции поисковой системой по трудоустройству, предположив ошибку в ее географической фильтрации. GitHub также стал источником развлечения: Ханс К. сообщил о проблеме с Dependabot, которую он хотел бы исправить. Питер С. также отметил очевидные трудности GitHub с базовой арифметикой, в шутку предположив, что у него есть "неопубликованное доказательство того, что 0=1". Также обсуждались недавние проблемы на Amazon: Мишель была разочарована тем, что поиск зарядного устройства USB-C выдал дорогие, малоизвестные музыкальные CD, возможно, сгенерированные ИИ. Статья заканчивается рекламой BuildMaster, платформы для самостоятельного управления релизами.
CdXz5zHNQW_KXQcyWrIQn.png
Гэри ожидал похвалы на встрече с руководством из-за недавних успехов в проекте. Он унаследовал хаотичное приложение с абсурдным количеством дублирующихся контроллеров и дезорганизованной инфраструктурой. Система страдала от низкого времени безотказной работы и ручного, ненадежного процесса развертывания. Бэклог был столь же неуправляемым, без каких-либо приоритетов или четких описаний задач. Однако Гэри и его команда проявили инициативу для решения критических проблем. Они значительно сократили облачные расходы, устранив избыточные ресурсы и внедрив стратегическое планирование. Внедрение конвейера CI/CD оптимизировало развертывания и значительно улучшило время безотказной работы системы. Гэри был готов представить эти достижения, ожидая похвалы. Вместо этого его руководители выразили обеспокоенность по поводу его предполагаемого отсутствия прогресса по устаревшей дорожной карте. Несмотря на объяснения Гэри о существенной экономии средств и улучшении циклов разработки, его руководители остались сосредоточены на нерешенных пунктах дорожной карты. Они отвергли его предложения по пересмотру дорожной карты как непродуктивные. В итоге Гэри закончил встречу, чувствуя себя недооцененным. Этот опыт побудил Гэри начать обновлять свое резюме, что свидетельствовало о его неудовлетворенности.
Команда разработчиков Гретхен была приобретена Initech в рамках покупки компании. Initech интересовали их успешные программные продукты и талант разработчиков. Изначально команда Гретхен была успешной, получив автономию в проектах. Они могли повторно использовать существующий код или переписывать его и выбирать собственные инструменты, что приводило к положительным результатам. Однако позже Гретхен была назначена на проблемный проект, характеризующийся постоянным "тушением пожаров". Кодовая база проекта демонстрировала плохие практики, такие как неадекватная обработка null.Приложение было ограничено устаревшей версией NodeJS, которая больше не получала обновлений. Гретхен отметила отсутствие последовательных соглашений по кодированию и отсутствие логирования. Даже существующий механизм логирования был неэффективен, выводя только слово "DEBUG" независимо от содержания сообщения. Код обрабатывал HTTP-запросы, вставляя тело запроса непосредственно в базу данных без проверки. Эта конкретная функция демонстрировала нерешительность, пытаясь использовать два разных метода для копирования данных запроса.Кроме того, система во многих местах полагалась на прямые SQL-запросы, создавая значительные уязвимости SQL-инъекций. В коде также отсутствовали критически важные проверки авторизации, причем большинство конечных точек были полностью незащищены. Даже критически важные конечные точки, такие как административный API, имели дублирующиеся версии без какой-либо настроенной аутентификации. Эта ситуация подчеркнула серьезный недостаток безопасности и качества кода в проекте.
В устаревшем финансовом приложении есть метод на C#, ValueAGPFund, который критикуют за многочисленные побочные эффекты. Этот метод изменяет входные параметры и внутренние члены класса, выполняя несколько различных операций. Он также взаимодействует с методом CheckPreviousValuationIfRequired. Последний метод предназначен для получения и обработки данных предыдущей оценки на основе конкретных параметров.Серьезная проблема возникает из-за циклической зависимости, когда ValueAGPFund вызывает CheckPreviousValuationIfRequired, который, в свою очередь, вызывает ValueAGPFund. Кроме того, оператор return в CheckPreviousValuationIfRequired имеет ошибку, приводящую к NullReferenceException при попытке доступа к нулевому значению. Эта ошибка, вероятно, скрывает предполагаемую логику, которая, предположительно, заключалась в рекурсивном вызове ValueAGPFund только при наличии данных предыдущей оценки. Текущая реализация означает, что эта функция либо возвращает null, либо выдает исключение.Несмотря на эти очевидные недостатки, приложение, как сообщается, работает корректно. Отправитель предполагает, что проблемный код, CheckPreviousValuationIfRequired и его взаимодействие с ValueAGPFund, может быть избыточным. Однако он не решается удалить его, не убедившись, есть ли у него какие-либо непредвиденные побочные эффекты или полагаются ли другие части системы на выброшенное исключение NullReferenceException. Отправитель саркастически отмечает, что модульные тесты обычно смягчают такие риски, подразумевая их отсутствие или неадекватность. Основная проблема заключается в сложной и потенциально ошибочной логике этих взаимозависимых методов.
Лилит интегрировала новые инструменты в API Ruby on Rails, который имел функцию "dry_run". Эта функция позволяла сервисам рассчитывать изменения без их применения. Возникла проблема, поскольку новый инструмент отправлял {"dry_run": false} в формате JSON, но сервис интерпретировал это как true. Такое неожиданное поведение было вызвано вспомогательным методом param_true?, предназначенным для обработки строковых или нулевых входных данных. Логика метода, в частности !param_value, некорректно оценивала фактическое булево значение false как true. Эта проблема, вероятно, оставалась незамеченной до тех пор, пока POST/PATCH/PUT запросы не начали отправлять тела JSON с булевыми значениями. Ранее GET запросы, вероятно, отправляли только строковые представления параметров. Также было отмечено как неудобство избыточная проверка метода params.key?(param_name) после получения значения. Основной проблемой была ошибочная обработка булевых значений false вспомогательным методом. Это привело к постоянной неправильной идентификации флага dry_run. Исходное предположение дизайна о типах параметров, по-видимому, стало первопричиной.
Два анонимных сообщения освещают забавные случаи использования чисел. Первое игриво использует "42" в качестве числового ответа, когда форма требует ввода числа. Второе выражает удивление по поводу точности нанобайтов на веб-сайте SAS для размеров файлов. Марк Р. делится юмористической школьной политикой, направленной на полное юридическое покрытие переписки детей. Филипп Х. предлагает запутанное сообщение от чат-системы, задаваясь вопросом, является ли оно философским утверждением или каламбуром. Майкл Р. лаконично указывает на иронию, не уточняя ее природу. Текст также упоминает День освобождения рабов (Juneteenth) и включает рекламу руководства по миграции на .NET 9. Общий тон легкий, сосредоточенный на причудливых наблюдениях и игре слов. Числовой забавный факт от одного анонимного автора включал плохо реализованную числовую проверку. Другое числовое наблюдение касалось чрезвычайной точности отчетов о размерах файлов.
CdXz5zHNQW_HUlWQMkr2p.png
Анонимный исполнитель работает над устранением проблем, оставленных предыдущим консультантом. Они начали с решения наиболее критических задач. После их завершения они приступили к анализу кода, который в настоящее время не вызывал проблем, но имел потенциал для возникновения будущих. При проверке JavaScript они обнаружили пользовательскую функцию сортировки, которая вызвала немедленные опасения. Первая строка этой функции, obj[x._id.account_id] = x.count_total, была особенно тревожной. Код неправильно обращается к полю account_id в том, что должно быть уникальным идентификатором MongoDB. Это указывает на то, что произвольный объект используется в качестве уникального идентификатора в базе данных, что считается проблематичной практикой. Помимо проблемы с идентификатором, назначение этого кода в функции сортировки неясно. Строка, по-видимому, создает объект типа {"id0": 5}, а не выполняет сортировку. Эта ситуация представляет собой значительную загадку, поскольку код еще не вызвал сбоя. Основные вопросы заключаются в том, почему он еще не сломался и что произойдет, когда это в конечном итоге случится.
Progress Advanced Business Language (ABL) описывается как многословный и похожий на английский. Однажды разработчику понадобилась дата шестимесячной давности, но он счел точность ненужной. Этот подход включал сложную логику для получения приблизительной даты. Фрагмент кода иллюстрирует этот процесс, начиная с текущей даты. Затем вызывается процедура для извлечения номера недели и года. Условная логика корректирует номер недели и, возможно, год, чтобы представить примерно шесть месяцев назад. Другая процедура преобразует эти скорректированные значения обратно в дату. Автор отмечает, что это окольный путь для вычислений с датами. В Progress ABL на самом деле есть специальная функция ADD_INTERVAL для таких расчетов. Мирьям заменила всю обходную схему одной строкой, используя эту функцию. Язык также демонстрирует своеобразную обработку дат, позволяя создавать даты из целых чисел в огромном историческом и будущем диапазоне. Этот диапазон охватывает период от доисторических времен до далекого будущего. Многословность и необычная обработка дат способствуют аспекту "WTF".
Подключение к другой системе требует аутентификации с помощью учетных данных. Унаследованная Лизой функция connect, хотя и предназначена для обеспечения требований к учетным данным, некорректно использует значения параметров по умолчанию. Это позволяет вызывать функцию без каких-либо аргументов, хотя в конечном итоге она выдаст исключение. Основная проблема заключается не только в вводящих в заблуждение значениях по умолчанию, но и в кошмаре отладки, который это создает. Если имя пользователя опущено, исключение корректно сообщает: "требуется имя пользователя". Однако, если пароль опущен, отображается то же самое вводящее в заблуждение сообщение об ошибке: "требуется имя пользователя". Это фактически верно, но не решает реальную проблему, заключающуюся в отсутствии пароля. Это ошибочное сообщение об ошибке иллюстрирует концепцию "даже не ошибочно". Сообщение об ошибке технически корректно, но совершенно бесполезно для диагностики конкретной проблемы пользователя. Более точное сообщение об ошибке четко указывало бы, какие учетные данные отсутствуют. Этот выбор дизайна значительно затрудняет эффективную отладку и пользовательский опыт.
Дэниел столкнулся с проблемой: запрос к базе данных не вернул результатов, хотя ожидались данные. Он использовал оберточную функцию execute_read для взаимодействия с базой данных. Эта функция имела несколько сомнительных дизайнерских решений. Одной из проблем был параметр only_one, который значительно изменял тип возвращаемого значения, в отличие от специализированных функций библиотек баз данных.Другой проблемой было использование env.is_production() для определения пороговых значений времени выполнения запроса, что указывает на то, что вместо этого должны использоваться параметры конфигурации. Однако самым критическим недостатком был широкий обработчик исключений. Этот обработчик без разбора перехватывал все ошибки, регистрировал их, но позволял функции продолжать работу.В результате, когда запрос Дэниела содержал синтаксическую ошибку, функция перехватила исключение и вернула пустой набор результатов. Это скрыло фактическую ошибку, заставив Дэниела потратить значительное время на отладку. В конце концов он обнаружил ошибку, затерянную в логах. Автор подчеркнул опасность таких тихих сбоев, особенно в производственных средах, где могут возникать проблемы с сетью. Возврат пустых результатов без явного указания на ошибку приводит к значительной путанице и трудностям в отладке.
Читатель по имени Адам Р. прислал материал об USPS Informed Delivery, сервисе, который ежедневно отправляет сканы писем по электронной почте. Он отметил необычное слово "None" в теме письма, предположив ошибку в программировании. Другой читатель, Карлос, поделился проблемой с движком шаблонов Mint Mobile, намекая на ошибку в их системе. Роберт Ф. сообщил о странном уведомлении от Carbonite, в котором говорилось, что резервные копии будут удалены через миллион с лишним дней, предлагая абсурдно долгий срок для повторного подключения диска. The Beast in Black прокомментировал использование слова в Claude Code, поставив под сомнение его значение и предположив, что медленная система может быть намеренно честной. Питер С. выразил разочарование программой лояльности Sixt, где для достижения статуса "серебро" требуется заполнить обширные поля данных с неясной выгодой по сравнению с более высокими уровнями. Автор отвлекся на видео на YouTube после получения материала от Адама, что задержало завершение колонки. Представленные материалы освещают различные технические сбои и странности, с которыми пользователи сталкиваются в цифровых сервисах. Эти ошибки варьируются от странного текста в уведомлениях до маловероятных сроков для критических действий. Автор с юмором признает отвлечение, вызванное предоставленной ссылкой на видео.
CdXz5zHNQW_T1g81Fpnst.png
Автор выражает резкое неодобрение венгерской нотации в коде. Он приводит примеры ее неправильного использования и плохого обращения с датами. В конкретном фрагменте кода используется переменная sCDate2, инициализированная из скрытого поля Hdn_SelectedDate. Префикс s намекает на строку, но переменная содержит дату, а суффикс CDate2 не имеет объяснения. Другое скрытое поле, Hdn_SelectedShifts, хранит время в виде числа с плавающей запятой, где 10.5 представляет 10:30. Это значение затем обрабатывается с помощью DateTime.FromOADate. Автор углубляется в историю OLE Automation и ее своеобразное представление дат, смещенное от 30 декабря 1899 года. Эта система унаследовала ошибку Excel, где 1900 год считался високосным. Затем код преобразует число с плавающей запятой, представляющее часы, в OADate, извлекает время и объединяет его со строкой даты. Автор отмечает, что метод AddHours в C# был бы более простым решением. Более того, данные времени были вручную закодированы в виде чисел с плавающей запятой для выпадающего списка, вместо использования более традиционного формата. Этот запутанный процесс подкрепляет общее неприятие автором венгерской нотации.
Разработчики должны с осторожностью относиться к догмам, окружающим такие методологии, как разработка через тестирование или разработка, управляемая предметной областью. Хотя сама разработка, управляемая предметной областью (DDD), является здравой практикой, ее принципы могут применяться слишком жестко, что приведет к негативным последствиям. Основная идея DDD заключается в абстрактном моделировании бизнес-домена, отделенном от технических деталей. Это позволяет создавать более эффективную и адаптированную логику предметной области. Однако команда, хвастающаяся своим соблюдением DDD, особенно с использованием множества модных словечек, может быть тревожным сигналом.Пример иллюстрирует эту проблему: класс "домена" для CakeSessionRepositoryInterface явно нарушает принципы DDD. Репозиторий в DDD должен абстрагировать хранение данных для объектов предметной области. Он не должен выполнять проверки аутентификации, взаимодействовать с файлами cookie, управлять информацией о сеансе или быть привязанным к конкретному веб-фреймворку, такому как CakePHP. Предоставленный фрагмент кода, несмотря на свою краткость, демонстрирует фундаментальное непонимание и неправильное применение DDD. Это говорит о том, что команда на самом деле не практиковала DDD, а скорее придерживалась поверхностной интерпретации. Неправильное применение DDD подчеркивает опасность обращения с методологиями как с жесткой догмой.
Предоставленный фрагмент кода React отображает административные опции в зависимости от авторизации пользователя. Он использует подход условного рендеринга с логическим оператором И. Если пользователь является администратором или имеет разрешение на просмотр результатов, отображается заголовок "Действия администратора". После заголовка также условно отображается кнопка "Показать результаты". Эта кнопка появляется только в том случае, если пользователь соответствует тем же критериям авторизации: быть администратором или иметь возможность видеть результаты. Автор сравнивает эту реализацию с подходом "ремень и подтяжки", предполагая избыточность. Они считают, что это дублирование условия не повышает безопасность или функциональность. Код предназначен для ограничения доступа к конфиденциальным административным функциям. Однако повторяющиеся проверки отмечены как ненужные или неэффективные. Основная идея заключается в том, что авторизованные пользователи видят контент, связанный с администратором, но реализация ставится под сомнение из-за повторений.
Мошенник пытается обмануть людей, выдавая себя за представителя консорциума, намеревающегося приобрести Google. Мошенническая схема заключается в создании поддельных профилей в LinkedIn и рассылке электронных писем с вымышленными предложениями о покупке компании. Скорее всего, мошенник требует оплату комиссионных непосредственно перед предполагаемым заключением сделки. Одна из жертв с юмором указывает на несостоятельность мошенничества, заявляя, что у них даже нет Google. В другом анекдоте кто-то мучается со сложными циклами выставления счетов за телефонную связь. Описана странная проблема с программным обеспечением, называемая «обратной ошибкой Y2K», когда для обновления требуется вернуться в прошлое. Задается вопрос о вычислении 30% от «NaN», причем ответ хорошо определен. Наконец, подчеркивается ошибка «потеря в переводе», когда веб-сайт не предоставляет запасной текст на английском языке, если язык браузера не распознается. Также включена реклама BuildMaster, платформы для управления релизами.
CdXz5zHNQW_3MUMBcJ57Q.png
Конкатенация строк для SQL-запросов является частым источником проблем. Автор выступает за использование API построителя SQL вместо "сырых" SQL-строк. Этот построитель создает синтаксическое дерево, которое может быть преобразовано в SQL при необходимости, избегая проблем прямой манипуляции строками. Хотя ORM также являются вариантом, автор рассматривает их как "протекающие абстракции". Команда использовала Java и следовала правилу использовать построитель, а не SQL-строки. Однако для построения они использовали StringBuilder, который технически подходит под определение построителя. Этот подход с StringBuilder был лишь конкатенацией строк с дополнительными шагами. Пример кода демонстрирует использование StringBuilder для создания запроса, но результирующая SQL-строка была принципиально некорректной и неполной для предполагаемой цели. Тот факт, что этот нерабочий код работал в продакшене без немедленного обнаружения, вызывает серьезную озабоченность. Это подразумевает, что ошибки были проигнорированы без уведомления, или ошибочный вывод был недостаточно критичен, чтобы вызвать тревогу. Автор выделяет это как момент "WTF", подчеркивая отсутствие надежной обработки ошибок или проверки.
Фрэнк столкнулся с необычным кодом на JavaScript, использующим функцию useMemo из React. Хук useMemo обычно предназначен для оптимизации ресурсоемких вычислений. Однако в данном случае он использовался для определения авторизации, что представляло собой простую проверку значений переменных. Конкретный фрагмент кода демонстрировал, казалось бы, нелогичное условие: session && token && !group === false. Автор объясняет, что для авторизации session, token и group должны быть не равны null. Более простой подход заключался бы в session && token && group или !!(session && token && group). Автор ставит под сомнение отрицание group и то, как это могло бы дать правильный результат авторизации. Он подробно описывает поведение оператора && в JavaScript, включая короткое замыкание. Затем он анализирует предоставленное выражение, объясняя, что null === false оценивается как false. Автор выражает недоверие к тому, что код работает должным образом, предполагая, что это результат случайного накопления операторов, а не продуманного дизайна. Он предполагает, что это мог быть код, сгенерированный LLM, или продукт неопытного разработчика, подчеркивая отсутствие явного намерения.
Отец рассказывает о своем участии в IT-карьере сыновей, начавшейся примерно в 2012 году. Его трое сыновей получили работу в перспективном веб-проекте при значительной поддержке VIP-персон. Позже они попросили отца инвестировать в проект, что он и сделал. Проект был запущен с опозданием, с превышением бюджета и незавершенным. Затем генеральный директор привлек отца для устранения проблем, что ему успешно удалось. За время работы там он обнаружил, что предложения по проекту варьировались от 5000 долларов до более высоких сумм, причем один поставщик планировал привлечь дешевую рабочую силу из Индии. После восстановления функциональности генеральный директор заявил, что проект следует переписать на PHP, вдохновившись предполагаемым использованием этого языка Facebook. Затем состоялась встреча для оценки сроков переписывания, большинство предложили всего несколько недель. Отец, однако, дал реалистичную оценку — не менее семи месяцев. В результате его уволили за недостаточную "дальновидность". Его сыновья остались еще на год, сообщая о затянувшемся переписывании на PHP. Автор использует этот опыт, чтобы проиллюстрировать, что наиболее опытные люди часто дают наиболее точные, хотя и менее популярные, оценки времени и затрат. Затем он приглашает других поделиться своими межпоколенческими рабочими курьезами.
Этот сайт постоянно привлекает блог-спам из-за простой опечатки, облегчающей размещение ссылок на сайты. Майкл Р. ищет возможности трудоустройства в Великобритании и разместил ссылку на соответствующий сайт. Б.Дж.Х. разочарован неточными прогнозами погоды на Weather.com, особенно расплывчатыми прогнозами температуры. Джейк У. небрежно упоминает о вакансии в Дурмстранге без особой срочности или раздражения. Мартин К. указывает на новостную статью, в которой была допущена ошибка в дате, касающейся отставки генерального директора Microsoft в Дании. Тотти добавляет серию общих и саркастических комментариев на сайт. Основная функция сайта - размещение кратких, юмористических или критических замечаний по различным темам. Реклама продвигает бесплатное руководство по миграции на .NET 9, предлагая помощь в избежании трудностей при миграции. Общий тон - легкомысленный и разговорный, с разнообразным контентом, предоставленным пользователями. Взаимодействия пользователей предполагают наличие сообщества комментаторов и наблюдателей.
CdXz5zHNQW_f5FfsCMMuS.png
"Предоставленный код определяет функцию parametersFilter внутри приложения Qt, вероятно, используемую для проектирования зондов. Функция принимает тип зонда, индекс позиции и список проектирования зонда в качестве входных данных. Она призвана сгенерировать пару строк, to и from, на основе входных параметров. Основная логика включает в себя ряд условных операторов, которые обрабатывают различные сценарии. Эти сценарии включают проверку значения pos (является ли оно -1, 0 или индексом последнего элемента), и длину списка probeDesign. Функция также проверяет тип части зонда, в частности, ищет элементы "stylus". Разные ветки внутри кода обрабатывают граничные случаи, такие как когда список пуст или содержит только один элемент. Основная цель этих условий - выполнить проверку границ списка. Большинство типичных операций происходит в последнем операторе else. Анализ предполагает, что исходный код, насколько он сложен, вероятно, можно упростить. Автор делает вывод, что "two-liner" от untodesu предполагает, что возможна более простая версия функции, возможно, оптимизирующая избыточное обработку граничных случаев. Структура кода указывает на то, что оригинальный разработчик, возможно, переоценил функцию, чтобы решить конкретные граничные случаи. Сложность функции возникает из-за необходимости обработки различных позиций и типов зондов в предоставленном списке. Также предоставляется реклама инструмента выпуска программного обеспечения."
Текст обсуждает проблемный фрагмент кода из старого PHP-приложения электронной коммерции. Изначальный разработчик часто спрашивал, есть ли файлы для отправки. Представленный код предназначен для прикрепления файлов к электронному письму, если массив $files заполнен. Код избыточно проверяет, содержит ли массив $files элементы. Затем он перебирает массив, добавляя каждый файл в качестве вложения. Автор подразумевает, что разработчик знал, что двойное условие излишне. Отступы предполагают подсознательное осознание недостатков кода. Критическая проблема заключается в том, что избыточное условие блокирует производительность приложения. Упрощенный подход будет включать прямое перебор массива файлов. Ненужные условия демонстрируют плохие методы кодирования и отсутствие понимания. Текст завершается рекламой программного обеспечения BuildMaster.
Представленный текст демонстрирует три разных опыта работы в сложных условиях. Первая история описывает опыт анонимного разработчика, где незначительная проблема клиента с вращающейся иконкой обновления стала главным приоритетом, потребовав выходных неоплачиваемой сверхурочной работы. Фокус их компании диктовался важностью генерального директора, подчеркивая разочаровывающую расстановку приоритетов, основанную на влиятельности клиента. Вторая история, рассказанная Дэниелом Орнером, описывает компанию, использующую "плевок и скотч" для непрерывного создания динамичных цифровых флаеров для крупного ритейлера. Это неадекватное решение оказалось функциональным в течение восьми лет, потребляя значительную часть их вычислительной мощности.Последняя история, рассказанная Брайаном, иллюстрирует токсичную рабочую среду в военно-промышленном комплексе. Жизнь Брайана больше диктовалась огромной корпорацией, чем его реальными потребностями. Он столкнулся с постоянным давлением, требовательными рабочими сменами и отсутствием уважения после завершения проекта. Этот опыт привел к негативному восприятию отрасли, несмотря на предложения о будущей работе. Примеры направлены на то, чтобы подчеркнуть, насколько сложными могут быть некоторые рабочие условия. Текст завершается призывом к читателям поделиться своим аналогичным опытом и рекламой ProGet.
CdXz5zHNQW_VMaidyJewz.jpeg
Текст описывает ситуацию, связанную с веб-приложением с уязвимым кодом JavaScript. Код, изученный Моше, использовал динамическую генерацию SQL, создавая значительный риск безопасности. Функция sendLinkVal, предназначенная для обработки данных доставки, была построена с использованием конкатенированных SQL-строк. Это позволяло проводить потенциальные SQL-инъекции, подвергая риску конфиденциальные данные клиентов. Моше обнаружил эту уязвимость, подробно описав, как он смог манипулировать данными клиентов. Он сообщил о проблеме в службу доставки, что привело к контакту с разработчиком. Разработчик перенес запросы в .NET бэкенд в качестве решения. Однако решение бэкенда по-прежнему использовало конкатенированные SQL-строки. Несмотря на изменения, приложение оставалось подверженным SQL-инъекциям из-за отсутствия параметризованных запросов. Текст служит предостережением о плохих методах программирования и недостатках безопасности.
Делайла критикует скрипт на Python, который она нашла на своем рабочем месте. Скрипт пытается объединить данные YAML, эффективно обновляя старые конфигурации новыми. Основная проблема заключается в функции key_exists, которая без необходимости воссоздает встроенный оператор in в Python. Эта функция использует блоки try-except, что является неуклюжим подходом по сравнению с простым идиомом key in dictionary. Автор скрипта непоследовательно использует как правильный оператор in, так и ошибочную функцию key_exists в одном и том же коде. Общая структура кода неряшлива, напоминая плохо написанный скрипт оболочки. Скрипт читает и загружает YAML-файлы, используя yaml.load, а затем объединяет данные. Он содержит функцию revert_db_tags, предназначенную для обработки обновлений тегов базы данных. Основная логика включает в себя сравнение ключей и значений между старыми и новыми данными YAML. Сравнения запускают слияние или конкретные корректировки тегов в новых данных. Наконец, измененные данные записываются обратно в новый YAML-файл с помощью yaml.dump. Автор заключает, что скрипт написан плохо и демонстрирует ненужное усложнение встроенных функций Python.
Текст критикует плохо спроектированное приложение "data pump", используемое для синхронизации данных между сущностями Foo и Bar. Приложение включает в себя ночную пакетную задачу, написанную на Quarkus и взаимодействующую с устаревшей системой. Основная функция пакетной задачи - идентифицировать и обновлять сущности Bar на основе сущностей Foo. Код извлекает все сущности Foo вместо фильтрации для отсутствующих сущностей Bar, что неэффективно. Основная проблема заключается в процессе обновления в рамках транзакции, которая выполняет несколько вызовов веб-сервисов. Этот дизайн приводит к проблемам с производительностью, включая таймауты, конфликты и исчерпание соединений с базой данных. Использование долгоживущих транзакций, количество вызовов веб-сервисов и отсутствие надлежащей конфигурации пула соединений - все это способствует возникновению этих проблем. Автор критикует необходимость ручного управления транзакциями и нестабильность веб-сервиса. Фундаментальной проблемой является сам подход пакетной задачи, который приводит к созданию реляционно несостоятельных данных. Автор указывает, что редизайн полностью устранит пакетную задачу, улучшив ситуацию. Текст завершается рекламой платформы управления пакетами.
База данных JB включает в себя таблицу под названием three_alpha_numerics, предназначенную для генерации уникальных идентификаторов. Эта таблица имеет два столбца: digit, хранящий трехсимвольные строки, и is_numeric, указывающий, является ли цифра числовой ('Y') или нет ('N'). Основная цель этой таблицы - облегчить эффективную генерацию уникальных идентификаторов. Хранимая процедура использует эту таблицу для генерации уникальных идентификаторов, объединяя ее с другой таблицей и фильтруя неиспользованные цифры. Однако хранимая процедура учитывает только строки, где is_numeric равно 'Y'. Следовательно, значительная часть таблицы, содержащая нечисловые данные, никогда не используется. Таблица позволяет генерировать ограниченный набор уникальных идентификаторов, примерно 1000, что считается достаточным. Эта конструкция жертвует использованием большого объема информации для генерации этих идентификаторов. Такая настройка имеет решающее значение для управления сложной задачей генерации уникальных идентификаторов в базе данных. Неиспользованные буквенно-цифровые триплеты представляют собой следствие такого подхода. Конструкция отдает приоритет генерации уникальных числовых идентификаторов, даже с неэффективностью. Затем текст включает рекламное объявление BuildMaster.