Комментарии 66
Странно что программиста устроившего диверсию на заводе не посадили :-)
Ещё больше странности, что это конец 80-х, начало 90-х… Тогда вроде не рабочим делали, а именно «дисквалифицировали без возможности восстановления».
Думаю, что тогда статьи за это не нашлось.
За сабботаж можно было и к стенке стать, как шпион :-)
Его судили по статье 98 часть 2 УК
Получил 3 года условно + выплаты в размере зарплаты рабочих конвейера за период вызванного им простоя. Поскольку экономика в СССР была в определенном смысле виртуальна, ущерб от невыпущенной продукции на него не повесили.
Про перевод в рабочие (того самого конвейера — шоб знал) — тоже все верно.
Получил 3 года условно + выплаты в размере зарплаты рабочих конвейера за период вызванного им простоя. Поскольку экономика в СССР была в определенном смысле виртуальна, ущерб от невыпущенной продукции на него не повесили.
Про перевод в рабочие (того самого конвейера — шоб знал) — тоже все верно.
Может быть вы и имя знаете, и где почитать больше?
Мурат Уртембаев
community.livejournal.com/ru_bestarticles/64439.html
community.livejournal.com/ru_bestarticles/64439.html
Мне кажется это байка.
Самая плохая ошибка — допущенная в ТЗ
4 и 5 тип ошибок к программистам явно не относится, да и с вирусами вряд ли программисты что-то смогут сделать.
Могут контролировать целостность данных и обеспечить нормальное API для резервного копирования.
Ну почему не относится? Не напрямую, конечно, а косвенно. Аппаратный сбой запросто приведёт к неправильному функционированию ПО
Насчёт вирусов — и могут, и делают :) Даже опытный специалист может «влипнуть» в такую историю
Кстати, совсем недавно такой инцидент мирового масштаба произошёл, с вирусом Induc (Virus.Win32.Induc.a), под ударом оказалось огромное количество программ, которые стали детектироваться антивирусами как вредоносное ПО…
Насчёт вирусов — и могут, и делают :) Даже опытный специалист может «влипнуть» в такую историю
Кстати, совсем недавно такой инцидент мирового масштаба произошёл, с вирусом Induc (Virus.Win32.Induc.a), под ударом оказалось огромное количество программ, которые стали детектироваться антивирусами как вредоносное ПО…
без тестирования сейчас наврядли вообще программы в производство запускаются
не все можно предусмотреть.
вот еще примеры непредусмотрительности программистов feelovblog.ru/2008/03/09/elektronnye-vojny-ne-za-gorami/
вот еще примеры непредусмотрительности программистов feelovblog.ru/2008/03/09/elektronnye-vojny-ne-za-gorami/
IMHO, здесь тоже хватает исторических анекдотов. К примеру, вот об этом случае я читал ранее:
Байка. В действительности сбой наблюдался на имитаторе во время штатной программы испытаний. Причем, там были и более неприятные — но также найденные на имитаторе — сбои. Например, в первой версии бортовая система разрешала убирать шасси самолету, который стоит на полосе.
Соответственно, вспоминаем про закон 13-го удара…
Испытания американского истребителя F-16 проводились, понятное дело, в северном полушарии. На заключительном этапе самолет решили проверить где-то в Латинской Америке, но уже с другой стороны экватора. При переводе самолета в режим автопилота он автоматически развернулся “вверх ногами”.
Байка. В действительности сбой наблюдался на имитаторе во время штатной программы испытаний. Причем, там были и более неприятные — но также найденные на имитаторе — сбои. Например, в первой версии бортовая система разрешала убирать шасси самолету, который стоит на полосе.
Соответственно, вспоминаем про закон 13-го удара…
Мне больше нравится история про самолёт, который летал в районе Мёртвого моря. Высота над уровнем моря там является отрицательной величиной. В один момент значение высоты самолёта составило 0, где-то произошло деление на ноль и бортовой компьютер крашнулся :)
Спасибо за статью =)
Ловите + в карму =)
Ловите + в карму =)
>Ещё один печальный пример: в восьмидесятые годы прошлого века в Антарктиде разбился самолёт с туристами на борту, поскольку в управляющую полётом систему были заложены неверные координаты аэропорта взлёта и система ошибочно рассчитала высоту полёта над горами
за такое надо пальцы отрубать прогерам :/
за такое надо пальцы отрубать прогерам :/
ага, а летчик, прощелкавший клювом гору, это ок?
И уж если на то пошло не только прогерам, а менеджерам, тестерам, да много еще кому.
И уж если на то пошло не только прогерам, а менеджерам, тестерам, да много еще кому.
А причём тут прогеры? Обычно данные вводит операторы. Не, может быть, что данные там в константах были зашиты, вот тогда точно надо отрывать :)
А проггеры тут при том, что
Точнее, они не во всех примерах замешаны явно, зато все случаи касаются их косвенно
Каюсь, не совсем раскрыл я цель статьи, в результате многие задают вопросы «а при чём тут программисты?»
В двух словах: цель была показать все виды ошибок, с которыми могут столкнуться создатели программных продуктов. Без разницы, произойдёт сбой оборудования, или пользователь-ламер введёт в программу набор случайных значений. В итоге программный продукт может выдать неправильный результат, а уж разбираться, что же случилось, приходится… конечно же в 90% случаев разработчикам! :)
После публикации довольно-таки оперативно дописал в начале
но на этой фразе в скобках мало кто сфокусировал внимание…
Ну, значит учту этот момент в будущем :) Ложка дёгтя никогда не помешает
проектирование программного обеспечения с учётом человеческого фактора
Точнее, они не во всех примерах замешаны явно, зато все случаи касаются их косвенно
Каюсь, не совсем раскрыл я цель статьи, в результате многие задают вопросы «а при чём тут программисты?»
В двух словах: цель была показать все виды ошибок, с которыми могут столкнуться создатели программных продуктов. Без разницы, произойдёт сбой оборудования, или пользователь-ламер введёт в программу набор случайных значений. В итоге программный продукт может выдать неправильный результат, а уж разбираться, что же случилось, приходится… конечно же в 90% случаев разработчикам! :)
После публикации довольно-таки оперативно дописал в начале
а программисты всё ещё допускают те же самые ошибки (или же сталкиваются с ними)
но на этой фразе в скобках мало кто сфокусировал внимание…
Ну, значит учту этот момент в будущем :) Ложка дёгтя никогда не помешает
Без разницы, произойдёт сбой оборудования, или пользователь-ламер введёт в программу набор случайных значений. В итоге программный продукт может выдать неправильный результат, а уж разбираться, что же случилось, приходится… конечно же в 90% случаев разработчикам! :)
В истории с самолетом никакая программа не давала неправильных результатов и не получала неправильных входных данных.
Причиной стали организационные проблемы — не была проработана схема внесения изменений в полетные планы.
А еще не описан вариант — когда ошибка возникает на этапе формирования требований к системе.
В случае с шаттлом ситуацию спас не только командир корабля, но и заученные им действия в случае такой ситуации.
Вообще интересная статья, спасибо :)
Вообще интересная статья, спасибо :)
Жаль, что из-за ошибок страдают люди.
> Неудача при запуске первого американского спутника к Венере случилась, вероятнее всего,
> из-за ошибки в программе – вместо требуемой в операторе точки программист поставил запятую.
Все было ровно наоборот:
В программе на Фортране IV требовался цикл
DO 50 I = 12,525
А программист поставил точку, получился оператор присваивания неявной переменной DO50I (пробелы в Фортране игнорируются)
DO 50 I = 12.525
> из-за ошибки в программе – вместо требуемой в операторе точки программист поставил запятую.
Все было ровно наоборот:
В программе на Фортране IV требовался цикл
DO 50 I = 12,525
А программист поставил точку, получился оператор присваивания неявной переменной DO50I (пробелы в Фортране игнорируются)
DO 50 I = 12.525
Спасибо, очень ценное замечание. Поменял строчки местами
Даже тут не обошлось без ошибок )
Даже тут не обошлось без ошибок )
Строчки-то вы поменяли, а текст видимо нет, написано «вместо требуемой в операторе точки программист поставил запятую». Тут тоже, как я понял нужно поменять )
Про Луну конечно повеселило :)) — ничего так «Вражеская ракетка» :))
Летом 1988 года в Мичиганском госпитале компьютерный вирус инфицировал три компьютера, которые обрабатывали информацию о пациентах. Вирус перемешал фамилии пациентов в базе данных. В результате данного «вмешательства» диагностические сведения одних пациентов оказались приписанными другим пациентам.
На эту тему я не встречал внятных публикаций, но предположительно заражен вирусом был компьютер, где хранились оцифрованные диагностические изображения. Причем вроде как нет особой уверенности, что это вообще был вирус, а не сбой оборудования.
Одна из первых компьютерных систем противовоздушной обороны США (60-е годы) в первое же дежурство подняла тревогу, приняв восходящую из-за горизонта Луну за вражескую ракету, поскольку этот «объект» приближался к территории США и не подавал сигналов, что он «свой» :)
Байка. Реальность такова: 5.10.1960 Луна действительно попала в поле зрения одного из радаров BMEWS, и выданные системой данные изумили операторов. Никакой тревоги поднято не было. И это не было первое дежурство ни данного радара, ни, тем более, всей системы. По результатам систему скорректировали, чтобы она игнорировала слишком далекие объекты.
Ещё один печальный пример: в восьмидесятые годы прошлого века в Антарктиде разбился самолёт с туристами на борту, поскольку в управляющую полётом систему были заложены неверные координаты аэропорта взлёта и система ошибочно рассчитала высоту полёта над горами
В действительности причиной катастрофы стал комплекс причин, которые давно известны.
И? Посмотрел, там тоже написано про координаты
Комплекс комплексом, но роковую роль сыграли неправильные координаты, поэтому я не совсем понял, при чём тут слова «в действительности» :) Предпосылки ввода неверной информации пилотами конечно интересны и как раз составляют «комплекс», но первопричина (суть примера) важнее
Комплекс комплексом, но роковую роль сыграли неправильные координаты, поэтому я не совсем понял, при чём тут слова «в действительности» :) Предпосылки ввода неверной информации пилотами конечно интересны и как раз составляют «комплекс», но первопричина (суть примера) важнее
Вы читали невнимательно. Были введены ПРАВИЛЬНЫЕ координаты. Просто экипажу забыли сообщить, что сегодня они летят фактически другим маршрутом. Теоретически, это наверняка прошло бы никем не замеченным, если бы не наложились другие факторы.
Тот факт. что координаты, которые использовались ДО этого были с ошибкой, значения не имеет — проблема не в наличии ошибки в прошлом, а в том, что экипаж не информировали об изменении. В точности то же самое произошло бы при любой другой причине изменения координат.
Сама ошибка — пока ее не исправили — никому годами не мешала.
Unknown to them, the coordinates had been modified earlier that morning to correct the error introduced years previously and undetected until now
Тот факт. что координаты, которые использовались ДО этого были с ошибкой, значения не имеет — проблема не в наличии ошибки в прошлом, а в том, что экипаж не информировали об изменении. В точности то же самое произошло бы при любой другой причине изменения координат.
Сама ошибка — пока ее не исправили — никому годами не мешала.
Я в шоке от работы американских программистов в НАСА, я бы их поувольнял без выплаты премий, а особо злостных заставил бы поатить стоимость потернного спутника. Почему они толком ничего не тестируют там? Такое ощущение что не ракету, а какой-то запорожец делают.
Не в тестировании решение проблем, а в создании языков, на которых труднее писать неправильные программы. Тот же Фортран провоцировал на ошибки; PL/1 позволял выполнить как программу вообще почти любой текст. Любимый многими (и мною) Perl не имеет внятной системы документирования и проверки передаваемых функциям аргументов; PHP, Javascript не требуют объявления переменных; С предоставляет неограниченный доступ к памяти.
Ну и программирование с хорошими тестами стоит даже не в разы дороже, а на порядки — позволить себе это могут очень богатые компании. Это требует и соблюдения технологии программистами, что для кодеров приемлемо, а для энтузиастов нет, и увеличения сроков, что неприемлемо для заказчиков. Поэтому тесты — не решение.
Ну и программирование с хорошими тестами стоит даже не в разы дороже, а на порядки — позволить себе это могут очень богатые компании. Это требует и соблюдения технологии программистами, что для кодеров приемлемо, а для энтузиастов нет, и увеличения сроков, что неприемлемо для заказчиков. Поэтому тесты — не решение.
К сожалению, выбор есть только между тестами и верификацией валидности программ. Первое более-менее успешно используется на практике, тогда как второе показало себя экономически нежизнеспособным на реальных программах еще в семидесятых годах.
Языки, на которых труднее писать неправильные программы (та же Ada), на практике сейчас сдают позиции и уступают место языкам, на которых проще писать правильные программы, сопровождаемые тестами. Обращаю внимание: та же Ada при достаточно высоком уровне жесткости на уровне языка никак не решает проблему дефектов алгоритмического уровня.
Я не буду спорить с оценкой того, насколько программирование с хорошими тестами (не модульными, а тестами вообще — полного спектра) дороже, чем программирование без тестирования — просто потому, что ни я, ни лично мне известные люди никогда не видели ни одной системы, стоящей упоминания, которая была бы сделана без тестирования. Возможно, без тестирования дешевле. Но таких систем, доведенный до внедрения, в природе нет.
Языки, на которых труднее писать неправильные программы (та же Ada), на практике сейчас сдают позиции и уступают место языкам, на которых проще писать правильные программы, сопровождаемые тестами. Обращаю внимание: та же Ada при достаточно высоком уровне жесткости на уровне языка никак не решает проблему дефектов алгоритмического уровня.
Я не буду спорить с оценкой того, насколько программирование с хорошими тестами (не модульными, а тестами вообще — полного спектра) дороже, чем программирование без тестирования — просто потому, что ни я, ни лично мне известные люди никогда не видели ни одной системы, стоящей упоминания, которая была бы сделана без тестирования. Возможно, без тестирования дешевле. Но таких систем, доведенный до внедрения, в природе нет.
Ошибки так же неисчерпаемы, как и атом.
Аксиома. В любой программе есть ошибки.
Закон пропорциональности. Чем более программа необходима, тем больше в ней ошибок.
Следствие. Ошибок не содержит лишь совершенно ненужная программа.
Фундаментальный закон теории ошибок. На ошибках учатся.
Следствие 1. Программист, написавший программу, становится ученым.
Следствие 2. Чем больше программист делает ошибок, тем быстрее он делается ученым.
Следствие 3. Крупный ученый-программист никогда не пишет правильные программы.
Указание начинающему программисту. Если вы с первого раза сумели написать программу, в которой транслятор не обнаружил ни одной ошибки, сообщите об этом системному программисту. Он исправит ошибки в трансляторе.
Закон необходимости ошибок. Программист может обнаружить ошибку только в чужой программе.
Следствие. Ошибке не все равно, кто ее обнаружит.
Аксиома. В любой программе есть ошибки.
Закон пропорциональности. Чем более программа необходима, тем больше в ней ошибок.
Следствие. Ошибок не содержит лишь совершенно ненужная программа.
Фундаментальный закон теории ошибок. На ошибках учатся.
Следствие 1. Программист, написавший программу, становится ученым.
Следствие 2. Чем больше программист делает ошибок, тем быстрее он делается ученым.
Следствие 3. Крупный ученый-программист никогда не пишет правильные программы.
Указание начинающему программисту. Если вы с первого раза сумели написать программу, в которой транслятор не обнаружил ни одной ошибки, сообщите об этом системному программисту. Он исправит ошибки в трансляторе.
Закон необходимости ошибок. Программист может обнаружить ошибку только в чужой программе.
Следствие. Ошибке не все равно, кто ее обнаружит.
Каким образом Ариана-5 попала в ошибки датчиков, если проблема была в блоке управления?
Неправильный вопрос. Правильный вопрос: как вообще это попало в статью о программистских ошибках? Я не знаю подробностей об этом случае, но согласно описанию, которое дано выше, программа отработала корректно.
подробности такие: скопипастили часть кода из предыдущей версии, которая летала на значительно меньшей скорости, а для полного счастья отключили обработчик переполнений, чтобы работало быстрее. продолжать надо? :)
en.wikipedia.org/wiki/Ariane_5_Flight_501
en.wikipedia.org/wiki/Ariane_5_Flight_501
В таком варианте вопросов к уместности. Выходит, что история переврана в статье еще в одном пункте… :(
вот и я о том же :)
кстати, я слышал, что про фортран — это байка, т.е. баг такой был, но он никаких серьезных проблем не вызвал: catless.ncl.ac.uk/Risks/9.54.html#subj1
кстати, я слышал, что про фортран — это байка, т.е. баг такой был, но он никаких серьезных проблем не вызвал: catless.ncl.ac.uk/Risks/9.54.html#subj1
При чём тут датчики? Ну я опять же читаю вики (спасибо за ссылку :), этот момент описан:
Specifically, the Ariane 5's greater acceleration caused the back-up and primary inertial guidance computers to crash, after which the launcher's nozzles were directed by spurious data.
Вы опять все перепутали. Вы пишете:
В действительности датчики сработали корректно и передали ДОСТОВЕРНУЮ информацию. Но программа не смогла ее правильно обработать. И четко указана причина:
получил от датчиков системы управления неверную информацию о пространственной ориентации ракеты
В действительности датчики сработали корректно и передали ДОСТОВЕРНУЮ информацию. Но программа не смогла ее правильно обработать. И четко указана причина:
Ariane 5's flight path was considerably different and beyond the range for which the reused computer program had been designed
Спасибо за отличную статью! Прочитав комментарии заметил, что SCoon у нас специалист по всем серьезным программным ошибкам. :-) Видимо серьезно интересовался в свое время.
А на самом деле чужие истории — это всегда интересно. Особенно когда они касаются программирования, больших финансовых затрат и хочется сказать «Вау! Как я раньше этого не знал» — однозначно хочется знать.
Может SCoon сможет поделиться с нами в отдельном хабратопике интересными историями, которые мы еще не знаем?
А на самом деле чужие истории — это всегда интересно. Особенно когда они касаются программирования, больших финансовых затрат и хочется сказать «Вау! Как я раньше этого не знал» — однозначно хочется знать.
Может SCoon сможет поделиться с нами в отдельном хабратопике интересными историями, которые мы еще не знаем?
Интересная статья, но название к ней мало подходит, так как к программистам многие ошибки не имеют отношения. У самих недавно был случай когда лег домен MS из-за ошибки в памяти сервера.
Косвенно — имеют. Повторяться не буду, см. выше:
habrahabr.ru/blogs/history/76002/#comment_2210383
habrahabr.ru/blogs/history/76002/#comment_2210383
Забавная статья, почти готовый сценарий для Mythbusters: практически в каждом пункте, о котором я что-нибудь знаю, причина переврана. По остальным пунктам пруфлинков в статье нет, поэтому, экстраполируя, представляю себе их качество.
Странно, что не включили летальный случай с race condition при определении дозы в рентгеновском аппарате.
Странно, что не включили летальный случай с race condition при определении дозы в рентгеновском аппарате.
Ну насчёт перевирания причин — я уже отписался в соседних комментариях. Причины-то наоборот совпадают, разве что происходило это, как выясняется, менее эффектно, без приукрас :)
Насчёт proof links — выкладываю, но это будут не гиперссылки + этих источников у меня на руках нет, поэтому я не видел особо смысла их указывать:
Насчёт proof links — выкладываю, но это будут не гиперссылки + этих источников у меня на руках нет, поэтому я не видел особо смысла их указывать:
- Мейер Б., Бодуэн К. Методы программирования. В 2-х томах. Т. 2. Пер. франц. М.: Мир. 1982
- Душа твоя — космонавтика. Газета «Правда», 8 апреля 1989
- Батурин Ю. М. Проблемы компьютерного права. М.: Юрид. лит.
- Альфред З. Спектор. Управление процессами. Современный компьютер. Сборник научно-популярных статей. Пер. с англ. М.: Мир. 1986
- Батурин Ю. М., Жодзишский А. М. Компьютерная преступность и компьютерная безопасность. М.: Юрид. лит, 1991
- Компьютерное обеспечение для «Ариан-5» требует доводки. Газета «Финансовые известия», 62 (296), 1996
Интересно, откуда у вас эти ссылки, если источников у вас нет? Вы записываете всю библиографическую инфу о том, что читаете? :)
Что касается Ariane 5, есть официальный отчёт комиссии расследования: [ОКР] esamultimedia.esa.int/docs/esa-x-1819eng.pdf
Исходя из него [ОКР 2.1, 3.1.m-p, 3.2], вывод в вашем посте о том, что «компьютер, находившийся на борту ракеты, получил от датчиков системы управления неверную информацию о пространственной ориентации ракеты», неверен. Компьютер получил от датчиков совершенно точную информацию, но в дальнейшем ошибки ПО, причём в функции, которая непосредственно на Ariane 5 не нужна произошло переполнение 16 битного целого со знаком, в которое загонялось 64 битное значение с плавающей запятой от датчика и инерционка стала давать неверные данные.
По другим пунктам вашего поста не хочу исследовать, т.к. нет времени, но предполагаю, что и там такие же неточности.
На самом деле проблема вашего поста в стиле подачи материала. Если бы вы не выбрали стиль жёлтой прессы («ААА! В Тибете йоги по 400 лет висят в пещерах кверх ногами!»), а написали бы только то, что происходило на самом деле, то статья была бы очень полезной.
В частности, по Ariane 5. Вы написали, что причина была в неисправности датчиков. Тогда как причина освещена в [ОКР 3.1.m]: "...but nevertheless retained for _commonality_ _reasons_ and allowed...". Т.е истинная причина: программисты не захотели причесать код и убрать лишнее.
Согласитесь, что эта причина — гораздо более обща и актуальна, чем неисправность датчиков: сколько раз мы сталкиваемся в ООП с Fragile base class или потомками, в которых доступны неактуальные методы из предков из-за того, что кому-то стало лень нормально скопипастить, отредактировать и оттестировать код вместо связывания через наследование похожих, но несвязываемых сущностей.
Извиняюсь за черезчур эмоциональный комментарий. :)
Что касается Ariane 5, есть официальный отчёт комиссии расследования: [ОКР] esamultimedia.esa.int/docs/esa-x-1819eng.pdf
Исходя из него [ОКР 2.1, 3.1.m-p, 3.2], вывод в вашем посте о том, что «компьютер, находившийся на борту ракеты, получил от датчиков системы управления неверную информацию о пространственной ориентации ракеты», неверен. Компьютер получил от датчиков совершенно точную информацию, но в дальнейшем ошибки ПО, причём в функции, которая непосредственно на Ariane 5 не нужна произошло переполнение 16 битного целого со знаком, в которое загонялось 64 битное значение с плавающей запятой от датчика и инерционка стала давать неверные данные.
По другим пунктам вашего поста не хочу исследовать, т.к. нет времени, но предполагаю, что и там такие же неточности.
На самом деле проблема вашего поста в стиле подачи материала. Если бы вы не выбрали стиль жёлтой прессы («ААА! В Тибете йоги по 400 лет висят в пещерах кверх ногами!»), а написали бы только то, что происходило на самом деле, то статья была бы очень полезной.
В частности, по Ariane 5. Вы написали, что причина была в неисправности датчиков. Тогда как причина освещена в [ОКР 3.1.m]: "...but nevertheless retained for _commonality_ _reasons_ and allowed...". Т.е истинная причина: программисты не захотели причесать код и убрать лишнее.
Согласитесь, что эта причина — гораздо более обща и актуальна, чем неисправность датчиков: сколько раз мы сталкиваемся в ООП с Fragile base class или потомками, в которых доступны неактуальные методы из предков из-за того, что кому-то стало лень нормально скопипастить, отредактировать и оттестировать код вместо связывания через наследование похожих, но несвязываемых сущностей.
Извиняюсь за черезчур эмоциональный комментарий. :)
вот почему им срочно потребовалось высадить людей на Луну!
Просто установили там систему чтобы правильно отвечала на вопрос «свой/чужой».
Теперь систему можно не переделывать. Программисты как всегда ленивы. А лень — двигатель прогресса!
Просто установили там систему чтобы правильно отвечала на вопрос «свой/чужой».
Теперь систему можно не переделывать. Программисты как всегда ленивы. А лень — двигатель прогресса!
важная разработка — беспилотный самолет, управление с компа из центра.
первый испытательный запуск первого образца.
самолет взлетает, пролетает 10 метров и на полном ходу врезается в землю.
за секунду до этого выбегает главный программист с криком: «подождите, я знак перепутал...»
первый испытательный запуск первого образца.
самолет взлетает, пролетает 10 метров и на полном ходу врезается в землю.
за секунду до этого выбегает главный программист с криком: «подождите, я знак перепутал...»
Возможно, вы будете смеятся, но один из безпилотных летатетльных аппаратов, совершая бреющий полёт над Мёртвым Морем, вдруг «сошёл с ума» и «убил себе о море». Как выяснилось создатели программного обеспечения не учли того, что абсолютная высота над уровнем моря может быть и отрицательной.
А один из моих приятелей был свидетелем того, как управляемая торпеда (по сути ракета только для воды) пыталась «вынырнуть» вместо того что бы «поднырнуть» — ошибка была найдена — переполюсовка при монтаже.
А один из моих приятелей был свидетелем того, как управляемая торпеда (по сути ракета только для воды) пыталась «вынырнуть» вместо того что бы «поднырнуть» — ошибка была найдена — переполюсовка при монтаже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программист и ошибки — актуально во все времена