Книги: How to Make Mistakes in Python

How to Make Mistakes in Python
Mike Pirnat.
How to Make Mistakes in Python.
O’Reilly, 2015.
Небольшая книжка-минутка на вечер. Кажется, любой Python-разработчик может такую написать. О том, как вместо class влепить def, как [после Java] попасть в ад getter’ов и setter’ов, как обмазаться декораторами и сидеть дурак дураком. Обычный житейский опыт.
В тексте нет откровений. Также книга не кажется полезной для начинающих (они могут не понять или не поверить, почему что-то плохо). Но почитать забавно.

Лучшие ошибки софта III

21 сентября 1997 года ответственный человек вбил нолик в базу данных американского авианосца Yorktown, чем на три часа превратил эту махину в печально дрейфующее корытце. Классика division by zero error, из-за которой по цепочке падений всякого софта на борту проблема докатилась до двигателей, которые тоже остановились. Корытцем авианосец стал не во время чего-нибудь боевого, потому всё обошлось.

В Калифорнии 2011 года ошиблись интереснее. Тюрем много, сидят в них толпами. Решили проредить ряды сидельцев, выпустив на волю безобидных. Проредили, выпустили. Только вот из-за баги в софте, отвечающего за личные дела, около 450 выпущенных оказались отнюдь не безобидными воришками, но вполне способными на насилие (некоторые из них потом это подтвердили действием). Устроили себе холодное лето пятьдесят третьего, в общем.

Не самый опасный, но весьма неприятный баг случился с немецкими банковскими карточками в 2010 году. В карточках микрочип. В 30 с лишним миллионах карточек этот микрочип крякнул в момент Нового года, не в силах распознать 2010-й. Всем было неприятно. Затрудняюсь подсчитать ущерб, но то, что в Новый год треть населения Германии не смогла оплатить покупки, мелочью не кажется.

И снова 2010-й год, на сей раз в Великобритании. Есть база людей, готовых пожертвовать свои органы. По состоянию на тот год в базе было около 17 миллионов человек. Проблема в том, что у ~800,000 доноров орган мог быть записан ошибочно. Как понимаю, вскрылось после того, как у 25 пожертвовавших удалили не то. Масштаб и ущерб не очень велик, наверное, но показателен. Довольно простая база данных. Вряд ли сложный интерфейс. Наверняка ошибки в ней простые и глупые. Но на кону оказалось человеческое здоровье.

Завершаем тем же 2010-м годом. 11-го января американские инженеры обновили софт у наземных GPS-станций, чтобы те шли в ногу с новым поколением спутников. Спустя две недели обнаружилось, что обновление фактически сделало слепыми от 8,000 до 10,000 военных GPS-приёмников без учёта пострадавших железок в зонах боевых действий (Ирак и Афганистан). Чтобы понять уровень ошибки, надо вспомнить про наличие этих вот GPS-приёмников во всём современном стреляющем — от джипов и танков до истребителей и ракет.

Лучшие ошибки софта II

Mars Climate Orbiter, 1998 год — отличная иллюстрация того, чем заканчивается разобщённость команд разработки. Железка должна была подкрасться к Марсу, выйти на орбиту и оттуда следить за интересным. Так и произошло бы, не используй разработчики двигателя метрическую систему СИ, а разработчики софта британскую метрическую систему. Состыковаться не получилось на $327M — спутник распался в атмосфере, промахнувшись на разницу между ньютонами и фунт-силами.

В 2005 году крупнейший британский продуктовый ритейлер J Sainsbury PLC потерял $526M. История покрыта мраком, удаётся найти лишь хвостики произошедшего. Выкатили систему автоматизации полезной логистики, упрощающей поступление товаров со склада на полки магазинов. Вместо автоматизации получилась блокировка, ничто никуда не поступало. Ритейлер срочно нанял ~3000 “клерков”, которые вручную обеспечивали хоть какое движение, но уже было поздно. Суммарный ущерб от плохой разработки, простоя сети, дополнительного найма и прочих убытков влетел в сотни миллионов.

15 января 1990 года ~60К пользователей AT&T не смогли никуда позвонить. И не могли ещё девять часов. Всё это время 114 свитчей компании хороводили reboot, успев заблокировать ~50M звонков и лишить AT&T около $60M прибыли. Ущерб второго порядка (у пользователей) составил и того больше. А всё потому, что за месяц до катастрофы программисты обновили софт на свитчах, попутно влепив одну строчку с ровно одной багой. Выстрелило через месяц. Казалось бы, всё очень, очень хорошо тестировали.

Осенью 2003 года госпиталь St. Mary’s Mercy в Мичигане убил около 8500 человек. Хорошо, что “на бумаге”, а не натуральным образом. И снова последствия миграции. Был старый софт. Перешли на новый софт. В процессе переноса данных вместо кода “01” (правильный) влепили “20” (неправильный), что привело к виртуальному геноциду. Было бы смешно, если бы не массовая же рассылка уведомлений о смерти в страховые компании, блокировка выплат и т.п.

