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

Game Engine 3 - 2D движок с открытым исходным кодом с визуальным редактором на основе нодов, которые позволяют создавать приложения без написание кода

Год назад мы начали использовать ASR для обработки записей телефонных звонков.

TL;DR: вместо бинарных правил и end-to-end ML мы выбрали скоринговую систему поверх ASR (T-One): анализируем диалог и поведение, получаем ~98% точности при среднем времени обработки ~4.9 сек вместо 20+ сек на Whisper.
Задача казалась простой: понять, ответил ли абонент сам или сработал автоответчик, и на основании этого корректно завершить звонок и вернуть деньги пользователю при неудаче.

На практике всё оказалось сильно сложнее.

Мы работаем с телефонными розыгрышами. Записи стерео: слева абонент, справа оператор. Оператор - это заранее подготовленная аудиозапись. Первые версии системы выглядели очевидно: если абонент говорит что-то вроде «абонент сейчас недоступен», «оставьте сообщение», «говорит голосовой помощник» - это автоответчик.

Так мы и начали.

Программист часто копирует и вставляет, переименовывает и рефакторит.Вот бы сразу видеть в статусной строке количество переменных или функции в редактируемом файле. Увы, стандартный поиск (Ctrl+F) требует лишние клики.

Мой небольшой Python-скрипт для Notepad++ по дабл-клику
отображает в Status-Bar количество вхождений,
частичных или полных, с учетом регистра и без.

Нет лучше способа в чем-то разобраться, чем написать свою реализацию.

Напишем базовую реализацию хеш-таблицы, выясним, когда операция добавления, удаления и получения значения по ключу выполняется не за константное время.

Record-классы удобны, пока класс = «состояние, всё состояние и ничего кроме». Любое отклонение (API канонического конутруктора не равно внутреннему представлению, нужно наследование) ломает «автогенерацию» и паттерн-деструктурирование (destructuring).

В новом переводе от команды Spring АйО статьи Brian`а Goetz`а, архитектора Java Language, предлагается следующий шаг в направлении data-oriented programming in Java: классы-носители �� интерфейсы-носители (они же Carrier classes & interfaces). Концептуально, carrier классы родились из record-ов путем ослабления части их ограничений.

Комментарий от Михаила Поливаха: Друзья, помните, пожалуйста, что данная статья по сути является суммированием обсуждения Carrier классов из JDK Project Amber Mailing List. Я это к тому, что пока непонятно, в какой версии языка carrier классы появятся, и появятся ли они в том виде, в котором представлены в статье. Статью стоит рассматривать как пищу для размышления.

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

Мы все видим, как ассистенты и агенты меняют правила игры. То, что недавно называли «умной IDE» с подсказками, рефакторингом и статическим анализом, сегодня лишь разминка перед сбором функциональности. Ассистенты и агенты могут пройтись по десяткам файлов, обновить тесты и даже оформить базовую документацию. Но вместе с бешеной скоростью генерации пришёл и хаос. 

Поговорим о том, как не дать «вайб-кодингу» развалить ваш продакшен и почему Spec-Driven Development (SDD) — это наш новый «компилятор», которому нужно доверять.

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

Но один тезис, который виден как у автора, так и в комментариях, хочется затронуть отдельно.

У нас в компании был один проект, с которым я не справился.

Дело было так: мне сообщили, что знакомый плюсовик написал какой-то скелет проекта на питоне, а теперь мне надо его допилить, подставив в нужные места реализации. Почему тогда делал он, а не я, а сейчас должен делать я, а не он? Да чёрт его знает. Но я подумал, что смогу — унаследуюсь и переопределю методы где нужно, подставлю зависимости во всякие DI, ну что там может быть плохого?

Оказалось, что плохо вообще всё.

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

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

Короче, вот она — анти-статья, собранная из того проекта. А где мне не хватало примеров, я брал код из Django, потому что он вообще полностью собран на антипаттернах.

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

Сегодня мы с радостью объявляем о выпуске Flutter 3.41, что знаменует собой важную веху на нашем совместном пути! Это захватывающее время для разработчиков; этот релиз отражает наше стремление расширить возможности нашего сообщества в формировании направления развития Flutter. Благодаря 868 коммитам от 145 уникальных участников, Flutter 3.41 обеспечивает дополнительную прозрачность и модульность, что еще больше улучшает опыт внесения вклада в Flutter.

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

Здесь столько всего интересного, так что давайте сразу же приступим…

Я сделал сервис, который помогает проходить технические собеседования. Побочный эффект - у меня есть транскрипции 9 247 интервью. В первой части я показал общую аналитику: кто собеседуется, куда, на какие позиции, какие вопросы задают на теории. Эта часть про конкретные задачи на секции live-coding.

Энигма не сохраняет скриншоты экрана - приватность. Зато vision-модель описывает то, что видит кандидат: "код на Go, функция принимает слайс, цикл с горутинами...". По этим слепкам и транскрипциям я восстановил условия самых частых задач. Это было похоже на сборку пазла из 2 000 фрагментов, где половина кусочков одного цвета.

