Бэкенд

Привет. Меня зовут Денис, я занимаюсь разработкой и доставкой приложений под Kubernetes с 2020 года. За это время через мои руки прошло достаточно проектов, чтобы заметить одну повторяющуюся вещь: почти в каждом из них рано или поздно заводился собственный набор скриптов, склеивающих сборку образа и выкатку релиза. Скрипты были разные, а болезнь одна – они прирастали к проекту и не переносились на следующий.

В этой статье я разберу контур доставки, который мы собрали, чтобы эту болезнь вылечить. Он ставит два совершенно разных по стеку приложения – React плюс Spring Boot и Angular плюс FastAPI – в кластеры двух окружений одной командой, при этом сам про эти приложения ничего не знает. Всё, что их связывает, – небольшой контракт из нескольких переменных.

Привет, Хабр! Меня зовут Степан Пестерников, мы с командой делаем Алису и активно используем СУБД Яндекса. Недавно коллеги из YDB провели большой рефакторинг в YDB Go SDK, где по умолчанию теперь используется новый Query Service.

Я воспользовался этим рефакторингом, чтобы уменьшить количество сетевых запросов от SDK к YDB. Клиентские SDK устанавливают к распределённой СУБД Яндекса gRPC-подключения, поверх которых отправляются низкоуровневые команды. Какие-то из этих команд можно объединять: например, команду начала транзакции и выполнения первого запроса.

В статье я покажу фрагменты кода и расскажу, как мы делали улучшения, которые вошли в релизы v3.126.0 и v3.126.5 Go SDK. Фрагменты кода получились небольшие, и на их примере удобно показать, как этими оптимизациями пользоваться.

Если честно, я давно планировал написать свой язык. Просто надоело на каждом проекте писать одинаковый бойлерплейт, ловить неожиданные ошибки в рантайме, натыкаться на компоненты аля LoanPreloanInterractNDFL6.2ReportViewComponent - и гадать - что имел ввиду художник...

В итоге получился язык "Марка" — штука статически-типозированная, но в которой типы живут во время выполнения, ошибки обрабатываются сами, а из REPL можно сразу дергать запросы и смотреть, что приходит на клиенте и сервере. Как давно мечтал.

Но раскидав исходники по знакомым, получил неутешительный фидбэк: читать трудно! Встал дурацкий вопрос: как это должно выглядеть в коде, чтобы было удобно? Я набросал 4 варианта синтаксиса — от LISP-стиля до почти Python - нотации. У каждого есть плюсы и минусы, и я уже неделю не могу выбрать.

Какой из вариантов читать было бы удобнее лично вам? Проголосуйте!

P.S. Если заинтересовал проект - уже сейчас доступна playground площадка для экспериментов http://marka-lang.ru/playground.php

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

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

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

Через несколько дней (говно)кода стало много — вменяемого сервиса не получилось.

Один BFS принимал map[string][]string. DFS жил на другом типе графа. В одной реализации направленность задавалась на уровне графа, в другой вытекала из того, как было записано ребро. Опции существовали, но их комбинации не образовывали понятной политики. Result types возвращали срезы и числа, однако я не мог внятно ответить, что именно они гарантируют.

Проблема была не в том, что LLM «не умеет BFS». Я попросил реализации раньше, чем сформулировал общий контракт данных. Генератор заполнил пустые места правдоподобными допущениями — которые, очевидно, не совпали в разных кусках кода.

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

Эта серия для тех, кто выучил синтаксис Go, написал первые go func() и хочет понять, что за ними стоит. Многопоточность знать не нужно: начнем с того, что такое поток. К концу первой части ты будешь понимать, почему поток операционной системы дорогой, что такое горутина физически и как Go пришел к схеме GMP.

В начале августа я сел делать игру для мессенджера MAX – обычный вордли, слово из пяти букв, шесть попыток. Мини-приложение на ванильном JS, сервер на Go, самый дешёвый VPS. По моим прикидкам – три вечера.

Первый вечер целиком ушёл на то, чтобы сервер вообще смог поговорить с API мессенджера. Не на игру, не на словарь – на TCP-соединение.

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

