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

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

Привет, Хабр! Меня зовут Максим Попов, я инженер по автоматизированному тестированию внутренних продуктов в Сбере — в том числе SCPL. В этой статье расскажу, как упростить настройку клиент-сервер взаимодействия в рамках фреймворка автотестирования.

Команда JavaScript for Devs подготовила перевод статьи о том, как доминирование React сдерживает развитие фронтенда. Автор утверждает: выбор React «по умолчанию» тормозит инновации, мешает развитию альтернативных фреймворков и превращает всю экосистему в монокультуру.

Написать код легко. Если у вас в голове сложилось решение, и вы уверенно владеете синтаксисом вашего любимого языка программирования, то напишете код с лёгкостью. А может быть у вас есть LLM, которая напишет за вас целые функции? Тогда ещё проще. Но сложнее всего не писать код, а читать. Требуется время, чтобы загрузить себе в голову ментальную модель системы. Вот это по-настоящему трудозатратно.

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

Когда я выполнял работу по заказу, большинство из моих заданий начинались одинаково. Мне ставили задачу пофиксить баг или добавить новую фичу в приложении, которое я видел впервые. Сначала моя ментальная модель была как чистая доска. Чтобы приступить к её заполнению, я открывал домашнюю страницу и разбирался, на что она похожа. Я открывал исходный код страницы: это React? jQuery? Сторонний плагин? Я просматривал базу кода, чтобы выяснить, используется ли у них где-нибудь ещё такая карусель, которую они просят поставить на первой страницы. Знакомился с их сборочным процессом, конфигурацией для тестирования, с тем, каким инструментарием они пользуются. Каждая мелкая деталь, которую я обнаруживал, встраивалась в ту модель, которая складывалась у меня в голове.

Команда Go for Devs подготовила перевод статьи о том, как работает сборщик мусора в Go. Автор подробно объясняет семантику алгоритма триколорной маркировки и очистки, механизмы Stop The World, пейсинг и источники задержек. Главное — не бороться со сборщиком, а работать с ним в унисон: устранять лишние выделения и снижать нагрузку на кучу.

Это третья статья из цикла про наш фреймворк Steroids: в ней мы рассказываем о том, как пришли к созданию собственного движка форм для React. Если вы ещё не читали предыдущие материалы, рекомендуем с ними ознакомиться:

Тема чистого кода — одна из самых обсуждаемых в сообществе разработчиков. Это не удивительно: от качества кода напрямую зависят скорость разработки, легкость поддержки и масштабирования проекта. В мире JavaScript и TypeScript, с их гибкостью и динамической природой, следование принципам чистого кода становится особенно важным.

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

В современных встраиваемых системах SPI остаётся одним из ключевых интерфейсов для обмена данными с периферийными устройствами — от датчиков до Flash-памяти. При этом эффективная работа с SPI требует не просто доступа к регистрам контроллера, а продуманной архитектуры, где драйвер выступает как последнее звено между программной логикой и аппаратной реализацией. В данной статье мы расскажем про архитектуру SPI и на практикте разберем все этапы разработки SPI драйвера для нашей операционной системы реального времени "Нейтрино".

Команда Python for Devs подготовила перевод большого туторила по Django Templates. В статье подробно разбирается, как устроен язык шаблонов Django, чем он отличается от Jinja, как правильно наследовать шаблоны и организовать структуру проекта. Если вы хотите сделать свои Django-приложения более чистыми, поддерживаемыми и быстрыми — этот материал для вас.

Всем привет! Пополняю интернеты «еще одной» статейкой с бенчмарками популярных СУБД. Захотелось выяснить, каков оверхед на протокол, работу с сетью и клиентскими соединениями в самом простом кейсе — когда таблица либо совсем пуста, либо данных так мало, что все они в памяти.

Бенчмарк на Rust. Я попросил написать его Chat‑GPT, и он отлично справился.

Исходник здесь

Сравнивал с официальными scylla‑bench и redis‑bench — результаты схожи.

Для теста я специально использовал слабую железку — Orange Pi 3b. Это китайский аналог малинки. Захотелось узнать, на что она способна.

Для проведения тестирования безопасности приложения существуют различные *AST инструменты. Прежде всего, это средства для статического тестирования безопасности приложений (SAST), а также средства динамического анализа (DAST). В этой статье мы рассмотрим еще один способ анализа приложений — IAST. Мы сравним этот способ со статическим и динамическим анализом и поговорим о его достоинствах и недостатках.

В мире Data Science написание нейронных сетей, кажется чем‑то очень трудоёмким, доступным для понимания лишь математикам с многолетним опытом. Многие руководства, начинаются со сложных объяснений backpropagation, градиентного спуска и т.п, от которых у новичков складывается впечатление, что написание нейросетей — им не по силам. В данной статье, я хочу развеять подобные убеждения и показать пример, написания простейшей нейронной сети на python. Мы не будем углубляться в теоретические основы высшей математики. Вместо этого, мы просто возьмем данные, напишем код, посмотрим на результат и проанализируем его.

23 сентября эксперты MWS Cloud расскажут, как самостоятельно создавать ИИ-агентов — с помощью кода или без. Мы поделимся, как доработали Langflow под реальные задачи. Встреча онлайн, регистрация — по ссылке. 

Сегодня же мы собрали несколько полезных материалов для желающих разобраться самостоятельно в устройстве работы ИИ-агентов (или написать собственную интеллектуальную систему).

