Разработка

Представлен обновлённый проект Awesome Black Hat Tools, где собраны все инструменты, которые когда-либо были представлены на ИБ-конференциях Black Hat. Инструменты аккуратно структурированы по странам, где проходила конференция, по годам и категориям Red Teaming, Blue Teaming, OSINT & Recon, Exploit Development, Malware Analysis, DFIR & Forensics, Threat Intelligence, ICS/IoT/SCADA и Application Security (AppSec).

Также все презентации с выступлений Black Hat, начиная с 2023 года, собраны на отдельной странице GitHub.

Теперь за специалистов по искусственному интеллекту платят больше, чем за футболистов.

Новая версия Gramax!

• Сравнение ревизий. Можно сравнить текущую версию каталога с одной из предыдущих.

• Экспорт в корпоративных шаблонах DOCX. Добавили возможность загрузить корпоративный шаблон DOCX и экспортировать статьи и каталоги в этом шаблоне.

• Избранное. Каталоги и статьи можно пометить как Избранные для быстрой навигации. Это доступно как в приложении, так и на портале документации.

• Связанные статьи. В меню статьи можно просмотреть: куда ссылается статья и какие статьи ссылаются на нее.

Об этих и других изменениях читайте в Release Notes 🔥

Привет Хабр! Это мой первый пост, и я просто хотелось спросить, стоит ли уходить в Go? У меня есть небольшая база в программировании, делал сайты на реакт и ларавел, реализовывал бэкенд с Солид и паттернами, писал на нативном пхп файловые обменники и апи. Не много знаю базы данных соответственно, гит, докер. Сейчас засматриваюсь на Go, где то вычитал что мол крутая штука для бигтехов в России, а сам я студент и пока сижу на шее у родителей, но в следующем году я окончу к курс, и хочу где то месяца за 4-5 изучить все нужное в го и во всех других сопутствующих технологиях для разработки высоконагруженных приложений и микросервисов и всякого подобного. Стоит ли сворачивать на этот путь, или добить стек ларавел плюс вью? Немного боюсь, так как слышал что в го нужны уже 25 летние синьоры со стажем работы минимум в 20 лет, но и не хочется проторчать всю жизнь в челябинской галере на фуллстеке за 70 деревянных на руки.

Прошло довольно много времени с тех пор, как я в последний раз что-либо публиковал на Хабре, около 10 лет или около того, и сегодня настал день, чтобы поделиться своим небольшим Open Source проектом.

Проект под названием Gaunt Sloth Assistant — это CLI-клиент для ИИ (AI), созданный на TypeScript (LangChain.js), распространяемый через npm и работающий в Linux, Windows и Mac. Пользователь полностью контролирует промпты, и рекомендуется формировать свои собственные системные промпты, но у него также есть и стандартный.

GitHub: https://github.com/andruhon/gaunt-sloth-assistant

NPM: https://www.npmjs.com/package/gaunt-sloth-assistant

В настоящее время Gaunt Sloth имеет dependencies, позволяющие использовать простую конфигурацию JSON для VertexAI, Anthropic, Groq и DeepSeek. Теоретически он должен работать с любой моделью, поддерживаемой LangChain; есть даже package для Яндекса, который я никогда не пробовал, но думаю, он должен работать, если установить пакет и предоставите конфиг в JS. OLLAMA? Возможно, это сработает; я никогда не пробовал, но буду признателен, если кто-нибудь поделится своим опытом.

Gaunt Sloth может просматривать запросы на слияние и сопоставлять их с требованиями из задачи Jira или GitHub, просматривать локальные различия, общаться в чате, имеет доступ к файловой системе и может записывать код в файловую систему.

Gaunt Sloth — это универсальный инструмент с рядом полезных возможностей:

• Просматривает запросы на слияние (например, 42) и сопоставляет их с требованиями из задачи Jira или GitHub (например, 12).

  • gth pr 42 12

• Просматривает локальные различия.

  • git --no-pager diff | gth review

• Предоставляет интерактивный сеанс чата.

  • gth chat

• Имеет доступ к файловой системе для чтения и записи кода.

  • gth code

Конечно, у него есть MCP и OAuth, так что вы можете подключиться к удаленному MCP, такому как Jira, и создавать и редактировать issues "like a boss".

