Всего за 20 лет разработка ПО перешла от архитектурных монолитов с единой базой данных и централизованным состоянием к микросервисам, где всё распределено по многочисленным контейнерам, серверам, ЦОДам и даже континентам. Распределённость упрощает масштабирование, но привносит и совершенно новые проблемы, многие из которых раньше решались с помощью монолитов.

Давайте с помощью краткого экскурса по истории сетевых приложений разберёмся, как мы пришли к сегодняшней ситуации. А затем поговорим о модели исполнения с сохранением состояния (stateful execution model), используемую в Temporal, и о том, как она решает проблемы сервис-ориентированных архитектур (service-oriented architectures, SOA). Я могу быть предвзятым, потому что руковожу продуктовым отделом в Temporal, но считаю, что за этим подходом будущее.

В этой статье мы рассмотрим некоторые алгоритмы рейт лимитов на основе Python и Redis, начиная с самой простой реализации и заканчивая продвинутым обобщённым алгоритмом контроля скорости передачи ячеек (Generic Cell Rate Algorithm, GCRA).

Для взаимодействия с Redis (pip install redis) мы будем пользоваться redis-py. Предлагаю клонировать мой репозиторий для экспериментирования с ограничениями запросов.

PHP 8 уже на этапе release candidate, версия RC 3 вышла 29 октября, а полноценный релиз назначен на 26 ноября. Так что пора взглянуть на новые возможности, которые нас ждут в PHP 8. График релизов можно посмотреть здесь. А официальное руководство по обновлению на новую версию лежит тут.

Вы наверняка уже использовали в своих проектах UUID и полагали, что они уникальны. Давайте рассмотрим основные аспекты реализации и разберёмся, почему UUID практически уникальны, поскольку существует мизерная возможность возникновения одинаковых значений.

Современную реализацию UUID можно проследить до RFC 4122, в котором описано пять разных подходов к генерированию этих идентификаторов. Мы рассмотрим каждый из них и пройдёмся по реализации версии 1 и версии 4.

Недавно мне выдалась случайная возможность поработать с несколькими старыми PHP-приложениями. Я заметил несколько распространённых антипаттернов, которые пришлось исправлять. Эта статья не о том, как переписывать старое PHP-приложение на <вставьте сюда название чудесного фреймворка>, а о том, как сделать его более удобным в сопровождении и менее хлопотным в работе.

Если вкратце: потому что мы так сказали.

:)

Ладно, это слишком короткое объяснение для статьи, дорогой читатель, и мои провокационные слова требуют объяснения.

Встреча Комитета по языку С — которую сначала планировали провести в германском Фрайбурге, но не срослось по понятным причинам, — завершилась 7 августа. Она прошла хорошо, мы продвинулись по всем фронтам. Да, мы действительно продвигаемся, уверяю вас, и язык С не умер.

Когда я начинал свою карьеру разработчика, моей первой работой стала DBA (администратор базы данных, АБД). В те годы, ещё до AWS RDS, Azure, Google Cloud и других облачных сервисов, существовало два типа АБД:

• АБД инфраструктуры отвечали за настройку базы данных, конфигурирование хранилища и заботу о резервных копиях и репликации. После настройки БД инфраструктурный администратор время от времени «настраивал экземпляры», например, уточнял размеры кэшей.
• АБД приложения получал от АБД инфраструктуры чистую базу и отвечал за её архитектуру: создание таблиц, индексов, ограничений и настройку SQL. АБД приложения также реализовывал ETL-процессы и миграцию данных. Если команды использовали хранимые процедуры, то АБД приложения поддерживал и их.

АБД приложений обычно были частью команд разработки. Они обладали глубокими познаниями по конкретной теме, поэтому обычно работали только над одним-двумя проектами. Инфраструктурные администраторы баз данных обычно входили в ИТ-команду и могли одновременно работать над несколькими проектами.

В этой статье мы поговорим о подробностях реализации и работе разных JIT-компиляторов, а также о стратегиях оптимизации. Обсуждать будем достаточно подробно, однако многие важные концепции опустим. То есть в этой статье не будет достаточной информации, чтобы прийти к обоснованным заключениям при любых сравнениях реализаций и языков.

Чтобы получить базовое представление о JIT-компиляторах, почитайте эту статью.

Небольшое примечание:

