Разработка

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

Поэтому некоторые разработчики уже перешли на Spec-Driven Development — подход, в котором требования четко описаны отдельно и всегда под рукой. Звучит логично? Но попробуйте внедрить его на реальном проекте... и вы быстро поймете, почему большинство разработчиков его не используют. Одна из основных причин — спецификации хранятся отдельно от кода, и ИИ их регулярно теряет. А еще они быстро устаревают, когда вы вносите изменения. 

Но что, если спецификацию встроить прямо в код? Именно это и предложил японский разработчик в своей оригинальной статье. Он обнаружил, что Vue SFC позволяет использовать пользовательские блоки — и создал <spec> блок для коллокации спецификации с кодом, который поможет решить устоявшиеся проблемы.

Добро пожаловать под кат: разберем, как коллокация спецификаций меняет правила игры в AI-driven разработке.

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

Как «Про это» стало первой киберпоэмой. Стихотворение, которое впервые в истории использовало фотоколлаж, разбивку строк по принципу «лесенки» и типографские эксперименты, напоминающие современные веб-дизайн?

В эпоху, когда нейросети становятся первым источником знаний для многих разработчиков, особенно важно проверять их утверждения на практике. Один из таких вопросов — прямая связь между типами ожиданий в PostgreSQL и отсутствием индексов. AI-помощники часто дают логичные, но упрощённые ответы, которые могут ввести в заблуждение при решении реальных задач оптимизации. В этой статье мы экспериментально, с помощью инструмента pg_expecto, проверим , насколько обоснованно распространённое мнение о том, что IO-ожидания однозначно указывают на проблемы с индексацией.

ℹ️Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic и GitHub

kznalp/PG_EXPECTO: Комплекс статистического анализа производительности СУБД PostgreSQL

pg-expecto/pg_expecto: Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

Всем привет! В этом году в китайском городе Суджоу прошла юбилейная тридцатая конференция EMNLP (Empirical Methods in Natural Language Processing). Это одна из ведущих международных конференций по обработке естественного языка (NLP), проводимая под эгидой ассоциации компьютерной лингвистики ACL (Association for Computational Linguistics). 

Впервые конференция EMNLP прошла в 1996 году. Сегодня она посвящена эмпирическим методам, то есть моделям, основанным на данных, статистике и машинном обучении. А тогда конференция называлась Workshop on Very Large Corpora и представляла собой небольшое мероприятие ACL, посвящённое использованию корпусов текстов для обучения моделей. Тогда еще не было никаких трансформеров и уже привычных нам больших языковых моделей (LLM) и уж тем более мультимодальности, агентов и прочих хайповых ИИ-направлений. Это была эпоха статистического NLP, когда всё строилось вокруг частот, вероятностей и корпусов текстов, а в ходу были N-граммные языковые модели и скрытые Марковские модели. 

На просторах интернета легко можно найти материалы по реализации нечёткого поиска, в которых предполагается поиск одной строки в множестве строк M. Но что если возникнет необходимость реализовать нечёткое сравнение множества M₁ с множеством M₂? При классическом подходе нам придется выполнить сравнений - при линейном росте этих множеств, сложность задачи будет расти экспоненциально, в плане производительности это решение никуда не годиться!
В этой статье предложен вариант реализации ускоренного алгоритма для решения этой задачи. Теоретической новизны в проекте практически нет. Цели:
1 - Ознакомить с концепцией
2 - Дать конкретный пример интеграции в БД SQL(MSSQL)
3 - Ознакомить с возможностями на базе практической реализации

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

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

Однажды, к нам пришли наши клиенты — юристы и рассказали, что наш агрегатор обходит по эффективности их дорогие нейросетевые юридические сервисы. Но! Всегда ведь есть но, правда?. Говорят — «Ребята», продукт классный, но нам нужно больше. Научите его работать с нашими внутренними шаблонами документов, искать актуальные нормы права, подбирать свежую судебную практику». Мы, если честно, даже и не думали, что нашим B2C продуктом пользуются юристы.

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

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

Привет! Я Полина, фронтенд-разработчик в Selectel. В этой статье я решила залезть в темные уголки React и Angular, чтобы лично посмотреть, что же там происходит. Для чистоты эксперимента я выбрала шесть типовых несложных задач, для решения которых подойдет и фреймворк, и библиотека. Подробности под катом.