У него также есть крошечная функция, которая может регистрировать время по задаче Jira, когда она заканчивает проверку PR. Это еще не задокументировано, но вы можете найти пример конфигурации в примечаниях к выпуску или спросить меня в комментариях (насколько я знаю, Jira MCP этого делать не может).

Кроме того, вы можете поставлять простые локальные инструменты ИИ в формате инструментов LangChainJS, такие как этот:

import { tool } from "@langchain/core/tools";
import { z } from "zod";
const multiply = tool(
  ({ a, b }: { a: number; b: number }): number => a * b,
  {name: "multiply", description: "Multiply two numbers", schema: z.object({ a: z.number(), b: z.number(), })}
);

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

Зачем?

Несколько месяцев назад я искал CLI-помощника на базе LangChainJS/LangGraphJS и не нашел многого. Был фактор любопытства и другие факторы.

Первоначальным намерением было создать инструмент, в который я мог бы передавать diff и отправлять этот diff вместе с рекомендациями в ИИ, но со временем он развивался, создавались новые функции, и потенциально это можно использовать в качестве агента для кода.

Например gth code, говорите implement requirements.md, чтобы он прочитал файл и начал кодить.

GeminiCli, ClaudeCode? Они не были официально выпущены, и я не знал, что они находятся в разработке. Aider, Goose? Конечно, они вероятно лучше, но в них сложнее вносить свой вклад и добавлять нужные вам функции.

И что?

У меня больше идей по созданию функций, чем времени.
Приветствуются контрибьюторы.
Попробовать его и создать issue или поделиться отзывом — это тоже вклад; PR был бы еще лучше.

АГЕНТЫ И АГЕНТНАЯ ЭКОНОМИКА. 02.07.25.

Микро-дайджест недели. Интересные мысли и инсайты.

=> В конце июня вышло 2 интересных отчета:

Отчет Menlo Ventures "2025: The State of Consumer AI", который представляет комплексный анализ состояния потребительского ИИ на основе опроса более 5000 американцев. Ключевые инсайты вынес в отдельную статью.

Отчет 2025 State of AI Report: The Builder’s Playbook это комплексное исследование состояния разработки ИИ-продуктов, основанное на опросе 300 руководителей технологических компаний в апреле 2025 года. Совсем кратенько ниже:

• Зрелость ИИ-продуктов: ИИ-нативные компании значительно опережают ИИ-интегрированные в цикле разработки - 47% ИИ-нативных продуктов уже достигли стадии масштабирования против 13% у ИИ-интегрированных компаний. Только 1% ИИ-нативных компаний находятся на стадии до запуска против 11% ИИ-интегрированных.

• Выбор моделей: При выборе базовых моделей для клиентских продуктов точность является главным приоритетом (74% респондентов), за ней следуют возможность тонкой настройки (57%) и приватность (41%). Для внутренних задач стоимость становится главным фактором (74%), затем точность (72%) и приватность (50%).

• Методы обучения: RAG (66-68%) и файн-тюнинг (67-69%) являются наиболее распространенными техниками адаптации моделей.

• Бюджеты разработки: ИИ-интегрированные компании выделяют ~10-20% своего R&D бюджета на разработку ИИ, при этом большинство планируют увеличить расходы в 2025 году.

• Бюджеты на внутреннюю ИИ-продуктивность планируется почти удвоить в 2025 году, составляя 1-8% от общей выручки. R&D бюджеты остаются наиболее распространенным источником финансирования.

• Разработка приложений: LangChain и инструменты Hugging Face доминируют как фреймворки оркестрации, около 70% респондентов используют частные или кастомные LLM API.

• Основные специализации: 88% компаний имеют AI/ML инженеров, 72% - data scientists, 54% - ИИ-продактов.

• Рынок очень быстро растет, при этом ИИ-нативные компании показывают значительные преимущества в скорости разработки и масштабировании по сравнению с традиционными компаниями, интегрирующими ИИ в существующие продукты.

=> OpenAI приобрел Crossing Minds, которые специализировались на максимально глубоком понимании намерений людей и рекомендательных алгоритмах. Их платформа позволяла компаниям на лету подбирать релевантные товары, интеллектуально увеличивать средний чек, персонализировать коммуникацию, а также обеспечивать позитивный пользовательский опыт в Е-com.

