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

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data. В Beeline Cloud у нас есть место для экспериментов — и я этим пользуюсь. Недавно я работал над шахматным ботом для игры по переписке в Телеграм. Одна из ключевых задач — генерация изображений шахматной доски из FEN-нотации.

Строгая типизация не всегда спасает от глупых ошибок. Если userId, orderId и productId — это один и тот же Int или Long, компилятор не увидит разницы и спокойно пропустит неверный аргумент. В Scala 3 для таких случаев есть opaque types: они позволяют сделать доменные типы различимыми на этапе компиляции, но без лишних обёрток и накладных расходов в рантайме. Разберём, как это работает и чем этот подход лучше type alias, case class и AnyVal.

В экосистеме JavaScript произошёл серьёзный инцидент, который хорошо показывает, насколько опасными стали атаки на open source и цепочки поставок. Исследователи StepSecurity сообщили о компрометации axios — одной из самых популярных HTTP-библиотек в npm (~83 миллионов загрузок в неделю). Злоумышленник получил доступ к аккаунту одного из ведущих мейнтейнеров проекта и опубликовал две вредоносные версии пакета: axios@1.14.1 и axios@0.30.4.

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

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

Традиционный подход — сессии. Вы логинитесь, сервер создаёт сессию, запоминает ваш ID у себя в базе данных, а вам выдаёт куку с ID этой сессии. Всё работает, пока вы на одном сервере. А если у вас их два? Или десять? Куда девать сессии? Начинаются проблемы с синхронизацией, Redis, общими хранилищами…

Альтернатива — JWT (JSON Web Token). В этой статье мы с вами:

Находясь в поиске вакансий я понял: что-то изменилось, кто то не просто построил новый механизм, а установил новый мод на сервер.

Наступила новая “эра” и пока не все это осознали. Многие до сих пор смотрят на AI как на обычный IT-продукт. Примерно как на площадку для видеохостинга, редактор или очередной удобный сервис. Но это уже слишком мелкий взгляд.

Для начала зафиксируем простую вещь: нейросеть как продукт - это инструмент. Для её создания нужны математики, программисты, лингвисты, биологи и исследователи из других областей. Да, конкретная нейросеть это IT-продукт. Но AI в целом уже больше, чем просто один класс продуктов. Если смотреть шире, это отдельная сфера, сопоставимая с IT по масштабу влияния, но не заменяющая его.

В 1931 году 25-летний Курт Гёдель написал доказательство, которое перевернуло мир математики с ног на голову. Выводы были настолько поразительными, а само доказательство настолько изящным, что это было… как-то даже забавно. Я хотел поделиться с вами его открытием.

Объединение

На протяжении последних 300 лет математики и ученые делали поразительные открытия, которые привели к появлению одной великой закономерности. Эта закономерность заключалась в объединении: идеи, которые раньше считались разрозненными и непохожими, неизменно оказывались одним и тем же!

Ньютон положил начало этому процессу в физике, когда обнаружил, что то, что удерживает нас на Земле, — это то же самое, что заставляет Землю вращаться вокруг Солнца. Люди думали, что тепло — это особый вид энергии, но оказалось, что его можно объяснить с помощью механики. Люди думали, что электричество, магнетизм и свет — это разные вещи, но Максвелл обнаружил, что их можно объяснить с помощью электромагнитного поля.

Знакомая ситуация? Вы открываете файл контроллера на 2000 строк. Там перемешаны SQL-запросы, HTML-разметка, бизнес-логика и комментарии на ломаном английском. В голове начинает играть тревожная музыка, а внутренний голос шепчет: “Закрой это немедленно, пока оно не сломалось”.

В психологии это называется “когнитивная перегрузка”. Мозг просто отказывается парсить такое количество переменных одновременно. Раньше программистам приходилось часами медитировать над распечатками кода, как сыщикам, пытаясь прокачать навык “Внутренняя империя”.

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

Здесь мы разберем 6 фундаментальных паттернов промптинга, которые вытащат вас из любой ямы.

DI-контейнер — сердечко Symfony. Контроллеры, сервисы, слушатели событий, консольные команды, Voter, нормалайзеры — всё это сервисы, которые живут в контейнере и получают зависимости через него.

Разберём три уровня глубины: autowiring для повседневной работы, теги для расширяемых архитектур, compiler passes для магии уровня фреймворка.

В новом переводе от команды Spring АйО смотрим, как подружить современный Spring Boot и OpenTelemetry так, чтобы данные уходили по OTLP в любой совместимый бэкенд. 

В экосистеме Spring большая часть телеметрии была завязана на Micrometer Project (Был ещё spring-cloud-sleuth если кто помнит). Но полноценного all-in-one решения для того, чтобы Spring Boot приложение просто начало экспортировать телеметрию по OTLP не было. До Spring Boot 4.

На данный момент для интеграции OTel в Spring Boot приложения есть 3 пути: Java Agent (минимум кода, но чувствителен к версиям и может конфликтовать с другими агентами), сторонний OTel starter (стартер от самих OpenTelemetry, но тянет alpha-зависимости) и новый spring-boot-starter-opentelemetry, доступный в Spring Boot 4.0. Про него и будет речь.

Представим, перед командой разработки встает задача. Необходимо реализовать конвейер ипотечных заявок.

