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

Большинство ИИ-ассистентов работают в облаке. А я сделал локальный — прямо внутри мессенджера HalChat.

Синтаксис сокращённой записи через точку — .foo — позволяет писать более лаконичный Dart-код, опуская имя типа там, где компилятор может вывести его из контекста. Это аккуратная альтернатива полному варианту вида ContextType.foo при обращении к значениям перечислений (enum), статическим членам и конструкторам.

Теперь язык стал еще более лаконичным.

Сегодня мы рады объявить о выпуске Dart 3.10!

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

В этом выпуске также реализован ряд улучшений pub.dev и управления пакетами. Вы найдёте новые возможности поиска на вкладке «Нравится» в своём профиле, а авторы пакетов теперь могут отключить ручную публикацию для повышения безопасности. Наконец, мы добавили набор новых, более точных аннотаций об устаревании , чтобы вы могли более точно контролировать развитие своего API.

Продолжайте читать, чтобы узнать больше об этих и других улучшениях в Dart 3.10.

Добро пожаловать в наш ежеквартальный релиз Flutter 3.38. Это обновление призвано повысить вашу продуктивность и улучшить взаимодействие с разработчиками благодаря сокращённым точкам и обновлениям для предварительных просмотров виджетов. Благодаря нашему сообществу этот релиз включает в себя в общей сложности 825 коммитов от 145 уникальных участников, 37 из которых — новички. Давайте разберёмся, что же нового в этом релизе.

В феврале этого года я [писал на Хабре](https://habr.com/ru/articles/883590/) про автоматизацию тестов для САПР. Мы делали систему с записью действий в JSON и воспроизведением через pyautogui. Работало. Но только для одного конкретного проекта.

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

Что изменилось? Убрал привязку к конкретному софту. Добавил умный поиск элементов вместо тупых координат. Сделал так, чтобы QA мог записать тест без единой строки кода. Прикрутил UI-ассерты, мониторинг системы, файловые проверки.

Короче, то что начиналось как решение для одной задачи, выросло в полноценный фреймворк. И оказалось полезным не только мне.

Пару лет назад я написал статью "Размышления о структурном программировании", в которой пытался разобраться с заблуждением, будто Эдсгер Дейкстра доказал, что любой алгоритм можно построить всего из трех конструкций (следования, ветвления, цикла).

А вот теперь настало время написать про некоторые проблемы машины Тьюринга - фундаментальной основы всех информационных технологий.

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

Команда Go for Devs подготовила перевод статьи о том, как Go отмечает шестнадцать лет в Open source. От новых инструментов для тестирования и профилирования до модернизаторов кода, MCP и прорывов в производительности — язык переживает один из самых насыщенных периодов развития.

BUSY Bar — девайс для концентрации и современный Pomodoro-таймер с блокировкой отвлекающих приложений и интеграцией в умный дом. Предыдущие посты [1],[2]

В этом посте мы покажем, как с помощью HTTP API создавать виджеты для BUSY Bar. Это смогут сделать не только разработчики, но и обычные пользователи.

Далее вы узнаете как:
— Вывести изображения и текст на экран BUSY Bar.
— Взаимодействовать с устройством прямо из браузера.
— Создать виджеты без программирования.

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

Привет, мы продолжаем разбирать полиморфизм в React. В прошлой серии мы разобрали паттерн as — мощный, типобезопасный, но с проблемами в композиции. Сегодня разберем, как решить эту проблему с помощью паттерна asChild. Спойлер: это сделает ваш код чище, композируемее и приятнее для глаз, но придется пожертвовать поддерживаемостью.

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

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

Введение

Приготовьтесь, мы совершим путь от единственного кубика до целого воксельного движка! Нам понадобится следующее:

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

API рендеринга! Выбирайте что угодно, эта статья — не туториал по рендерингу.

Если в процессе у вас возникнут вопросы, можете связаться со мной на моём сервере Discord или написать на contact@daymare.net.

VaryPack — новый, простой, гибкий, шустрый и компактный формат бинарной сериализации произвольных данных.

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

Четвертая статья в серии про DOM-подобные модели данных в различных языках программирования.

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

Сегодня — Card DOM на Rust — великом и ужасном.

Команда AI for Devs подготовила перевод статьи о первой зафиксированной кибератаке, почти полностью выполненной ИИ. Атака, где человек нужен лишь для того, чтобы пару раз «подтвердить заказ», — и это уже не фантастика, а реальность 2025 года.

Я давно хотел написать статью или пост на эту тему, поскольку заметил проблему с некорректным пониманием синтаксиса так называемой «деструктуризации» в JavaScript. Эта информация будет особенно интересна разработчикам, использующим React, где деструктуризация (например, в хуке useState) встречается повсеместно.

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

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

В этом тексте я написал про то, как добавить индикатор прогресса в процесс сборки прошивки.

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

Наш проект использует паттерн двойной записи (Dual-Write):

Solana — гарантирует неизменность и прозрачность данных о выданных дипломах

PostgreSQL (Supabase) — обеспечивает быстрые выборки и сложные запросы

Звучит красиво на архитектурных диаграммах, но в production всё не так радужно. Главная проблема — частичные сбои. Транзакция в Solana прошла успешно, диплом записан в блокчейн навечно, а вот запись в PostgreSQL упала. Пользователь получил подтверждение, но половина системы о его дипломе не знает.

Сегодня я покажу, как мы столкнулись с этой проблемой лицом к лицу и какие паттерны применили для её решения.