Команда AI for Devs перевела статью, показывающую, что открытые веса — это не только про прозрачность, но и про утечку тайн обучения. На примере модели GPT-oss автор показывает, как можно восстановить части обучающего пайплайна и даже выявить, что GPT-5 видела фразы с сайтов для взрослых.
Когда в 19-летнем возрасте я покупал свой первый компьютер, то я очень сильно хотел купить БК-0010-01. Однако обстоятельства сложились так, что к моменту, когда у меня появилась необходимая сумма, в магазинах БК‑шек не осталось, и вообще ничего не осталось. На полке в «Электронике» лежало только невзрачное нечто с нарисованной клавиатурой и названием «ЛИК».
Ты живёшь, а мир вокруг превращается в цифру. Было аналоговое - стало цифровое. Было живое - стало искуственное. И ирония в том, что мы, айтишники, и делаем эти изменения. Мы не просто свидетели Иеговы, мы сами это и кодим.
Но сколько в нашей работе курьёзных моментов. И сколько песен было сложено про любовь, и, скажем, осень. А вот про бессонный деплой, бесконечный рефакторинг, костыли, эпические баги - мало. Совсем мало. Может быть потому что нас, ИТ-шников мало? Да много нас, и с каждым годом нас только больше. На мой взгляд, про нас не поют просто потому, что про любовь все знают, а про ИТ-шные угары знаем только мы.
Большинство тестов языков программирования — это синтетика. Мы сравниваем скорость сортировки массивов, подсчёт аллокаций и другие упражнения, которые почти не встречаются в реальной жизни.
А вот настоящие приложения — редакторы, движки, интерфейсы, базы данных — живут совсем в другом мире. Они управляют не числами, а сложными структурами объектов. И если присмотреться, почти все эти структуры сводятся к одной универсальной модели: DOM-подобному графу.
Давным-давно, когда с ездовым котом приключилась "записка шестая", а знания об аллокаторах и опыт их применения ограничивался линейным и системным, перебросили мою команду в помощь другой команде, которая занималась системами навигации больших судов. Ездовые коты, особенно нестарые - это такие создания, которые редко изучают документацию детально, а чаще бегло читают там про интерфейсы систем в проекте, malloc, new, системные аллокаторы и думают, что теперь-то точно понятно, как всё устроено. А потом приходит работа и такая: “Забудь всё, что ты знал. Ты не дочитал до страницы восемьсот что-то там РД, тут есть свой аллокатор - и он реально плохой”.
Примерно так началось мое погружение в мир ненормального распределения памяти. Это сейчас я знаю с десяток разных аллокаторов, и специфику их работы, специфика правда больше игровая, но думаю многим будет интересно - зачем нужны все эти "танцы с аллокаторами". В той статье все аллокаторы еще более менее нормальные, но есть еще ненормальные и они оказывается тоже нужны, и в определенных сферах разработки очень даже важны и применяются.
А вот почему нужны и важны ненормальные - объяснений почти нет, как и самих реализаций в открытом доступе. В этой статье я расскажу, какие повстречал ненормальные алгоритмы распределения памяти, чем они живут, кого едят, и почему иногда malloc делает вид, что он не при делах и таки да, malloc может возвращать null и ту проверку мы убрали зря.
Привет, Хабр! Представьте у вас есть идея для небольшого приложения. Вы начинаете продумывать его структуру и реализацию. Перед вами предстает ворох проблем; прописать разметку, стили, логику, отладить баги. Эти задачи могут вызвать затруднения у начинающих программистов и предпринимателей. А что если бы у вас был персональный ассистент, который не просто подсказывает код, а сам пишет его по вашим инструкциям на естественном языке?
Протокол Model Context Protocol (MCP) стремительно развивается, и вопросы его безопасности становятся всё актуальнее. Чтобы упростить реализацию защиты MCP-серверов в проектах на Spring AI, был запущен инкубационный проект spring-ai-community/mcp-security. В новом переводе от команды Spring АйО рассмотрим, как защитить MCP-сервер с помощью OAuth2 или API-ключей, а также как развернуть собственный MCP-совместимый Spring Authorization Server.
Привет! Вообще у меня свой бизнес есть, а программирую я так, для души.
Нет, серьезно, я не умею программировать, но всегда хотел запустить свой IT-продукт.
Стать настоящим стартапером, как ребята из Кремниевой Долины. Сделать сервис, которым будут пользоваться люди, и за который они будут платить. И чтобы все само работало, без этих вот отделов продаж, встреч, договоров, актов и прочего.
И вот в последнее время я все чаще видел истории в интернете, как люди в одиночку запускали свои сервисы с помощью нейронок. Говоришь бездушной машине, что делать, она пишет код, он чудесным образом работает — продукт готов.
Решил попробовать тоже.
Увидел, как кто-то в Телеграме опубликовал пост с мемасом внутри поста, собранным из эмодзи.
В жизненном цикле разработки код — это лишь заполненные клеточки кроссворда. Самое интересное — в размышлениях: изучение предметной области, уточнение требований, продумывание архитектуры, поиск компромиссов, поэтапное тестирование и отладка.
Если коротко, процесс выглядит примерно так: сначала думаем — потом пишем. Но с приходом ИИ-кодинга всё изменилось.
В ноябре 2024 года я написал пост «Действительно ли Python такой медленный?», в котором протестировал множество версий Python и отметил стабильный прогресс производительности языка.
Сегодня девятое октября 2025 года, прошла всего пара дней после официального релиза Python 3.14. Давайте снова запустим бенчмарки, чтобы проверить, насколько быстра новая версия Python!
Примечание: если вам неинтересны таблицы и графики и вы хотите просто прочитать мои выводы, сразу переходите к концу статьи.
Одним томным вечером наши разработчики собрались в баре на тимбилдинг и подняли хрестоматийные вопросы: почему нельзя делить на ноль и почему ноль в степени ноль зачастую принимается за единицу. О том, что делить на ноль нельзя, всем известно ещё со школы. На деле это не просто правило, а фундаментальный запрет. Пример простой:
Представим, что у нас есть кастрюля компота объемом 10 литров (10 000 мл):
Команда Python for Devs подготовила перевод статьи о PEP 8. Мысль проста: споры о стиле в Python часто сводятся к одному — snake_case против camelCase. Даже сам Python не следует своим же правилам. Так стоит ли вообще относиться к PEP 8 как к догме?
Команда AI for Devs подготовила перевод статьи об инженерии контекста — новом ключевом подходе в построении AI-агентов. Если раньше все говорили о prompt engineering, то теперь на первый план выходит умение управлять ограниченным ресурсом — контекстом. Компакция, заметки, подагенты, динамическая подгрузка данных — всё это формирует новое искусство работы с LLM.
Привет, Хабр! Я Николай Видов, разработчик в команде чатботов. Я работал как в небольших компаниях, так и в тех, которые на слуху: EPAM, QIWI, Т-Банке. За время работы я часто сталкивался с понятием продуктовости: «Разработчики должны активно участвовать в бизнесе», «Разработчики должны предлагать улучшения для продукта», «Разработчики должны аргументированно спорить, если не согласны с предложенной функциональностью».
Раньше я думал, что все это пустая болтовня и не моя забота. Моя задача — писать код и делать это на высшем уровне. Но спустя годы осознал, что это важный шаг в карьерном развитии разработчика, который хочет быть вовлеченным и полезным для бизнеса.
Продуктовый разработчик — это следующая ступень эволюции разработчика, который активно участвует в бизнес-процессах. © Никита Пастухов, мейнтейнер FastStream
В статье поделюсь принципами продуктовой разработки и расскажу, как стать ценным продуктовым разработчиком для бизнеса, основываясь на своем опыте. Будет кратко и полезно, без тайных знаний и секретных ингредиентов 🙃
Вы тоже хоть раз ловили себя на мысли: «А может, ну его, этот Node.js — перепишем всё на Rust, и будет летать?»
Поздравляю — вы не одиноки. Я тоже через это прошёл.
В этой статье я разложу по полочкам, когда действительно стоит лезть в Rust, а когда лучше остаться на TypeScript и просто выспаться. Без фанатизма, маркетинга и с примерами из практики.
Привет, Хабр! Недавно мы запустили Wunder RNN Challenge — соревнование по машинному обучению, где нужно предсказывать следующее состояние рынка по последовательности предыдущих состояний.
В этом посте мы расскажем, что это за состояние рынка, и в чём вообще прикол.
📅 Решения принимаются до 1 декабря
💰 Призовой фонд $13,600
Привет, Хабр!
Все мы привыкли к операторам Kubernetes с их паттерном leader election. Один под становится лидером, остальные молча ждут своей участи в тени, обрабатывая события только через его призму. Надежная схема? Безусловно. Но что, если я скажу, что можно создать оператор вообще без единой точки отказа, где каждый под равен друг другу, а координация действий происходит через механизм слухов, gossip-протокол? Звучит как ересь? Возможно. Но это работает.
Дружелюбный русский алгоритмический язык, который обеспечивает наглядность сокращенно ДРАКОН — визуальный язык, созданный в СССР для космической программы «Буран». Его разработали для задач высокой ответственности, где ошибка недопустима. Основная цель ДРАКОН — сделать логику однозначной и понятной. Сегодня мне кажется, что ДРАКОН может обрести новую жизнь благодаря искусственному интеллекту. Я не встречал статей о его применении с ИИ, и поэтому решил написать об этом.
В этой статье я разберу практический кейс: от простого алгоритма до готового кода через JSON-представление и проверку логики. Задача будет элементарной, но цель — показать смысл такого подхода. В конце статьи приведу пример из сферы, не связанной с программированием и мы разберём его на примере работы с ДРАКОН.
Салют, Хабр!
Я Алексей, занимаюсь ассистентом в SberDevices. В свободное время занимаюсь дискретной математикой, поэтому обожаю регулярные выражения — они по сути довольно близки к предмету моих интересов и делают код удобоваримее. В этой статье хочу рассказать о математике регулярных выражений и их интересной особенности, которая возникает внезапно
Последние 4 года я занимаюсь реализациейпроектов на PHP по DDD, используя слоистую архитектуру. Каждый раз я сталкиваюсь с одной из самых насущных проблем DDD: определение границ агрегата. Ведя разработку «как удобно», очень легко не заметить, как вся бизнес логика сосредоточилась в один «божий класс».
В этой статье я поделюсь своим опытом, как проектировать и разрабатывать по DDD, не скатываясь в «один агрегат, чтобы править всеми». Поговорю о проблемах определения границ агрегата и цены чтения, гидрации и содержания больших объектов в памяти PHP процесса.