Я часто буду описывать поведение оптимизации и утверждать, что она, вероятно, есть и в каком-нибудь другом компиляторе. Хотя я не всегда проверяю, есть ли эта оптимизация в другом JIT (иногда всё неоднозначно), но если знаю точно, то укажу на это. Я также приведу примеры кода, чтобы показать, где может быть применена оптимизация, но это не точно, ведь приоритет может быть отдан другой оптимизации. Могут быть и какие-то общие упрощения, но не больше, чем в большинстве подобных постов.

Всем привет, сегодня мы будем разбираться с алгоритмом сжатия JPEG. Многие не знают, что JPEG — это не столько формат, сколько алгоритм. Большинство JPEG-изображений, которые вы видите, представлены в формате JFIF (JPEG File Interchange Format), внутри которого применяется алгоритм сжатия JPEG. К концу статьи вы будете гораздо лучше понимать, как этот алгоритм сжимает данные и как написать код распаковки на Python. Мы не будем рассматривать все нюансы формата JPEG (например, прогрессивное сканирование), а поговорим только о базовых возможностях формата, пока будем писать свой декодер.

Я принял участие в проекте с двухлетней кодовой базой и Symfony 3.4 в качестве веб-фреймворка. Это был не самый новый и блестящий проект, но у него было большое достоинство: тесты покрывали самые важные действия приложения.

Впервые в своей карьере я увидел, как тесты могут придать уверенности в кодовой базе, начинают экономить твоё время и помогают соблюсти требования бизнеса.

Этого достигли с помощью многочисленных функциональных тестов Symfony и некоторых модульных тестов, которые заполнили некоторые пустоты. Общее покрытие было около 50-52 %, но покрытие критически важной функциональности было гораздо выше. Это придавало достаточно уверенности, чтобы добавлять новые функции без ручного тестирования.

Было ли у вас ощущение, что ради тестирования вы делаете код труднее для чтения? Допустим, у вас есть код, который ещё не тестировался. У него есть ряд побочных эффектов, и вас просят сначала прогнать тесты. Вы начинаете следовать советам вроде передачи глобальных переменных в виде параметров или извлечения проблемных побочных эффектов, чтобы сделать вместо них заглушки в тестах.

Но чем дальше вы заходите, тем больше чувствуете себя не в своей тарелке. У вас скапливается куча заглушек для состояний и данных, которые позволяют писать быстрые и надёжные модульные тесты. В результате создаётся ощущение, что вы создали совершенно другой класс, который неточно воспроизводит реальный код.

Вы останавливаетесь и задумываетесь: «Допустимо ли менять сигнатуры кода ради тестирования? Тестирую ли я реальный код или совершенно другой класс, в котором не происходит то, что нужно?» Перед вами может возникнуть дилемма. Вы уверены, что стоит и дальше придерживаться этого подхода? Или это потеря времени?

Вопрос на миллион: для устаревшего кода нужно писать модульные тесты или интеграционные?

FYI: Первая часть.

Бенчмарк пакетного конвейера

Пакетный конвейер обрабатывает конечный объём сохранённых данных. Здесь нет потока результатов обработки, выходные данные агрегирующей функции нужно применить ко всему набору данных. Это меняет требования к производительности: задержка — ключевой фактор при потоковой обработке — здесь отсутствует, потому что мы обрабатываем данные не в реальном времени. Единственная важная метрика — общее время работы конвейера.

Поэтому мы выбрали Parallel. На первом этапе тестирования, при работе на одной ноде, этот сборщик действительно показал лучшую пропускную способность (но только после настройки). Однако это было получено ценой длительных пауз. Если одна из нод кластера останавливается на сборку мусора, это стопорит весь конвейер. А поскольку ноды собирают мусор в разное время, общее время сборки увеличивается с добавлением каждой ноды к кластеру. Мы проанализировали этот эффект, сравнив результаты тестирования на одной ноде и на кластере из трёх нод.

Кроме того, на этом этапе мы не рассматривали экспериментальные сборщики с низкой задержкой. Их очень короткие паузы не влияют на результаты тестирования, к тому же это достигается за счёт пропускной способности.

Среда исполнения Java в последние годы развивалась быстрее, чем раньше. Спустя 15 лет мы наконец-то получили сборщик мусора по умолчанию — G1. Ещё два в разработке и доступны в качестве экспериментальных функций — Oracle ZGC и OpenJDK Shenandoah. Мы решили протестировать все эти новые инструменты и выяснить, что лучше работает с нагрузками, типичными для распределённого opensource-движка потоковой обработки Hazelcast Jet.

