Иногда лучше не обновлять свои компьютеры... долго. Авиакомпания Southwest Airlines не пострадала от "дня синего экрана", так как у нее стоит Windows 3.1. В 2024-м году.
Планирую в воскресенье провести трансляцию, в которой обсудим с теми, кто присоединится, последние новости, поговорим о происходящем в индустрии, отвечу на вопросы, если будут. Планирую стрим не сохранять, думаю нарезать его на отдельные части и выложить в течение недели как дополнение к обычным роликам.
Интересная статья от разработчиков Zerodha (индийская платформа для инвестиций и торговли) о том, как они генерируют и подписывают более полутора миллионов (1 500 000) pdf-документов за 25 минут. Вкратце: - Python-скрипт собирает информацию из разных источников и создает html-файлы на основе темплейтов Jinja - Chrome (Puppeteer) конвертирует html в pdf - консольное java-приложение подписывает pdf - собственный сервер Postal SMTP отправляет эти документы.
Проблема присутствует, количество вакансий для разработчиков в США падает. Не нашел такой статистики для других регионов (или глобальной), но предположу, что тренд +- такой же везде.
Министерство обороны США опубликовало довольно занимательный документ, как определить, что проект занимается разработкой программного обеспечения, и, что там используется 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