Должен был быть первым в списке, но я начал с финансовых потерь, а тут планета на кону. 26 сентября 1983 года Станислав Петров спас нас всех. Я тогда уже был, потому мог краем глаза увидеть грибки ядерных взрывов, если бы Петров (в тот момент дежурный командного пункта Серпухов-15) поверил ложному срабатыванию космической системы раннего предупреждения и дал ход последовательности, завершающейся World War III. Не поверил и не дал. Спасибо. Не спасибо тем, кто не учёл, что датчики спутника могут настолько засвечиваться солнечным светом, отражённым от высотных облаков. Не думаю, что проблема железная (исправили сверкой данных с других спутников, как понимаю), потому с натяжкой в софт.

Книги: Data Source Handbook

Data Source Handbook
Pete Warden.
Data Source Handbook. A Guide to Public Data.
O’Reilly, 2011.
Отличный пример бесполезной однодневной книги. Не знаю, зачем её написали, издали, продавали и продают до сих пор.
Автор натырил 57 ссылок, к каждой дал краткое описание и небольшой кусочек API (у тех, у кого есть), ну и всё, пожалуй. Предполагалось, что по ссылкам источники разных интересных big data, но по факту всем известные и без траты бумаги: Bing, Amazon, LinkedIn, etc.
В топку.

Лучшие ошибки софта I

Arian-5. 4 июня 1996 года произошёл первый пуск ракеты-носителя Ариан-5. Происходил 37 секунд, после чего ракеты не стало. Всему виной legacy и разработчики. Взяли кусок кода из Ариан-4 и перетащили в код Ариан-5. Все так делают, но эти ребята не в полной мере учли, что ракеты разные. В какой-то момент компьютер Ариан-5 решил, что всё плохо, ну и дал серию неверных команд. Ракеты не стало, а вместе с ней и дорогостоящего спутника Cluster. Цена ошибки — $370M.

В 2012 году US National Grid Gas Company промигрировала со старой SAP на новую ERP. Всё прошло не очень удачно. Оказывается, новая система обрабатывает счета с адовыми глюками, ну и вообще сделана совсем не так, как хотелось бы. Ясно, что это не одна красивая бага, но case попал в выборку для иллюстрации: бюджет на разработку был в $383M, а вот доработку оценили в $945M. Рядышком судебные дела от тех, кому не то выплатили и не так насчитали. Ничёси выкатились в production.

2012 год, 1-е августа. Компьютеры Knight Capital Group (один из крупнейших трейдеров США) начинают биржевые сделки. И за 45 минут причиняют убыток в ~$400M. Вы не будете смеяться, но снова legacy! Если кратко, то при наливке нового софта на восемь серверов не долили на один. И всё стало плохо. Кусочек старого мамонта нанёс ответный удар.

Во сколько долларов обошёлся США blackout 2003 года? Если верить отчёту, в $6.4 миллиарда. Несколько штатов осталось без электричества, система обсыпалась доминошками, полетело множество голов. К таким сложным катастрофам очень редко приводит одна причина, но важно, что в данном случае одной из основных причин был баг в General Electric Energy Unix-based XA/21.

Mariner-1. Миссии космических штуковин навечно в списках крупнейших багов. 22 июля 1962 года стартанул, но через 293 секунды полёта всё крякнулось. Не очень понятно, насколько публичная версия о “пропущенном дефисе” верна, но кажется фактом то, что ошибку допустили при переносе формул с бумажки в код. Опечатались на $18.5M (сейчас это около $140M), в общем.

Реальность разработки

То, что в вузах не дают, а вне нутра этого не увидишь, только краешек. Можно бы представлять, что программист занят программированием, пишет программы и реализует свои мысли в алгоритмы, а алгоритмы в код. Ни хрена. Ну т.е. хрена, но это лишь часть. Другая часть (одна из остальных) не такая. Языком аналогии (нельзя иначе) суровая реальность многих лет.
Вы дворник. У вас есть задача. Достаточно тривиальная. Замести двор. Казалось бы, бери метлу и бдыщ. Нет.
Утром вы обнаружили, что метла пропала. Оооок, ищем. Нашли. Она почему-то лежала не там, где была положена.
Метла на плече, идём во двор. По пути замечаем, что в заборе кто-то проделал дыру. Метеорит. Вызываем службы, милицию, Малдера и Скалли. Вроде дыра заделана.
Доходим до калитки. Она закрыта. На замок. К которому ваши ключи не подходят. Находим ответственных, ждём дубликат ключа. Меланхолично помахиваем метлой.
Открываем калитку. Заходим. Это не тот двор. Адрес на заборе тот, а двор не тот.
Соседний оказался тем. Процедура с калиткой и замком повторяется. Полируем ручку метлы в ожидании.
Заходим. Весь двор в листьях. Жёлтых. А метла для красных.
Тащим из кармана походный набор стамесок, переделываем метлу. Вроде теперь всё хорошо.
Листья прибиты к асфальту. Сюрприз. Нигде не написано, а вот.
Некоторое время бегаем по двору, истерим. Пугнули воробья, гавкнули на собаку. Вроде стало чуть легче.
Метла меняется на лом. Так уж точно листья отковыривать удобнее.
Гаснет солнце. В темноте ничего не увидать. Ваще ничего. Истерика переходит в нездоровое хихиканье.
Разговариваем с ломом. Кажется, он даже отвечает.
Дают свет.
Вечер.
Рабочий день прошёл.
Ни один лист не потревожен.
Вот это и есть разработка. А программирование — лишь один из элементов.

