Бэкенд

Я устроился в Apple в октябре 1995 года. В это время Apple кружилась в сливном отверстии раковины, готовясь отправиться в канализацию. Возможно, вы помните все эти разговоры о том, что Apple скоро закроется. Немного странно, что она продолжала нанимать сотрудников, но, очевидно, в Apple считали, что им всё равно нужен ещё один «графический инженер» для работы над технологией QuickdrawGX. Тогда мне был 31 год, я жил в Канзасе и программировал игры для Macintosh. Разумеется, в компании решили, что я хорошо подойду на эту должность.

Процесс собеседования оказался для меня совершенно неожиданным и новым (подробно о нём написано здесь), но в конечном итоге мне предложили работать графическим инженером QuickdrawGX в Apple Computer, Inc.

Переезжать с моей девушкой, всеми вещами (и двумя кошками) из Канзаса в Калифорнию было безумно сложно, но мы справились. Как окажется позже, мне предстояло ещё многое узнать о программировании, да и о профессионализме в целом. И тут я сразу понял, что, возможно, взялся за задачу, которая мне не по зубам (как программисту). Другие инженеры Apple были дружелюбными, но и очень умными. (Наверно, мне стоит подробнее написать о панике, которую я ощущал первое время; казалось, будто я случайно забрёл в глубокую часть бассейна.)

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

Вскоре после моего прихода в компанию проект QuickdrawGX расценили провалившимся, меня перевели в новую команду (ColorSync) и чуть позже выдали новый проект. У Apple было стандартное окно, в котором пользователь мог выбирать цвет, оно называлось Color Picker («Палитра»). Кроме того, в то время Apple начинала переход с чипов Motorola 68K на новые, более быстрые чипы PowerPC (PPC). Моя задача заключалась в том, чтобы проект Color Picker, написанный для чипов 68K, компилировался для новой архитектуры PPC.

Этот вопрос интересовал меня настолько давно, что за прошедшие годы даже стал как-то про него забывать. И не то, чтобы меня это прям как-то сильно интересовало, но всё же лучше понимать назначение было бы приятно.

И, ведь, ну в самом деле, подумаешь, ну может разработчику хочеться вернуть не эземпляр, не instance, а какой-нибудь другой объект, и зачем-то при этом ему нужен именно вызов конструктора. Ну, допустим, он хочет чтобы new.target был заполнен и т.п., ну, мало ли какие варианты зачем-то иметь возможность в противном случае вернуть объект. Или может он хочет асинхронных конструкторов и вернуть new Promise, где уже в resolve передать this как вариант для создания await new MyConstructor. Или может быть хочет вернуть Proxy над this для отслеживания операций с этим экземпляром. В общем есть всякие разные причины когда гуманно было бы иметь этот "сахар", но всё же, может быть есть что-то, что иначе никак не сделать? И, самое важное, что эта функциональность былв всегда, с самой первой версии же. Понятно, что может быть про это вообще не думали, просто делали "как привычно". И, да, функции-конструкторы, в отличие от class-овможно вызвать без new и в те времена никаких классов в JavaScript не было конечно, и return объективно был нужен, но может быть есть какие-нибудь варианты когда и с new имеется глубокий практический смысл уже и тогда существовали, то есть может быть назначение операции возврата иного значения конкретно у конструкторов вполне себе приемлемое. И, да, конечно, конструкторы не возвращают примитивы, но может быть и для объектов есть какое-то применение тоже находилось бы, ну, вдруг, внезапно, может быть ...

Я Евгений Прочан, в платформенной команде Magnit OMNI развиваю инфраструктуру DWH. Расскажу здесь, почему нам понадобилось перейти от батчинга к CDC и как мы это делали. Причин перехода было две: потребность бизнеса в расширении возможностей инфраструктуры и нестабильность нашего старого процесса репликации. 

Мы используем в основном базы данных PostgreSQL. Оттуда пакетами раз в час передаём данные в S3, ClickHouse и таблицы Iceberg. Наша потоковая нагрузка достигает примерно полутора терабайта данных, 6000 операций в секунду (около 1500 в самой нагруженной базе данных). 

В этой очередной статье по GIL разберемся, как работает Python, как был реализован GIL до версии языка 3.2, как глобальная блокировка работает сейчас, и что с ней делать.