На текущий момент есть целая группа решений — low-code платформ, призванных ускорить разработку целого ряда решений, сконцентрировавшись на реализации нужных бизнесу фич, при этом по минимуму обращая внимание на детали технической реализации.

Было решено реализовать конкретный процесс с помощью low-code платформы Nuxeo, чтобы понять, где она действительно упрощает жизнь, а где добавляет новые ограничения.

Ошибки шаблонов в C++ — отдельный жанр: вы ожидаете простой контракт к типу, а получаете десятки строк из глубин STL. Проблема не в компиляторе, а в том, что сами требования к типам в классических шаблонах долгое время оставались неявными. Concepts это меняют: они позволяют формализовать ожидания к типу прямо в коде, сделать перегрузку осмысленной, а ошибки — читаемыми. В этой статье разберём, как работают concepts, зачем они действительно нужны и как использовать их не как «синтаксический сахар», а как инструмент проектирования.

Привет! Это снова Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Наши операторы продолжают бороздить просторы K8s, а инсталляторы — разворачивать новые кластеры, и мы готовы поделиться с вами новыми полезностями.

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

Мне нравится писать тесты. Написание теста и последующее обновление кода для его прохождения — всегда увлекательный процесс.

Но нет ничего хуже, чем выяснение того, что проверяют существующие тесты (раньше я сам часто был автором таких тестов).

Представляю вашему вниманию мои советы по написанию высококачественных тестов для фронтенда.

Пользователь спросил ChatGPT про бизнес-идею «говно на палке». Ответ: «It’s not just smart - it’s genius». Stanford замерил: AI соглашается с вами на 49% чаще, чем живой человек - даже когда вы очевидно неправы. Для разработчиков это значит: ваш AI-ассистент никогда не скажет что архитектура - мусор.

Кошмар с автозавершением

Наше префиксное дерево было в 8 раз медленнее хэш-таблицы. И оно потребляло 128 МБ памяти, в отличие от хэш-таблицы с 24 МБ.

Такого не должно было произойти. Префиксные деревья — стандартное решение для автозавершения: поиск за O(k), где k — длина строки вне зависимости от размера датасета. Идеально подходит для сопоставления префиксов. Обычно всегда используется для автозавершения, проверки правописания и таблиц IP-маршрутизации.

Мой коллега предложил использовать префиксное дерево для функции автозавершения в нашем инструменте командной строки. Поиск в нём должен был выполняться по 50 тысячам команд и опций. Учебники говорили, что это правильный выбор.

Поэтому мы реализовали префиксное дерево. Результаты бенчмарка оказались ужасными:

Префиксное дерево было в 8 раз медленнее простой хэш-таблицы. И оно использовало 128 МБ памяти, в то время как хэш-таблица — всего 24 МБ.

Где мы ошиблись?

В этой статье мы не просто посмотрим синтаксис — мы поймём зачем это нужно и как работает под капотом. Мы пройдём путь от указателей на функции в C/C++ до современных лямбда-выражений в C#, разберёмся с делегатами и научимся использовать всю мощь функциональных возможностей языка.

“Долг понимания” (comprehension debt) — это скрытая цена, которую человеческий интеллект и память платят в результате чрезмерной зависимости от ИИ и автоматизации. Для инженеров это особенно актуально в сфере разработки агентных систем.

Когда команды активно используют инструменты для генерации кода с помощью ИИ, возникают определенные издержки, которые не отражаются в показателях производительности. Особенно это касается случаев, когда проверка всего кода, генерируемого ИИ, становится утомительной. Эти издержки накапливаются постепенно, и в конечном итоге их приходится оплачивать — с процентами. Это называется “долг понимания” или “когнитивный долг”.

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

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

Эту статью я позиционирую как введение в парсер‑комбинаторы «для чайников» (или «для самых маленьких» — как вам больше нравится). Цель: попытаться рассказать простым языком и с примерами так, чтобы Вы могли после прочтения написать свой парсер без какого‑либо предварительного опыта и знаний в области синтаксического анализа.

Приятного чтения!

Загадка базы данных

Вся наша база данных находилась в памяти, однако операции поиска по ней занимали 12 тысяч тактов. При миллионе показаний датчика IoT-устройства с 64 КБ кэша реализация красно-чёрного дерева оказалась слишком медленной для запросов в реальном времени.

«Давайте попробуем B-дерево», — предложил я.

«Разве они нужны не только для баз данных на дисках? — спросил лид, — У нас всё находится в памяти. Чем нам будет полезно B-дерево?»

Вопрос был вполне разумным. B-деревья были придуманы для доступа к диску; каждый узел в них — это блок диска. Однако паттерны промахов кэша выглядели подозрительно похожими на паттерны дискового ввода-вывода — всего в 100 раз, а не в 100000 раз быстрее.

В итоге мы реализовали B-дерево. Результаты удивили всех...

Что если взять одну из базовых концепций computer science и построить её прямо внутри игры — из пикселей, блоков и виртуальных проводов? Именно это я и сделал. Машина Тьюринга — теоретическая модель, которая лежит в основе всех современных компьютеров. Она читает символы, записывает их и переходит между состояниями по заданной программе. Майнкрафт позволяет симулировать электрические сигналы с помощью редстоуна. Из этого материала можно собирать настоящие логические схемы — и в итоге целые вычислительные устройства. Получился полностью рабочий механизм: машина читает данные, выполняет команды и останавливается по завершении программы.