Программирование *

В мире микросервисов десятки, а то и сотни сервисов живут своей жизнью. Каждый со своим адресом, своими правилами, своей аутентификацией. Для внешнего клиента это выглядит как город без улиц и указателей. API Gateway — это попытка навести порядок. Он становится единым фасадом, центральным КПП для всего вашего бэкенда.

Но эта простота обманчива. Внедрение шлюза порождает свой собственный набор сложных архитектурных проблем. Решить их неправильно — значит построить себе очень дорогую и хрупкую тюрьму.

Лежу я тут недавно, в 5 утра, а сам понимаю, что вставать-то мне в 9. А сплю я ну очень крепко. И в целом мне сложно проснуться. 

И я осознаю, что нужна тяжёлая артиллерия! Что-то из давно себя зарекомендовавшего. А единственное, что меня стабильно хорошо будило - это AIMP на ноуте, который запускал мой плейлист на полную катушку в заданное время. А теперь у меня Macbook, а вместо скачанного архива музыки - Яндекс Музыка. 

Решение, казалось бы, найдено. Открой приложение, да настрой запуск по таймеру, да? А вот как бы не так! В ЯМузыке такой фичи нет, крутитесь как хотите. 

Настроить что-то такое через Календарь и другие штатные приложения мне не удалось. 

Потраченные в пустую пол часа моего драгоценного сна! Чёрт! Надо решать как это сделать, это уже дело принципа!

^{-Что же, что мы умеем?}

^{-Мы умеем писать автотесты на Java!}

^{-Как нам это тут может помочь?}

^{-Ну хз...} 

Ага! Фреймворк Robot. Вроде штатная Java либа. Давайте раскручивать с чем умеем работать. Вооружаемся гуглом и Perplexity. Ещё пол часика умствований и у нас уже запускается приложение Яндекс Музыка.

Теперь остался вопрос, а как заставить его запускаться в нужное время и включать воспроизведение музыки?

Ну с запуском по времени не сложно Calendar и Timer. А вот как запустить воспроизведение вообще не тривиально. Клик на пробел - не работает, на enter - не работает. После прокликивания всех кнопок вычисляем, что запускается по клику на "K". Ну всё, теперь-то вообще нет проблем, да? Робот кликнет на любую кнопку - только скажи, что тыкнуть. Дописываем, компилим, запускаем - хрен там плавал а вот вы и не угадали, не работает! Клик по кнопке происходит не в последнем открытом окне, а на рабочем столе.

Привет! Нет, вы не ошиблись — это действительно историческая статья. Но не о Риме, а о статическом анализе кода. Хотя... чем он хуже? У него тоже есть свои императоры-родоначальники, войны с багами и даже падения (пожалуйста, не запускайте анализ на некомпилируемом коде).

Я долго не понимал, почему «Размышление о Римской империи» стали одним из самых популярных мемов прошлого года, пока сам не начал ловить себя на навязчивых мыслях о статическом анализе. Разобравшись в его истории, я решил поделиться с вами этим исследованием. 

Меня зовут Владислав Столяров, я руководитель команды анализа безопасности продуктов в мультипродуктовой экосистеме МойОфис. Кстати, идея статического анализа напрямую связана с компиляторами (разбор кода, как никак). Поэтому уместно вспомнить, что недавно мы открыли исходный код собственного компилятора tsnative, позволяющего использовать в одном приложении сразу два языка — TypeScript и C++. Скачать и поисследовать можно по ссылке (лицензия Apache 2.0).

А теперь вернёмся к истории статического анализа. Пойдём по порядку и и попробуем восстановить хронологию его становления...

Продолжаем изучать использование PVS-Studio для бесплатных (и не только) проектов. В этой статье мы разберём основные настройки анализатора и их важность, а также с чего стоит начать знакомство при первом запуске анализа на новом проекте.

Занимаясь проектированием систем ПО, идите самым простым путём из возможных.

Причём эту рекомендацию можно применять на удивление широко. Я искренне верю, что так можно делать всегда. Эта техника подходит для исправления багов, обслуживания имеющихся систем и проектирования новых.

