Миша Ларченко

Занимательная статья Реймонда Чена о цифровых последовательностях после Alt+. История цифровых последовательностей Alt+ и почему Alt+9731 иногда дает вам сердце, а иногда снеговика Давным-давно был выпущен компьютер IBM PC. В BIOS IBM PC можно было вводить символы, которых не было на клавиатуре, удерживая клавишу Alt и набирая десятичное значение на цифровой клавиатуре. Например, вы могли ввести ñ, удерживая Alt и набирая Numpad1 Numpad6 Numpad4, а затем отпустив клавишу Alt. Для простоты изложения в дальнейшем я буду использовать обозначение Alt+164, чтобы указать, что вы нажимаете клавишу Alt, затем последовательно набираете указанные цифры на цифровой клавиатуре, после чего отпускаете клавишу Alt. Итак, в BIOS IBM PC, когда вы набирали Alt+…, кодовые числа воспринимались как десятичные значения байтов, а результат на экране получался от генератора символов вашей видеокарты. В Соединенных Штатах в ПЗУ генератора символов отображалось то, что мы сегодня называем Code Page 437. Когда Windows была представлена, в США в качестве 8-битного набора символов использовался Code Page 1252, который назывался "набором символов ANSI"; старый набор символов BIOS был задним числом назван набором символов OEM. Для сохранения совместимости с MS-DOS, если вы использовали клавишу Alt в сочетании с цифровой клавиатурой, набранное вами число все равно искалось в наборе символов OEM, так что ваши кодовые числа, запомненные мускульной памятью, все еще работали. Вы могли набрать Alt+164, чтобы получить символ ñ, даже несмотря на то, что номер кода ñ в Code Page 1252 - 241, а не 164. Если вы хотели набрать символ, у которого не было OEM-эквивалента, вы могли набрать с цифровой клавиатуры 0, чтобы указать, что вы хотите найти значение в кодовой странице ANSI. Таким образом, можно набрать Alt+0169, чтобы получить символ ©, которого не было в кодовой странице OEM. Вы также можете набрать Alt+0241, чтобы получить драгоценное ñ, используя номер кодовой точки ANSI, а не номер кодовой точки OEM. Если вы вводили число больше 255, то и Windows, и BIOS IBM PC принимали значение за 256, поэтому набрать Alt+259 было то же самое, что набрать Alt+3. В обоих случаях вы получали OEM-код 3, который для Code Page 437 представляет собой сердечко ♥. Если вы спросите в Интернете, как набрать некоторые из этих не-ASCII символов в Windows, вы можете увидеть людей (и большие языковые модели), которые скажут вам набрать, скажем, Alt+9731, чтобы получить юникодовского снеговика ☃. К сожалению, из того, что мы узнали выше, это не работает. Вместо этого вы получите OEM-символ, значение которого равно 9731 mod 256 = 3, или вышеупомянутое сердце ♥. Один из клиентов сообщил, что недавнее обновление Windows нарушило его способность набирать снеговика с помощью Alt+9731. Мы объяснили, что обновление не виновато; скорее, Alt+9731 вообще не должен был создавать снеговика! Но клиент настаивал, что раньше это работало. Более тщательное изучение проблемы выявило причину. Видите ли, хотя это правда, что десятичное значение Alt+… берется по модулю 256, это просто поведение системы ввода Windows по умолчанию. Но некоторые элементы управления (в частности, элемент управления RichEdit) переопределяют стандартную обработку последовательности Alt+… и разбирают десятичное значение по модулю 65536, а не по модулю 256. Это означает, что то, будет ли значение Alt+… приниматься по модулю 256, зависит от того, в какой элемент управления вы вводите текст. По умолчанию значение берется по модулю 256, и Alt+9731 дает вам сердечко. Но если вы используете элемент управления RichEdit, то значение Alt+… берется по модулю 65536, и Alt+9731 выдает снеговика. — Для перевода использовался DeepL.

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

Министерство обороны США опубликовало довольно занимательный документ, как определить, что проект занимается разработкой программного обеспечения, и, что там используется Agile. И там есть всякие интересные вопросы, которые надо задавать членам команды, что бы понять чем и как она занимается.