Обработка ошибок в Go — это нечто большее, чем просто предотвращение падений программы. Она помогает строить системы, которые «ломаются красиво», ясно сообщают о проблемах и упрощают отладку. В отличие от языков в которых есть обработка исключений, Go заставляет нас явно думать о том, что может пойти не так. Это одновременно и преимущество, и недостаток.

Роб Пайк однажды сказал: «Ошибки — это значения» (прим. переводчика: В Go ошибка — это не исключение и не что‑то «особенное», а просто значение, которое может вернуть функция.) Эта простая мысль определяет то, как мы должны подходить к обработке ошибок в Go. Давайте посмотрим, как превратить эту «филосовскую» мысль в практические паттерны.

Кажется, про TDD давно всё известно: сперва тест — потом код — получаем покрытие. Но на деле его суть понимают неправильно — как критики, так и сторонники.

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

TDD часто воспринимают как способ добиться максимального покрытия или как дисциплину «писать тесты вперёд». Но настоящая цель — не в тестах, а в итеративном проектировании поведения и архитектуры.

Если вам кажется, что TDD — это занудно, медленно, не подходит к реальному коду или убивает гибкость — возможно, вы всё делали правильно.
Но с совершенно другими целями.
Именно поэтому вам не понравилось.

Разберёмся, что такое TDD на самом деле — и почему вы, скорее всего, не знаете TDD.

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

Привет, Хабр! Меня зовут Валентин Вертелецкий, я DevOps в СберТехе, занимаюсь развитием Platform V Kintsugi — это графическая консоль для сопровождения Postgres-like СУБД. Наш продукт построен на микросервисной архитектуре и сначала разрабатывался с использованием базовой функциональности Kubernetes — там нет встроенных механизмов аутентификации, авторизации, управления доступом и шифрования трафика. Когда же у нас стало больше сервисов, нам понадобилось повысить защиту и отказоустойчивость, добавить возможности управления доступом.

Мы опираемся на подход Zero Trust: ни одному элементу системы не доверяем по умолчанию. Каждый запрос проверяется, привилегии для администраторов минимальны, трафик валидируется и шифруется. Нам предстояло обеспечить надёжную аутентификацию и авторизацию, а также централизованный контроль и мониторинг запросов. В этом нам помогла технология Service Mesh. 

Для управления микросервисами в Kubernetes мы используем Platform V Synapse Service Mesh от СберТеха — это решение на основе платформы Istio. Покажу, как всё работает у нас. Плюс, я подготовил демо-проект для тестирования кейсов (ссылка в конце статьи). Надеюсь, он будет полезен командам, работающим с микросервисами. 

Считается, что на конференции лучше всего запоминаются первое и последнее выступления. И тут я не являюсь исключением, так как при посещении С++ Zero CostConf 2025 мне сильнее всего запомнились как раз первый и последний доклады, но думаю не только из-за эффекта края, но и по той причине, что они были для меня самыми интересными и именно ради них и я решил съездить в Москву из далекой российской глубинки.

Но мне не хочется писать про само мероприятие, тем более, что видеозапись всех выступлений выложена на сайте конференции C++ Zero Cost Conf 2025 и пересказывать технически детали докладов не имеет смысла.

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

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

В C/C++ давно принято встраивать Python в приложения для скриптовой логики и плагинов. Именно эта экосистема много лет давала повод развивать в CPython идею нескольких изолированных интерпретаторов в одном процессе. Долгое время это было только в C-API: создаёшь новый интерпретатор через Py_NewInterpreter, живёшь с одним общим GIL и кучей глобального состояния. В Python 3.12 появилось ключевое изменение — GIL стал на-интерпретатор (каждый subinterpreter со своим GIL), но доступ был только через C-API. В 3.14 подвезли полноценный высокоуровневый Python-API: модуль concurrent.interpreters и InterpreterPoolExecutor.

Теперь можно писать параллельный код без multiprocessing, но с изоляцией уровня «почти процесс».

Дальше разберёмся, что это такое, когда это уместно вместо multiprocessing.

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

Сергей Пантелеев и Данил Щуцкий собрали ключевые новости PHP и Laravel за июль. Будьте в тренде — читайте обзор! 🚀

