Бэкенд

Носителям прекрасного языка программирования C++ тема частичного применения может показаться скучной. Что примечательного в пяти строчках кода? Но дьявол кроется в деталях: я часто встречал реализации, которые работали не так, как ожидали их авторы. Иногда дело доходило до undefined behavior. Поэтому здесь хочется разобраться прежде всего с владением, временем жизни и категориями значений.

Приложение на Tauri 2 проходит все тесты на Ubuntu, а на ALT Linux теряет HTTPS сразу после проверки обновлений. Разбираю, почему так происходит, как это воспроизвести и как исправить одной функцией в своём коде.

Мой язык программирования HydraScript, написанный на C#, уже умел выполнять такой код:

let x = 10 x = x + 1 >>> x

Получаем 11; >>> — это оператор вывода. Присваивание работает, сложение работает. Захотелось добавить привычное сокращение:

let x = 10 x += 1 >>> x

Результат должен остаться тем же — 11. Зачем учить весь компилятор ещё одной операции, если всё необходимое у него уже есть? Можно прямо в парсере превратить x += 1 в дерево для x = x + 1.

Эта часть уместилась в несколько строк. Основная работа досталась методу Clone().

Не война двух языков (хоть и бывает), не разные идиомы и взгляды на реализацию делают инструмент “плохим”, а по классике - забивание гвоздей молотком и карго-культ

Всем привет! Меня зовут Антон Рыков и я backend-разработчик в компании "Исходный Код".

Пять CRUD-эндпоинтов. К обеду я понял: бизнес-логика заняла минут двадцать. Остальные два часа ушли на UUID вместо автоинкремента, одинаковые DTO с валидацией и ручную уборку временных файлов на стейджинге. Пальцы работали. Голова — нет.

Почти любая команда на Symfony рано или поздно упирается в ту же стену: фреймворк перестаёт быть помощником и превращается в конвейер. make:entity → вырезать integer id → прикрутить трейт дат → руками разобрать $request в контроллере. Снова. И снова.

DX — это не красивая тема в терминале. Это меньше трения между архитектурным решением и кодом. Правильная лень — точечная автоматизация того, что вы и так делаете каждый день.

В статье — четыре уровня, которые убрали это трение у меня. Настроите PhpStorm так, чтобы скелет JSON-экшена появлялся по Tab. Уберёте ручной json_decode и isset через MapRequestPayload и строгие DTO. Научите MakerBundle сразу генерировать сущности с UUID и вашими трейтами. Перенесёте cron в PHP через Scheduler - расписание

As we say, two of the most complicated problems in software are naming things and versioning software

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

Всем привет! Меня зовут Михаил Поливаха, я являюсь техническим лидером Open Source проекта Axelix.

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

Покажу, как можно ускорить код h11 (HTTP/1.1 библиотечка со 710k пользователями на Github) с помощью компиляции с mypyc примерно в два раза. В процессе расскажу, как я чинил разные интересные ошибки, связанные c адаптацией кодовой базы под mypyc.

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

В статье расскажу, почему мы не стали просто оптимизировать старую систему, как построили новый контур на ClickHouse и XLTable и что произошло после перехода.

Большинству людей известны бренды Visa и Mastercard. Есть вероятность, что вы ежедневно пользуетесь их картами для транзакций. Кто-то знает, что большинство магазинов (в США) принимает оба типа, но некоторые принимают только Visa (например, Costco) и наоборот.

Так чем же они занимаются? Visa попыталась ответить на этот вопрос.

• Вот, чем она не занимается:

• Компания не выпускает карты.Этим занимаются эмитенты карт.

• Она — не банк, хотя карты зачастую эмитированы банком.

• Они не продают кассовые терминалы и системы онлайн-оплаты, этим занимаются платёжные операторы.

• Она не отвечает за подключение или оценку рисков магазинов и предпринимателей: этот процесс называется торговым эквайрингом, и им занимаются банки, предоставляющие услуги торговых счетов, а также всё чаще современные платёжные операторы (Stripe, Square, Adyen)².

• Она не производит и не печатает карты.

• Как и не производит она кассовое оборудование.

Visa и Mastercard — это карточные платёжные сети, которые обеспечивают проведение карточных транзакций, связывая держателей карт и эмитентов с торговыми организациями (мерчантами) и эквайерами.

Больше года назад я запустил SVG4 — каталог векторных иконок. Сейчас в нём больше 500 000 SVG‑файлов.

Первая версия была написана на Laravel. На тот момент выбор был простой: Laravel я хорошо знал, на нём можно было быстро собрать рабочий проект и проверить, нужен ли он вообще кому‑нибудь.

Проект вырос. Вместе с ним выросли база, количество страниц, поисковый трафик и нагрузка. Старая версия работала на сервере с 4 ядрами и 6 ГБ оперативной памяти. После переписывания на Go весь проект работает на 2 ядрах и 2 ГБ RAM.

При этом я не ставил задачу доказать, что Go быстрее PHP. За время переписывания изменилась не только технология, но и сама архитектура приложения. Именно об этом переходе и хочу рассказать.

Классические базы данных в современных высоконагруженных сценариях быстро упираются в потолок: когда от одной системы требуются миллионы транзакций в секунду и тяжелые аналитические срезы по всей истории событий, традиционный стек просто не вывозит. Поэтому компании всё чаще переходят на in-memory HTAP-системы, которые объединяют OLTP- и OLAP-нагрузки под капотом и дают нужную скорость за счет того, что держат горячие данные в оперативной памяти (RAM).

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