Немного о безопасности в аутсорсе. Компьютер, который выдается для работы работодателем, часто используется разработчиком как свой собственный. У многих своего и нет вообще. Зачем? На работе выдали мощный хороший, а то и Мак, поэтому нет смысла тратить большие деньги на личный аналог. В итоге туда устанавливаются все самые необходимые для полноценной жизни айтишника программы: игры, взломанный софт, фейковые плагины к VSCode. Конечно же, никакого контроля за установленным софтом и правами доступа со стороны работодателя нет, и уж тем более нет его со стороны заказчика. Жалкие попытки установить специальные программы для этого обычно заканчиваются безуспешно, а единственный "нормальный" способ делать это на уровне системы используется крайне редко. Вот и происходят эти утечки данных, паролей, ключей доступа и токенов. Конечно, решение скорее должно заключаться в обучении сотрудников, нежели их ограничений, но и этого нет.

Я не большой знаток баз данных, но стараюсь читать и следить за тем, что в этом "мире" происходит. Мои самые любимые базы (не бейте меня) MySQL и Sqlite3. И тут попалась мне на глаза статья с громким заголовком "Как Youtube поддерживал 2.5 миллиарда пользователей с MySQL". Для этого был написан специальный дополнительный слой над базой данных - Vitess. Vitess — это система, которая позволяет масштабировать MySQL для работы с большими объёмами данных и высокой нагрузкой. Она обеспечивает горизонтальное масштабирование, то есть добавление новых узлов в кластер, что позволяет увеличить производительность и доступность системы. Vitess решает следующие задачи: - Масштабирование: позволяет увеличивать количество серверов MySQL без изменения кода приложения. - Автоматическое распределение нагрузки: распределяет запросы между серверами MySQL в зависимости от их загрузки. - Репликация: обеспечивает синхронизацию данных между серверами MySQL. - Отказоустойчивость: автоматически переключает запросы на доступные серверы MySQL при отказе одного из них. Для работы с Vitess необходимо использовать специальный драйвер, который преобразует запросы к базе данных в формат, понятный Vitess. Это позволяет абстрагироваться от особенностей работы с MySQL и сосредоточиться на логике приложения. Рекомендую к прочтению, если интересуетесь масштабированием баз данных, особенно таких "старых", как MySQL.

У меня есть видео об удалении целого сайта со всеми бэкапами из Google Cloud. И вот появилось объяснение от Google. Там много читать, но если вкратце, то был запущен процесс деплоя Google Cloud VMware Engine с одним пустым полем (ну, просто ничего не вписали, бывает). Делалось это на стороне Гугл работником компании через специальный инструмент для администраторов. Из-за этого система повела себя непредсказуемо и просто полностью удалила все что связано с клиентом. То есть получается, что инструмент, который имеет карт-бланш на работу со всем внутри Google Cloud не был проверен на все возможные входящие данные. Ни юнит-тестов, ни ручного/автоматизированного тестирования? Это как-будто базовый уровень тестирования, тем более для таких серьезных инструментов.

Все знают про HTTPS, и все также знают, что надо ставить редиректы с http на https, чтобы пользователя всегда отправляло на страницу с безопасным соединением. Но знаете ли вы, что это не безопасно? Дело в том, что если у вас есть такой редирект, и пользователь условно отправляет запрос на адрес с http-протоколом, то все данные из запроса будут не зашифрованы. Да, в итоге сервер перенаправит запрос на адрес с https, но при этом первый "небезопасный" запрос тоже пройдет, а в случае с http данные окажутся в "открытом" виде. Подробнее вот здесь https://jviide.iki.fi/http-redirects

Вчера произошел мой самый большой фейл в карьере. После вечерних посиделок я отравился. И все что я пил из меня выходило утром практически сразу. Но началось все в тот момент, когда я стоял на сцене и рассказывал про Azure DataFactory. Я буквально рыгал на сцене. Но чтобы не измазать зрителей, я сглатывал все что выходило. И так 45 минут, рыгание в перемешку с презентацией. Ужасно, относительно стыдно, но могло бы быть и хуже.

Huawei тоже решила выкатить свой генератор картинок. Но во время презентации показали код, где видно, что готовая картинка просто загружается из директории после 6-секундного таймера.

Я думал, что прикольно, если Чат ГПТ будет писать код за меня. Оказалось, что для кода он мне вовсе не нужен – Codeium (или Copilot какой) делают это прямо в редакторе. Однако все те разы, когда я просил ЧатГПТ написать мне много кода, что-то всегда было или плохо написано, или требовало правок для работы.

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

На прошлой неделе написали из банка (да у меня сейчас клиент - банк), мол твой ноутбук, который мы тебе выдали и который ты не используешь, устарел. Приезжай, дадим новый классный. Будешь на нем работать вместо своего личного мака. Внимание! Новый классный ноутбук для фуллстек разработки.