В этот раз я пришёл с двухчастным текстом про F#, тайппровайдеры, скрипты, спортивное программирование, MVU, консольные интерфейсы в стиле FarManager, низкоуровневый интероп с виндой, некоторое количество хаков ХМ и, внезапно, живопись. Причём только консольные интерфейсы с некоторой натяжкой можно назвать центральным элементом повествования, поэтому я понятия не имею, как должен выглядеть потенциальный читатель этой статьи. Будем исходить из предположения, что он либо достаточно опытен, либо у него достаточно времени и усердия, чтобы расковырять всё, что я не счёл должным разобрать детально (я могу, но только за 16 глав).

Сегодня мы изучим небольшой .fsx-скрипт, который я ежедневно запускаю, чтобы получить очередную порцию задачек из архива codeforces.com. Необычно то, что скрипт функционирует как полноценное GUI-приложение, пусть и очень страшное старое. Кажется, что до меня так никто не делал, так что с осторожностью назову это авторской инновацией.

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

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

Последние 3 года я веду свой блог и активно общаюсь с Python разработчиками. И это помогает мне делать выводы относительно рынка труда более рационально, чем я делал в начале своей карьеры. Надеюсь, что этот материал даст тебе, дорогой читатель, пищу для размышления.

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

Сегодня мы будем говорить преимущественно о таких гигантах, как Django, FastAPI и Flask, а также затронем не менее важные библиотеки: для работы с базами данных, тестирования, сборки проектов. Поговорим о таких противостояниях, как uv vs poetry, pytest vs unittest и других. В общем, будет интересно. Усаживайтесь поудобнее и погнали!

Вы, скорее всего, встречались с кардинально противоположными мнениями: "Django умер, да здравствует FastAPI", "Сейчас на FastAPI уже не пишут, встречай LiteStar", "Вообще на FastAPI особо ничего не пишем, только на Django".

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

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

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

В прошлой статье я рассказывал, почему в какой-то момент пришлось делать собственный Анти Бот для WordPress: Cloudflare для части клиентов стал недоступен, а платные альтернативы вроде облачных WAF просят от 10 тысяч рублей в месяц за один сайт – и это при том, что задача у большинства клиентов скромная: отсеять спам-регистрации, спам в комментариях и мусор в формах обратной связи.

Статья неожиданно вызвала живое обсуждение, и часть комментариев была настолько по делу, что отвечать одной строкой в треде было бы нечестно. Так что это скорее не «часть 2» в смысле новой большой темы, а закрытие долгов перед читателями плюс рассказ о том, что успело измениться в плагине с мая.

Если вы поставляете товар в крупную розницу, возите грузы для 3PL-оператора, шлёте платёжные извещения банку или обмениваетесь медицинскими транзакциями X12 — вы почти наверняка обмениваетесь этими документами по AS2. Заказ (EDI 850), счёт (810), уведомление об отгрузке (856), платёжное авизо (820) уходят партнёру не почтой и не через REST, а как подписанный и зашифрованный S/MIME-конверт поверх HTTP, с подписанной квиткой-распиской в ответ. Так работает регламентированный B2B-документооборот в рознице, логистике, финансах, производстве и здравоохранении уже двадцать лет: Walmart, Amazon и их сети поставщиков, банки с host-to-host каналом, автопром, дистрибьюторы — все требуют AS2.

В .NET до сих пор было два пути. Либо коммерческий AS2-шлюз — Cleo, Seeburger, BizTalk — отдельная коробка, отдельная лицензия, отдельная команда сопровождения. Либо Java-сервер с открытым кодом — OpenAS2, Mendelson Community — отдельный JVM-процесс рядом с вашим .NET-бэкендом, со своим inbox-каталогом, откуда документы надо ещё забирать джобой. В обоих случаях AS2 живёт сбоку от вашей интеграции, а не внутри неё.