=> Агентный ИИ это возможность для создания более интеллектуальных, эффективных и автономных приложений. На контрасте - небольшая ода в стиле Болливуд и инженерный прикладной мануал для сборки когнитивных (контекстных) пайплайнов в мультиагентных системах.

=> Следующий рубеж для ИИ это не уровень интеллекта. Это доверие. Исследователь из США, довольно известный в узких кругах кибербеза, представил архитектуру Cognitive Trust, для митигации угроз Агентного ИИ. Такая система не только наблюдает за тем, что делают ИИ-агенты, но и стремится понять, почему они ведут себя определенным образом. Более подробно в его работе на ResearchGate.

=> У меня были в наставничестве ребята, которые делали российскую ИИ-игрушку. Увы, этот проект инвестор прикрыл, но мне вот попался на глаза Dino. Классная штука, точно такая же бизмодель.

=> Скорость изменений такова, что то, во что не верилось еще 6 месяцев назад, сейчас уже не звучит так фантастически. А значит завтра это может стать и нашей актуалочкой. From chatbots to collaborators: How AI agents are reshaping enterprise work.

=> И напоследок два небольших стартапа, решающих узкие джобы (JTBD) в музыкальной индустрии:

• Подбирать больше не надо, сервис мгновенно превращает любой аудиоклип или музыку из ролика в ноты.

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

  И таких нерешенных задачек - миллионы.

***

О новых ИИ бизнес-моделях и нерешенных задачах: Айвентор и Фред

Предыдущие материалы и выпуски дайджеста, там до сих пор много интересных инсайтов.

Доступен репозиторий Project Ideas and Resources с десятками пет-проектов для реализации, где разработчики собрали огромное пошаговое руководство к наработке железных навыков программирования. Ресурс предоставляет бесплатный доступ к проектам разного уровня сложности: от простого шахматного приложения до полноценного клона Airbnb. Есть пошаговое руководство для реализации каждого проекта на самых популярных языках программирования: Java, Python, JS, C#, а также ссылки на теоретические выкладки, книги и видео по различным темам программирования.

В открытый доступ вышла книга по машинному обучению Machine Learning Q and AI. Ранее целый год фундаментальный труд Себастьяна Рашки можно было купить только на Амазоне, и вот автор открыл книгу для всех бесплатно.

Внутри огромный сборник тем по Deep Learning, 30 глав отборной, понятной и подробной информации по компьютерному зрению, LLM, эвалу и методам деплоя моделей, а также множество примеров и практических пояснений — автор все объясняет на схемах и картинках. Также есть упражнения после каждой главы.

Control Plane и User Plane в мобильной связи: зачем нужны два типа трафика и как они работают

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

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

Физически между базовой станцией и опорной сетью проходят два потока:

• Control Plane — управляющий трафик. Отвечает за процедуры подключения к сети, аутентификации, переключения между станциями, сессий и т. д.

• User Plane — пользовательский трафик. Это все, что идет от приложений пользователя: стриминговые сервисы, мессенджеры, браузер и так далее.

Они разделены как логически, так и физически. Такой подход нужен, чтобы обеспечивать надежность, безопасность и гибкость.

В статье Елена Степанова, ведущий инженер-программист в YADRO, объясняет, чем опорная сеть отличается от базовой станции, зачем в 5G сотни микросервисов и как устроена архитектура мобильной связи.

Сила RxJS. scan + mergeScan = 'Загрузить еще'

Кнопка 'Загрузить еще' (либо автоматическая подгрузка данных при скролле) довольно часто встречается в проектах и обычно решение связано с большим количеством подписок и переменных.

Как всегда, для оптимизации чего либо нам на помощь приходит великий и могучий RxJS, а в данной ситуации конкретно операторы scan & mergeScan.

Код:

  readonly loadTrigger$ = new Subject<void>();
  private readonly batchSize = 5;

  private readonly posts$ = this.loadTrigger$.pipe(
    startWith(void 0),
    scan((offset) => offset + this.batchSize, -this.batchSize),
    mergeScan(
      (accPosts: Post[], offset: number) =>
        getPosts(offset, this.batchSize).pipe(
          map((newPosts) => [...accPosts, ...newPosts]),
        ),
      [] as Post[],
    ),
  );

1. scan – калькулятор + хранитель состояния для offset:

   • Управляет состоянием загрузки (текущее смещение)

   • Начинается с -batchSize, чтобы первая загрузка была с 0

   • Увеличивает смещение на batchSize при каждом срабатывании

