DEV Community на русском Заметка

DEV Community на русском

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

Трэд заметок

В этой статье подробно описывается серверная настройка чат-бота на базе Claude под названием Claudius, уделяя особое внимание системе идентификации, подключению к сервисам и реалиям развертывания. Система идентификации гарантирует, что роли пользователей, такие как администратор, участник или гость, определяются исключительно на сервере и не могут быть изменены клиентом. Это достигается с помощью Auth.js с провайдером Google и адаптером MongoDB, где роли определяются на основе электронной почты администратора, списка разрешенных адресов или по умолчанию устанавливаются как гость. Определенная роль затем встраивается в JWT для эффективного доступа в приложении. Процесс предоставления также устанавливает значения по умолчанию для полей, специфичных для пользователя, и гарантирует, что роль пересчитывается при каждом входе в систему.Подключение проверяется с помощью маршрута проверки работоспособности, который отправляет запрос к MongoDB Atlas и, при необходимости, выполняет небольшой вызов модели Claude Haiku Bedrock. Этот зонд проверяет, может ли приложение успешно взаимодействовать со своим ИИ-бэкендом, и возвращает метаданные использования токенов. Приложение также определяет каталог ИИ-моделей с соответствующими идентификаторами профилей вывода и информацией о ценах. Переменные среды проверяются итеративно по мере необходимости для каждого этапа разработки, причем текущий набор включает учетные данные для аутентификации, базы данных и Bedrock.В ходе этого этапа настройки были обнаружены и устранены несколько критических проблем, или "подводных камней". Серьезная проблема заключалась в обеспечении того, чтобы правильная база данных была выбрана как адаптером Auth.js, так и вспомогательным модулем базы данных приложения, поскольку отсутствующий путь к базе данных в строке подключения по умолчанию приводил к недоступной базе данных "test". Пул соединений был оптимизирован путем глобального кэширования клиента MongoDB. Управление зависимостями в монорепозитории требовало тщательного внимания к зависимостям времени выполнения и включения специфичных для платформы бинарных файлов в необязательные зависимости для развертывания. Основа для идентификации пользователей и взаимодействия с сервисами теперь заложена, хотя основная функция чата еще не реализована.
ИИ следует рассматривать как функцию, а не как волшебного джинна. Относиться к ИИ как к поисковой строке для разовых запросов — это нормально, но неэффективно для повторяющихся задач. Чтобы создать полезного ИИ-ассистента, начните с одной узкой, повторяющейся, скучной и проверяемой задачи. Думайте о промптах как о сигнатурах функций с четкими входными данными и структурированными выходными данными. Чтобы обеспечить надежные резюме, заставьте ИИ цитировать подтверждающие предложения из исходного материала. Для очистки данных избегайте изменений на месте и вместо этого попросите ИИ выдать карту для проверки. Крайне важно проверять выходные данные ИИ, создав небольшой "золотой набор" правильных примеров. Внедряйте дешевые проверки, такие как утверждения кода и выборочные проверки, чтобы рано выявлять ошибки. Вводите агентов только для задач, которые действительно включают несколько шагов или вызовы инструментов. Наконец, итерируйте, включая успешные выходные данные ИИ обратно в промпт, чтобы создать предсказуемого и надежного ассистента.
В сборке 0731 DeepSeek V4 Flash имеется дефект, при котором целочисленные поля в структурированном JSON-выводе могут повреждаться при включенном режиме "мышления". Эта проблема возникает конкретно со строгими JSON-схемами и наблюдалась в большинстве тестовых запусков. Однако отключение режима "мышления" устраняет повреждение и значительно снижает использование токенов. Переобучение сборки 0731 также привело к более резкому снижению производительности в многошаговых задачах при отключенном режиме "мышления". Модель имеет кэш, который хранит страницы объемом 1024 токена, при этом попадания в кэш происходят быстро, а записи сохраняются не менее 45 минут. Цены остаются прежними: 0,14 доллара за миллион входных токенов и 0,28 доллара за миллион выходных токенов, при этом попадания в кэш значительно дешевле. По сравнению с другими сборками V4, версия 0731 наиболее подвержена повреждению структурированного вывода. Регулятор "effort" в API не дал измеримых различий в производительности или использовании токенов. Двухэтапные математические задачи, являющиеся сложными, теперь в значительной степени зависят от включенного режима "мышления" для сборки 0731. Контекстное окно является существенным, вмещая большие запросы, а ограничения на вывод, по-видимому, подлежат обсуждению. Пользователям, которым требуется надежный структурированный вывод, следует отключить режим "мышления" в сборке 0731 до устранения дефекта.
Современные системы ИИ теперь могут выполнять сложные задачи, взаимодействуя с внешними инструментами, базами данных и сервисами, что порождает ИИ-агентов. Возникает значительная проблема, поскольку каждое приложение и API уникально раскрывает свои возможности, что требует индивидуальной интеграции для каждой платформы ИИ. Протокол контекста модели (MCP) решает эту проблему, предоставляя стандартный способ для моделей ИИ обнаруживать, понимать и использовать внешние ресурсы. MCP действует как общий язык, позволяя ИИ-клиентам обнаруживать инструменты, понимать их функции, получать структурированный ввод, выполнять их и получать структурированные результаты. Этот протокол имеет решающее значение для ИИ-агентов, которым необходимо выполнять действия, выходящие за рамки генерации текста, такие как взаимодействие с GitHub, Slack или базами данных. MCP включает в себя MCP-клиент (приложение ИИ), MCP-сервер (раскрывающий возможности) и сами инструменты. Процесс включает в себя подключение ИИ-клиента к серверу, обнаружение доступных инструментов, вызов выбранного инструмента на основе запроса пользователя и получение структурированного результата. Для разработчиков MCP предлагает стандартизированные интеграции, лучшую поддерживаемость и улучшенную обнаруживаемость инструментов. В отличие от традиционных API, которые раскрывают необработанные конечные точки, MCP описывает возможности, понятные моделям ИИ на более высоком уровне. В то время как вызов функций позволяет ИИ вызывать предопределенные функции в приложении, MCP предоставляет более широкую экосистему для обмена возможностями между различными ИИ-клиентами. Безопасность имеет первостепенное значение, поскольку MCP-серверы требуют надежной аутентификации, авторизации и проверки. MCP подходит для различных сценариев использования, включая помощников по программированию, корпоративный поиск и рабочие процессы DevOps, и дополняет существующие API, а не заменяет их.
Интеграция API спецификаций мобильного оборудования исторически была затруднена из-за неполных и ненормализованных данных. Сырые строковые форматы спецификаций, такие как частота обновления экрана и тактовая частота процессора, неудобны для программной логики. Для решения этой проблемы был разработан API Device Specs, предлагающий решение для неструктурированных и беспорядочных данных. Новый API переносит нагрузку по парсингу на бэкенд, предоставляя чистые, строго типизированные и нормализованные JSON-данные. Это означает, что числа являются настоящими числами, булевы значения — булевыми, а сложные спецификации представлены в виде структурированных массивов. Например, емкость аккумулятора — это целое число, а наличие NFC — четкое булево значение, а не текст. API также поддерживает глубокую фильтрацию, позволяя пользователям запрашивать очень специфические аппаратные параметры через параметры URL. Это позволяет выполнять сложные поиски, такие как поиск устройств с емкостью аккумулятора более 5000 мАч, объемом оперативной памяти не менее 8 ГБ, от Samsung или Xiaomi и содержащих "pro" в названии модели. Бэкенд построен на ASP.NET Core Web API, а фронтенд использует гибрид Blazor WebAssembly/Server. Caddy используется в качестве обратного прокси и обработчика SSL благодаря автоматическому управлению сертификатами HTTPS и чистому конфигурированию. Документация API и интерактивное тестирование доступны онлайн для пользователей, чтобы они могли изучить их и оставить свои отзывы.
Плейбуки реагирования на инциденты предоставляют структурированные процессы для управления и минимизации сбоев во время кризисов. Перед созданием плейбука определите его цели, объем и роли, обеспечив установление четких каналов связи и документирования. Тестирование и обучение являются важными подготовительными этапами. Конкретные типы инцидентов требуют индивидуальных плейбуков; утечки секретов представляют уникальные проблемы обнаружения по сравнению с системными сбоями. В отличие от системных сбоев, утечки секретов могут не вызывать немедленных очевидных оповещений, что требует специализированного мониторинга использования API, облачной активности и запросов к базам данных. Расследование утечек секретов включает определение их полного масштаба и воздействия, которое может быть далеко идущим. Предотвращение утечек секретов зависит от безопасного управления секретами, принципа наименьших привилегий, сканирования кода и непрерывного обучения. Во время инцидента сдерживание включает изоляцию систем, отключение учетных записей или отзыв скомпрометированных секретов после оценки радиуса поражения. Автоматизированные процессы и инструменты могут ускорить ротацию секретов и обновление систем. Развертывание секретов в производственной среде требует тщательных стратегий, таких как сине-зеленые развертывания или канареечные релизы, для минимизации времени простоя. Анализ после инцидента жизненно важен для выявления коренных причин и системных слабостей без возложения вины. Этот анализ должен информировать о проактивных мерах по предотвращению будущих инцидентов, таких как улучшение практик безопасности и обновление плейбуков.
CdXz5zHNQW_EPwVFzBOM1.webp
Этот учебник демонстрирует, как построить конвейер производства видео с использованием ИИ, применяя Hermes Agent и Remotion для создания коротких вертикальных видео. Автоматизированный рабочий процесс автоматизирует задачи от исследования трендовых тем до рендеринга финального отполированного видео. Он начинается с того, что Hermes Agent исследует вирусные темы, выбирая в качестве примера обнаружение метана в межзвездной комете с помощью космического телескопа Джеймса Уэбба. Затем Агент генерирует подробный производственный сценарий, включающий повествование, раскадровку и подсказки Remotion. Создается план производства по сценам, определяющий цветовые палитры, стили анимации и редакционное направление. Рабочий процесс автоматически генерирует произведения искусства ИИ для каждой сцены и использует Remotion для создания видео с движущейся графикой, даже итеративно улучшая сцены. Добавляются естественные голоса ИИ, а затем фоновая музыка и звуковые эффекты для отполированного звучания. Анимированные подписи на уровне слов генерируются с помощью Whisper для улучшения читаемости и визуальной привлекательности. Этот комплексный подход позволяет создателям сосредоточиться на повествовании, а не на ручном редактировании. Рабочий процесс идеально подходит для различных проектов, таких как образовательный контент, маркетинговые видео и социальные сети. Он предлагает большую гибкость, чем традиционные видеоредакторы, для разработчиков и технических создателей.
Отладка сложных проблем с помощью ИИ наиболее эффективна, когда вы предоставляете конкретные, фактические доказательства, а не расплывчатые описания. Расплывчатые вопросы о сбоях приложений приведут к общим советам, которые редко бывают полезными. Вместо того чтобы описывать проблему, покажите ИИ фактический стек ошибок, соответствующие фрагменты кода и последние коммиты git. Создание небольшого, воспроизводимого случая, который последовательно вызывает ошибку, еще лучше. Предоставив этот контекст, вы можете задавать целенаправленные вопросы о конкретном поведении, которое вы наблюдаете. ИИ испытывает трудности с двусмысленностью, но преуспевает в объяснении точного выполнения кода. Например, отладка утечки памяти включала предоставление снимка кучи и конкретных фрагментов кода, что привело к быстрой идентификации отсутствующей очистки записи карты. Такие инструменты, как Chrome DevTools для снимков кучи, clinic.js для профилирования и функция inspect в Node, бесценны для сбора этих доказательств. Отображение diff'ов и логов git помогает выявить недавние изменения, которые могут вызывать проблемы. Ключ в том, чтобы использовать ИИ как инструмент для ускорения вашего понимания, а не как замену вашему собственному процессу отладки. Думайте об ИИ как о неутомимых свежих глазах, которые могут помочь вам проанализировать предоставленные вами доказательства.
Данное руководство содержит основные сведения о сетях для разработчиков, пользователей Linux и начинающих специалистов в области кибербезопасности. Сети позволяют устройствам взаимодействовать и обмениваться данными, используя MAC-адреса для локальных подключений и IP-адреса для более обширных сетей, таких как Интернет. Серверы DHCP автоматически назначают IP-адреса, упрощая управление сетью. Подсети разделяют крупные сети, а маршрутизаторы соединяют разные сети, используя шлюзы по умолчанию для маршрутизации внешнего трафика.Система DNS преобразует доменные имена в IP-адреса: рекурсивные серверы находят эти адреса, а авторитетные серверы предоставляют официальные записи. Протокол TCP обеспечивает надёжную и упорядоченную доставку данных, что идеально подходит для просмотра веб-страниц и передачи файлов, тогда как протокол UDP ставит во главу угла скорость для таких приложений, как прямые трансляции и игры. Порты направляют сетевой трафик к конкретным службам или приложениям на устройстве.ARP сопоставляет IP-адреса с MAC-адресами, облегчая обмен данными внутри локальных сетей. Туннелирование инкапсулирует пакеты для передачи через различные сети. Модель OSI описывает семь уровней сетевого взаимодействия — от физической передачи до взаимодействия приложений — обеспечивая стандартизированную структуру. Различные сетевые протоколы, включая HTTP/HTTPS для веб-взаимодействия, WebSocket для соединений в реальном времени и FTP для передачи файлов, определяют порядок обмена данными. Освоение этих основ имеет решающее значение для понимания современных вычислений и для непрерывного обучения в обширной области сетевых технологий.
Для небольшого количества векторов в существующих установках Postgres, pgvector является идеальным начальным выбором, упрощая операции, сохраняя фильтры, соединения и транзакции в одном месте. Он служит расширением Postgres, добавляя типы векторных столбцов и ANN-индексы, и является открытым исходным кодом. Специализированные векторные базы данных, такие как Pinecone или Qdrant, становятся необходимыми, когда производительность, большой объем запросов, горизонтальное масштабирование или передача операционных задач становятся проблематичными с Postgres. Pinecone — это полностью управляемый облачный сервис с закрытым исходным кодом, предлагающий нулевую операционную нагрузку, но сопряженный с привязкой к поставщику и ценообразованием на основе потребления. Qdrant — это векторная база данных с открытым исходным кодом на Rust, предлагающая самостоятельный хостинг или облачный вариант, с мощной фильтрацией метаданных и квантованием. В то время как pgvector превосходен в операционной простоте и выразительности запросов, он может испытывать трудности при больших объемах, конкурируя с транзакционными нагрузками. Решение о переходе на специализированную векторную базу данных обычно продиктовано масштабом, изоляцией параллелизма запросов или желанием снять с себя операционную ответственность за поиск. Реальная стоимость специализированной векторной базы данных заключается не в самой миграции, а в постоянной операционной сложности управления дополнительной системой в вашей архитектуре. Поэтому начните с pgvector, перейдите на Pinecone для управляемой простоты или выберите Qdrant для специализированного, открытого исходного кода движка с контролем. Всегда проводите тестирование на своих собственных данных, чтобы принять обоснованное, специфичное для рабочей нагрузки решение.
Автор различает синдром самозванца и реальные стратегические проблемы, вызывающие неуверенность в себе. Синдром самозванца предполагает ощущение себя обманщиком, несмотря на объективные достижения, что иллюстрируется личным опытом с статьями об ИИ и приглашениями на конференции. В этих случаях мозг придумывает объяснения предполагаемым недостаткам. Однако не все чувства неадекватности проистекают из синдрома самозванца. Например, быть плохим бегуном не означает, что у человека синдром самозванца; это может просто означать отсутствие таланта или неправильные методы тренировок. Давать советы вроде "работай усерднее" или "продолжай идти" при проблемах, связанных со стратегией, а не с уверенностью в себе, может быть контрпродуктивно. Инженерный подход предполагает критический анализ собственной стратегии, а не только сосредоточение на повышении уверенности. Это включает в себя вопрос, приносит ли вложенное время результаты, и рассмотрение альтернативных стратегий. Крайне важно различать истинный синдром самозванца и сомнения, сигнализирующие о неправильном подходе. Иногда упорство — это решение, но иногда необходимы стратегические изменения. Научиться проводить это различие — сложная, но важная часть личностного роста.
В .NET внедрение зависимостей требует тщательного рассмотрения жизненных циклов служб. Распространенная ошибка возникает, когда служба с временем жизни "singleton", такая как EventListener, напрямую зависит от службы с временем жизни "scoped", например DbContext. Внедрение DbContext с временем жизни "scoped" в EventProcessor с временем жизни "singleton" приводит к тому, что один и тот же экземпляр DbContext используется повторно бесконечно. Этот устаревший DbContext может вызвать проблемы, такие как устаревшие данные и ошибки параллелизма.Рекомендуемая практика — сохранить EventProcessor как "singleton", но внедрить IServiceScopeFactory. Эта фабрика позволяет службе "singleton" создавать новую область действия и получать свежий DbContext всякий раз, когда он ей нужен. Альтернативно, сам EventProcessor может быть зарегистрирован с временем жизни "scoped". В этом сценарии EventListener с временем жизни "singleton" будет использовать IServiceScopeFactory для создания области действия и получения EventProcessor с временем жизни "scoped" для каждого обрабатываемого им события.В конечном итоге, основной принцип заключается в том, чтобы избегать прямого внедрения зависимостей с временем жизни "scoped" в службы с временем жизни "singleton". Если службе с временем жизни "singleton" требуется доступ к службе с временем жизни "scoped", она должна получать его динамически через IServiceScopeFactory. Аналогично, если службе требуется определенное время жизни, например "scoped", она должна быть зарегистрирована с этим временем жизни и соответствующим образом разрешена. Понимание этих стратегий управления жизненным циклом предотвращает распространенные ошибки, связанные с внедрением зависимостей.
Слияния и поглощения в финтехе — частое явление в британской технологической сфере, и их следует рассматривать как инженерный риск. Недавние примеры показывают, как приобретения могут изменить траекторию развития продуктов и создать проблемы с интеграцией. Приобретение Plaid компанией Visa сместило фокус на корпоративные условия, усложнив подключение для малого бизнеса. Миграция API TrueLayer потребовала значительных усилий разработчиков для адаптации к новым требованиям. Приобретение Nordigen компанией GoCardless привело к сокращению бесплатного уровня, вынудив некоторых разработчиков пересмотреть свои технологические стеки. Статистически вероятно, что любой бизнес, полагающийся на сторонние платежные API, столкнется с изменениями из-за приобретений или изменений цен. Чтобы снизить этот риск, разработчикам следует создать тонкий слой абстракции вокруг SDK поставщиков, изолируя основную бизнес-логику. Хранение канонического платежного состояния в собственной базе данных имеет решающее значение для поддержания целостности данных при изменениях поставщика. Наблюдение за ранними сигналами, такими как сокращение бесплатных уровней или замедление поддержки, может указывать на предстоящие изменения платформы. Включение в дорожные карты времени для спекулятивной миграции позволяет быстрее адаптироваться к непредвиденным изменениям. В конечном итоге, признание бизнес-рисков, связанных с API поставщиков, и создание архитектурной дистанции необходимы для устойчивости.
Автор недавно опубликовал подробный ретроспективный обзор архитектуры создания ToolHub — набора из 138 веб-утилит в браузере, ориентированных на чистоту, конфиденциальность и отсутствие лишнего кода. Сайт разработан так, чтобы загружаться менее чем за секунду и полностью работать в автономном режиме, с ключевыми инженерными компромиссами и техническими решениями, которые обеспечивают эти функции. Одним из основных архитектурных достижений является использование Next.js Static Export, которое позволяет полностью статически экспортировать модель, размещенную на CDN пограничного типа, что приводит к нулевому обслуживанию серверов и сверхнизкому времени до первого байта. Этот подход также обеспечивает бесконечную масштабируемость, но требует, чтобы весь динамический контент выполнялся строго на стороне клиента в памяти браузера. Автор также реализовал собственную стратегию кэширования Service Worker, которая включает stale-while-revalidate для статических ресурсов и network-first для навигации по HTML-документам, обеспечивая полную автономность всех инструментов после кэширования. Кроме того, автор разработал программный SEO-движок, который генерирует статические страницы инструментов с полными структурированными данными JSON-LD и автоматизированными сетями внутренних ссылок, все это встроено в статический HTML во время сборки. На сайте также реализована стратегия рекламы с нулевым CLS (Cumulative Layout Shift), которая предотвращает смещение макета, резервируя явные слоты фиксированной высоты для рекламных блоков до их загрузки. Автор предоставил сайт ToolHub для ознакомления пользователям, а также опубликовал подробный технический обзор в своем блоге, где делится более подробной информацией о технических решениях и компромиссах, которые были приняты при создании сайта. Автор ищет отзывы и предложения от пользователей и открыт для обсуждения архитектуры и идей для новых инструментов. В целом, проект ToolHub демонстрирует ряд инновационных технических подходов к созданию быстрых, автономных и ориентированных на конфиденциальность веб-приложений.
Автор отмечает распространенную проблему в обсуждениях системного дизайна: чрезмерный акцент на диаграммах и недостаток внимания к критически важным компромиссам, которые определяют архитектурные решения. Он задает несколько фундаментальных вопросов, таких как баланс между согласованностью и доступностью, а также оценка преимуществ монолитов по сравнению с микросервисами. Автор также подчеркивает сложности событийно-ориентированных архитектур и допустимую задержку для улучшения масштабируемости. Еще одна ключевая область беспокойства — когда следует разумно избегать или внедрять стратегии кэширования. Эти решения, по мнению автора, оказывают на производственные системы гораздо большее влияние, чем само визуальное представление. Недавно он опубликовал статью, в которой подробно рассматриваются эти реальные архитектурные компромиссы с использованием практических примеров. Автор активно ищет отзывы опытных архитекторов и бэкенд-инженеров о своих выводах. Его особенно интересуют противоположные точки зрения или альтернативные перспективы. Основной вопрос к сообществу касается одного архитектурного компромисса, который кардинально изменил их подход к проектированию распределенных систем.
Эффективное редактирование персональных данных требует тщательного проектирования конвейера, поскольку модели часто выходят из строя незаметно. Инициализация с помощью прохода на основе правил перед привлечением модели может ухудшить результаты, создавая неестественные шаблоны токенов, которые сбивают модель с толку. Вместо этого запускайте семантические и структурные проходы независимо друг от друга на исходном тексте, затем сверяйте результаты, обеспечивая действительность структурных смещений и отфильтровывая обнаружения дат с низкой уверенностью из структурного прохода.Разметка в корпоративных документах может исказить выходные данные модели; извлекайте обычный текст, редактируйте, а затем повторно вставляйте в исходную структуру, чтобы значительно улучшить полноту. Реализуйте обнаружение отказов для моделей, которые отказываются от редактирования, переключаясь на структурные проходы и регистрируя эти случаи для корректировки подсказок.Критически важно спроектировать систему так, чтобы она "закрывалась при сбое", а не "открывалась при сбое", чтобы предотвратить утечку данных при истечении времени ожидания вызовов редактирования, рассматривая структурные проходы как ухудшенный путь и оповещая о таких событиях. Контролируйте версии подсказок, регистрируя идентификатор модели и хэш подсказки с каждым редактированием, чтобы отслеживать изменения производительности с течением времени.Для кореференции в отредактированном тексте используйте нумерованные заполнители вместо общих тегов, но помните, что результирующая таблица сопоставления также является персональными данными и требует соответствующей безопасности, или отбрасывайте ее, если обратимость не требуется. Для измерения точности создайте "канареечный" набор документов без персональных данных и запускайте его при каждом изменении; любые редактирования в этом наборе сигнализируют о регрессиях.При масштабировании выходите за рамки одной модели, создавая интерфейс маршрутизации, который направляет запросы к различным моделям на основе ограничений вызывающего абонента, таких как задержка, местоположение или язык, при этом структурный проход всегда служит универсальным запасным вариантом. Реализуйте тщательные стратегии кэширования для подсказок длиной более 1024 токенов, чтобы оптимизировать затраты и пропускную способность. Рекомендуемый порядок сборки включает извлечение текста, выполнение независимых семантических и структурных проходов, фильтрацию дат, вставку структурных результатов, подстановку обратно в разметку, обнаружение отказов и регистрацию основных метаданных, при этом постоянно тестируя с помощью "канареечного" набора.
CdXz5zHNQW_YNDXntIFNX.webp
При создании React-приложения разработчики часто сталкиваются с ошибкой CORS при выполнении запросов к API. Эта ошибка возникает из-за политики безопасности браузера, которая запрещает запросы из одного источника к другому без соответствующего разрешения. Наиболее надежным решением является настройка серверного приложения для отправки заголовка Access-Control-Allow-Origin. Этот заголовок указывает, каким доменам фронтенда разрешен доступ к API.Для Node.js с Express это включает использование промежуточного ПО cors и его настройку для приема определенных источников. Аналогично, Laravel и Python с Flask предлагают способы установки этих заголовков напрямую или через библиотеки, такие как flask-cors. Если прямая модификация серверной части невозможна, во время локальной разработки можно использовать прокси. Добавив поле "proxy" в файл package.json, сервер разработки React может перенаправлять запросы к API. Это обходит ограничения CORS, поскольку браузер воспринимает запрос как исходящий из того же источника.Однако это решение с прокси эффективно только в среде разработки и не будет работать в продакшене. Временным, менее рекомендуемым обходным путем является использование общедоступного сервиса прокси CORS, но это приводит к задержкам, возможным ограничениям скорости и проблемам безопасности. Если API требует аутентификации, такой как файлы cookie или токены JWT, необходимо обновить как запрос fetch на фронтенде, так и конфигурацию серверной части для включения учетных данных. Запросы на фронтенде требуют credentials: 'include', а на серверной части — credentials: true.Отладка проблем CORS включает проверку наличия и правильности заголовка Access-Control-Allow-Origin на вкладке "Сеть" инструментов разработчика браузера. Если запросы предварительной проверки (OPTIONS) завершаются неудачно, серверная часть может быть неправильно настроена для их обработки. В конечном итоге большинство ошибок CORS связаны с проблемами конфигурации серверной части, а не с кодом фронтенда. Понимание среды, а также фреймворков фронтенда и бэкенда имеет решающее значение для эффективной отладки.
Структурированное создание контента позволяет создавать его из повторно используемых семантических строительных блоков, концепция, формализованная DITA XML. Topicary реализует эти принципы без необходимости знания XML. Основной функцией являются компоненты контента, которые пишутся один раз и могут повторно использоваться в нескольких темах. Обновление компонента автоматически распространяет изменения на все его ссылки. Пользователи могут легко сохранить любой блок текста как компонент с помощью простой команды. Компоненты предлагают надежное отслеживание "где используется", позволяя авторам оценивать влияние правок. Условный контент позволяет адаптировать одну тему для разных аудиторий, помечая блоки определенными условиями. Авторы могут просматривать эти условные представления непосредственно в редакторе для получения немедленной обратной связи. Переменные упрощают управление контентом, позволяя обновлять повторяющиеся элементы, такие как названия продуктов или номера версий, в одной точке. Topicary поддерживает импорт контента из различных форматов, включая Markdown, DITA и MadCap Flare, сохраняя существующие структуры и функции.
Анонс Microsoft Build 2026 посвящен их Agent Harness и Foundry Hosted Agents, которые теперь доступны в общей доступности. Это знаменует собой сдвиг в том, как ИИ-агенты воспринимаются и создаются для производства. Исследования показывают, что примерно 98,4% системы агента составляет инфраструктура, а не сама модель ИИ. Agent Harness предоставляет это критически важное операционное ядро, обрабатывая такие задачи, как вызов функций, управление контекстом и маршрутизация инструментов. Foundry Hosted Agents предлагает этот harness в виде управляемого сервиса с оплатой по мере использования, что упрощает развертывание.Agent Harness устраняет распространенные производственные узкие места, такие как подключение агентов к инструментам и сохранение истории разговоров. Основная ставка Microsoft заключается в том, что эта инфраструктура harness, а не взаимозаменяемая модель ИИ, является настоящим продуктом. Harness включает в себя такие функции, как вызов функций с историей, сжатие контекста, список задач для планирования и выполнения, файловую память и встроенный OpenTelemetry для наблюдаемости. Это гарантирует, что каждое действие, от вызовов инструментов до решений об утверждении, отслеживается.Foundry Hosted Agents устраняет необходимость в сложных конфигурациях YAML, предоставляя управляемое развертывание, где пользователи предоставляют только клиент чата, инструкции и инструменты. Этот управляемый сервис использует ту же основную логику, что и локально запускаемый harness, обеспечивая согласованное поведение в средах разработки и производства. Фреймворк также представляет коннекторы для GitHub Copilot и Claude Agent SDK, позволяя менять модели без изменения harness. Эта унифицированная плоскость политики управления обеспечивает согласованные правила утверждения и аудиторские следы для различных базовых моделей ИИ. Прочный слой системы агента, охватывающий ворота утверждения, историю и применение политики, выделяется как ключевая область для инженерных инвестиций. Предложение Microsoft позиционирует harness как стабильный, поддерживаемый продукт, позволяющий разработчикам сосредоточиться на создании адаптивных приложений.
В этом разделе рассматривается контроль затрат, связанных с выводом, историей разговоров и повторяющимся статическим контентом в моделях ИИ. Токены вывода и рассуждений значительно дороже входных токенов, причем некоторые модели стоят до восьми раз дороже за вывод. Процессы рассуждений могут генерировать скрытые "мыслительные" токены, которые также влекут за собой более высокие тарифы на вывод. Spring AI предлагает такие элементы управления, как maxTokens, для независимых от поставщика ограничений по длине и настроек, специфичных для поставщика, для управления усилиями по рассуждению. История разговоров, которая включает повторную отправку всего журнала чата с каждым запросом, быстро увеличивает затраты на входные токены. Хранение и повторная отправка истории означает, что даже небольшие разговоры со временем могут привести к значительному использованию токенов. Spring AI предоставляет MessageWindowChatMemory для управления историей разговоров путем использования скользящего окна указанного количества сообщений. Для очень длинных сессий VectorStoreChatMemoryAdvisor предлагает альтернативу, сохраняя историю в векторном хранилище и извлекая только релевантные сообщения. Повторяющийся статический контент, такой как системные подсказки или определения инструментов, оплачивается при каждом запросе без кэширования. Кэширование подсказок снижает эти затраты, сохраняя обработанные префиксы подсказок для повторного использования. Anthropic и AWS Bedrock позволяют пользователям указывать стратегии кэширования, в то время как OpenAI автоматически кэширует подсказки для запросов, превышающих определенное количество токенов, хотя запись в кэш теперь взимается. Локальные модели, такие как Ollama, используют кэширование для повышения скорости, экономя время обработки на GPU, но нет никаких сборов за токены для снижения. Явное планирование кэширования и управление ключами кэша имеет решающее значение для оптимизации затрат с этими моделями.
Шесть недель назад автор отметил, что только 4 из 122 страниц на их новом домене tamethebot.com были индексированы Google. Они связали это с ограничением бюджета на молодой домен без обратных ссылок, а не техническими проблемами. Недавнее обновление показывает значительное улучшение: сейчас индексировано 115 страниц, а остались только 14 неиндексированными. Первоначальное предсказание автора по вопросу с бюджетом на обмещение оказалось верным: категория «Обнаружено — в настоящее время не индексировано» упала до нуля.Важно, что в этот период почти не было изменений в содержание сайта; новые страницы добавлялись с той же скоростью, и одна экспериментальная «глубокая» страница не показала результатов выше среднего. Ключевым изменением, совпавшим с усилением индексации, стало публикация предыдущего поста автора, который успешно собрал две обратные ссылки на главную страницу и карту сайта. Хотя эта обратная ссылка не подлежит окончательному доказательству, наряду со старением домена и регулярным повторным сканированием давали Google повод выделить больше бюджета.Автор признал одну техническую ошибку: их крючок для развертывания IndexNow тихо выходил из строя несколько недель, хотя это не повлияло на индексацию Google, так как IndexNow в основном обслуживает Bing и Yandex. Рост числа индексируемых страниц привёл к значительному увеличению количества органических сессий Google с небольшой базы. Однако автор предупреждает, что некоторые отслеживаемые «активные пользователи» на самом деле являются дата-центрами, а не настоящими людьми.В неожиданном повороте, хотя индексатор Google одобрял страницы, Google AdSense дважды отклонял тот же контент как «контент низкой ценности». Автор признаёт, что критерии индексатора (это настоящая страница, которая может захотеть искатель?) отличаются от AdSense (является ли это сайтом с достаточной глубиной и трафиком для рекламного бизнеса?). Следующие шаги автора заключаются в том, чтобы продолжить публичное письмо, чтобы получить одобрение как от индексатора Google, так и от AdSense.
Этот текст сравнивает различные решения межсетевых экранов веб-приложений (WAF), категоризируя их по типу и способу развертывания. SafeLine Community — это самостоятельный обратный прокси, развернутый через Docker. Cloudflare Free — это облачный граничный прокси, требующий изменения DNS. CrowdSec WAF — это модульный самостоятельный вариант, а ModSecurity интегрируется как модуль сервера. BunkerWeb — это самостоятельное решение на базе NGINX.Что касается обнаружения, SafeLine и ModSecurity показывают сопоставимые результаты, но ModSecurity имеет значительно больше ложных срабатываний. Уровень обнаружения Cloudflare Free очень низкий, он больше функционирует как CDN. Производительность CrowdSec и BunkerWeb зависит от используемых ими наборов правил.Несколько бесплатных WAF предлагают неограниченное количество пользовательских правил, в отличие от ограниченного бесплатного уровня Cloudflare. Защита от ботов и блокировка по странам, как правило, сильнее в самостоятельных решениях. SafeLine выделяется простой настройкой одной командой и функциональностью "из коробки". Cloudflare прост в использовании, но обеспечивает меньшее обнаружение и собирает данные пользователей.CrowdSec и ModSecurity требуют более сложной настройки, при этом ModSecurity нуждается в обширной настройке. WAF рекомендуется для любого общедоступного веб-сайта или API. Бесплатные WAF, как правило, достаточны для личных проектов и малого бизнеса, особенно в сочетании с другими сервисами.Для производственных сред, требующих SLA и расширенных функций, необходимы платные WAF. Бесплатные уровни обычно не имеют выделенной поддержки и расширенного логирования, хотя качество обнаружения может быть схожим с платными версиями. SafeLine Community и CrowdSec выделяются как действительно бесплатные варианты без скрытых платежей. Плагинные WAF менее эффективны, чем WAF на базе обратного прокси, поскольку они проверяют трафик позже. Регулярные обновления имеют решающее значение для поддержания эффективности WAF.
TCP является стандартом для надежных сетей, но UDP предлагает больше контроля для специализированных приложений. Сам по себе UDP ненадежен, отправляя пакеты без гарантий доставки или порядка. Многие высокопроизводительные системы, такие как игры и потоковые сервисы, выбирают UDP, потому что он позволяет разработчикам создавать собственные механизмы надежности. Это достигается с помощью инженерного подхода, а не отдельного протокола, путем добавления метаданных к пакетам UDP. Ключевые компоненты включают порядковые номера для отслеживания пакетов и подтверждения для подтверждения получения. Таймеры повторной передачи инициируют повторную отправку, если пакеты потеряны, а обнаружение дубликатов обрабатывает избыточные пакеты. Механизмы упорядочивания пакетов гарантируют, что данные поступают в правильной последовательности для приложения. Скользящее окно позволяет обрабатывать несколько ожидающих пакетов, повышая пропускную способность. Установка соединения, хотя и не является неотъемлемой частью UDP, может быть реализована для управления сеансами. Пульс используется для проверки активных соединений. Осведомленность о перегрузке имеет решающее значение для соблюдения пропускной способности сети. В конечном итоге, объединяя эти разработанные компоненты, UDP может быть преобразован в надежный транспортный уровень, адаптированный к конкретным потребностям приложения, как это видно в протоколах, таких как QUIC. Надежность в инженерии часто возникает из множества простых механизмов, работающих вместе, а не из одной сложной функции.
Запись DNS с подстановочным знаком упрощает публикацию сервисов, автоматически разрешая любой поддомен одному IP-адресу. Nginx Proxy Manager (NPM) еще больше упрощает публикацию, требуя всего несколько полей для безопасного предоставления доступа к сервисам с помощью HTTPS. Эта автоматизация привела к созданию девятнадцати прокси-хостов, все из которых запускают саморазмещенное программное обеспечение с различными методами аутентификации. Основная выявленная проблема заключается в том, что простота публикации обходит критически важные решения по безопасности, касающиеся контроля доступа.Цель автора заключалась не в том, чтобы полностью скрыть сервисы, а в том, чтобы сделать их доступными только из частной сети, построенной на общедоступной инфраструктуре. Запись DNS с подстановочным знаком, хотя и упрощает настройку, сама по себе не обеспечивает безопасности. NPM использует вызовы HTTP-01 для сертификатов Let's Encrypt, что требует, чтобы порт 80 оставался открытым, что является уязвимостью безопасности. Подстановочный сертификат через DNS-01 позволил бы закрыть порт 80, но требует предоставления прав на запись в зоне DNS.Сервисы публикуются путем размещения их контейнеров в общей сети Docker, что позволяет NPM проксировать запросы внутри сети. Это означает, что сервисам не нужно напрямую открывать порты для хоста, что повышает безопасность. Саморазмещенный прокси-шлюз на том же VPS направляет трафик обратно в NPM, представляясь как входящий HTTPS с общедоступного IP-адреса VPS. Поведение этого шлюза, первоначально ошибочно принятое за ошибку маршрутизации, является неотъемлемой частью схемы безопасности.NPM обеспечивает контроль доступа с помощью блоков конфигурации Nginx, которые разрешают запросы только с внутреннего IP-адреса Docker шлюза или общедоступного IP-адреса VPS, за которыми следует базовая HTTP-аутентификация. Это гарантирует, что, несмотря на то, что сервисы общедоступны и имеют действительные сертификаты, доступ к ним ограничен. Отдельное расположение для вызовов Let's Encrypt остается открытым для Интернета, как того требует проверка сертификата. Два критически важных хоста, панель администратора шлюза и конечная точка распространения конфигурации, являются исключениями из строгого контроля доступа, поскольку они должны быть доступны до полной интеграции шлюза.Серьезная проблема возникла, когда сервис, который встраивал свой серверный адрес в профили подключений пользователей, ошибочно рекламировал неправильный адрес. Поскольку NPM передает реальный IP-адрес клиента через заголовок X-Forwarded-For, сервис интерпретировал этот заголовок как свой собственный общедоступный адрес, что приводило к тому, что клиенты подключались к неправильному серверу. Эта ошибка оставалась незамеченной, потому что собственное тестирование автора, использующее шлюз, всегда представляло правильный ожидаемый адрес. Терминация TLS происходит в NPM, а трафик между NPM и серверными контейнерами передается в виде незашифрованного HTTP по сети Docker.
Вы можете подключать ИИ-агентов к Telegram, используя сервер MCP, но существуют две различные конфигурации со значительными последствиями для безопасности. Первый тип использует токен Bot API, аутентифицируясь как бот. Этот бот может получать доступ только к чатам, в которые он явно добавлен, и его доступ ограничен и легко отзывается. Он не может видеть личные сообщения или чаты, куда он не был приглашен.Второй тип использует сервер MTProto, который аутентифицируется по вашему номеру телефона и входит в систему от вашего имени. Это дает агенту доступ ко всем вашим данным Telegram, включая личные сообщения, группы, сохраненные сообщения и контакты. Это достигается путем создания файла сессии, который представляет собой активный вход в систему.Настройка Bot API или уведомлений включает предоставление токена бота и, возможно, идентификатора чата. Настройка MTProto требует установки и интерактивного входа в систему с использованием вашего API ID и API Hash. Расположение конфигурационного файла значительно варьируется в зависимости от используемого ИИ-клиента, а некоторые клиенты, такие как Codex CLI, используют другой формат конфигурации (TOML).Основная проблема с серверами MTProto заключается в том, что файл сессии предоставляет полный доступ к вашей учетной записи. Этот файл сессии никогда не должен храниться в синхронизированных папках или включаться в репозитории кода. Кроме того, поскольку ИИ-агенты обрабатывают как данные, так и инструкции как текст, злонамеренное сообщение может быть составлено для использования возможности агента отправлять сообщения, что представляет угрозу безопасности.Радиус поражения токена Bot API ограничен чатами, в которых находится бот, в то время как файл сессии MTProto компрометирует всю вашу учетную запись. Серверы MTProto не являются принципиально непригодными для использования, но требуют обдуманного рассмотрения и в идеале должны использоваться со вторичной учетной записью для снижения рисков. Крайне важно проверять код этих разработанных сообществом серверов MCP перед подключением их к важным учетным записям.
Чтобы контролировать расходы на RAG для приложения семантического поиска, выполняйте пакетное индексирование документов и оценивайте затраты на токены перед запуском. Отправляйте в модель чата только верхние извлеченные фрагменты для генерации ответов. Полезная оценка стоимости токенов должна разделять ввод эмбеддингов во время индексирования, операции во время извлечения, а также ввод и вывод для генерации ответов. Оценка выходит за рамки простого подсчета токенов; она включает оценку размера фрагмента, перекрытия и настройки top-k, поскольку эти параметры напрямую влияют на длину подсказки и стоимость. Практическая оценка начинается с репрезентативных документов и реальных вопросов пользователей для расчета общего количества токенов при различных стратегиях фрагментации. Полнота извлечения имеет решающее значение; меньшее количество фрагментов полезно только в том случае, если наиболее релевантный отрывок все еще извлекается. Переранжирование может улучшить порядок контекста, позволяя отправлять меньше фрагментов в модель чата.Индексирование следует рассматривать как отдельную пакетную задачу, не связанную с путем запроса пользователя. Это предотвращает неожиданные счета за подсказки из-за больших объемов приема данных. Повторные попытки при индексировании документов требуют идемпотентных ключей или идентификаторов, предоставляемых клиентом, чтобы избежать дублирования данных. Прежде чем оптимизировать подсказки или модели, важно сделать распределение документов видимым и выявить чрезмерно большие фрагменты. Использование вызовов подсчета токенов, специфичных для поставщика, с соответствующими стратегиями отката и повторных попыток является ключом к точным оценкам.Пакетное индексирование предлагает преимущества для больших объемов данных, позволяя отслеживать задания и вести журналы аудита, отделяя загрузки от создания эмбеддингов. Важно не путать политики повторных попыток между пакетными заданиями с опросом и идемпотентными операциями записи. Хотя пакетное индексирование не идеально для немедленной возможности поиска, небольшой синхронный путь может удовлетворить эту потребность. Выбор компонентов стека RAG, таких как OpenAI, Anthropic, Google Gemini, Pinecone, Weaviate или Infrai, зависит от существующих рабочих процессов и приоритетов команды. Миграция должна происходить только в том случае, если она действительно улучшает систему, а не просто ради незначительной экономии средств. В конечном итоге код должен предоставлять обоснованные ответы, а чистая оценка затрат бессмысленна при слабом извлечении.
Этот пост посвящен проблеме дистрибуции для автономных ИИ-компаний, утверждая, что это серьезное препятствие без четкого плана действий. Платное привлечение клиентов через такие платформы, как Meta Ads, непомерно дорого для малого и среднего бизнеса, поскольку стоимость привлечения клиента значительно превышает его пожизненную ценность с учетом расходов на инференс и данные. Математика просто не сходится для автономных агентов при типичных ставках подписки для малого и среднего бизнеса.Каналы холодных обращений, некогда бывшие выходом из положения, все больше закрываются для автоматизированных сообщений в больших объемах. Социальные платформы внедряют более строгие правила против спама, генерируемого ИИ, что затрудняет программную отправку исходящих сообщений агентами. LinkedIn и Reddit имеют свои условия обслуживания и поведенческие фильтры, которые активно наказывают за автоматизированные обращения. Доставляемость холодных писем также страдает из-за общих доменов и возможного попадания в черные списки из-за злоупотребления со стороны одного клиента.Оставшиеся жизнеспособные каналы дистрибуции требуют человеческого участия, включая контент-маркетинг, SEO, построение сообщества, брендинг, основанный на основателе, и партнерства. Эти методы требуют постоянных усилий, суждений, вкуса и построения отношений в течение длительного времени. Автономные агенты по своей природе с трудом реализуют эти, по сути, человекоцентричные стратегии, особенно на ранних этапах роста компании.Автор утверждает, что, хотя затраты на инференс снижаются, а методы получения данных улучшаются, дистрибуция остается фундаментальной проблемой для автономного ИИ. Не существует простого решения "создать" или "ждать" для масштабирования дистрибуции автономно. Этот тезис верен для конкретных ниш, таких как потребительские приложения с устоявшимся платным привлечением или встроенные решения, но не для общего видения "ИИ управляет вашей компанией".В конечном счете, истинное преимущество ИИ для малого и среднего бизнеса заключается не в полной автоматизации, а в автоматизации повторяющейся "рутины" дистрибуции, в то время как человеческое суждение направляет процесс. Компания автора, Thread Otter, стремится предоставить автопилот, который помогает находить существующий спрос и взаимодействовать с ним, составлять ответы голосом пользователя и автоматизировать трудоемкие аспекты обращений, позволяя людям сосредоточиться на накапливающемся вкладе суждений. Этот подход признает, что дистрибуцию нельзя создать автономно, но ее можно обнаружить и управлять ею под человеческим надзором.
Этот материал описывает Penny — простой трекер расходов в командной строке, созданный на Python с использованием библиотеки Click. Penny позволяет пользователям добавлять, перечислять, суммировать и очищать расходы непосредственно из терминала, без необходимости веб-интерфейса или базы данных. Автор выбрал Click вместо встроенного в Python argparse из-за его более интуитивного подхода, основанного на декораторах, для определения команд и опций.Проект состоит из трех основных файлов: commands.py для логики отдельных команд, penny.py для группировки этих команд в единый инструмент командной строки и pyproject.toml для упаковки и определения точки входа. Penny хранит данные о расходах в обычном JSON-файле с именем expenses.json, читая и записывая в него при каждой операции. Команда add создает JSON-файл, если он не существует, добавляет новые расходы и сохраняет обновленный список, предоставляя цветное подтверждение.Команда list отображает сохраненные расходы в табличном формате, выдавая предупреждение, если расходы не найдены. Команда summary вычисляет и выводит общие суммы расходов по категориям и общую сумму, представляя результаты в виде отформатированного JSON. Команда clear включает запрос подтверждения перед перезаписью файла expenses.json пустым списком.Файл penny.py использует функциональность группировки Click для объединения всех команд под единым исполняемым файлом penny. Файл pyproject.toml настраивает эту группировку, делая Penny глобально устанавливаемым инструментом командной строки через pip install .. Автор подчеркивает преимущества декларативного стиля Click, пригодность JSON для простого хранения данных, важность мелких деталей пользовательского опыта и то, как группировка команд превращает скрипт в отточенное приложение командной строки.
Незначительный дефект разметки включал двенадцать идентичных SVG-градиентов, каждый из которых был определен с одинаковым ID. В результате одиннадцать из двенадцати определений градиентов не использовались, в то время как все визуальные элементы некорректно ссылались на первое определение. Страница выглядела визуально правильно, потому что все дублирующиеся градиенты имели идентичные цветовые остановки. Эта невидимость означала, что стандартные аудиты сайта, включая пять собственных проверок автора, не смогли обнаружить проблему. Проблема оставалась скрытой до тех пор, пока не было изменено определение градиента, что потенциально могло повлиять на неправильный элемент или вообще ни на какой элемент. Критическая проверка аудита на дублирующиеся ID отсутствовала, потому что раньше это никогда не вызывало видимых проблем. Первоначальная попытка исправления, которая последовательно переименовывала ID, создала более серьезную, видимую ошибку, связав неправильные определения с ссылками. Это упущение было предотвращено проверкой количества, которая выявила дисбаланс между определениями и ссылками. Правильное решение заключается в ограничении области действия переименования ID отдельными блоками SVG, гарантируя, что определения соответствуют ссылкам только в пределах их собственной области. Этот опыт подчеркивает важность аудита на дублирующиеся ID, особенно для встроенных SVG, и тщательной проверки операций поиска и замены.
Письмо — неотъемлемая часть карьеры инженера-программиста, выходящая за рамки простого написания кода. Каждый разработчик пишет сообщения коммитов, имена переменных, отчеты об ошибках и документацию, что делает это фундаментальным навыком. Истинная польза письма, особенно технических статей, заключается не во внешней аудитории, а в личностном росте и улучшении инженерных навыков. Письмо заставляет структурировать мышление, тем самым выявляя пробелы в собственном понимании и выступая в качестве строгого теста знаний. Документирование опыта превращает мимолетные уроки в прочные знания, выступая в качестве высшей формы обучения.Опытные инженеры понимают, что отличная документация ускоряет прогресс и уменьшает технический долг, создавая поддерживаемые знания для команд. Такие платформы, как LinkedIn, и личные блоги предоставляют возможности для демонстрации профессионального роста и создания прочной, доступной для поиска базы знаний. Эта практика письма создает "второй мозг", внешнюю память, которая помогает в будущем решать проблемы и делает технические собеседования более естественными. Развитие личного бренда посредством письма демонстрирует экспертизу и надежность, доказывая невидимую экспертизу видимым доказательством.Крайне важно начать писать как можно раньше, даже без опыта или аудитории, поскольку рост предшествует признанию. Составной эффект последовательного письма со временем создает ценное профессиональное наследие. В конечном итоге, в то время как код создает продукты, письмо создает инженера, стоящего за ними, способствуя карьере, которая запоминается как техническим мастерством, так и вдумчивым общением.
Автор описывает распространенный сценарий отладки, когда сервис в Kubernetes не работает, несмотря на то, что все технические индикаторы выглядят исправными. Это происходит потому, что Docker проверяет, работает ли приложение, в то время как Kubernetes проверяет его работоспособность. Простота Docker скрывает четыре критических вопроса, на которые приложение должно ответить в производственной среде. Первый вопрос заключается в том, может ли приложение быть найдено по имени, а не только по адресу, поскольку localhost в подах Kubernetes относится только к самому поду. Во-вторых, приложения должны уметь корректно завершать работу по команде внешней системы, правильно реагируя на сигналы, такие как SIGTERM. Третий важный аспект — это демонстрация готовности перед получением трафика, поскольку Kubernetes активно проверяет работоспособность приложения с момента его запуска. Наконец, приложения должны функционировать, не полагаясь на локальное хранение на диске, используя механизмы Kubernetes для конфигурации и хранения данных. Понимание этих четырех вопросов помогает понять, почему приложения ведут себя по-разному в Docker и Kubernetes. Автор приводит примеры того, как игнорирование этих моментов может привести к распространенным производственным проблемам. Это объяснение не является аргументом против Kubernetes, а скорее исследованием долга работоспособности, который Docker позволяет командам накапливать.
Автор провел визуальное тестирование нескольких приложений, включая панель управления с отсутствующим графиком, транспортное приложение, отображающее статус транспортных средств на карте, и служебное приложение для отметки местоположений деревьев. Визуальное тестирование помогает выявлять сбои пользовательского интерфейса на ранних стадиях, особенно когда интерфейс стабилен. Playwright предлагает бесплатные возможности визуального тестирования, в отличие от платных инструментов, таких как Applitools и Percy. Основная проблема заключается в визуальном тестировании панели управления дебиторской задолженности, где показатель "Среднее количество дней просрочки" ежедневно колеблется. Тестирование на нескольких языках, включая английский, испанский, немецкий и японский, также представляет собой проблему из-за разной длины текста. Кроме того, для проверки точности данных требуется интегрированное тестирование API без мокирования. Когда динамические значения влияют на визуальную согласованность, стратегии тестирования включают маскирование динамической области или мокирование API для возврата предопределенных значений. Предоставленные ссылки содержат веб-сайт и API для тестирования этих сценариев. Автор призывает делиться репозиториями и задавать вопросы по завершении задания.
Использование автономных агентов в бизнес-процессах может быть непредсказуемым и приводить к хаотичным циклам выполнения, что может стать проблемой при работе с операциями с высокими ставками, такими как коммерческие контракты или подача нормативных документов. Для решения этой проблемы необходима структурированная система, которая обеспечивает соблюдение строгих правил при сохранении когнитивной гибкости. LangGraph — это система оркестровки, которая позволяет создавать детерминированные многоагентные рабочие процессы, способные превратить непредсказуемое поведение ИИ в надежные бизнес-процессы, управляемые конечными автоматами. LangGraph моделирует взаимодействие агентов как узлы, а переходы — как ребра, позволяя реализовать циклические пути и самокоррекцию. Эта архитектура гарантирует, что каждый узел имеет доступ к накопленному контексту, а любые изменения состояния явно отслеживаются и проверяются. Используя LangGraph, предприятия могут создавать устойчивые, самокорректирующиеся системы, которые ведут себя предсказуемо даже при работе с сильно варьирующимися выходными данными LLM. LangGraph особенно полезен для создания строгих, проверяемых бизнес-процессов, а его подход, ориентированный на состояние, гарантирует, что правила, определенные разработчиком, всегда имеют приоритет над автономией агента. Внедрение детерминированных рабочих процессов агентов может напрямую повлиять на операционную эффективность, профили рисков и рост прибыли, как показывают примеры, такие как андеррайтинг коммерческого страхования, управление циклом доходов в здравоохранении и таможенное брокерство в цепочке поставок. Используя LangGraph, компании могут снизить риск ошибок, повысить эффективность и производительность, что в конечном итоге приведет к экономии затрат и росту доходов. В целом, LangGraph предоставляет надежное решение для создания детерминированных многоагентных рабочих процессов, позволяя компаниям автоматизировать сложные процессы, сохраняя при этом контроль и предсказуемость.
Alibaba выпустила Qwen3.8-Max, мощную модель Mixture-of-Experts с 2,4 триллионами параметров. Эта модель имеет контекстное окно в 1 миллион токенов и поддерживает ввод текста, изображений и видео. Ее API совместим с протоколами OpenAI и Anthropic, что упрощает интеграцию для разработчиков. Цена установлена на уровне 2 долларов за миллион входных токенов и 6 долларов за миллион выходных токенов. Существенным фактором экономии является снижение цены на кэшированные входные токены, что подчеркивает важность стабильных префиксов в запросах.Соглашение об именовании модели различает поколения и точечные выпуски, причем Qwen3.8-Max является последним флагманом. Хотя общее количество параметров составляет 2,4 триллиона, для каждого токена активно лишь около 95 миллиардов, что делает инференс более эффективным. Эффективное контекстное окно составляет около 991 тыс. токенов, с максимальным ограничением выходных токенов в 131 тыс. Разработчики могут использовать ее API, совместимый с OpenAI, обновив базовый URL и название модели.SDK DashScope от Alibaba демонстрирует ее мультимодальные возможности с помощью фрагмента кода. Модель поддерживает различные функции, включая вызов функций и структурированные выходные данные, а также поставляется с пятью встроенными инструментами. Тесты показывают высокую производительность в мультимодальных и агентских задачах, хотя в некоторых областях она отстает от конкурентов, таких как Claude 3.5. Ожидается, что вскоре будут выпущены открытые веса, а также меньшая версия с 27 миллиардами параметров.В настоящее время отсутствует официальная карточка модели с подробными данными об обучении и оценками безопасности. Условия лицензирования для коммерческого использования станут ясными только после выпуска открытых весов. Количество активных параметров сообщается, но пока официально не подтверждено Alibaba. Несмотря на эти недостающие элементы, Qwen3.8-Max рекомендуется для мультимодальных приложений, задач с большим контекстом и для пользователей, уже использующих протоколы OpenAI/Anthropic.
Задержка является критически важной проблемой при внедрении моделей языка и ИИ в продакшн. Игнорирование вычислительной производительности, фокусируясь только на точности, является ошибкой. Скорость, измеряемая в токенах в секунду, стала важной архитектурной метрикой. Это связано с тем, что критически важные приложения нуждаются в быстрых ответах, особенно в финансах и здравоохранении. Оптимизация производительности моделей также приводит к меньшему использованию GPU и, следовательно, к более низким счетам за облачные услуги. Такие методы, как использование легких архитектур, квантование и пакетная обработка, помогают повысить скорость без ущерба для точности. Представлен практический пример на Python для измерения скорости моделей в токенах в секунду. Цель примерно в сто токенов в секунду является хорошим ориентиром для взаимодействия человека в реальном времени. Шаги по оптимизации включают установку начального бенчмарка, внедрение пакетной обработки и оценку дистиллированных или квантованных моделей. Сообщество делится инструментами и библиотеками для профилирования и бенчмаркинга моделей ИИ.
ИИ-агенты распространены, но испытывают трудности с взаимодействием с реальными компьютерами. Существующие автономные агенты часто терпят неудачу, преждевременно объявляя задачи выполненными, теряя контекст в многошаговых рабочих процессах или не имея интеграции с настольной средой. HeyAgent призван решить эти проблемы, выступая в роли настоящего помощника, а не простой обертки для большой языковой модели. Этот агент с открытым исходным кодом может управлять настольными приложениями, взаимодействовать с браузерами, управлять файлами, выполнять команды терминала и подключаться к внешним службам. HeyAgent отличается тем, что планирует, выполняет, проверяет результаты и только потом подтверждает завершение задачи, чтобы уменьшить количество ложных срабатываний. Проект получил значительное ускорение и поддержку от AWS, которая предоставила критически важную облачную инфраструктуру и вычислительные ресурсы. HeyAgent построен на технологическом стеке, не зависящем от конкретной модели, с использованием TypeScript и Node.js, поддерживая как облачные, так и локальные LLM. Будучи открытым исходным кодом, он позволяет разработчикам анализировать его логику, создавать инструменты и вносить улучшения. Будущая разработка будет сосредоточена на улучшенном планировании, более надежной автоматизации рабочего стола и расширенной экосистеме плагинов. Команда приветствует отзывы, идеи, сообщения об ошибках и вклад в проект.
Плохой опыт коллеги со случайным генератором китайских имен вдохновил автора на создание более совершенного. Существующие генераторы фокусируются исключительно на звучании, игнорируя такие важные элементы, как значение, тон и культурное значение, что может привести к комичным или неуместным сочетаниям имен. Китайские традиции именования включают в себя факторы, выходящие за рамки фонетики, такие как количество черт, классификация по стихиям и историческое использование, — все это жизненно важно для того, чтобы имя было хорошо воспринято. Исследования показывают, что значительная часть людей по-прежнему учитывает нумерологию количества черт при выборе имен, что в значительной степени игнорируется современными инструментами. Проект автора ставил во главу угла точность путем создания тщательно проверенной базы данных китайских иероглифов. Каждый иероглиф прошел строгие проверки, включая перекрестную сверку со словарем Канси для определения значений
CdXz5zHNQW_UgBCzhzMEb.webp
Автоматизированный контент-пайплайн не смог обнаружить, что в описаниях видео отсутствуют кликабельные призывы к действию. Проверка системы на наличие строки домена была недостаточной, поскольку платформы, такие как YouTube, не связывают автоматически голые URL-адреса без "http://" или "https://". Это означало, что, хотя в описаниях упоминался домен предложения, зрители не могли получить к нему прямой доступ. Первоначальный аудит ошибочно сообщил о прохождении проверки, что привело к нулевым конверсиям, несмотря на наличие текста URL.Решение заключалось в обновлении аудита для конкретного поиска формата кликабельной ссылки, включая необходимую схему URL. Это было достигнуто с помощью регулярного выражения, нацеленного на "https?://". Затем было реализовано более надежное и обобщенное исправление: централизованный процесс, который автоматически преобразует любые упоминания голых доменов в реальные, кликабельные ссылки перед публикацией контента. Эта функция гарантирует сохранение существующих markdown-ссылок и полных URL-адресов.Функция преобразования ссылок использует чередование для приоритезации существующих ссылок, предотвращая случайное изменение уже функционирующих URL-адресов. Это предотвратило вторичную ошибку, когда наивный подход повреждал существующие ссылки. Основной урок заключается в том, что автоматизированные проверки на простое наличие обманчивы, когда фактическим требованием является удобство использования. Проверка, подтверждающая наличие ссылки, не то же самое, что подтверждение того, что человек может ее использовать. Если автоматизированные процессы не приносят результатов, крайне важно проверить, оценивают ли инструменты правильный, функциональный критерий.
Совет "просто поместите его за группу автомасштабирования" часто используется для масштабирования stateless-приложений, таких как веб-серверы. Он хорошо работает, потому что реплики взаимозаменяемы и могут быть добавлены или удалены с минимальным влиянием. Однако этот подход не подходит для всех рабочих нагрузок, особенно для тех, которые имеют специфические свойства, нарушающие взаимозаменяемость.Одним из таких свойств является привязка к сессии (session affinity), когда сессия связана с конкретным экземпляром и не может быть легко перенесена. Другим является медленное время запуска новых экземпляров, что делает реактивное масштабирование неэффективным, если экземпляры не готовы, когда они нужны. Для рабочих нагрузок с такими характеристиками стандартное реактивное автомасштабирование является неправильным решением.Вместо немедленной реакции, масштабирование должно использовать более медленные, основанные на трендах триггеры. Это дает новым экземплярам достаточно времени, чтобы стать полностью работоспособными, прежде чем они станут критически необходимы. Безопасное масштабирование также имеет решающее значение, поскольку простое завершение работы экземпляров может нарушить текущую работу.Отраслевые решения, такие как хуки жизненного цикла AWS, позволяют корректно завершать сессии перед остановкой экземпляра. Этот шаблон включает в себя остановку новой работы, ожидание завершения существующих сессий, а затем удаление экземпляра. Крупномасштабные системы, такие как платформы для видеоконференций, уже используют эти более сложные стратегии масштабирования.Ключевой вывод заключается в оценке взаимозаменяемости экземпляров. Если любой экземпляр может мгновенно выполнять любую задачу, автомасштабирование подходит. В противном случае необходим более медленный механизм масштабирования и правильная логика завер
Большинство домашних страниц SaaS используют статичный скриншот продукта для демонстрации своего предложения. Однако на домашней странице этого продукта вместо этого используется встроенная, функциональная книга гостей под названием "Owners Were Here". Эта книга гостей, созданная с помощью конструктора виджетов, демонстрирует невидимый бэкэнд продукта, показывая реальные, живые отправки. Книга гостей служит доказательством концепции, подчеркивая функциональность, которую скриншоты не могут передать. Основная причина такого выбора заключается в том, что формы трудно убедительно подделать в маркетинговых материалах. Встроенная книга гостей призвана обеспечить немедленное, накапливающееся социальное доказательство через вклад пользователей. Этот подход использует эстетику "стены для граффити", которая заполняется органически. При раскрытии публичной конечной точки крайне важны надежные меры безопасности. К ним относятся обнаружение ботов с помощью Cloudflare Turnstile, ограничение скорости, проверка схемы и ограничение размера для предотвращения эксплуатации. Рендеринг недоверенного пользовательского ввода требует осторожного обращения, чтобы избежать уязвимостей безопасности, таких как межсайтовый скриптинг. Правильная очистка текста с использованием textContent вместо innerHTML необходима для безопасного отображения пользовательского контента. Растущая книга гостей может негативно сказаться на макете домашней страницы и времени загрузки. Реализация области просмотра с максимальной высотой и внутренним скроллингом предотвращает перегрузку страницы книгой гостей. Хотя некоторые нежелательные записи ожидаются, основные безопасность и функциональность встроенного виджета защищены этими дизайнерскими решениями.
Автор объясняет образ мышления хакера, который коренится в установке на рост и прикладном любопытстве. Вместо типичного взаимодействия с пользователем, хакеры исследуют, что происходит при выполнении случайных действий, подобно изучению недокументированной машины. Это включает в себя вопрос "что произойдет, если я сделаю это", а не просто следование намеченным процедурам. Ранний опыт, такой как многократное получение root-доступа к телефону, несмотря на его поломку, иллюстрирует приоритет любопытства над безопасностью. Неудача рассматривается не как конец, а как возможность для обучения, которая улучшает будущие попытки. Инстинкт исследования становится более значимым, когда он сочетается с настойчивостью, а не прекращается после получения объяснения. Чтобы эффективно внедрять инновации, необходимо сначала понять существующие правила и основы, прежде чем пытаться от них отклониться. Рекомендуется тестирование в контролируемых средах, а не повторение рискованных детских экспериментов. Важным, часто упускаемым из виду аспектом является комфорт с неопределенностью и настойчивость в преодолении запутанных, неясных этапов исследования. Эта стойкость, терпимость к "скучной, запутанной середине", отличает тех, кто делает новые открытия, от тех, кто сдается. В конечном итоге, образ мышления хакера — это линза для изучения систем, поиска расхождений между предполагаемой функцией и фактическим поведением, что может выявить ошибки безопасности или интересные особенности.
Счета за AWS NAT Gateway включают два основных платежа: небольшую почасовую плату и плату за обработку данных. Плата за обработку данных, составляющая 0,045 доллара за гигабайт, является основным фактором затрат и увеличивается с ростом трафика. Для снижения этих затрат можно использовать несколько стратегий, начиная с наиболее эффективных.Во-первых, внедрите бесплатные шлюзовые конечные точки для S3 и DynamoDB, так как это часто устраняет 30-60% платежей за гигабайт. Далее, рассмотрите интерфейсные конечные точки для часто используемых сервисов AWS. VPC Flow Logs имеют решающее значение для выявления источников с высоким трафиком, а исправления часто включают кэширование и улучшение управления.Чтобы избежать дополнительных сборов за межзонную доступность, направляйте трафик зонально или целенаправленно консолидируйте шлюзы. Консолидация NAT-шлюзов для непроизводственных сред может сэкономить на почасовой оплате неиспользуемых ресурсов. Для дальнейшей экономии NAT-инстанс, такой как fck-nat, может полностью исключить плату за гигабайт, хотя и требует управления операциями.Сетевое виртуальное устройство (NVA) с фиксированной ценой и фильтрацией исходящего трафика предлагает управляемую замену NAT Gateway, устраняя плату за гигабайт и действуя как брандмауэр. Выбор между этими решениями зависит от объема трафика и операционных возможностей. Плата за обработку данных за гигабайт, как правило, является наиболее значительной статьей расходов, которую следует устранить, а не почасовая плата.
Автор обсуждает растущее использование ИИ на платформе dev.to и его последствия. Распространенное мнение заключается в том, что качество контента важнее использования ИИ, но автор задается вопросом, как определить "хороший" контент в этом контексте. ИИ может легко генерировать полезный и содержательный материал, что затрудняет распознавание подлинного понимания. Автор проводит параллель с разработчиками, использующими ИИ для проектов, отмечая, что, хотя на бумаге это впечатляет, они часто испытывают трудности с объяснением своей работы в реальном времени. Это выявляет потенциальный недостаток чрезмерной зависимости от ИИ, препятствующий истинному обучению и развитию навыков. Автор выражает личную обеспокоенность по поводу чрезмерной зависимости от ИИ, опасаясь, что это ставит под угрозу их способность учиться и уверенно объяснять свою работу. Истинный опыт, по их мнению, приходит от понимания и способности формулировать свои творения. Автор предполагает, что цель таких платформ, как dev.to, заключается в содействии подлинному обучению и обмену, а не в представлении контента, сгенерированного ИИ, как личного опыта. Они предлагают две ключевые рекомендации по конструктивному использованию ИИ: задавать расширяющие вопросы вместо простого пересказа информации и использовать ИИ как вспомогательный инструмент, который помогает обучению, а не заменяет его. Такой сбалансированный подход обеспечивает личный рост и способствует осмысленному взаимодействию в сообществе. Основная тема — обучение на практике и избегание чрезмерной зависимости от ИИ. В конечном счете, хороший контент на dev.to должен способствовать взаимному обучению между авторами и читателями, независимо от темы.
CdXz5zHNQW_x1mHmRWPT1.webp
Gemini Spark — это круглосуточный автономный ИИ-агент от Google, предназначенный для автоматизации сложных рабочих процессов в Google Workspace. Хотя он предлагает надежные нативные интеграции с такими приложениями, как Gmail, Drive и Docs, подключение к внешним API требует дополнительной настройки. Google Apps Script (GAS) служит важным мостом, позволяя предприятиям значительно расширить возможности Gemini Spark. Развертывая GAS в качестве сервера протокола контекста модели (MCP) или конечной точки веб-перехватчика, пользователи могут предоставить Gemini Spark доступ к специализированным API и пользовательской бизнес-логике.В статье представлены пять показательных запросов, демонстрирующих нативные функции Gemini Spark. К ним относятся автономное создание электронных таблиц с динамическими формулами, интеллектуальный поиск файлов в Google Drive и оркестровка междоменных рабочих процессов, таких как веб-скрейпинг для генерации документов. Также подчеркивается способность Gemini Spark автономно настраивать фоновые прослушиватели событий для таких задач, как обработка входящих электронных писем. Однако тестовый запрос, включающий прямой доступ к API данных Google Analytics, выявил текущее ограничение в нативной связности со специализированными API Google.Для преодоления этих нативных ограничений в статье подробно описывается интеграция Gemini Spark с Google Apps Script через пользовательские серверы MCP и триггеры веб-перехватчиков. Объясняется, как развернуть веб-приложение GAS в качестве сервера MCP, используя библиотеки GASADK и GoogleApiApp для облегчения связи JSON-RPC. Эта интеграция позволяет Gemini Spark безопасно взаимодействовать с такими API, как Google Analytics 4, пользовательские базы данных и другая сложная бизнес-логика. Используя GAS в качестве промежуточного сервера MCP, разработчики могут инкапсулировать безопасную аутентификацию и логику извлечения данных. Конечная цель состоит в том, чтобы позволить Gemini Spark выполнять автоматизацию рабочих процессов корпоративного уровня, получая доступ к более широкому спектру источников данных и сервисов.
CdXz5zHNQW_EaBgJiSslu.webp
LINE MINI Apps не требуют автоматической верификации, но определенные функции требуют ее для публикации. Если верификация необходима, LINE тщательно проверяет соответствие личности, соблюдение правил, конфигурацию канала и пользовательские сценарии. Чтобы избежать задержек, крайне важно тщательно проверить заявку перед запросом на рассмотрение. Ключевые функции, требующие верификации, включают производственные служебные сообщения, пользовательские пути, ярлыки на главном экране, быстрое заполнение общего профиля и проверенные значки.Перед подачей заявки согласуйте организационную идентичность в LINE Developers Console, информацию о канале, политику конфиденциальности и описание канала. Убедитесь, что название компании одинаково во всех этих местах и на всех языках. Четко опишите рабочий процесс MINI App, определив основного пользователя, основные функции и ожидаемые результаты. Убедитесь, что канал для рассмотрения точно отражает функции, переходы, данные, аутентификацию и состояния ошибок опубликованного канала.Подготовьте исчерпывающие сценарии тестирования для платежей, бронирований и заказов, включая регистрацию, успешные и неудачные транзакции, а также управление данными. Тщательно проверьте страницы конфиденциальности и условий на предмет общедоступности, единообразия названий компании и сервиса, а также точности контактной информации. Убедитесь, что бизнес-категория и контент MINI App соответствуют правилам LINE, избегая запрещенных категорий и контента.Запрашивайте только необходимые области API и документируйте их использование. Служебные сообщения требуют отдельного процесса утверждения и предназначены исключительно для подтверждений или ответов на действия пользователя, а не для продвижения. После верификации многие настройки становятся чувствительными к повторному рассмотрению, поэтому перед первоначальной подачей заявки зафиксируйте критические конфигурации, такие как идентификатор канала, юридические URL-адреса и области действия. Планируйте сроки верификации, которые обычно занимают от одной до двух недель, и заложите буфер для возможных повторных рассмотрений. Наконец, помните, что верификация MINI App отличается от обработки входящих сообщений клиентов.