Команда JavaScript for Devs подготовила перевод большого апдейта от команды TypeScript. Разработчики рассказали, как идёт переписывание компилятора на нативный код, что уже работает в превью TypeScript 7, какие ограничения остаются и почему версия 6.0 станет последним релизом на JavaScript. Новый TypeScript обещает серьёзный рывок в скорости и стабильности — самое время понять, что нас ждёт.
Команда AI for Devs подготовила перевод статьи о том, как AI-агенты на базе LLM тратят лишние деньги из-за разрастающегося контекста и как простое маскирование наблюдений нередко работает лучше сложного LLM-суммирования. Авторы предлагают гибридный метод, который делает агентов дешевле и надёжнее без дообучения модели.
Я уже около года занимаюсь выведением в опенсорс общего кода, который используется у нас, в Gaijin Entertainment — порой, это бывает непросто. Как с точки зрения выбора — у нас около двухсот пакетов которые считаются обобщенными, так и со стороны облагораживания кода до состояния "и людям не стыдно показать". Но, Я сюда не жаловаться пришел, а делиться опытом😉
Эту статью Я решил начать совместно с принятием решения о том какой пакет будет следующим и на его примере, рассказать через какие этапы Я прошел в процессе.
Привет, Хабр!
Многие во Flutter привыкли собирать интерфейс из виджетов, не задумываясь, как они вообще устроены. Действительно, стандартных виджетов хватает почти на всё. Почти. Иногда возникает задача, где готовых решений нет или их производительности недостаточно. В такие моменты хочется залезть в движок Flutter и написать что-то своё на уровне рендеринга. Звучит немного страшненько, но я посмотрим, как сделать собственный RenderObject (конкретно RenderBox) с нуля.
Недавно провели стрим, где собрались специалисты, у которых ИИ не в презентациях, а в production. Провели разговор про галлюцинации моделей и про будущее разработки с ИИ. Ниже основные мысли — получился материал про три уровня работы с ИИ (вайб-кодинг, ИИ-ассистированная разработка и промышленный конвейер), про экономику вопроса и про то, почему галлюцинации — это не приговор, а управляемый риск.
Привет, Хабр!
Знаете, что объединяет разработчика из стартапа, архитектора банковской системы и техлида платежного сервиса? Все они хотя бы раз материлась над интеграцией, которая должна была занять день, а растянулась на месяц. Легаси не подружилось с новой системой, протоколы оказались несовместимы, а документация — устаревшей на три года.
Привет, Хабр!
Я двадцать лет работал в руководстве ИТ в банках и страховых компаниях. За это время через меня прошли десятки проектов заказной разработки. Некоторые из них я вспоминаю с гордостью. Некоторые — с содроганием.
Всё началось с внутреннего предложения на работе присоединиться к отделу по развитию и поддержке веб-сайтов (название другое, но это их обязанности, поэтому написал так). Это была одновременно лестная и пугающая перспектива. Возможность работать над реальными проектами манила, но мой опыт в веб-разработке был скорее теоретическим. Я понимал, что для старта мне нужен был собственный, понятный проект, который стал бы началом.
И тут я вспомнил о своей идее сделать сайт для консольной реализации шахмат на Python. Это была сухая игра, написанная на Pygame для двоих программистов, но не для людей, так как её нельзя было запустить на других устройствах. И у меня родилась идея: а что, если превратить этот скелет игры в веб-приложение на JS?
Из минусов было только то, что моя игра написана на языке Python, а для работы мне нужен JavaScript, и я решил, что это не проблема, и начал переписывать готовую логику на новый язык, параллельно добавляя новые функции.
Идея зацепила сразу, представьте: вы переносите свой проверенный, рабочий кейс, у которого вся шахматная логика (проверка ходов, матов и пат) уже работает и ничего нового придумывать не надо, нужно только сделать интерфейс для браузера и все новые идеи (например, таймер).
Привет, меня зовут Иван и я SDET‑специалист в SimbirSoft. Полагаю, каждый программист хотя бы раз слышал про инструмент Kafka, многие работали с ним. Наиболее простое его использование — это настройка взаимодействия между микросервисами. А если попробовать использовать его как инструмент для логирования — связать Kafka и Elasticsearch? И при чём тут вообще Elasticsearch? Все просто: это система, которая позволяет работать с большим объемом данных. В нашем случае также необходимо использовать Kibana, надстройку над эластиком, которая позволит визуализировать данные.
В этой статье мы рассмотрим процесс настройки потоковой передачи логов из Kafka в Elasticsearch:
— как настроить взаимодействие между Kafka и Elasticsearch
— как настроить Kibana для визуализации логов, хранящихся в Elasticsearch.
Эта статья будет полезна тестировщикам для настройки анализа логов в распределённых системах, а также разработчикам, желающим реализовать альтернативные сценарии использования Kafka для централизованного логирования.
Много лет пользовался проектом https://github.com/antirek/alarmo для отправки сообщений с идентификацией по номеру телефона в viber и telegram. Но современные реалии диктуют новые условия и пришлось потратить время чтобы сделать аналогичное решение для нового мессенджера MAX. В текущем моменте регистрация ботов доступна только для корпоративного сегмента, но я думаю это не проблема.
Готового решения я не нашел, поэтому сделал на коленке свое, буду надеяться что кому-нибудь поможет и пригодится. Как поставить Docker и Docker-compose я думаю каждый найдет в интернете, а вот с новинкой в виде MAX пока информации маловато.
В предыдущей статье я рассматривал различные способы организации стековых корутин в языке Си. Эти сопрограммы имели чисто учебное значение так как вряд ли кто-то будет создавать генераторы последовательностей при помощи сопрограмм. Сегодня рассмотрим как писать стектовые корутины на С++ и создадим на их основе tcp сервер, обрабатывающий запросы от клиентов на основе опроса событий с использованием API мультиплексированного ввода-вывода epoll. Данная тема, на мой взгляд, является ключевой для понимания того, как функционируют современные серверные приложения, написанные при помощи таких библиотек как Boost Asio.
Недавно на Хабре появилась функция "Объяснить код с SourceCraft", реакция на которую была неоднозначна из-за довольно странного решения сделать эту функцию обязательной, а не опциональной. Мусолить эту тему особо желания нет, а вот пройтись по существу хотелось бы, потому что как мы все знаем LLMки довольно хороши в коде, который уже миллион раз был выложен в открытый доступ, но вот со всякими редкими штуками есть проблемы, а еще они позвиздеть любят. В этой статье распишу как я прошёлся по сниппетам кода в двух своих статьях на хабре, попросил SourceCraft пояснить сломанные варианты этих сниппетов, и что из этого вышло. Спойлер: результат лучше, чем я предполагал, штука определённо полезная если использовать с умом.
Дисклеймер. За эту статью мне никто не платил, в ней есть сгенерированный контент, он явно обозначен и спрятан под спойлеры, а я вообще скептик относительно AI, но стараюсь трезво и честно оценивать его.
Где проходит граница между случайностью и замыслом? Почему в наших ДНК куча мусора? Можно ли воспроизвести эволюцию в машине, и как зарождалась жизнь? Хотя и на последний вопрос ответа нет, но мы можем создать эксперимент, который позволяет моделировать механизмы эволюции с нуля. О таком эксперименте из области Artificial Life (искусственной жизни, где эволюция идёт внутри компьютера) и пойдет речь сегодня.
Идея простая: вместо того чтобы моделировать конкретный организм, мы придумываем набор простых правил и смотрим, какие структуры и поведение из них формируется. Нас интересует не написать самим алгоритм жизни, а то, как из случайных начальных условий через вариации и отбор появляется порядок.
GUCA (Graph Unfolding Cellular Automata) — один из таких маленьких миров: в нём мы выращиваем “организмы” из узлов и рёбер графа.
Больше, чем сам АИ, меня бесят только топы АИ‑компаний, которые дуют щёки и втирают, что сейчас АГИ уже вот‑вот за углом, что вот‑вот они заменят всех программистов, суппортов и прочих бесполезных проедателей денег за свой псевдоинтеллектуальный труд, который, очевидно (!), сводится к генерации текста. Как же эти негодяи рисуются и втирают, что они решают проблемы масштаба всего человечества! В то время как на самом деле все проблемы, которые они решают — это набивание собственных карманов.
Больше топов меня бесят только коллеги, которые дуют щёки и говорят, что вот они‑то познали искусство промтинга, и теперь они — 10х программеры, потому что вместо того, чтобы делать задачи самим, они запускают пяток‑другой агентов, и те пишут код лучше, чем они.
Во‑первых, ребята, если агенты правда пишут код лучше, чем вы — у меня для вас плохие новости...
В статье рассмотрен паттерн проектирования «Буфер» как мощный инструмент оптимизации и повышения надежности систем. Показано, чем отличается архитектурный паттерн от простого буфера памяти, приведены разновидности и примеры использования в разных областях: от сетевых протоколов и логирования до встроенного ПО и GPU. Особое внимание уделено ошибкам при смешении понятий, тестированию эффективности и общим параметрам буферов.
Статья поможет разработчикам и архитекторам осознанно применять паттерн Буфер для создания производительных и устойчивых решений.
Я полюбил программирование ещё молодым. Мне очень нравилась удовлетворённость от достигнутого результата и сам процесс решения задач. Ещё я любил делиться своими достижениями с другими, просто ради их удивления или в качестве помощи.
Один особенно мудрый взрослый (где-то в 1996 году) однажды отвёл меня в сторону и сказал: «Знаешь, хорошо, что программирование приносит тебе удовольствие, потому что в будущем оно тебя не прокормит. Делать это из любви, а не ради денег — отличный подход.
Программированию приходит конец. Объектно-ориентированный подход позволит одному человеку, который будет намного умнее любого из нас, один раз написать библиотеку, которую мы будем использовать бесконечно. Решив какую-либо задачу, повторно решать её больше не придётся.
Через пять лет соберётся целая библиотека объектов, где они будут лежать подобно книжкам на полках, и бизнес сможет решать любую программную задачу по щелчку пальцев, просто комбинируя нужные библиотеки как детали LEGO. Вы ему не потребуетесь».
Я начал размышлять об этом совете и о том, что разработка ПО сойдёт на нет к тому моменту, как я поступлю в институт. Тогда я понял, что ещё даже не думал о перспективах своего образования. Я учился в средних классах и уже явно понимал, что это будет не программирование.
И вот я здесь почти 30 лет спустя, и разработка, несмотря ни на что, продолжает меня кормить. Существует опенсорс, и всегда находятся библиотеки, с помощью которых я могу скроить что-то нужное. Постоянно возникают новые серии задач, для которых ещё нет готовых решений. Комбинирование деталей LEGO по-прежнему требует усердного труда. Как только я решаю эту задачу на одном уровне абстракции, мы переходим на другой… и так продолжается по кругу.
На конференции Joker 2025 у нас была отличная возможность понять, как живётся Java-сообществу.
Как AI влияет на Java-разработку? Вайб-кодинг — полезный инструмент или угроза рабочим местам? Spring — незаменимый фреймворк или слишком тяжёл для многих задач? Что с рынком труда и зачем кандидаты накручивают опыт? И главное — зачем писать на Java, если есть JavaScript?
Начну, пожалуй, с предыстории. Несколько лет назад завел себе домашнего питомца, королевского питона. Пуф вырос классным змеем и сих пор эта наглая колбаса является моим верным антидепрессантом. В итоге это привело к том, что заинтересовался фильмами по змеям. Но, как назло, большинство фильмов идут на английском или испанском языке. Нет, не то, чтобы я не знал английского, будучи разработчиком, да и когда‑то заканчивал языковую школу с углубленном изучением ин. языков, однако вечером, с пивасом и креветками смотреть английскую озвучку.... в общем, не каждому это по душе. И тут пришла в голову мысль, «а чтобы нам не использовать ИИ для перевода фильмов», к тому же множество компаний уже предлагают подобные решения. Но мне было ещё интересно изучить этот вопрос и пройти весь путь самим.
От переводчика: статья немного сокращена по сравнению с оригиналом, исключён раздел об этимологии слова "Ouroboros", а также полные каламбуров отсылки автора к латинским, прочим романским и английским корням.
Далее - от автора.
Можно ли создать язык программирования, в котором нет синтаксиса? Кажется, что это чистое противоречие. Вся суть языков программирования заключается в синтаксисе, плюс немного в генерации и оптимизации кода, настройке сред выполнения и т.д. Но с точки зрения программиста — именно синтаксис самая важная часть языка. Когда вы приступаете к изучению нового языка программирования, вам обязательно придётся уделить время освоению синтаксиса.
Можно ли просто избавиться от синтаксиса или, как минимум, предельно его упростить? Другой вариант — можно ли сделать синтаксис произвольным, чтобы программист, пишущий код, мог сам для себя его определять?
Именно этих целей мы попытались достичь, создав язык Ouroboros. Его синтаксис максимально прост. Настолько, что в этом языке даже не предусмотрен синтаксический анализатор. В нём есть только лексический анализатор, код которого составляет 20 строк.
Стоит задача разделить два числа, то есть найти частное от деления и остаток, используя встроенный в процессор алгоритм деления двухразрядного числа на одноразрядное, который дает лишь одноразрядное частное и остаток.
Ограничимся делением двухразрядных чисел без знака. Деление чисел большей разрядности можно обобщить, при необходимости обратившись к первоисточнику [1]. Описываемый алгоритм назовем «программный 128/128». Заметим, что во многих 64-битных компиляторах он реализован (GCC, Clang, Intel Compiler) и может быть использован напрямую без изобретения велосипеда.
Цель данной статьи — подробно объяснить детали алгоритма, чтобы снизить порог входа в энциклопедические труды Д. Кнута, в том числе объяснить почему деление в процессоре дает лишь одноразрядное частное (конкретно для 64-битных процессоров можно делить 128-битное число на 64-битное, получая лишь 64-битное частное). Назовем процессорный алгоритм деления как «аппаратный 128/64».
Ключевым моментом в понимании алгоритма деления является процесс нормализации чисел, который позволяет воспользоваться встроенным в процессор делением 128/64.
Алгоритм деления двухразрядных чисел в зависимости от разрядности делителя разделяется на два: половинчатое деление, когда делитель по факту одноразрядный, и полное деление, когда делитель двухразрядный. Назовем первый алгоритм как «половинчатый программный», а второй как «полный программный». Заметим, что «аппаратный 128/64» является половинчатым; он будет использован в обеих ветках программного алгоритма.