2. mergeScan – волшебный оператор для инкрементальной загрузки:

   • Сохраняет массив накопленных постов

   • Объединяет новые данные с существующими

   • Корректно обрабатывает параллельные запросы (в отличие от обычного scan)

Где полезен этот паттерн?

• Постраничные API (пагинация)

• Бесконечная прокрутка

• Порционная загрузка данных

• Любые сценарии накопления асинхронных данных

scan - https://rxjs.dev/api/operators/scan
mergeScan - https://rxjs.dev/api/operators/mergeScan
Больше об Angular - https://t.me/grandgular

Карма vs Инженерная честность: Почему рейтинги убивают экспертизу

Есть в инженерной культуре наивная вера: если система имеет метрики и правила - она безусловно и по умолчанию объективна. Карма на Хабре тому идеальный контрпример. Формально всё честно: пост → оценка → рейтинг. На практике же это цифровой аналог пассивно-агрессивного "не зашло". Без объяснений. Без контекста.

Социальная инженерия вместо экспертной оценки

Главный парадокс: чтобы выжить, ты должен угадывать не истину, а ожидания аудитории. Тон, формат, табу. Это краш-тест на конформизм:

Написал, что 80% мониторинга в проде — это фейковый SLO? → Минус ("негатив").
Сказал, что ChatGPT пишет ТЗ лучше джуна? → Минус ("ересь").
Осмелился быть лаконичным без смайликов? → Минус ("агрессия").

Почему так? Потому что карма измеряет не глубину мысли, а комфорт восприятия. Инженерная точность = высокомерие. Прямолинейность = токсичность. Даже если за этим — годы практики и статистика.

Карма как инструмент подавления инакомыслия

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

Итог:
Действительно качественные и экспертные умы, готовые спорить и рушить догмы, — уходят.
Остаются те, кто мастерски жонглирует банальностями в дружелюбной обёртке. Звучит довольно резко, соглашусь. Но иначе не донести усть мысли.
Платформа медленно превращается в клуб взаимного одобрения.

Что делать?

1. Игнорировать карму как погрешность системы (но тогда зачем она?).

2. Требовать мандат для минусов ("Укажи причину: факт ошибка/оффтоп/токсичность"). Хотя у кого тут истребуешь - не нравится, двери на кнопке "выйти".

3. Ввести верифицированную карму - например, чисто теоретически, только от пользователей с 100+ постами в профильных хабах.

Пока же мы имеем соцсеть, где алгоритмическая справедливость проигрывает человеческой... нетерпимости.

P.S. Этот текст - эксперимент. Проверим, сколько стоит сказать: "Император голый". За инженерную честность - не жалко.
P.P.S. Карма — временна. Культура дискуссии — вечна.

Приглашаем на бесплатный вебинар «Как стартовать в Java и не потеряться: структура, инструменты, кейсы». 

📅 Дата: 8 июля

⏰ Время: 18:00–19:00 (Мск)

Java — один из самых востребованных языков, но с чего начать, если вокруг столько информации, а подходы быстро устаревают? В прямом эфире разберем:

✔️ С чего начать в Java, чтобы не тратить время на устаревшие методы

✔️ Ключевые инструменты (JUnit, Maven, Git) — как их применять с первых шагов

✔️ Кейсы, которые помогут на собеседованиях и в реальных проектах

✔️ Как избежать типичных ошибок новичков и сразу писать чистый код

Почему стоит прийти?

🔹 Узнаете, как быстро войти в Java с актуальными знаниями

🔹 Увидите разбор реальных примеров и учебных проектов

🔹 Получите рекомендации по ресурсам и дальнейшему развитию

👨‍🎓 Спикер: Судакевич Игорь — преподаватель международного уровня, более 15 лет работает в ИТ. Уполномоченный инструктор корпорации Oracle. Магистр компьютерно-информационных технологий. Инструктор платформы Udemy. 

🔗 Записаться

Чем занимается команда Data Science в финтехе

Рассказывает Слава, инженер машинного обучения в ЮMoney.

У нас в компании много данных, которые можно обрабатывать, чтобы улучшать пользовательский опыт. Например, данные пользовательских обращений ЮKassa из разных каналов: чатов с техподдержкой, почты, звонков в колл-центр.

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