Многие инженеры, продумывая дизайн системы, представляют себе некий её «идеал»: что-то стройное, практически бесконечно масштабируемое, удобно распространяемое и так далее. Я же считаю, что это абсолютно ошибочный подход к проектированию ПО. Напротив, нужно вложить всё это время в глубокий анализ имеющейся системы, а затем реализовать простейшее рабочее решение.

Команда JavaScript for Devs подготовила перевод статьи о том, сколько трафика реально выдерживает сайт на Next.js. Автор провёл нагрузочные тесты, сравнил VPS и выделенный сервер, проверил разницу между предрендерингом и SSR и сделал вывод: для сайтов с потенциальными всплесками трафика предрендеринг — спасение, а SSR может стать бутылочным горлышком.

Привет, Хабр! На связи Олег Сивченко @OlegSivchenko редактор направления «Компьютерная литература».

Наша первая статья в корпоративном блоге вызвала ваш огромный интерес (+122) и оживлённое обсуждение с участием 30 пользователей (считая нас). На наш взгляд, вас заинтересовал вопрос авторских черновиков и доработки их до полноценных рукописей. Развивая тему, связанную со свободным ПО, хочу рассказать вам сразу о трёх наших знаковых книгах, посвящённых операционной системе Linux. Эти книги написал легендарный харьковский программист Олег Иванович Цилюрик (1951 — 2024), к сожалению, не дождавшийся выхода в свет 2-го издания своей книги «Linux и Go. Эффективное низкоуровневое программирование» (оглавление).  Opus Magnum, принадлежащий его перу и вышедший у нас в марте 2023 года, называется «Расширения ядра Linux. Драйверы и модули» (оглавление). Кроме того, мы выпустили экзотический и по-своему незаменимый труд Олега Ивановича, который называется «Сети Linux. Модели и приложения» (оглавление), посвящённый настройке, эксплуатации и внутренней организации оверлейной сети Yggdrasil (октябрь 2023).  Эта книга очень хорошо вписалась по духу и уровню в разрабатываемую нишу кибербезопасности, и, судя по отзывам на маркетплейсах, незаменима в нашу эпоху не столь свободного Интернета. Наконец, Олег Иванович самоотверженно справился с переводом одной книги O’Reilly —«Изучаем eBPF: программирование ядра Linux для улучшения безопасности, сетевых функций и наблюдаемости», вышедшей у нас в июле 2024 года. Давайте расскажу о двух из этих книг немного подробнее.

В 90-х и 2000-х студия Impressions Games выпускала отличные исторические градостроительные симуляторы. Я играл во все игры этой серии от незабываемого Caesar 3, который вообще был первой моей компьютерной игрой на отцовском компуктере, до Императора про древний Китай. Но египетский Pharaoh и греческий Zeus запомнились намного четче, но вот почему я сказать не берусь.

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

Команда Go for Devs подготовила перевод статьи о том, как кэширование помогает ускорить API на Go и снизить нагрузку на базу данных. В статье разбираются основные стратегии кэширования — от Write-Through до Write-Back — и показан пример реализации кэша с TTL на чистом Go. Отличный материал, если хотите ускорить свой сервис без перехода на Redis.

Привет, Хабр!

С вами снова Дмитрий. В первой части мы с головой окунулись в философию Headless CMS и разобрали, почему Strapi стал глотком свежего воздуха для разработчиков, уставших от рамок монолитных систем. Мы увидели, как контент освобождается от шаблонов, получая возможность жить на любых платформах и устройствах.

Но мощный и гибкий бэкенд - только половина уравнения. Без современного, умного и производительного фронтенда вся эта свобода рискует остаться просто красивой теорией. Где же тот самый «идеальный фронтенд», который раскроет потенциал Headless на все 100%?

Команда Python for Devs подготовила перевод статьи о том, почему Python так медленный и что сообщество делает, чтобы это исправить. PyCon 2024 показал: Python ждут субинтерпретаторы, immortal objects, JIT-компиляция и другие технологии, которые могут ускорить его в разы.