17 задач. 10 компаний. 5 стеков. Go, Java, Python, React, C#. С кодом, статистикой ошибок и выводами, на чём фокусироваться.

Я инженер ОВиК, и меня достало каждый день гуглить перевод кгс/см² в бары. Универсальные конвертеры не знают про Гкал/ч и кгс/м², а инженерные калькуляторы — платные или с рекламой. Написал своё Android-приложение на Python/Kivy: 10 категорий, 60 единиц измерения (включая все инженерные), 5 калькуляторов (скорость в трубе, тепловая мощность с гликолями, расширительный бак по СП 60.13330, потери на клапане, площадь изоляции). Работает полностью офлайн, бесплатно, без рекламы. Рассказываю как сделал, с какими граблями столкнулся и как выложил в RuStore.

В новом переводе от команды Spring АйО рассмотрим, как можно ускорить Java-приложения без переписываний: в свежих JDK появились Ahead-of-Time оптимизации кэша, которые выносят «дорогие» этапы загрузки/линковки классов (и даже частично профилирование методов) из рантайма в заранее подготовленный артефакт.

Рассмотрим как устроен AOT-кэш в JDK 24–26, какие есть workflow (3 шага vs 2 шага/в один прогон), где прячутся подводные камни вроде удвоения требований по памяти при -XX:AOTCacheOutput, и какие практики обучения помогут реально сократить время старта и быстрее выйти на пик производительности.

Месяц назад я закинул задачу на рефакторинг модуля авторизации и пошёл варить кофе. Кофе я допить не успел. Через двадцать минут пришло уведомление в ТГ: «staging обновлён, 94 теста пройдено, 0 упало».
Открыл репозиторий. Ветка, diff на два экрана. Code review от второго агента. Три замечания, два по делу. Третий агент прогнал тесты и задеплоил.
Код был чище, чем я обычно пишу по пятницам.
Но до этого момента были три месяца граблей, упавший продакшен, и одна ночь, когда агенты сделали десятки бесполезных коммитов. Обо всём по порядку.

Представьте: вы провели часовое интервью, записали важнейшее совещание или наконец-то зафиксировали на диктофон ту самую гениальную идею, которая пришла за рулём. А дальше начинается самое «весёлое». Сидеть и вручную переводить всё это в текст, перематывая запись снова и снова. Минута аудио превращается в пять минут работы, а час записи съедает целый вечер. Знакомо? Ещё пару лет назад это была неизбежная рутина, от которой страдали журналисты, студенты, маркетологи и вообще все, кому приходилось работать с голосом.

Но нейросети перевернули эту игру с ног на голову. Сегодня искусственный интеллект расшифровывает аудио быстрее, чем вы успеваете допить кофе. Причём не просто выдаёт кашу из слов, а расставляет знаки препинания, различает спикеров, понимает акценты и даже справляется с фоновым шумом. Технологии, которые ещё недавно казались фантастикой, стали доступны каждому: загрузил файл, нажал кнопку, получил готовый текст.

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

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

Если вы используете AI-ассистента для на��исания кода, довольно часто выясняется, что модель уверенно говорит неправду. Она выдумывает методы, которых нет в библиотеке, или описывает API, удалённый два релиза назад. Формально это называют галлюцинациями и knowledge cutoff, но для пользователя разницы нет. Ассистент ошибается именно там, где от него ждут точности.

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

Решение: RAG на документацию...

Всем привет! Я решил углубленно изучить динамическое программирование и поделиться с вами опытом. Недавно я обнаружил довольно интересный план обучения на LeetCode (https://leetcode.com/studyplan/dynamic-programming/), взял его за основу - и полностью завершил, решив все задачи (50/50).

Observability — это не просто логи или метрики по отдельности, а целостная картина поведения системы. В этой статье разберём минимальный, но полноценный стек OpenTelemetry для Go-приложений: соберём метрики, трейсы и логи, прокинем их через otel-collector и посмотрим результат в Grafana (Prometheus + Tempo + Loki).

Без лишней теории — только практический пример: docker-compose, инициализация OTel в Go, инструментирование HTTP-клиента и сервера и просмотр данных в UI. В итоге получится рабочий шаблон, который можно использовать как основу для своих сервисов.

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

Данная реализация является моделью для прототипа. Описание полной сборки и настройки, как и сборки многих других занимательных устройств я описал в своей книге "Умная робототехника для начинающих. Разработка на Arduino".

Для создания работающей модели нам понадобяться прочный, но лёгкий материал, на котором будет производиться монтаж электрокомпонентов и сам он будет использоваться в качестве несущей конструкции. Можно выбрать вспенённый пвх лист 3 мм или листовой прозрачный пластик 1,5-3 мм. Так же подойдёт корпус из под лазерных дисков.

Нам нужны электрокомпоненты. Я возьму: arduino uno, два сервопривода- четыре фоторезистора, четыре резистора на 1 кОм, соединительные провода, плата для монтажа (можно беспаечную).

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

Фоторезисторы в этом устройстве будут работать, как датчики света. Располагаться они должны по краям подвижной платформу. С какой стороны более яркий свет – в ту сторону и поворачивается устройство.