Если по одной теме у нас пять тысяч обращений, по второй — десять тысяч, а по третьей — всего два, значит, нам нужно уделить особое внимание первым двум.

В классификаторе пользовательских обращений мы используем языковые модели типа BERT. Также развиваем использование больших языковых моделей (LLM). У них много знаний «из коробки», они не требуют дообучения и могут применяться для разных задач. Есть и недостатки (требовательность к вычислительным ресурсам или галлюцинации), но LLM способны выполнять задачи намного быстрее, чем человек.

Ещё одно интересное направление Data Science, которое мы тестируем, — распознавание изображений и классификация по категориям. Сейчас мы решаем эту задачу с помощью модели clip, но планируем проверить эффективность работы visual LLM, например Qwen-VL. Этот вид моделей анализирует изображение и даёт текстовое описание, которое можно использовать в продуктах, например при проверке сайтов, которые подключаются к ЮKassa.

Также LLM хорошо выполняет задачи написания саммари — например, по итогам проведённой встречи. Предварительно отдельная модель (у нас это Whisper) переводит аудио в текст, что сильно ускоряет работу коллег.

***

Делитесь в комментариях, есть ли команда Data Science в вашей компании и какие задачи она решает. 🙌

Как QA и DEV могут эффективно работать вместе, а не играть в бесконечный пинг-понг с передачей фичи на тестирование и багов туда-обратно?

Об этом Лена Федорова, QA Garage Eight, рассказала на своей лекции «Мир, дружба, тестирование» на QA митапе в офисе Garage Eight. Она поделилась кейсом своей команды по внедрению совместного тестирования и тем, какие результаты оно дало.

Смотри лекцию и узнаешь:
> что такое «совместное тестирование»?
> какие у него преимущества и недостатки;
> каким командам подойдет этот подход;
> как измерить успех.

YouTube | VK Видео

Нужно было быстренько перехватить вызов нативной функции и посмотреть значение переменной в Android приложении. Как то давно использовал для этого замечательную утилиту Frida. Установил на планшет frida-server (root уже был) и клиент на PC, написал классический JS хук, но он не работал:

defineHandler({
  onEnter(log, args, state) {
    conslole.log('decoder_CRC_check()');
  },

  onLeave(log, retval, state) {
    const libc = Module.findBaseAddress('libc.so');
    console.log(hexdump(libc, {
      /* address: ptr('0x1000'), -- to override the base address */
      offset: 0,
      length: 64,
      header: true,
      ansi: true
    }));
  }
});

В консоли лишь получал TypeError: not a function at onEnter (D:\Distrib\Android TV\frida\hook.js:7)

Убил полдня в поисках "чего я делаю не так", при том что и официальная дока и нейронки твердят, что именно так и нужно получать базовый адрес модуля и, при необходимости, функций. Оказалось, во Frida 17 автор полностью удалил некоторые функции (а дока и нейронки еще не обновились):

• Module.ensureInitialized()

• Module.findBaseAddress()

• Module.getBaseAddress()

• Module.findExportByName()

• Module.getExportByName()

• Module.findSymbolByName()

• Module.getSymbolByName()

• Туда же статические функции Memory

И теперь надо писать цепочку вызовов:

const lib = Process.findModuleByName("libc.so");
console.log("[*] libc.so loaded at base: " + lib.base);
const funcAddr = lib.findExportByName("decoder_CRC_t_init");

Итог получился такой универсальный скрипт:

Java.perform(function () {
	const System = Java.use("java.lang.System");
    const Runtime = Java.use('java.lang.Runtime');
    const SystemLoadLibrary = System.loadLibrary.overload('java.lang.String');
    const VMStack = Java.use('dalvik.system.VMStack');
    // "ожидание"\перехват динамической загрузки нативных библиотек
    SystemLoadLibrary.implementation = function(library) {
		console.log("Loading dynamic library => " + library);
        const loaded = Runtime.getRuntime().loadLibrary0(
            VMStack.getCallingClassLoader(), library
        );
        if (library.includes("mylibname")) {
            console.log("\n[+] Hooked mylibname");
            // перехватываем только нужную нам
            hookNativeFunc();
        }
        return loaded;
    }	
});

