Команда AI for Devs подготовила перевод статьи о новом API /v1/responses от OpenAI, который объединяет простоту Chat Completions и мощь Assistants, и при этом сохраняет состояние рассуждений, мультимодальность и встроенные инструменты. Это шаг к агентам будущего — и, похоже, к новому стандарту работы с моделями OpenAI.
Покопаемся в исходниках Retrofit, чтобы открыть завесу тайны, как же он всё-таки работает с корутинами и почему я не ловлю краш, даже когда при вызове метода из Service не переключаю диспатчер на Dispatchers.IO.
Команда Go for Devs подготовила перевод статьи о том, почему спустя десять лет автор по-прежнему критикует Go. Ошибки на миллиард долларов, загадочный nil, проблемы с памятью и «магия» defer — по мнению автора, всё это делает язык излишне сложным и болезненным. А стоит ли оно того?
Привет, Хабр!
В проде полно таблиц и маппингов, которые создаются один раз и потом живут годами на чистом чтении. Раньше выбирали между ReadOnlyDictionary и Immutable*. Первый не ускоряет доступ и просто прикрывает исходную коллекцию, второй дает чистые апдейты, но платит временем построения и lookup. В .NET 8 появился третий путь для такого профиля: System.Collections.Frozen.
Задача у Frozen простая и приземленная. Заплатить за построение структуры один раз на старте, а дальше получать быстрый TryGetValue/Contains и предсказуемое перечисление без блокировок. Контейнер неизменяемый, потокобезопасен для чтения и специально заточен под lookup. Стоимость сборки выше обычной, это ожидаемо, поэтому применять его есть смысл там, где чтений на порядки больше, чем конструирований.
С .NET 9 стало еще удобнее: появился alternate lookup. Теперь словарь со строковыми ключами может принимать ReadOnlySpan<char> прямо на lookup, без лишних аллокаций. Это хорошо заходит в веб-пути, парсеры заголовков и любые сценарии, где строка у вас уже как span.
Команда Python for Devs подготовила перевод статьи о скрытых издержках использования старых версий Python. TL;DR: 83% разработчиков застряли на Python 3.10–3.11, и это обходится компаниям в миллионы долларов ежегодно из-за лишних "облачных" затрат. А ведь казалось бы, обновиться — проще простого.
Недавно на работе передо мной возникла задача максимально быстро погрузиться в автоматизированное тестирование с ранее мной не использовавшимся фреймворком pytest. Почитав порядка десяти статей на Хабре я понял, что в каждой из статей есть много всего интересного, а чтобы системно погрузиться - необходимо идти читать документацию. Я решил, в привычной мне манере, разобраться и систематизировать самый сок для того, чтобы быстро въехать в суть и важные тонкости положив основу для дальнейшего использования.
Всем интересующимся - добро пожаловать под кат!
Разработка на Laravel становится максимально эффективной, если использовать автоматизацию на каждом этапе: от настройки окружения до проверки кода и тестирования. В этой статье я покажу, как построить процесс разработки, который снижает количество ручной работы, повышает качество кода и ускоряет выпуск функционала.
Материал рассчитан на разработчиков с опытом работы с Laravel, которые хотят внедрить автоматические проверки, статический анализ, единый стиль кода и готовую сборку Docker Compose для быстрого старта проектов. Я поделюсь своим опытом, конкретными инструментами и практическими примерами.
Да, это очередная статья по чистому коду. Но по разным источникам, соотношение времени, затрачиваемого на чтение и написание кода, может достигать 7 к 1 и даже больше. Когда вы исправляете ошибку, добавляете новую функциональность или проводите рефакторинг, вы сначала погружаетесь в логику, написанную другими людьми (или вами же, но несколько месяцев назад). Именно поэтому читаемость кода становится более важным фактором, чем скорость его первоначального написания. Нечитаемый код - это технический долг, который замедляет всю команду и увеличивает стоимость разработки в долгосрочной перспективе.
Привет, Хабровчане!
Это продолжение моего дневника разработки DIY струйного принтера. Предыдущие части:
DIY Open Source принтер. Часть 0
DIY Open Source принтер. Часть 1. Покоряем USB Printer Class и имитируем печать текста
В прошлый я рассказывал как наладить интерфейс между ПК и STM32 таким образом чтобы ПК понимал что мы подключили к нему принтер, а не неизвестное устройство. В этой статье я предлагаю разобраться с тем как работает печатающая голова в картридже HP123, каким образом сформировать управляющие сигналы для неё и как удержаться в рамках субмикросекундных таймингов.
Основным источником информации для меня выступают:
- статья на Hackaday и проект PrintSpider_Arduino от нашего товарища по Хабру @lichnost
- cтатья Magic Printer Cartridge Paintbrush и проект printercart_simple от Spritetm
Речь пойдёт только об отработке логики! Подключение железа пока невозможно - затронем в следующий раз - я работаю в этом направлении.
Содержание
§1. Базовая информация про HP123
§2. Добиваемся нужных таймингов на GPIO
§3. Формирование задания для HP123
§4. Работа над ошибками. Отладка проблемы при формировании задания
§5. Диаграммы здоровых управляющих сигналов
FHIR (Fast Healthcare Interoperability Resources) - это стандарт обмена медицинскими данными, разработанный HL7. Сегодня он является основой для взаимодействия между EHR-системами, мобильными приложениями и медицинскими сервисами. Последние актуальные версии стандарта - R4 (2019) и R5 (2023).
Если очень коротко: FHIR описывает ресурсы (Patient, Observation, Encounter, MedicationRequest и т. д.), которые доступны через REST API в JSON или XML. Поверх этого можно строить и пациентские приложения, и интеграции между медицинскими организациями.
На этой базе появились так называемые patient-facing API - интерфейсы, через которые сам пациент или доверенные приложения могут получить доступ к медицинским данным: диагнозам, назначениям, результатам лабораторных анализов, изображениям, выпискам. Для США эту модель дополнительно закрепили регуляторы (ONC Cures Act), а для разработчиков удобные инструменты предлагает инициатива SMART on FHIR (OAuth2, scopes вида patient/*.read, PKCE и рефреш-токены).
Однако реальность заметно сложнее, чем стандарты на бумаге. Даже если два провайдера «поддерживают FHIR R4», API у них могут радикально отличаться:
В новом переводе от команды Spring АйО команда Spring делает важное объявление — RestTemplate уходит в прошлое. С выходом Spring Framework 7.0 разработчики официально заявляют о плане поэтапного прекращения поддержки одного из самых популярных HTTP-клиентов в экосистеме. Его место занимает RestClient, современный fluent-клиент с расширенными возможностями: API-версионирование, гибкая конфигурация конвертеров, группы HTTP-интерфейсов и новый тестовый клиент RestTestClient.
Кроме того, в Spring Boot 4.0 появятся отдельные стартеры для каждого типа клиента, а RestClient теперь можно удобно переиспользовать с уже существующей инфраструктурой RestTemplate.
Привет, Хабр! Уже давненько вокруг ходит тема про io_uring — новую высокопроизводительную модель асинхронного I/O в Linux. В теории это обещает минимальные системные вызовы и очереди отправки/завершения, но как это в деле работает с привычными утилитами? Я решил разобраться на примере типичной задачи – копирования файлов (и немного упомянем хеширование) – переписав её под liburing и сравнив с традиционной синхронной версией.
Мы все сталкивались с этим: открываешь репозиторий, а там код, который вроде бы работает, но при ближайшем рассмотрении вызывает лёгкую дрожь в руках. В этой статье я хочу поговорить о том, как «студенческий» код, написанный в спешке или ради эксперимента, неожиданно становится частью продакшн-систем. Разберём примеры, посмотрим, как такие артефакты выживают, какие последствия это несёт, и что с этим можно сделать, чтобы не жить на пороховой бочке.
Когда у вас нет гарантированного интернета, привычные подходы «подключился к облаку и забыл» перестают работать. В этой статье я попробую показать, как проектировать автономные системы для работы на краю сети: от железа и протоколов до стратегий хранения данных и синхронизации. Будет много практики, примеров кода и немного личных наблюдений.
Я раньше работал обычным безопасником. Кто-то называет таких «ИБшниками», кто-то — «параноиками», кто-то — «тем самым занудой, который мешает жить».
Каждый день у меня был один и тот же диалог:
• Тимлид: «У нас релиз в пятницу, отстань со своим сканированием».
• Менеджер: «В бюджете только Jira и пицца, какие ещё 15 миллионов за софт?»
• Разработчик: «Код сгенерил AI, билд прошёл, значит, всё норм».
История о создании Telegram Miniapp с нуля: боль, костыли и необычные решения.
- Как превратить обычный сайт в миниапп малыми усилиями
- Как передавать данные в миниапп чтобы ничего не сломалось.
- Как реализовать версионирование в миниапп
Привет, хабр! Меня зовут Егор, я бэкенд разработчик в команде ЦФА в Альфа-Банке.
Сейчас мы рассматриваем возможность внедрения фича-тоглов в наш проект и проводим исследование уже существующих решений. В рамках него мне удалось глубоко познакомиться с Unleash — самой популярной платформой для фича-тоглов на данный момент.
В статье пробежимся по основным понятиям и сущностям в Unleash, разберем примеры кода на Java и также с помощью метрик проверим, работает ли это на самом деле.
В конце будет ссылка на демо-проект, в котором можно одной командой поднять все окружение и поэкспериментировать с настройками Unleash.
Здравствуйте!
В большинстве своём мы не думаем о том, как Go размещает поля структуры в памяти. И правильно делаем, пока наши структуры не используются в миллионах экземпляров, не передаются в каналах или не сериализуются каждую миллисекунду.
Также неправильное выравнивание может негативно сказаться на кеш-памяти процессора и скорости доступа к данным. На 32-битных платформах некорректное выравнивание 64-битных атомарных переменных (например, int64 для sync/atomic) вообще способно привести к панике.
В этой статье разберём выравнивание структур в Go, посмотрим на примерах влияние порядка полей и подумаем над тем, когда такие оптимизации действительно нужны.
Мы давно работаем на рынке BI и, как любой зрелый продукт, регулярно сравниваем себя с другими системами, которых с каждым годом появляется всё больше и больше — каждая со своими сильными и слабыми сторонами. И мы решили задать себе простой, но важный вопрос: а чем мы в Luxms BI действительно гордимся? Что нравится не только нам, как разработчикам, но и экспертам, которые делают на нашей платформе десятки проектов? Какие особенности мы сами считаем важными и удобными?
Так появилась эта серия: 23 фичи Luxms BI, которыми мы гордимся. Это не список «всё, что у нас есть», и не подборка базовых возможностей, которые сегодня есть почти в каждом BI-инструменте. Мы собрали то, что нас самих вдохновляет, и то, что мы чаще всего видим в успешных проектах наших клиентов.
Для удобства мы разделили эти фичи на четыре тематических блока. Начнём с первого блока — архитектура и платформенность, с того, на чём держится всё остальное. В этой статье мы расскажем, как устроена платформа Luxms BI, почему мы сделали ставку на датацентричную модель, как устроена быстрая кастомизация интерфейсов, что такое BI-Magic-Resources, и зачем внутри BI-платформы observable-сервисы.
Привет, Хабр! Я работаю фронтенд-разработчиком в ЛАНИТ. В этой статье я поделюсь опытом изменения подхода к интернационализации и опытом внедрения автоматизированной проверки переводов, что позволяет снизить риски появления багов и ускорить релизы приложения.