redb.Route.AS2закрывает этот разрыв: AS2 становится обычным шагом маршрута в вашем .NET-процессе. Приняли конверт от партнёра, расшифровали, проверили подпись, отдали документ в pipeline — провалидировали, трансформировали, положили в Kafka или SQL — и вернули партнёру подписанную расписку. Один процесс, один деплой, одна панель наблюдаемости. Разберём, как это выглядит в коде, где применяется и почему нативный коннектор в ESB выигрывает у отдельного шлюза.

Последнее время я почти не пишу код руками — значительную часть реализации берут на себя AI-агенты. Но работы меньше не стало: теперь нужно задавать ограничения, проверять архитектуру и понимать результат, не перечитывая тысячи сгенерированных строк. Я попробовал сделать архитектурный граф общей моделью для человека, агента и генератора кода. Из одного графа получил сервисы на Go, Python, C++ и Rust, а затем сравнил их с прямыми реализациями того же HTTP → gRPC сценария. Главный вопрос эксперимента: какова runtime-плата за систему, которую проще понимать, изменять и наблюдать?

Продолжаем изучать, как устроен SFU изнутри: добавляем simulcast, ice restart и мониторинг сети. Дневник разработки на Rust.

← Девятая часть

В предыдущих постах мы подробно разбирали каждый слой: CPU, арифметику, скриптовый интерпретатор, оборудование. Вот, что окончательный отчёт о синтезе Quartus сообщает обо всех них: в готовой архитектуре используется 1593 логические ячейки из доступных в EP2C5 4608 (35% чипа) с 594 выделенными логическими регистрами и 17 блоками памяти M4K. Сам модуль CPU занимает 1173 из этих логических ячеек и 400 регистров. Остальная логика отдана периферии: драйверу ЖК‑дисплея (154 логические ячейки), сканеру клавиатуры (97), интерфейсу термопринтера (64), таймеру CTC (49) и аппаратному PRNG (20). 12 блоков памяти M4K занимает ROM микрокода (49152 бит: это полная программа калькулятора), 2 блока — ROM скриптинга (8192 бита), 1 — ROM BCD‑констант, 1 — таблица поиска для BCD‑умножения внутри CPU и 1 блок — ОЗУ. Меня это очень радует: полнофункциональный научный калькулятор уместился в 35% небольшой дешёвой FPGA.

Encore зародился как фреймворк на Go, и на Go там были написаны среда выполнения, интерфейс командной строки (CLI), парсер и компилятор. Когда мы решили поддерживать TypeScript, логичнее всего было бы написать на TypeScript и среду выполнения тоже, либо достроить к среде выполнения Go какой‑нибудь мостик. Но в итоге пришли к тому, что написали новую среду выполнения с нуля на Rust.

Сервис жив, CPU в норме, паники нет — а часть запросов зависает на минуты. В async‑Rust привычный стек часто мало помогает: задача могла застрять на блокирующем вызове, мьютексе или просто перестать получать пробуждения.

Разбираем, как отличать эти сценарии в Tokio и куда смотреть, когда отладчик молчит.

Наткнулся на интересный материал про тестирование GitOps на масштабируемость и нагрузку. Его целых три недели проводила компания iits-Consulting. Оригинал читать не меньше 40 минут, поэтому сократил его, сохранив все самое важное — и теперь делюсь со всеми обитателями Хабра.

Всем привет! Сегодня я хочу вам рассказать о Peertube — некоммерческой децентрализованной видеоплатформе с открытым исходным кодом. В нем есть возможность загрузки контента, комментирования, поиска, а также изменения видео, когда оно уже опубликовано.

Peertube основан на технологии P2P (peer-to-peer) для обмена видео по принципу всех известных торрентов. Исторически PeerTube использовал WebTorrent, но уже несколько лет (начиная с версии 6.0) проект полностью перешел на протокол HLS в связке с WebRTC.

Что лучше — централизация или децентрализация? Что такое Fediverse? И наконец — как создать свой инстанс-сайт для сохранения видео на случай, например, блокировки ютуба? Давайте-ка погрузимся в теорию и практику!

В конце концов мы опубликуем свой децентрализованный видеохостинг!