Мне тут попалась идеальная статья про DI в который нашелся очень интересный пример для разбора. Есть фундаментальные основы, которые почему то никто не хочет сформулировать, а начинающим разработчикам, которые впервые сталкиваются с концепцией DI, в первую очередь надо бы рассказать эти фундаментальные основы, но почему то нет желающих это сделать и у меня даже есть предположения, почему это не получается, я попробую их как-то выразить в том числе.

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

В предыдущей статье мы выяснили как создать два класса (Хост и Енкодер, класс А и класс В) один из которых (А) не может работать без использования функций другого класса (В, а может, и без данных из этого класса В не может работать), но при этом совершенно не зависит от этого класса В! То есть класс А может запросто работать с любым другим классом (C, D, … ) вместо класса В, при некотором условии изложенном в предыдущей статье. По моему, та статья может быть хорошей разминкой для понимания концепции Внедрения Зависимостей. И, определенно, эта статья может считаться продолжением темы практической архитектуры ПО.

Месяц назад я опубликовал пост об инструменте для автоматической оптимизации SQL-запросов. Идея была простая — убрать этап «общения» с ИИ и предоставить простой интерфейс, где не нужно придумывать промпты.

За первый месяц сервис использовали более 1000 человек. Ниже — выводы и результаты.

Привет, Хабр! Меня зовут Илья Андреев, я старший программист в компании Syntacore. Вы, наверно, слышали, что виртуальные функции в C++ пользуются дурной славой — а может, и сами придерживаетесь о них не самого лучшего мнения. В этой статье, подготовленной совместно с Константином Владимировым, я в некоторой степени выступлю адвокатом виртуализации.

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

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

В экосистеме C# за последние два релиза случилось ровно то, чего многим не хватало для аккуратной работы со списками значений. В C# 12 появились collection expressions — синтаксис вида [1, 2, 3] со spread-элементами .., который конвертируется в массивы, Span, ReadOnlySpan, интерфейсы коллекций и любые правильно устроенные типы. В C# 13 к этому добавили params-коллекции: теперь params может быть не только массивом, а почти любой поддерживаемой коллекцией, включая спаны и неизменяемые контейнеры.

Зависимости тоже хотят заботы — но без драмы. modup — лёгкий tui, подскажет, что обновить, и поднимет нужные версии аккуратно, без «сломалось, но почему?».

Выберите пакеты, жмите — наблюдайте прогресс. Один запуск — и go.mod причёсан. Сюрпризы оставим код‑ревью, а не сборке.

Быть или не быть? Стоит ли использовать key-value-базы данных в большом продакшне? На связи Иван Храмов, CTO МТС ID, и Николай Диденко, техлид из команды инфраструктуры МТС Web Services. Мы используем Cassandra в МТС ID и за годы эксплуатации познали и сильные, и слабые стороны этого решения.

Главная особенность и одновременно ограничение Cassandra и ScyllaDb — это то, что они строго key-value-хранилища. Именно с этим они справляются отлично — быстрое чтение и запись по ключу, георезервирование и масштабирование. На этом этапе все выглядит радужно.

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

Привет, Хабр! На связи Сергей Гайдамаков. Продолжаем обсуждать и тестировать набор реплик MongoDB. 

В предыдущей статье мы рассмотрели структуру отдельного узла MongoDB, разобрали свойства параметров writeConcern и readConcern для работы с набором реплик MongoDB. 

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

Я хотел видеть состояние своих CPU и ОЗУ прямо в трее панели задач, чтобы не открывать дополнительные окна, по типу cpuz или CoreTemp. Решил написать свою фоновую программу с возможностью настроек и вот что получилось.

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

Меня зовут Дмитрий, я бэкенд-разработчик в SENSE и последние 10 лет пишу серверную часть на Java. Эта статья — продолжение серии гайдов по Spring GraphQL, где в первой части мы с нуля подняли проект и подключили GraphQL к Spring Boot, а во второй разобрались с SchemaMapping, DataLoader и реализацией запросов посложнее.

Сегодня двигаемся дальше: разберём валидацию данных, работу с заголовками (headers), обработку ошибок, подключение кастомных скаляров и директив. А ещё посмотрим, как работать с интерфейсами и union-типами, и напишем клиент для GraphQL-сервиса.

Поехали!