DZone.com Feed на русском Заметка

DZone.com Feed на русском

DZone - это комплексная онлайн-платформа, посвященная различным аспектам технологий и программирования. Сайт предоставляет обширную информацию о различных языках программирования, технологиях, фреймворках и инструментах. Среди основных возможностей и ресурсов сайта - новости и статьи о последних тенденциях и обновлениях в технологическом секторе, различные ресурсы и учебники для обучения различным навыкам программирования, а также сообщество, где пользователи могут общаться друг с другом и делиться своим опытом и знаниями. Кроме того, DZone предлагает объявления о вакансиях для технических специалистов, являясь полезным ресурсом для тех, кто интересуется технологиями и программированием.

Трэд заметок

Это первая из восьми статей о том, как веб-приложения работают на iOS, и в ней меньше кода, чем в остальных. Здесь я рассмотрю, откуда берутся странности, с которыми приходится мириться всем, кто выпускает PWA для iPhone.Откройте манифест почти любого PWA, созданного в 2026 году, и рядом со ссылкой на манифест вы, скорее всего, найдете метатег apple-mobile-web-app-capable. Старая справка Safari гласит: "Доступно в iOS 2.1 и новее". Версия 2.1 вышла 12 сентября 2008 года, когда App Store работал уже два месяца. Таким образом, полноэкранные веб-приложения на iPhone появились после того, как Apple переключилась на нативный SDK, хотя обычно история рассказывается наоборот. Поведение PWA на iPhone полно мелких деталей, подобных этой. За иконкой на вашем главном экране стоят двадцать пять лет попыток превратить веб-страницу в программу, и многие решения, принятые в процессе, до сих пор присутствуют в вашем коде.
Виртуальные потоки позволяют нам использовать обычный блокирующий код, в то время как множество других запросов ожидают параллельно. Однако под нагрузкой это выдвигает на первый план три критических вопроса:Сколько работы мы допускаем? Дешевые потоки все еще могут создавать дорогую очередь. Что должно находиться внутри блокировки? Спящий владелец блокировки все равно заставляет всех остальных ждать. Кто останавливает заброшенную работу? Тайм-аут вызывающего абонента не отменяет его задачу.Примеры ниже изолируют эти вопросы с помощью отдельных программ "до" и "после". Каждая программа является полной: сохраните ее блок кода под указанным именем файла и выполните соответствующую команду без аргументов. Все, что вам нужно, это JDK 25. Они используют его компактный синтаксис исходных файлов, поэтому не требуется объявление класса, инструмент сборки, внешняя библиотека или флаг предварительного просмотра.
Существует особый вид тишины, который возникает в телефонном разговоре, когда регулятор спрашивает: «Можете ли вы подробно рассказать, как был рассчитан этот показатель?», а человек на другом конце вынужден ответить: «Я вернусь к вам с ответом». Я был на таком звонке. Это неприятное положение, и обычно оно возникает не потому, что кто-то сделал что-то не так. Оно возникает потому, что система, которая выдала этот показатель, изначально не была предназначена для ответа на этот вопрос.Регуляторная отчетность, будь то отчет о ликвидности, расчет капитала или что-то более специфическое, обладает странным свойством по сравнению с большинством задач инженерии данных. Никому за пределами команды на самом деле не важно, как выглядит панель мониторинга, стоящая за этим. Их волнует, сможете ли вы доказать, спустя месяцы или годы, откуда именно взялась каждая цифра, кто ее изменял и почему она изменилась между двумя отчетными периодами. Это принципиально иная цель проектирования, чем «сделать так, чтобы отчет работал быстро», и, честно говоря, многие системы создаются в первую очередь для скорости и удобства, а проверяемость добавляется потом как нечто второстепенное. И это видно.
Google Cloud Secret Manager имеет четкую, продуманную модель: секрет — это контейнер, а внутри него находятся неизменяемые версионированные значения. Вы никогда не редактируете версию — вы добавляете новую (1, 2, 3, …) и, когда она готова, перенаправляете на нее трафик, обычно путем разрешения последнего псевдонима (или отключения старой версии).Это действительно хороший дизайн. Но он сталкивается с тем, как большинство сервисов Go потребляют секреты: вы вызываете AccessSecretVersion("latest") ровно один раз при запуске и кэшируете результат. С этого момента ваш процесс привязан к тому, что означало "latest" при загрузке. Добавьте версию 4, отключите версию 3, и ваш сервис будет счастливо продолжать использовать 3-ю, пока кто-нибудь не перезапустит его — что, в лучшем случае, является запланированным повторным развертыванием, а в худшем — инцидентом, когда отключенная версия перестанет разрешаться.
Большинство команд, работающих с Apache Flink, думают о потоковой обработке: фильтрация событий, агрегирование значений, обогащение записей, объединение потоков. Это охватывает большинство проблем с данными в реальном времени. Но существует определенный класс проблем, с которыми потоковая обработка справляется плохо: обнаружение значимых последовательностей событий во времени. Произошла ли эта конкретная цепочка событий в таком порядке и в таком временном окне? Обработка сложных событий (CEP) — это инструмент, разработанный именно для этого, и он работает принципиально иначе, чем потоковая обработка.CEP является встроенной возможностью Apache Flink, доступной в виде открытого исходного кода и развертываемой в масштабах, недостижимых для старых проприетарных платформ. Тем не менее, она остается недоиспользованной и неправильно понятой. Эта статья представляет собой практическое руководство по тому, что такое CEP, когда ее следует использовать, как Flink ее реализует и какое место она занимает в современных архитектурах данных, включая агентный ИИ, который подробно рассматривается в сопутствующей статье.
Все администраторы баз данных в тот или иной момент сталкивались с подобным. Запрос, который раньше работал хорошо, внезапно начинает вызывать проблемы. На панели мониторинга не появляется никаких ошибок, сбоев или предупреждений, и единственным заметным признаком является жалоба пользователей на то, что сегодня приложение работает медленно. Теперь администратору базы данных предстоит определить, какой из бесчисленных запросов вызывает проблему.Лучшим решением здесь является инструмент Query Store. С момента его внедрения в 2016 году эта специальная функция хранит данные о тексте SQL-запросов, планах выполнения и статистике. Кроме того, в отличие от кэша планов, она сохраняет эту информацию даже после перезапуска сервера. Однако хитрость заключается в том, чтобы получить эти данные в удобном для пользователя формате.
За последний год я участвовал в достаточном количестве бесед с руководителями, чтобы заметить закономерность. Технический директор сообщает мне, что их организация "внедрила ИИ", потому что большинство инженеров теперь имеют доступ к Copilot или ChatGPT, и все посетили обед-семинар по составлению запросов. Через несколько месяцев ажиотаж обычно сменяется чем-то более спокойным: горстка инженеров ежедневно использует ИИ, один или два пилотных проекта так и не вышли из песочницы, и нет четкого ответа на вопрос, что же на самом деле изменилось в операционной деятельности.Проблема не в том, что эти инструменты не работают. Проблема в том, что внедрение измеряется неправильно. Количество людей, имеющих доступ к чат-боту с ИИ, почти ничего не говорит о том, насколько глубоко ИИ интегрирован в рабочий процесс. Команда из десяти человек, где ИИ надежно управляет одним интегрированным производственным рабочим процессом, возможно, продвинулась дальше, чем компания из ста человек, где каждый время от времени вставляет текст в чат-бот.
Кто-то внедряет слой дифференциальной приватности перед хранилищем событий и оставляет дашборды поверх него. Запросы по-прежнему выполняются, итоги по-прежнему выглядят как итоги, и задача закрывается. Никто в команде не рассчитал предел обнаружения.Каждый приватный агрегат несет шум, и этот шум не маркирован. Он находится в той же ячейке, которую кто-то читает в понедельник утром, прежде чем решить, изменился ли сегмент, и на вид это выглядит как небольшое реальное изменение. В работе с рекламными аккаунтами, которую я выполняю, переход к агрегированной и приватной отчетности обусловлен регулированием, а не архитектурой, поэтому дебаты никогда не ведутся, и шаблон всегда один и тот же: эпсилон согласовывается на совещании, а арифметика, которая превратила бы его в предел обнаружения, никогда не попадает ни в один документ.
Azure Key Vault — это примерный гражданин мира секретов Azure. Каждый секрет версионируется; вы получаете мягкое удаление и защиту от очистки; доступ управляется RBAC или политиками доступа; а DefaultAzureCredential означает, что ваше приложение аутентифицируется одинаково локально (az login) и в производственной среде (Managed Identity/Workload Identity на AKS) без каких-либо изменений в коде.И все же тот же старый пробел остается. Ваша Go-служба вызывает GetSecret один раз при запуске, декодирует значение в структуру и считает его неизменяемым в течение всего времени работы процесса. Когда кто-то обновляет секрет в Key Vault — новую версию, старая отключена — ваша служба об этом не узнает. Она продолжает использовать значение, прочитанное при загрузке, до следующего развертывания или перезапуска пода. Обновление было бесшовным в Azure и незаметным для вашего приложения, что является совершенно неправильной комбинацией.
Распространенная проблема, когда программное обеспечение работает на машине разработчика, но дает сбой в другом месте, указывает на архитектурную проблему. Это происходит потому, что критически важные части поведения системы не зафиксированы в системе контроля версий, что делает рабочую станцию разработчика неявной, недокументированной зависимостью. Различия в версиях среды выполнения, архитектуре ЦП, файловой системе, локали, часовых поясах, нативных библиотеках, сертификатах, переменных среды, разрешении зависимостей или инструментах сборки могут привести к этим сбоям. Эти расхождения означают, что системе не хватает полного и воспроизводимого определения условий сборки и выполнения. Практики воспроизводимой сборки направлены на решение этой проблемы, обеспечивая, чтобы заявленные источники и входные данные приводили к проверяемым артефактам. В настоящее время репозитории часто содержат исходный код и конфигурацию, но исключают операционные предположения. Например, разные комплекты разработки Java (JDK) могут изменять поведение службы. Код, зависящий от часового пояса хоста, может давать разные результаты из-за различий в среде выполнения виртуальной машины Java. Аналогично, локаль по умолчанию, которая влияет на операции, чувствительные к локали, может наследоваться из среды, что приводит к несогласованным результатам.