Привет, я — Евгений Клецов, Go-разработчик в Cloud.ru. Если вы тоже Go-разработчик, то и вам, наверняка, приходила в голову мысль добавить в свой сервис «немного AI», но казалось, что это требует погружения в незнакомый мир Python и машинного обучения. Каждый день появляются новые AI-стартапы, да и существующие сервисы не отстают с внедрением искусственного интеллекта. Еще недавно это и правда было невозможным без глубоких знаний в области ML/AI, но сейчас всё меняется. Большие текстовые модели обзавелись удобным API для работы и фактически превратились в AI as a Service. Давайте на практике убедимся, что Go тоже прекрасно подходит для разработки подобных приложений на примере RAG.

В новом переводе от команды Spring АйО Пунит Патвари недавно принял предложение о работе в Atlassian на должность ведущего инженера-программиста (Principal Software Engineer). За три месяца он прошёл более 60 собеседований в 11 компаниях, как он мне рассказал, и отказался ещё от трёх процессов после того, как согласился на предложение от Atlassian — включая собеседование в Meta*.

* Meta признана экстремистcкой организацией в России

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

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

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

А еще приглашаем вас на бесплатный вебинар 18 ноября в 11:00 мск, где разберем реальные провалы и фатальные ошибки при работе 1С в облаке. Поговорим о том, почему CPU не покажет реальных проблем, расскажем про кейс с дедлоками при нормальных показателях железа и объясним, почему 40% нагрузки должны стать вашим новым максимумом. 

Всем зарегистрировавшимся пришлем чек-лист по критическим настройкам 1С из практики обслуживания 7000 пользователей. 

Регистрация здесь

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

На данный момент я прохожу 5-дневный интенсив по AI‑агентам от Google. Эта статья представляет собой перевод оригинального материала, выполненный с помощью Gemini и мной. В этой статье вы узнаете как сделать так, чтобы ИИ не просто «отвечал», а «понимал» и «запоминал»? И если вы когда‑либо задумывались о том, как научить LLM‑агентов вести осмысленные, долгосрочные беседы, эта статья станет вашим проводником в мир сессий и памяти, которые формируют ИИ агентов.

Ученые из Московского физико-технического института (МФТИ) и Всероссийского научно-исследовательского института автоматики им. Н.Л. Духова (ВНИИА), Евгений Андрианов и Олег Толстихин, разработали теорию, которая показывает, как казалось бы пассивное облако свободных электронов, рожденных при ионизации газа мощным лазером, способно кардинально изменять саму квантовую природу этого лазерного света. Их работа, опубликованная в журнале Physical Review A и отдельно особо отмеченная редакцией (Editors’ Suggestion), предсказывает формирование так называемых неклассических и негауссовых состояний света, включая состояния с кольцеобразной функцией Вигнера, что открывает новые пути к созданию и управлению светом для будущих квантовых технологий.

Привет, Хабр! Меня зовут Иван, и сегодня я хочу поделиться историей о своём пет‑проекте A‑Zero. Истории про провалы традиционно интереснее историй об успехах, и моя как раз такая (почти). Довольно бодро начинавшийся проект чуть было не свёл меня с ума из‑за одной единственной фичи, «просочившейся» в MVP, и сейчас я расскажу, как я из этого выкарабкался и чему научился по дороге.

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

Финальная толщина печатной платы формируется из нескольких основных компонентов.

Тон данной публикации задал товарищ @kiltum в своих статьях, начатых с этой. В самом начале был задан вопрос

может ли ИИ заменить программиста?

А действительно? Сколько вокруг этой темы хайпа, нет ни дня чтобы здесь на ресурсе не появилось 100 500 статей на тему нейросетей, LLM, ML и прочего. Пишут много и всякое. Возникло желание проверить лично, насколько решения, предлагаемые ИИ могут быть воплощены в жизнь.

Системы ИИ прочно вошли в нашу жизнь, и да, я тоже ими регулярно пользуюсь. Но мысли программировать с их помощью особо не возникало. Но что если попробовать, поставив при этом задачу из предметной области в которой ты не особо разбираешься? Похожий вопрос ставит и @kiltum, но я хочу попросить автора не ругаться на мою невольную попытку «пообезьянничать». Своей публикацией я лишь хочу подкрепить уже высказанные тезисы, на примере личного опыта. К тому же, старое железо — это всегда интересно, не правда ли? Если так, то добро пожаловать под кат.

JOIN vs коррелированный подзапрос: мой разбор мифа «JOIN всегда быстрее»

Я проверил оба подхода (JOIN + GROUP BY и коррелированный подзапрос) на маленьком датасете и в ряде СУБД. Иногда подзапрос быстрее. Всё зависит от плана (Nested Loop vs Hash) и индексов. Слепо верить «JOIN всегда быстрее» не стоит. Смотрите EXPLAIN.