У некоторых компьютерных терминов необычное происхождение. Многие слова относятся к давно забытым технологиям. В этой статье мы сдуем пыль времён с некоторых терминов, которыми пользуемся каждый день.

Бо́льшая часть статьи взята из Википедии, но найти пояснения не так-то просто, если не знаешь, что искать.

В этой статье описаны простые и понятные шаги по внедрению моделирования угроз — подхода к проектированию защищённых систем на основе оценки рисков. В основе подхода лежит определение угроз, чтобы разработчики могли к ним подготовиться. С ростом киберугроз и желания компаний сохранить свои средства командам разработчиков требуются эффективные способы защиты ПО. К сожалению, внедрение моделирования угроз часто проходит с трудом. Многие методологии требуют сложного и исчерпывающего предварительного анализа, который не совместим с работой современных команд. Поэтому вместо того, чтобы всё останавливать ради создания идеальной модели угроз, я рекомендую начинать с малого и постепенно расширять.

Вы играете в свежую Call of Mario: Deathduty Battleyard на своём совершенном игровом ПК. Смотрите на прекрасный сверширокий 4K-монитор, любуясь великолепными пейзажами и замысловатыми деталями. Вас когда-нибудь интересовало, как графика попадает на экран? Задумывались, как игра заставляет компьютер всё это показать вам?

Добро пожаловать в наш тур по рендерингу в 3D-играх: путешествие для начинающих, из которого вы узнаете, как создаётся один базовый кадр на экране.

Полгода назад мне захотелось создать лучший генератор псевдослучайных чисел (ГПСЧ) с какой-нибудь необычной архитектурой. Я думал, что начало будет лёгким, а по мере работы задача станет медленно усложняться. И думал, смогу ли я научиться всему достаточно быстро, чтобы справиться с самым сложным.

К моему удивлению, сложность возрастала не линейно. Побайтовое тестирование по критерию хи-квадрат оказалось очень трудным! Позднее столь же трудно было пройти тесты diehard. Я опубликовал текущие результаты, чтобы понять, какие ещё трудности меня ожидают. Однако тест PractRand в тот раз пройти не удалось.

Затем было очень трудно прохождение теста BigCrush.

Затем было очень трудно передавать 32 тебибайта данных при прохождении PractRand. Скорость стала проблемой. Мало было создать конструкцию, генерирующей десять мегабайтов в секунду, потому что прохождение PractRand заняло бы месяц. Но должен признаться, что пройти этот тест со скоростью гигабайт в секунду было очень трудно.

После появления DeBroglie и Tessera меня много раз просили объяснить, как они работают. Генерирование может выглядеть как волшебство, но лежащие в его основе правила на самом деле просты.

В этой статье описана реализация конвейеров в ядре Unix. Я был несколько разочарован, что недавняя статья под названием «Как работают конвейеры в Unix?» оказалась не про внутреннее устройство. Мне стало интересно, и я зарылся в старые источники, чтобы найти ответ.

С помощью этого руководства мы с помощью Keras, TensorFlow и глубокого обучения научимся на собранном вручную датасете из рентгеновских снимков автоматически определять COVID-19.

Как и многие другие, я искренне беспокоюсь относительно COVID-19. Я заметил, что постоянно анализирую своё состояние и гадаю, подхвачу ли болезнь и когда это произойдёт. И чем больше я об этом беспокоюсь, тем больше это превращается в болезненную игру разума, в которой симптоматика сочетается с ипохондрией:

• Я проснулся утром, чувствуя некоторую болезненность и слабость.
• Когда я выполз из кровати, то обнаружил у себя насморк (хотя уже известно, что насморк не является симптомом COVID-19).
• К тому времени, как я добрёл до ванной, чтобы взять бумажный платок, я уже кашлял.

Сначала я не обращал на это особого внимания — у меня аллергия на пыльцу, а из-за тёплой погоды на восточном побережье США весна в этом году выдалась ранняя. Скорее всего, это аллергические симптомы. Но в течение дня моё состояние не улучшалось. Я сижу и пишу это руководство с градусником во рту. Смотрю вниз и вижу 37,4 °С. Моя нормальная температура тела чуть ниже, чем у других, на уровне 36,3 °С. Всё, что выше 37,2 °С, для меня уже небольшой жар.

Кашель и небольшой жар? Это может быть COVID-19… или просто моя аллергия. Выяснить без тестирования невозможно, и именно это «незнание» делает ситуацию столь пугающей на человеческом уровне.