Иван Бевуч - Пузыри. Айти для детей и их родителей

– А бездушная и безошибочная машина бездушно не ошиблась, просто тоже не учла зимнее/летнее время, отличие времен на устройстве от текущего часового пояса и много чего еще. Либо учла несколько раз.

– Да-да. Несколько лет назад лично наблюдал, как мои коллеги делали мобильные приложения для крупной конференции, которая должна была состояться во Владивостоке. Суть была такова: часть разработчиков находится в Москве, часть в Астрахани (это уже другой пояс), мероприятие во Владивостоке (третий). Гости мероприятия едут из разных стран. Приложения работают на двух-трех операционных системах разных версий. У конкретного пользователя может быть вообще любой часовой пояс. При этом часовой пояс может быть установлен один, а время выбрано другое. А еще между непосредственно разработкой и мероприятием должно было время то ли переехать с летнего на зимнее, то ли это был первый год, когда, наоборот, не должно было. И при этом при всем пользователь должен был видеть актуальную информацию о времени проведения конкретных мероприятий конференции относительно времени на устройстве. Наблюдал за этими страданиями не одну ночь.

– Нам пора закругляться.

– Спасибо, Борис Николаевич. Напоследок, вернусь к форматам дат. Сам неоднократно сталкивался с тем, что крутое западное ПО говорит, что единственный католический вариант вывода даты – «мм. дд. гггг», а иногда «м.д.гггг», а вы со своими «дд. мм. гггг» можете идти и построить CRM/BI на базе…

– На базе «2Ж», Антон. У нас это называется так.

– Хм, окей. Нет, ну некоторые, конечно, пытались сделать это на 2Ж. Но большинство использовало то, что есть. Однако с датой надо было что-то делать.

– Тем, кто за жизнь не успел достаточно пострадать над форматами дат, поясни, пожалуйста, чем отличается «мм. дд. гггг» от «м.д.гггг».

– В двухзначных значениях месяца и дня разницы нет, а вот третий день восьмого месяца будет записан в первом случае как «08.03», а во втором как «8.3». В итоге, чтобы это католическое написание преобразовать в православное «дд. мм. гггг», в далекие годы нужно было перевести дату в текст, поискать в нем точки или другие разделители и запомнить их положение. После чего относительно положения понять, сколько символов (1 или 2) занимает значение, после чего поменять их местами и хранить дальше в виде текста. Этот топорный механизм работал почти всегда. Были и более изящные, но их реализация была не всегда доступна. Сейчас все это атавизм. Даже большие западные католики поняли, что нужно дать православным возможность выводить дату в православном режиме.

– Но если что-то является атавизмом, это не значит, что это что-то не продолжает использоваться повсеместно… На этом все, до следующего вторника. Антон, спасибо.

– Борис Николаевич, к вашему Антону претензий нет. Даты – это очень и очень важно. Но обозначенную «Проблему-2000» вы так и не раскрыли в ходе лекции.

– Михаил Сергеевич, извиняюсь, память старая… Запамятовал. В следующий вторник обязательно расскажу.

– Что кроме нее?

– Информационная безопасность. На этой лекции буду рассказывать на основании своего опыта. На следующую хочу позвать еще одного бывшего коллегу.

– Специалиста по ИБ?

– Специалиста по общению с ИБ.

– Если бы я был японцем, я бы сказал:

Каждый диалог

С вами сердце скорбью

Наполняет мне.

Лекция от 29.10.2019

– Всем ку! Мы в прошлый раз разглагольствовали целую лекцию про даты, а «Проблема-2000» опять мимо. Давайте быстренько. На дворе рубеж третьего десятилетия двадцать первого века. Те, кто писал программы в начале девяностых прошлого века, особо не думали о проблемах календарей. Сотрудники передовых многомиллиардных корпораций не думали о том, что их детища проживут пять-десять лет и перешагнут рубеж тысячелетия. Что уж говорить о сотрудниках более мелких продуктовых компаний. Хотя официально рубеж вроде бы перешагнулся с 00 на 01, а не с 99 на 00, но именно смена с 99 на 00 грозила всему миру. Из-за этого отвратительного мученичества с датами, а также еще и из-за крайне невысокой производительности компьютеров того времени считать биты было необходимостью. На один символ два бита. Еще два бита на каждый разделитель. А выкидывание двух лишних символов из каждой даты («19») позволяло сэкономить четыре бита и чуть-чуть сократить трудоемкость операций над ними. Сделали и забыли, другие тоже сделали и забыли, третьи… Четвертые поставили ПО и решили больше не обновляться, пятые поставили, но больше обновлений не прилетало от шестых, потому что они закрылись и разбежались. И вот в какой-то момент времени оказывается, что компьютеров на планете десятки миллионов, на каждом десятки программ, компьютеры замешаны уже практически во всех сегментах человеческого бизнеса… И большая часть экземпляров используемого ПО, то есть сотни миллионов инсталляций, считает, что после 1999 года идет 1900-й. Точнее, после 99 идет 100, что могло запросто считаться и как 19100.

– Возникала натуральная квантовая неопределенность. Каждая программа могла умереть или жить дальше при начале 2000 года. И только позиция наблюдателя, который посмотрит в программный код, могла внести ясность в эту неопределенность. Это, конечно, шутка, квантовой неопределенностью тут и не пахнет. Обычная такая, неквантовая… Человечество спохватилось своевременно, что-то обновили разработчики, что-то поменяли пользователи: подкрутили в исходниках, где это было возможно, либо перешли на новые системы, где нет. Также некоторым системам было индифферентно, какой на дворе год, хоть 1601-й, хоть 2038-й. Калькулятор и пасьянс «Косынка» будут служить вам верой и правдой вне зависимости от года. Человечество преодолело проблему малой кровью.

Мерзкое солнце вышло из-за тучи и внезапно ударило по глазам. Прямо хоть опять аудиторию меняй. Но все остальные были меньшего размеры. Поэтому приходилось терпеть все пытки, назначаемые светилом.

– При этом не стоит забывать, что «Проблема-2000» была не только в 2000. Она случалась каждый год, но в сильно меньших масштабах. Вот представьте, разработчик ПО добавляет выбор года из списка на экран. Неважно, на какой, просто выбор года из списка. В техническом задании сказано – «год должен быть этот и предыдущий». Разработчик доблестно выполняет требование, прописывая ручками номер «этого» и номер «предыдущего». На этапе тестирования это проходит незамеченным… Как минимум потому, что с таким разработчиком наверняка там будет огромный перечень других, более наглядных ошибок. Заказчик получает свое ПО, начинает пользоваться, все довольны (чаще нет). И вот Рождество (у бездуховных), Новый год (у православных), шампанское, мандарины, каникулы. Все возвращаются в рабочий ритм в начале января, идут в систему, чтобы ввести первый заказ в новом году, а система говорит: «Ничего не знаю, такого года не существует, он не похож ни на тот, который был этот , ни уж точно на предыдущий ».