Меня зовут Екатерина Силецкая. Я старший менеджер продукта Tarantool Column Store (TCS) — in-memory HTAP СУБД от VK Tech для транзакций и аналитики в реальном времени. В статье расскажу на примере Tarantool Column Store, как работает механизм охлаждения в HTAP-системах и в каких сценариях может быть полезен. 

У нас начали активно появляться кластеры на Talos Linux, в том числе и небольшая песочница для тестирования продуктов, о которой пойдёт речь далее. Доступы раздавались через обмен рутовыми kubeconfig'ами в yopass. Быстро, привычно и, к сожалению, абсолютно неуправляемо.

Проблема даже не в самом факте передачи файла. Проблема в том, что лежит внутри: клиентский сертификат, который выписан на год, работает всегда и отовсюду, не привязан ни к какому конкретному человеку и не отзывается ничем, кроме ротации CA всего кластера. Сотрудник уходит из компании — его kubeconfig продолжает работать. Ноутбук потеряли — конфиг продолжает работать. Кто-то выполнил kubectl delete не в том кластере — найти его не удастся. Blameless culture в чистом виде.

Хотелось получить другое поведение:

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

Все шесть случаев ниже объединяет одно свойство. Код не упал. Он отработал, записал результат в базу, и всё выглядело правильным ровно до того момента, пока я не полез проверять руками.

Один интерфейс LLMProvider быстро перестаёт быть достаточным, когда в SaaS появляются разные модели, требования к приватности, fallback, стоимость и observability. Разбираю, как вынести эти решения в отдельный AI Gateway на Go и не размазать AI-логику по всему backend.

В 2018 году я выступил на SECON с докладом «Кому ты нужен завтра, программист?». Программистов не хватало, зарплаты росли, а я пытался разобраться, может ли наша профессия повторить путь радиоинженеров: создать универсальный инструмент, который постепенно заберёт часть работы у своих создателей.

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

Ниже — статья по материалам того доклада. Я сохранил рассуждения, сомнения и взгляд из 2018 года, поэтому «сегодня» в основном тексте означает именно тот момент. Мне интересно снова пройти эту цепочку рассуждений — и предложить вам сопоставить её с собственным опытом последних лет.

Март 2018 года.

20 октября 2017 года Герман Греф заявил, что «век айтишников закончился». На такое заявление легко ответить: программистов не хватает, зарплаты растут, компании конкурируют за людей. Обсудили, посмеялись — пошли дальше писать код.

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

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

Есть встроенный в Windows Win+V. Я честно пользовался им года полтора. А потом однажды скопировал кусок кода, полез искать то, что копировал двадцать минут назад, и понял, что искать там нечем. В Win+V нет поиска. Совсем. Список, по которому ты скроллишь глазами. Двадцать пять элементов, картинки вперемешку с текстом, и ты листаешь колёсиком, как ленту, пытаясь вспомнить, как выглядела нужная строчка.

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

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

Вышел PVS-Studio 8.0! Мы добавили поддержку анализа Go проектов и многое другое. В этой статье мы разберем интересные диагностические правила для Go, которые мы подготовили с выходом новой версии нашего анализатора.

В JDK 26 есть JEP 500 — Prepare to Make Final Mean Final. Теперь JVM предупреждает о попытках изменить через deep reflection final-поле объекта, не объявленное как static. В одном из будущих релизов такие операции планируется запрещать, если владелец приложения не разрешил их явно. В статье разберём:

У любого ускорителя Python есть число: во сколько раз он быстрее. Меряют его на ядрах - сортировка, обход дерева, арифметика в цикле. Сервис устроен не так: обработчик ходит в базу, считает в numpy, сериализует ответ, и байткода, к которому это число применимо, в нём может почти не остаться. CinderX ускоряет байткод, и за пределы байткода это число не распространяется. Доля байткода в вашем сервисе - свойство вашего кода, а не расширения, и пока она не посчитана, «ставить или нет» решается угадыванием.

Мне давно было любопытно разобраться, как в RTB (Real Time Bidding — аукционная закупка рекламы в реальном времени) устроена хайлоад часть. Задача выглядит сложной: от площадок идет поток запросов на покупку рекламы (бид-реквестов), на стороне рекламного движка есть каталог рекламных объектов (кампаний и баннеров в них) со своими таргетингами, и на каждый входящий запрос надо успеть найти подходящие объекты, посчитать ставку и ответить. На весь обмен с биржей дается порядка ста миллисекунд, и в них должно поместиться все сразу — сеть в обе стороны, разбор запроса, подбор объекта, расчет ставки, сборка ответа. То есть на сам подбор остается еще меньше времени.

А еще такая система должна быть подвижной в обе стороны по нагрузке. Трафик у поставщиков не постоянен, он гуляет и в течение суток, и от поставщика к поставщику, так что держать максимальный конфиг под пиковую нагрузку круглосуточно нет смысла. Значит нужна возможность добавлять и убирать мощности, понимая при этом, сколько пропускной способности дает каждая добавленная единица. Спроектировать такое — интересная инженерная работа. Ну это я, как продакт работающий в этой сфере, так считаю :-)

В каждой компании где я работал с рекламными движками (DSP – Demand Side Platform) были свои кастомные решения, свое легаси – не везде можно найти обоснование каждому решению, поэтому мне всегда было интересно, как это устроено у других. Так что я решил разобраться, какие вообще бывают решения — чтобы лучше понимать возможности и ограничения, с которыми имеют дело мои разработчики. Это важно, потому что от выбора хранилища напрямую зависит сколько трафика мы физически способны обработать не отъехав, и что случится (а точнее что мы можем быстро сделать), если завтра нужно будет попросить у поставщика (в рекламе он называется SSP - Supply Side Platform) вдвое больше.