function hookNativeFunc() {
    //тут имя полностью как называется сам файл в ресурсах
	const lib = Process.findModuleByName("libmylibname.so");
    console.log("[*] mylibname.so loaded at base: " + lib.base);
    const funcAddr = lib.findExportByName("decoder_CRC_t_init");
    if (!funcAddr) {
        console.log("[-] Function not found!");
		return;
    }
    console.log("[+] Found decoder_CRC_t_init at: " + funcAddr);
    Interceptor.attach(funcAddr, {
        onEnter: function (args) {
            var result = args[0];
            var inputPtr = args[1];
            var len = args[2].toInt32();
            console.log("\n[+] decoder_CRC_t_init called");
            console.log("    result:    " + result);
            console.log("    inputPtr:  " + inputPtr);
            console.log("    len:       " + len);
        },
        onLeave: function (retval) {
            //нужный адрес массива, например из IDA PRO
            const wordArrayOffset = 0x5B2C04;
            const wordArray = lib.base.add(wordArrayOffset);
			var ptr = new NativePointer(wordArray); // современный вариант чтения
            console.log("[*] 5B2C04 contents:");
            try {
                console.log(hexdump(ptr, {
				  offset: 0,
				  length: 512,
				  header: true,
				  ansi: true
				}));
            } catch (e) {
                console.log("[!] Error reading 5B2C04:", e);
            }
            console.log("Return value:", retval);
        }
    });
}

Запускается так frida -U -f com.android.app -l hook.js

АГЕНТЫ И АГЕНТНАЯ ЭКОНОМИКА. 30.06.25. ИЮНЬ ВСЁ.

Микро-дайджест недели. Интересные мысли и инсайты.

Дайджест по материалам зарубежных медиа. Минимум булшита, максимум инсайтов.

=>  «Агенты не всегда следуют правилам», — сказала Мэй Хабиб в прошлую среду на сцене VB Transform. «Они ориентированы на результат. Они интерпретируют. Они адаптируются. И их поведение действительно становится очевидным только в реальных условиях».

Это означает отказ от традиционного жизненного цикла разработки программного обеспечения при работе с адаптивными системами.

То есть, процесс рассуждения как бы выносит агентов из формата "это просто код", потому что они демонстрируют поведение «мыслящих сущностей», чья логика во многом формируется не в момент написания условий взаимодействия, а только в момент их реалтайм использования. И это выглядит похожим на разумное, а порой и на неразумное, поведение.

=>  В прошлом дайджесте я написал о концепте "Один мир, один язык", но забыл прикрепить подкаст, который я сгенерил для вас по этой теме. Исправляюсь.

=> Профессор-экономист Anton Korinek доносит мысли о вариативности сценариев на рынке труда. Процесс подготовки осознания и принятия населением больших изменений идет полным ходом. Пока все сходятся на том, что человек+ИИ это выгодно всем, поэтому людям надо поскорее брать новые навыки, ну и склонять свои правительства к управляемому и регуляторному подходу к внедрению ИИ-технологий.

Мне только одно не понятно, если половина мира находится в свободном рынке, то как они собираются это регулировать?

=> Alexandre Bobeda, айвентор из Бразилии, запустил свой мини-стартап Recipfy

"Моя коллекция рецептов была просто катастрофой. У меня были скриншоты, наброски, PDF-файлы, случайные ссылки на блоги. Ничего не было доступно для поиска или использования, когда я действительно хотел что-то приготовить.

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

Стэк, на котором он это запустил: Lovable, Windsurf (как замена VS Code), Supabase  (база данных и бэкэнд), Vercel (хостинг приложений для быстрого развертывания и глобальной производительности), Klaviyo (рассылка + отзывы пользователей), LLM (Mistral как основной движок, Gemini 3.5 Pro и Claude Sonnet 4 для UX и функционала).

Я бы хотел, чтобы в России появилось больше айвенторов (предпринимателей нового поколения, которые запускают министартапы и дизраптят действующий бизнес).

=> Большая Игра. Кто будет владеть каналами дистрибуции и что делать уже сегодня?

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

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

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

=> Deep Research Agents это новый этап в развитии интеллектуальных систем: они планируют, исследуют, анализируют и создают отчёты автономно. Их сила в комбинации гибкого поиска, инструментальной экосистемы и продвинутого обучения. Однако вызовы остаются: масштабируемость, оценка, мультимодальность, сотрудничество.

=> Гайд по тестированию ИИ-приложений OWASP