Язык за 24 часа

При смене языка X на язык Y речь никогда не идёт о смене языка. Всегда под водой огромная часть айсберга.

Синтаксис. Не обсуждается. Ты обязан знать синтаксис назубок. Любой текст на языке Y должен быть тебе понятен, даже если речь про C и победителей IOCCC.
Идиомы. Многие языки позволяют решить коротенькие тактические задачки разными путями. Идиома — принятый устоявшийся путь. Не пишут “for (.. i = i + 1)”, пишут “for (.. i++)”. Писать надо так, как принято. Тем, кто так не делает, напоминают ироничную поговорку “You Can Write FORTRAN in any Language”.
Стиль. Отступы. Имена переменных. Вообще именование. Пробелы. Иное форматирование текста. Для любого распространённого языка есть style guide. Например, PEP 8 — Style Guide for Python Code. Стиль настолько важен, что публикуются и корпоративные guides. Если ты работаешь в ABC, очень рекомендовано писать так, как пишут в ABC. Примером Google JavaScript Style Guide.
Стандартные библиотеки. Синтаксис — 1% языка. В JDK 1.4.2 было 2723 классов. В JDK 8 их уже 4240. Лишь у ArrayList 26 методов. Когда вы решаете задачу, как минимум, вы должны знать, где искать и где вы найдёте нужное что-то: пакет, класс, метод, функцию. Для задач текучки вы должны помнить найденное, а не искать всякий раз.
Популярные библиотеки. Зачастую стандартных библиотек или не хватает, или они плохонькие. В таком случае вы должны знать то, что на самом деле используется. В JDK есть java.net, но все используют Apache HTTP Client. В Python есть urllib2, но все используют Requests.
Стек. Для решения больших задач нужен “технологический стек”. Как “производственная линия” (IDE, инструменты сборки проекта, тестирования, выкатки и т.п.), так и “продуктовый набор”. Скажем, вы хотите поднять небольшой веб-сервис. Один из классических Java-стеков для этого: Apache Tomcat (контейнер), Spring Framework (огромная масса всякой полезной обвязки), Hibernate ORM (упрощение работы с базой).
Парадигма. Китайский и английский — языки. Но знание одного вам мало поможет в изучении другого. Так и в программировании. Smalltalk — чистейший представитель Object-oriented programming, а Haskell — едва ли не эталон Functional programming. Чтобы оптимально использовать язык, вам потребуется переформатировать голову мышлением в нужной парадигме.
Культура. История языка, его вектор развития, сообщества вокруг, философия, причины и нужды, байки и всякое. Знание культуры, нахождение в ней… это помогает разработчику понимать, а не просто что-то делать. Проблемы JavaScript в том, что изначально это язык для беготни по DOM-дереву браузера, а не нормальный язык программирования. Фан Python’а также и в том, что есть PEP 20 — The Zen of Python. А Java долгое время считалась очень медленной (ну а чего вы ждали от JVM конца 90-х?). Нет, C++ — это уже совсем не C с классами (C with Classes), пусть Страуструп и начал так в 1979 году.
Практика. Программист должен писать код. И писать быстро. Всё упомянутое знание должно сесть “на пальцы”, войти под кожу. Если ты несколько секунд размышляешь, вспоминая, какое значение by default у какой-нибудь переменной, попутно листая справочник в поисках синтаксиса конструктора класса… ну, ты пока ещё не пишешь на языке. А всё это появляется только после долгой практики.

Уф. Вот всё это в сумме заставляет скептически смотреть на манящие заголовки книг вроде “Освой самостоятельно C++ за 21 день”. Нет цели “освоить” язык. Есть цель быстро решать на нём большие задачи с production ready качеством. А должный универсальный уровень достигается отнюдь не за месяц и даже не за полугодие. Объём одних лишь основных знаний можно оценить… ну, я вот бегло посчитал по Amazon’у количество страниц для набора “язык + базовый стек”. Что для Java, что для Python получилось по ~4000 страниц. О том, что счёт статей по другим темам идёт на сотни, и говорить не надо.
И это мы ещё подразумеваем, что в фоновых знаниях программиста уже есть всё остальное. Свежий чувак, который обладает хорошим опытом работы с базами, может не обладать опытом REST и потому в задачке на пару часов застрять на сутки, осваивая как саму архитектуру решения, так и всякую мелочь вроде разницы GET и POST.
Разница в изучении языка между junior developer и senior developer — она вот в этом всём. Для junior’а существует только синтаксис, грубо говоря, а для senior’а всё остальное.
Такие они, переходы.