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

Проверил реализацию Boyer-Moore в TheAlgorithms/Python (190K+ звёзд). Оказалось, что сдвиг bad character записывается в переменную for-цикла, что в Python не имеет эффекта. Алгоритм выдаёт правильные результаты, но работает как brute-force O(nm) вместо O(n/m). Плюс ещё две находки: бесконечный цикл в типичных реализациях full BM и ошибка в оригинальной статье 1977 года, которую исправили только в 1980-м.

Мы уже разобрались с тем, что такое BaaS, почему появились Firebase и Supabase, чем они отличаются от обычного backend и можно ли самому собрать что-то похожее.

Как я и говорил в прошлой статье, сегодня мы наконец попробуем самостоятельно собрать альтернативу Firebase с Realtime исключительно на open-source компонентах!

Но важная оговорка: мы не будем делать полный клон Firebase с его тонной функционала, но мы соберем минимальную рабочую альтернативу, которую уже можно подключить к frontend через SDK и использовать почти как Firebase.

Сколько лекций по карате нужно прослушать, чтобы уверенно противостоять нескольким хулиганам в тёмном переулке? Звучит нелепо, правда? Тогда сколько лекций по информатике нужно прослушать, чтобы научиться пользоваться компьютером? Компьютером в широком смысле — аппаратной частью, существующими программами и создавать свои программы под конкретные задачи. И может оказаться, что информатика не учит программировать, особенно если студента или учащегося не готовят именно как программиста. А ведь всё могло бы быть иначе.