=> Мануал, как подготовить ваше API для ИИ (LLMs и ИИ-агентов)

Предыдущие материалы и выпуски дайджеста за июнь, там до сих пор много интересных инсайтов!

Альфред Лао. Айвентор и Фред

Спустя 26 лет чуть не истёк срок действия домена half-life3.com. Домен был создан ещё в 1999 году и раньше перенаправлял на сайт The Orange Box. Однако 28 июня домен прекращал своё существование, из-за чего некоторые фанаты начали бить тревогу и даже связались со службой поддержки Valve, которая сообщила, что домен в безопасности — его продлили некоторое время назад.

Хочу поделиться с вами видением хорошей архитектуры Go проекта, к которой я пришёл на данный момент и также интересно послушать ваши варианты и мнения по данному поводу.

Моё видение:

У нас ядро приложения это сервисный слой (юзкейсы), именно ядро самая основная часть приложения, которая взаимодействует с какой‑то логикой.

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

Так как мы не хотим, чтобы логика из ядра уходила во внешние компоненты (по моему мнению, это повлечет переплетение зависимостей и нарушение принципов разделения ответственности), то вся логика должна выполняться на уровне ядра (например, вместо default значений полей в базе, мы создаём модель на уровне ядра, а база служит лишь в качестве хранилища, не выполняя какой‑либо бизнес логики). То есть бизнес‑валидация (инварианты агрегатов) остаётся в ядре, а адаптеры проводят schema‑валидацию (обязательные поля и форматы) до передачи в юзкейсы, тем самым мы избегаем лишних вызовов ядра (при некорректных данных), и не засоряя само ядро валидацией (отличным примером служит то, когда HTTP адаптер валидирует модель до передачи её в юзкейсы).

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

То есть я считаю идеальной архитектурой для большинства Go проектов, работающих на основании адаптеров (к примеру, REST или gRPC сервис) гексагональную архитектуру с включением подхода DDD.

У меня остались также холиварные вопросы к вам. Как считаете:

• Передавать в юзкейсы структуру или поля по отдельности?

• Должно ли хранилище, в виде БД например, иметь валидацию данных? Операции по крону? Дефолтные значения полей?

• Транзакции: где их начинать/заканчивать?

• Когда и где вводить versioning: в HTTP‑уровне, в домене (разные агрегаты) или в репозиториях (Multi‑tenant)?

• Должны ли доменные ошибки возвращать rich‑error (с кодом/контекстом) или достаточно обычных error с текстом?

💫 Получите развернутый анализ GitHub репозитория через ChatGPT Deep Research

Не все про это знают, но с помощью ChatGPT Deep Research можно изучить любой GitHub проект

В режиме Deep Research через селектор выберите желаемый репозиторий, а через 5 минут получите детальный анализ по вашему запросу

Иногда пользуюсь этой функцией, чтобы разобрать архитектуру проекта, объяснить логику кода или найти потенциальные проблемы и улучшения. Сам я не кодер, поэтому мне это очень сильно помогает

Особенно полезно при изучении чужих проектов, когда надо быстро вкатиться

Вот тут можете посмотреть, как ChatGPT сделал разбор моего тестового репозитория, опираясь на мой неполноценный промпт

UART-сенсоры и браузер: читаем воздух через браузер на sensor.pollutants.eu

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

🤔 Зачем всё это?

Если ты возишься с датчиками качества воздуха, то знаешь, как это бывает: подключил — и пошёл искать minicom, Ultra, какой-нибудь Python-скрипт, или ещё чего. А если ты просто хочешь посмотреть, дышит ли твой сенсор — зачем столько движений?

И тут пришла идея: а почему бы не сделать всё в браузере?

🌐 HTML + JS + JSON = 👌

Ты заходишь на sensor.pollutants.eu, выбираешь нужный сенсор из списка (если в JSON их несколько), подключаешься к COM-порту — и данные потекли.

Без установки. Просто HTML-страница, в которой уже всё встроено:

• работа с Web Serial API,

• парсинг бинарных фреймов по структуре из JSON,

• визуализация данных через Chart.js,

• конфигурация через внешний JSON-файл.

• скачивание статистики в CSV

⚙️ Конфигурация сенсоров

Конфиг грузится с GitHub и содержит несколько сенсоров. Можeте загрузить свой JSON.
Проект на hackaday