В прошлых статьях цикла, а именно

Часть 1, вводная

Часть 2. Более сложные приемы анализа

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

Языковые модели — это не магия, а мощный инструмент, который может ускорить работу программистов, аналитиков, маркетологов и менеджеров. В статье — разбор принципов работы LLM, ключевых проблем (галлюцинации, ограниченный контекст) и практик промпт-инженерии с примерами, которые помогают превратить ИИ в надежного помощника.

Привет, Хабровчане!

Это продолжение моего дневника разработки DIY струйного принтера предыдущая часть:

DIY Open Source принтер. Часть 0

В прошлый раз одной из поднятых проблем стал интерфейс между ПК и устройством. В данной статье я постараюсь решить вопрос подключения STM32 по USB и убедить Windows и Linux что это принтер.

Содержание

§1. Кратко о USB
§2. Поиск реализаций USB Printer Class для STM32
§3. Реализация USB Printer Class для STM32
§4. Тест на Windows
§5. Тест на Linux
§6. Как добавить поддержку печати изображений?

Привет, меня зовут Сергей Киселев, я управляю командой Development Platform в MWS Cloud Platform, а ещё давно провожу собеседования разработчиков и собираю команды. Умею делать алгоритмические секции без негатива от кандидатов, сам иногда собираю оферы, учу сына писать на C++. В этой статье расскажу, как мы построили процесс интервью для разработчика в MWS Cloud Platform. И почему важно на собеседовании проверять практические навыки.

Shenandoah — это высокопроизводительный сборщик мусора с низкими задержками, разработанный компанией Red Hat и впервые внедрённый в OpenJDK. Он был создан с целью минимизировать задержки на протяжении работы приложения, что особенно важно для приложений с высокими требованиями к производительности и отзывчивости. В новом переводе от команды Spring АйО рассмотрим основные особенности Shenandoah, его работу, настройку и примеры использования.

Контекстуальное Примечание для Читателя:

Добро пожаловать в уникальное исследование архитектуры программного обеспечения. Проект Hive Chat построен на философии, которая рассматривает программное обеспечение не просто как инструмент, а как «Живое Приложение» — автономный, развивающийся цифровой организм. Чтобы выразить это видение, мы намеренно используем богатое, биоинспирированное и философское повествование.

// p-e: echo

Привет, Хабр! Меня зовут Алексей Николаевский, и мы с командой делаем СУБД Яндекса. С 2013 года в Яндексе использовали Kafka для потоковой передачи данных. Но Kafka со временем перестала справляться с растущими объёмами, и в 2017 году мы перешли на своё решение.

Брокер сообщений YDB Topics во многом вдохновлялся Kafka: в нём также есть топики, партиции и аналогичные способы работы с данными. Но есть и существенные отличия, о которых в конце прошлого года я рассказал на московской конференции HighLoad. Под катом — адаптированная для Хабра статья по мотивам этого доклада: про архитектуру транзакций в обеих системах и интересные для разработчиков детали и нюансы, которые мы обсуждали на конференции.

Привет, Хабр!

Есть такой интересный компонент в Vue.js и называется он<Suspense>. Он устроен так, чтобы собирать зависимые async-компоненты и показывать единый индикатор загрузки вместо кучи спиннеров. Проще говоря, пока внутренняя часть (слот #default) ещё не готова из-за ожидания данных, показывается запасное содержимое из слота #fallback. Как только все асинхронные зависимости разрешатся – снимаем запасной экран и выводим основное содержимое. По сути, <Suspense> создаёт границу вокруг вложенных компонентов и контролирует их загрузку.

Команда AI for Devs перевела статью, в которой автор делится прогнозами о будущем ИИ-агентов в 2025 году. Его выводы: несмотря на шумиху, «автономные агенты» столкнутся с экономическими и техническими барьерами. Почему текущий подход к архитектуре агентов не сработает и какие методы действительно приносят результат — читайте в статье.