Комментарии 33
С JSON бы такое вряд ли прокатило. Потому что там 0, "0", false и "false" — это, как говорят в Одессе, 4 большие разницы, и поэтому хорошее, типизированное API при сериализации такой джейсонки выкинет ошибку.
И вообще-то мне даже интересно как веб-сервис мог пропустить такой документ. Разве что тип поля был объявлен как String, но это надо быть сильно криворуким.
Ха-ха, схема. Тип (http://www.w3.org/2001/XMLSchema):boolean допускает 4 значения: 0, 1, true и false.
Нет, так-то мне схемы в XML нравятся — но только при условии, что обе стороны понимают что на самом деле эта схема означает.
И вообще-то мне даже интересно как веб-сервис мог пропустить такой документ. Разве что тип поля был объявлен как String, но это надо быть сильно криворуким.
Да запросто: они работали с XML через DOM, а не через десериализацию.
хорошее, типизированное APIэто от формата не сильно зависит.
Например, в Ирландии на прошлой неделе цены на электричество (фьючерсные, не для конечного потребителя) достигли рекордных -36 фунтов. Просто низкое потребление и сильные ветра, а у них 30% — это ветровая энергия.
Нефть — точно так же — низкий спрос, но добыча не останавливается потому что во многих странах, кроме Саудовской Аравии, приостановить добычу довольно дорого. А уж совсем остановить скважину — это совсем дорого. А как объясняли где-то тут в соседней ветке — перед экспирацией фьючерсных контрактов очень часто трейдеры избавляются от активов в последние моменты и цена может сильно опускаться.
Но как говорится — и не заряженное ружье раз в жизни выстреливает. Так и тут — одна кривая строчка + она кривая строчка + непогрешимый трейдер = овердофига угля.
Народ в комментах обычно выражает здоровый скептицизм, но даже в комментариях к оригиналу нашелся кто-то, кто заявляет что похожая история приключилась в компании, в которой он работал.
Я тоже начал искать пруфы, но потом подумал — какого черта! Я сам уже 4.5 года работаю на небольшую компанию, которая торгует фьючерсами на электричество. И я, в сущности и есть тот самый (и единственный) программист, который пишет схожий код. И, поверьте, у меня встречается разный говнокод по разным причинам (у всех встречается же?).
И я в предметной области довольно слабо разбираюсь, потому что все зарегулировано настолько серьезно, что просто огромное количество документации и ее невозможно всю осилить.
Я вполне допускаю что могу однажды совершить ошибку, которая приведет к чему-нибудь похожему. Довольно часто приходится иметь дело с XML-документами (правда, входящими), у которых нет схемы или хз где ее взять.
Что до оригинала — скорее всего просто журналист где-то слышал байку, проверил насколько вероятно получить такое стечение совпадений, добавил «художественный вымысел» и опубликовал.
Нет, не байка. Это одна из классических историй с The Daily WTF, старинного и уважаемого коллективного блога околоИТшных приколов. Ведётся он аж с 2004 года, а правила модерации там изначально жёсткие. История, присланная без пруфов, её просто не пройдёт.
К сожалению, он не очень известен, но я на него подписан уж лет 15 как. Некоторые истории прямо готовые антипримеры для всяких обучающих материалов, довольно часто юзаю их в таком качестве.
The stories we tell on The Daily WTF (i.e. the Feature Articles) are “dramatized retellings” of actual events. It’s a bit like those “based on a true story” movies you’ve seen: we take the core facts surrounding the WTF moments (the who, what, where, when) and try to create an entertaining, engaging, and memorable story. It’s a fun and challenging excise for us as writers and it’s what most readers come to the site for.
То есть «вы присылаете историю — мы ее приукрашиваем».
Не очень понятно как именно они проверяют достоверность — это фактически авторский блог и максимум что читатель может — это поверить авторам.
Даже интересно какие были бы способы проверить историю из топика. Скажем я слышал эту историю от своего друга по телефону и решил ее запостить на этот сайт, но ни имени друга ни название компании я писать бы не стал.
Напомнило одну историю, хоть и не связанную с трейдерством, но зато связанную с физической доставкой и одной строчкой в коде. Одна компания тестировала свежеразвёрнутые сервисы мобильного оператора, и тестировщик вместо тестового API ломанулся на прод (с учёткой созданной для тестирования прода), успев в цикле заказать несколько тысяч контрактов с телефонами на адрес компании. О том что что-то пошло не так догадались только после вскрытия большого ящика с первой партией, и что примечательно, отдел доставки даже глазом не моргнул что "частник" (контракты для частных лиц) заказал такую огромную партию, даже сгруппировали по ящикам вместо одиночной доставки.
Час назад один из клиентов сообщил, что в проге что я сделал для их банкомата я сделал ошибку, которая привела к умножению на 100 номиналов всех купюр которые вносят клиенты.
В этом контексте читать статью вдвойне занятнее…
Вспоминаются похожего рода ошибки при назначении региональных цен во всяких игровых магазинах типа Steam и прочих: время от времени попадаются игры, на которые цены выставляли в копейках.
Например, Valiant Hearts — у них в первую пару часов после выхода цена в России была 700. Копеек.
Или MS Office тоже когда-то недолго стоил несколько тысяч копеек.
А тут вышло с точностью до наоборот. (Правда, всё равно в плюсе для клиента)
У вас появилось время читать? :)
А вообще выглядит так, что использовали инт для копеек/центов/… в одних местах, но где-то decimal для полных единиц.
float нельзя же использовать при операциях с деньгами, а с фиксированной точкой в языке нет, да и нужды не было изначально, т.к. копейки не нужны были.
Были только купюропиемники, всё хранилось в целых УЕ. А потом добавили монетоприемники, понадобилась поддержка мелкий значений. Я просто умножил номиналы на 100, чтобы и дальше всё в int хранить.
Ну и в одном месте проморгал обратную конвертацию.
Как по заказу: история о том, как строка кода превратилась в килотонны угля