Всем привет! Пару месяцев Альянс в сфере искусственного интеллекта, в который MWS AI тоже входит, запустил MERA CODE — бенчмарк для оценки качества умений написания кода для больших языковых моделей.  Инструмент хороший, но есть одна проблема. Все задачи в MERA CODE, как впрочем и в SWE-bench и других бенчмарках подобного назначения , следуют классической парадигме: есть фиксированный обучающий набор данных и, что более важно, фиксированный проверочный набор, которые имеют свойство устаревать. Например, многие из наборов данных для таких бенчмарков собраны из открытых источников типа GitHub.  Большие языковые модели, которые мы  пытаемся оценивать нашим набором задач, также учатся на GitHub и рано или поздно (и в наше время скорее рано) они во время обучения увидят данные из проверочного множества. Это явление называется контаминацией данных. Из-за этого мы не можем больше быть уверены в том, что оценка способностей моделей является объективной.

Мы думали об этой проблеме, и пришли к выводу, что ее влияние можно минимизировать, если мы будем периодически обновлять проверочное множество. Так родилась идея для нашего нового бенчмарка — SWE-MERA, о котором и пойдет речь в этой статье. 

Привет, Хабр! Меня зовут Глеб, я Java-разработчик в Сбере. Сегодня я хочу рассказать про исторический контекст двух фундаментальных подходов к системе типов в программировании.

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

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

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

PostgreSQL 18 вот-вот выйдет, и это не просто минорное обновление, а настоящий прорыв для разработчиков и администраторов БД. В новом переводе от команды Spring АйО рассмотрим ключевые новинки — асинхронный I/O для ускорения чтения, поддержка UUID версии 7 с улучшенной сортировкой, skip scans в B-tree индексах, виртуальные вычисляемые столбцы и даже OAUTH 2.0 для аутентификации. Всё это делает Postgres ещё более быстрым, гибким и современным.

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

Оказалось, что форумы кишат людьми, которые не до конца понимают, как компьютеры манипулируют числами. Например, мемасик с КПДВ я стянул с реддита (перечеркнул его я). Кто-то настолько был напуган страшными ошибками округления чисел с плавающей точкой, что даже смешную картинку смастерил. Только вот проблема в том, что 0.5 + 0.5 в точности равно 1.0.

Таким образом, я решил засучить рукава, и изобрести велосипед. То есть, написать самую неоптимизированную C++ библиотеку для эмуляции IEEE754 32-битных чисел с плавающей точкой при помощи исключительно 32-битной целочисленной арифметики. Библиотека уложится в несколько сотен строк кода, и в ней не будет никакого битхакинга. Задача написать понятный код, а не быстрый. А заодно хорошенько его документировать серией статей.

Итак, этим полукреслом мастер Гамбс начинает новую партию мебели, или статья первая: поговорим о числах и компьютерах.

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

Сегодня вам предстоит увлекательное путешествие по стыку технологий, кода и технических решений, которые и расскажут вам то, о чем адепты съемки мобильного RAW‑видео предпочитают не говорить.

Развертывание ИИ-моделей в облаке — стандартная задача для современных специалистов по машинному обучению. Но выбор подходящего инстанса GPU часто превращается в «лотерею»: переплата за избыточные ресурсы или, наоборот, «торможение» из-за недостаточной мощности. В этой статье мы расскажем, как не ошибиться с выбором облачного GPU, сохранив баланс между производительностью и бюджетом. Акцент сделаем на реальных кейсах — от обучения нейросетей до инференса в продакшене.

Хочу поделиться своим опытом разработки крупных игровых проектов на C++, где производительность и стабильность — это не просто приятные бонусы, а абсолютно естественные требования к разработке. За годы работы над движками и играми я понял, что подход к управлению памятью очень сильно влияет на весь проект. В отличие от многих приложений - игры, особенно большие, часто работают часами без прерываний и должны поддерживать стабильный фреймрейт и отзывчивость. Когда проседание fps или фриз происходит на глазах у сотен тысяч игроков, вам уже никто не поможет — ущерб уже нанесен, а в steam полетели отзывы о кривизне рук разработчиков.

Однажды моя команда закончила работу над довольно интересным проектом, который портировали больше двух лет на плойку. Движок старый, большой и мощный, но работа с памятью была ориентирована на ПК времен конца 2000-х, и что меня поразило, так это насколько сильно большая часть кодовой базы зависела от динамической памяти во время выполнения. На ограниченном железе (далеко не у всех есть PS5 pro) и в условиях жёстких требований к сертификации на консолях такие решения быстро превращаются в проблему.

В разработке для консолей (про мобильные устройства я молчу, потому что игра не влезает по памяти даже в восемь гигов) с ограниченными ресурсами, архитектура с частыми аллокациями не просто неэффективна — она становится реальной угрозой для стабильности проекта. Каждое выделение памяти в куче влечёт за собой накладные расходы: это дополнительные !миллисекунды! (в целом на кадре) задержки, риск большой фрагментации памяти, и непредсказуемое поведение в долгой игровой сессии. После двух часов игры постоянные операции с кучей буквально «сжигают» половину бюджета кадра.

Команда JavaScript for Devs подготовила перевод статьи о том, как Node.js выжимает максимум из I/O в 2025 году. В ней подробно объясняется цикл событий, порядок фаз и то, как правильно писать код, чтобы серверы оставались отзывчивыми даже под нагрузкой.