Привет! Продолжаю разбирать классические задачи с System Design интервью на стримах (за анонсами можете следить тут https://t.me/siliconchannel), а это текстовая версия стрима. В прошлый раз была бесконечная лента, сегодня очередная классика жанра - веб-краулер. Условие звучит примерно так:

Я часто вижу в комментариях выражения, типа "ИИ не заменит программиста, потому что ИИ выдаёт недетерминированный результат". Но ведь и человек не выдаёт детерминированный результат. Много ли вы знаете людей, которые могут написать программу на тысячу с лишним строк, а затем повторить её байт в байт? Ладно, согласен - это возможно. Ну а на 10 тысяч?

Из опыта общения с ИИ могу сказать, что ИИ более детерминирован в своём поведении, чем многие люди, несмотря на свою вероятностную природу. Теория вероятностей плохо предсказывает результат бросания одной монеты - "орёл" или "решка", зато хорошо предсказывает, что на миллион бросков "орлов" будет не менее 400 тысяч, впрочем, как и "решек".

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

"Хау, я всё сказал!" (с) ЧБЗ

У меня было полторы сотни кросс-языковых фикстур, все тесты зелёные, и я был уверен, что мой Go-порт Yjs байт-в-байт совместим с оригиналом. Потом сравнил байты напрямую с канонической реализацией, и они разъехались: семантика сходится идеально, а на проводе документ толще.

Юнит-тесты, roundtrip и даже конвергенц-тесты систематически пропускают баги совместимости, когда портируешь чужой бинарный формат на другой язык. Рабочий метод один: генерировать фикстуры из канона и требовать в CI побайтового совпадения в обе стороны.

Разбираю конвейер и три реальных бага из трёх своих портов (Yjs, Loro, Willow): документ в 12 раз толще канона, big-endian остров, который молча портил бы все float’ы при обмене, и дыра, через которую 9-байтный апдейт заказывал make() на 67 ТБ. Метод обобщается на любой «порт формата X на язык Y», CRDT тут просто материал.

Хабр, привет! Меня зовут Илья Благородов, я занимаюсь разработкой уже 30 лет, в том числе — выступаю экспертом в онлайн-магистратуре «Фронтенд и бэкенд-разработка» ИТМО в партнёрстве с Яндекс Практикумом. В этой статье я хочу поделиться своим взглядом на то, что происходит с профессией в 2026 году, что действительно изменилось, а что осталось прежним, и как сегодня новичку войти в профессию.

Если вы работаете с Claude Code или Cursor на большом проекте, знаете боль: просишь “найди, где обрабатывается авторизация”, а агент гоняет grep по ключевым словам. Если функция называется validateUserSession, а вы спросили про “авторизацию” — grep её не найдёт. Это ограничение текстового поиска, и его решает семантический поиск через эмбеддинги. Я уже разбирал CodeGraph и SocratiCode из этой ниши, теперь поставил третий — cocoindex-code. Зацепил тем, что ставится в две команды без Docker и баз данных. Прогнал на своём проекте, разобрался с AST-чанкингом и сравнил с аналогами.

Месяц назад я тут рассказывал, как сделал свой сервис для обмена чувствительной и приватной информацией Copy Sync - устроенный так, чтобы мой сервер физически не мог прочитать ваши пароли и ссылки. Текст шифруется прямо на вашем устройстве, на сервер уезжает уже зашифрованная каша, ключа от неё у меня нет.

Многие тогда справедливо спросили в комментах: "а ключи-то от шифрования откуда устройства берут?" Вопрос в точку. И в той статье я сам честно написал, что тут осталась слабое место. Вот её и чиню.

Недавно я написал две статьи про решение проблем с доступом с Claude Code, Antigravity и другими сервисами из России (часть 1, часть 2), но практика показала, что доступ мне к ним нужен не только с домашнего компьютера, но и с телефона, когда я нахожусь на улице. А с этим сложнее. У мобильных операторов какие-то свои, особые правила маршрутизации интернета.

В прошлый раз мы решали проблемы с использованием VPS с заграничным IP, но на улице они не работают, поэтому там, где не помогает 1 VPS, проблему решат 2 VPS.

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

Всем привет! 

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

Я не смогу передать всё содержание разговора, но постараюсь вынести для вас самое главное — где-то спорное, местами смешное, но очень честное. Если хотите послушать и узнать больше, — вот тг-канал подкаста. Там есть ссылки на беседу на разных платформах. 

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

В этой статье мы порассуждаем о поиске некоего «универсального» SDK (Software Development Kit), который бы всем нравился, как новогодняя ёлка.

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

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

Для каждого из этих подходов рассмотрим конкретные реализации, выделим плюсы и минусы, приведём примеры использования. В конце объединим все реализации в общую таблицу.

Исполним обещанное в [1], где упомянута задача о светофоре Ангера [2]. Она интересна формулировкой, которая заметно отличается от аналогичных задач, и утверждением, что более компактного решения, чем предложенное автором монографии, не существует.

Обычно светофоры моргают, «тупо» реализуя фиксированную временную последовательность. В светофоре С..Ангера есть динамизм. Он определяется датчиками, фиксирующими ситуацию на перекрестке. И это само по себе интересно. А утверждение формальным путем, сомневаться в справедливости которого оснований, казалось бы, нет.

Но нет исследователя, который не ставил бы перед собой задачу доказать недоказуемое или опровергнуть неопровергаемое. И один из способов достичь желаемого – создать решение, подтверждающее вашу правоту. Как настоящие исследователи, мы именно это и попытаемся сделать, опровергнув, если удастся, тем самым утверждение С.Ангера.

А начнем мы с реализации светофора в исходной формулировке, хотя и в рамках другой формальной модели [3].

В прошлой главе мы начали разбирать порт тайловых миров на F#, где познакомились с некоторыми малоизвестными возможностями Godot. В этот раз наш прицел сместится с технологических особенностей RenderingServer на обычную бытовуху (бизнес-логика + высокоуровневое рисование).

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

Это первая из двух статей о CancelledError — сигнале отмены задачи. В ней мы остановимся на стандартном asyncio. Узнаем, что на самом деле представляет собой CancelledError, с точки зрения event‑loop. Разберёмся, как работает счётчик отмены (cancel/uncancel), на котором построены TaskGroup и asyncio.timeout. Наконец, обсудим проблемы, которые возникают на практике, в первую очередь связанные с asyncio.shield.

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

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

Привет, Хабр!  Меня зовут Александр Сахаров, я Член Правления и директор по работе с технологическими партнерами компании «Диасофт».

Недавно провели Летний день для клиентов и партнеров – на нем мы представили наше видение ИИ трансформации процесса разработки ПО и провели демонстрацию новой AI Driven версии нашей Экосистемы Digital Q.

Ключевая мысль: уже этим летом любая команда разработки может скачать с сайта Экосистему Digital Q и начать выпускать ПО высочайшего качества со скоростью в 10 раз быстрее, чем сегодня.

Это вторая статья об использовании LLM в проекте разработки компилятора языка программирования как транспилятора в код на C++. Я продолжаю историю и хочу рассказать о своих наблюдениях и впечатлениях от попыток применять автономных агентов в большом и сложном проекте. А также о навязчивой рекламе и встроенных «закладках» в коде некоторых инструментов, которые, похоже, целенаправленно ухудшают работу с моделями конкурентов.