Знаете ли вы, как настроить эффективное автоматическое масштабирование в Kubernetes?

Horizontal Pod Autoscaler (HPA) изменяет количество реплик приложения на основе метрик, таких как использование CPU или памяти. Для более точного масштабирования можно использовать кастомные метрики или внешние источники данных.

Пример YAML конфигурации HPA с использованием кастомной метрики:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 15
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Pods
    pods:
      metric:
        name: transactions_per_second
      target:
        type: AverageValue
        averageValue: 100

В этом примере HPA масштабирует количество подов myapp от 2 до 15 реплик. Масштабирование происходит при превышении средней загрузки CPU до 60% или при среднем числе транзакций в секунду выше 100. Для использования кастомных метрик необходимо настроить соответствующий метрик-сервер, например, Prometheus Adapter.

Дополнительно можно настроить автоскейлинг на основе внешних метрик, таких как задержка запросов или использование памяти:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa-external
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: request_latency
        selector:
          matchLabels:
            endpoint: /api/v1/resource
      target:
        type: AverageValue
        averageValue: "200ms"

Здесь HPA масштабирует приложение myapp на основе внешней метрики request_latency для определенного эндпоинта. Это позволяет более гибко реагировать на реальные показатели производительности приложения.

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

Знаете ли вы, как eBPF позволяет реализовать мониторинг специфических туннельных протоколов, таких как GRE, прямо в ядре Linux?

Глубокий разбор анализа GRE-трафика через eBPF

eBPF (extended Berkeley Packet Filter) даёт системным администраторам и разработчикам возможность добавлять свой код прямо в ядро Linux для перехвата и обработки сетевых пакетов без необходимости модификации исходного кода ядра или загрузки kernel-модулей.

Чтобы следить за специфическими типами трафика на уровне ядра — например, за туннелированием через GRE, — не нужно писать обвязки на user space или тянуть pcap-тулзы. Программа eBPF может быстро подсчитать пакеты и байты GRE прямо при обработке пакета и тут же отправить события в user space.

Вот сокращённый пример кода для такой задачи. Программа считает количество байтов GRE-пакетов, приходящих на интерфейс, и отправляет статистику в map, которую можно читать снаружи:

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/gre.h>
#include <linux/bpf_helpers.h>

struct bpf_map_def SEC("maps") packet_count = {
    .type = BPF_MAP_TYPE_PERF_EVENT_ARRAY,
    .key_size = sizeof(u32),
    .value_size = sizeof(u64),
    .max_entries = 1024,
};

SEC("xdp") int count_packets(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;

    struct ethhdr *eth = data;
    if ((void*)(eth + 1) > data_end)
        return XDP_PASS;

    if (eth->h_proto != htons(ETH_P_IP))
        return XDP_PASS;

    struct iphdr *ip = (void *)(eth + 1);
    if ((void*)(ip + 1) > data_end)
        return XDP_PASS;

    if (ip->protocol != IPPROTO_GRE)
        return XDP_PASS;

    // Проверяем доступность GRE-заголовка
    struct gre_hdr *gre = (void *)(ip + 1);
    if ((void*)(gre + 1) > data_end)
        return XDP_PASS;

    // Собираем метрики
    u64 bytes = (u64)(data_end - data);
    u32 key = 0;
    bpf_perf_event_output(ctx, &packet_count, BPF_F_CURRENT_CPU, &bytes, sizeof(bytes));
    return XDP_PASS;
}

Подключение и использование

Компилируйте код с помощью clang под target BPF, затем загрузите через bpftool:

clang -O2 -target bpf -c gre_monitor.c -o gre_monitor.o
bpftool prog load gre_monitor.o /sys/fs/bpf/gre_monitor pinmaps /sys/fs/bpf/
bpftool net attach xdp id $(bpftool prog show name count_packets | grep -o '[0-9]*') dev eth0

Для сбора статистики потребуется простая программа на C или Python, которая читает события из perf-буфера:

from bcc import BPF

b = BPF(obj="gre_monitor.o")
b["packet_count"].open_perf_buffer(lambda cpu, data, size: print(f"GRE packet: {int.from_bytes(data, byteorder='little')} bytes"))

print("Monitoring GRE packets... Press Ctrl+C to exit")
while True:
    try:
        b.perf_buffer_poll()
    except KeyboardInterrupt:
        break

Почему стоит использовать этот подход для туннелирования?

Обычные способы мониторинга не видят вложенные полезные данные за GRE и L2TP, а XDP-программа на eBPF позволяет точно считать только нужные протоколы, не тормозя всю систему. Можно расширить пример для трекинга L2TP, подсчёта RTT или фильтрации по списку IP-адресов: работать с породами туннелирования становится намного проще.

Данный подход обеспечивает производительность на порядок выше традиционных решений на базе libpcap, так как:
- Обработка происходит на ранней стадии в сетевом стеке ядра
- Отсутствует копирование пакетов в пространство пользователя для всего трафика
- Фильтрация выполняется атомарно, без взаимодействия с userspace

Реальный кейс: на больших инфраструктурах так можно ловить подозрительные GRE-туннели (например, неожиданный P2P), отслеживать логику отказа каналов и собирать детальную статистику без затрат на зеркалирование трафика и внешние анализаторы. Также возможно интегрировать это решение с системами мониторинга вроде Prometheus или Grafana для построения визуализаций и настройки алертов.

Знаете ли вы, как просто управлять фичами без сторонних библиотек и фреймворков?

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

Изоляция изменений через конфиг

Нужно раздать новую функцию только части пользователей? Самописный контроль с помощью простого конфиг-файла легко справится с этим.

Пример: нужно плавно перевести пользователей со старой логики на новую и иметь возможность моментально вернуть все обратно. Используем обычный JSON-файл с включателями:

{
  "features": {
    "newFeature": false,
    "legacyFeature": true
  }
}

Весь контроль у вас: достаточно поменять значение в json – и поведение тут же изменится.

Применение в коде

В коде легко читать флаги из файла:

import json

with open('config.json') as config_file:
    config = json.load(config_file)

if config['features']['newFeature']:
    newFeature()
else:
    legacyFeature()

Такой файл можно править на лету, он одинаково читается как скриптом, так и человеком.

Плюсы подхода

1. Управление полностью отделено от логики – никакой жёсткой прошивки фичей в коде.
2. Откат фичи не требует ручного редеплоя – внести правку можно прямо на сервере.
3. Легко масштабируется: можно дописать разные уровни управления (например, добавлять флаги для отдельных пользователей или групп).
4. Нет скрытых зависимостей и магии – код весь на виду, править можно в любой момент.

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

Знаете ли вы, как можно использовать reverse proxy для быстрого autosave между фронтовыми модулями без единой базы, через WebSocket-соединения?

В распределённых модульных фронтендах часто требуется без задержек синхронизировать пользовательские настройки или черновики между разными частями SPA, не прибегая к общей базе данных. Такой обмен можно реализовать, если объединять WebSocket-сессии модулями сквозь reverse proxy, чтобы получать центральную точку обмена и упростить маршрутизацию трафика между отдельными сервисами или микрофронтендами. Это позволяет каждому модулю слушать и отправлять изменения состояния мгновенно, без лишнего кустарного взаимодействия.

Зачем здесь reverse proxy — и чем он помогает с WebSocket

Прямое соединение каждого фронта с autosave-сервисом может быстро привести к избытку открытых WebSocket-каналов и хаосу в настройках CORS, балансировке и безопасности. Reverse proxy превращает все WebSocket-запросы в управляемый поток: получает их на одном порту, потом аккуратно раскидывает на нужные микросервисы, централизует контроль соединений и позволяет быстро масштабировать инфраструктуру. Архитектурно это убирает необходимость в отдельном сервисе шины данных или синхронизации между фронтами.

Пример reverse proxy для WebSocket autosave на Node.js

В этом фрагменте сервер принимает входящие WebSocket-подключения на единый порт (через proxy), а затем проксирует дальше к нужному сервису. Каждый входящий autosave-запрос обрабатывается на целевом сервере – так, чтобы фронты не взаимодействовали друг с другом напрямую и не пересекались на уровне логики:

const http = require('http');
const WebSocket = require('ws');
const httpProxy = require('http-proxy');

const proxy = httpProxy.createProxyServer({});
const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Reverse Proxy for Autosave');
});

const wss = new WebSocket.Server({ noServer: true });

server.on('upgrade', (req, socket, head) => {
  proxy.ws(req, socket, head, { target: 'ws://localhost:5000' });
});

wss.on('connection', (ws) => {
  ws.on('message', (message) => {
    // Обрабатываем autosave – сохраняем данные во временное хранилище, если нужно
    ws.send('Autosave performed');
  });
});

server.listen(3000, () => {
  console.log('Proxy server is running on port 3000');
});

В этом примере autosave-логика реализуется на целевом сервере (localhost:5000) – reverse proxy лишь пересылает WebSocket-сессии, не привязываясь к конкретной реализации хранения. Это значит, можно гибко менять схему хранения: временно записывать в память, сбрасывать в redis или даже на диск, не меняя прокси.

Что интересно учесть для production-сценариев

– С помощью такого reverse proxy можно организовать маршрутизацию на разные группы сервисов или разные версии серверов, проставлять нужные заголовки и прокидывать авторизацию.
– Для фронтов, построенных как модульные микросервисы, это снимает многие ограничения по количеству соединений и позволяет держать WebSocket-пул небольшим и управляемым.
– Если нужно централизовано контролировать autosave-сессии или временные данные, достаточно добавить простую прослойку на target-сервере на redis или file-based storage. Прокси остается “глупым”, быстро реагируя на события и не лезет в детали логики хранения.

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

Знаете ли вы, как сочетать Terraform и Chaos Engineering для анализа устойчивости инфраструктуры?

Подход “инфраструктуры как кода” дает надежные механизмы автоматизации, но гарантии реальной отказоустойчивости появляются только после проверки системы под неожиданными сбоями и хаосными событиями. Автоматизированный деплой средствами Terraform — это база, а устойчивость к реальным отказам требует симуляции “аварий” и анализа процессов самовосстановления.

Внедрение хаотического тестирования для облачных инфраструктур как AWS

Когда инфраструктура на AWS развернута через Terraform и управляется autoscaling group, можно предположить, что резервы устойчивости уже реализованы за счет автоматического масштабирования и перезапусков. Тем не менее, без моделирования реальных сбоев сложно сказать, насколько быстро и корректно восстанавливается сервис под нагрузкой или во время отсутствия одного из ресурсов.

Вот базовый пример Terraform-конфигурации для группы приложений на EC2:

resource "aws_launch_configuration" "app_lc" {
  image_id        = "ami-0c55b159cbfafe1f0"
  instance_type   = "t2.micro"
  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group" "app_asg" {
  launch_configuration = aws_launch_configuration.app_lc.id
  min_size             = 2
  max_size             = 10
  desired_capacity     = 5
  tag {
    key                 = "Name"
    value               = "AppServer"
    propagate_at_launch = true
  }
  health_check_type        = "EC2"
  health_check_grace_period = 60
}

Автоматизация запуска и поддержки пяти инстансов выглядит рабочей конфигурацией. Но готова ли система действительно к хаосу? Чтобы проверить это, можно задействовать Chaos Monkey или иной инструмент для случайных остановок или завершения инстансов прямо внутри указанной ASG. Пример вызова для “убийства” случайного сервера:

chaos-monkey --app AppServer --instance-type t2.micro --duration 30s

Такой сценарий воспроизведет внезапный отказ в реальном времени. Дальнейшее поведение наблюдаем через метрики: ASG практически сразу запустит новый инстанс, чтобы поддерживать необходимый desiredcapacity. Но чтобы сделать вывод об устойчивости, обязательно фиксируйте время до полного восстановления сервиса (вплоть до прохождения всех health-check и включения в балансировщик) и сопоставьте с логами группы и приложений.

Тонкости на практике: что смотреть после теста?

- Важно мониторить не только момент появления нового EC2, но и скорость его регистрации во всех жизненно важных компонентах (LB, сервис-дискавери и др).
- Если неправильно заданы параметры healthcheckgraceperiod, scale-in или scale-out, система может либо не среагировать на сбой вовремя, либо потерять часть ресурсов под нагрузкой.
- Обязательно проверьте, что lifecycle hooks корректно отрабатывают: иногда задержки в shutdown могут тормозить быстрое восстановление.

Добавьте интеграцию с Telegram-ботом — моментальные нотификации о рестарте инстансов позволят ловить аномалии не только по метрикам, а и по необычным сценариям (например, если один инстанс постоянно уходит в unhealthy без явных причин).

Такой подход позволяет удостовериться, что код инфраструктуры не только развернут “по спецификации”, но и готов к реальным непредсказуемым событиям: проверена реакция на аварии, скорость восстановления и корректность триггеров автоскейлинга. Чем лучше симулированы настоящие сбои, тем увереннее можно масштабироваться — и тем спокойнее команда поддерживает работу в проде.

Когда один разработчик из dotCloud решил упростить деплой своих Python-приложений, мир еще не знал, что через пять лет контейнеры станут стандартом индустрии.

В 2013-м Docker появился как обертка над LXC – технологией, которую мало кто понимал и еще меньше использовал. Соломон Хайкс показал демо на PyCon, где приложение запускалось одной командой на любой машине. Магия была в том, что контейнер нес с собой все зависимости, от библиотек до переменных окружения.

docker run -d -p 80:80 nginx

Эта строчка делала то, на что раньше уходили часы настройки. Netflix быстро подхватили идею – их микросервисная архитектура требовала быстрого масштабирования. Google молча усмехнулся – у них уже десять лет работал Borg, но никто об этом не знал.

К 2014-му стало ясно, что один контейнер – это игрушка. Нужна оркестрация. Docker Swarm появился как встроенное решение, но был слишком простым. Kubernetes вышел из недр Google как открытая версия Borg, со всей сложностью enterprise-систем. Mesos пытался конкурировать, предлагая универсальную платформу для любых задач.

Банки начали экспериментировать с контейнерами для изоляции торговых алгоритмов. Каждый алгоритм жил в своем контейнере с четко определенными ресурсами – CPU, память, сетевые лимиты. Это решало проблему "соседей", когда один агрессивный алгоритм мог положить всю систему.

В 2015-м произошел раскол экосистемы. Docker Inc. хотела монетизировать платформу, добавляя enterprise-фичи в Docker Engine. Сообщество забеспокоилось о vendor lock-in. Появился Open Container Initiative – попытка стандартизировать формат контейнеров и runtime.

Kubernetes тем временем набирал обороты. Red Hat делала ставку на него в OpenShift, Microsoft интегрировала в Azure. К 2017-му стало очевидно – в войне оркестраторов побеждает K8s. Docker Swarm остался нишевым решением, Mesos ушел в специализированные кейсы.

Появление CRI-O и containerd показало, что Docker как runtime становится избыточным. Kubernetes научился работать с любым OCI-совместимым runtime. Docker превратился из платформы в один из инструментов экосистемы.

Финтех-стартапы строили всю инфраструктуру на контейнерах с первого дня. Deployment pipeline выглядел как конвейер: git push → CI собирает образ → registry → K8s разворачивает. Rollback за секунды, blue-green deployment из коробки.

К 2018-му контейнеры стали commodity. AWS запустила Fargate – serverless-контейнеры без управления нодами. Google предложила Cloud Run. Абстракция поднялась на уровень выше – разработчики думали о сервисах, а не о серверах.

Пять лет потребовалось, чтобы превратить "работает на моей машине" из мема в решенную проблему. Контейнеры не просто изменили деплой – они переосмыслили саму архитектуру приложений.

5 инструментов LangChain для MLOps в 2025

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

1. LangSmith для observability

Платформа мониторинга и evaluation LLM-приложений. Автоматически отслеживает стоимость запросов к моделям, синхронизирует промпты с внешними системами через webhook-уведомления. Включает LLM-as-Judge evaluators для автоматической оценки качества и возможность сбора human feedback от экспертов. Особенно полезна для отладки сложных цепочек агентов, где нужно видеть промежуточные шаги и токены. Framework-agnostic - работает не только с LangChain.

2. LangGraph для stateful агентов

Low-level фреймворк для создания контролируемых агентов с поддержкой state management. Поддерживает различные control flows - single agent, multi-agent, hierarchical, sequential. Решает проблему управления состоянием в enterprise-сценариях, где агенты должны помнить контекст между сессиями. Включает built-in checkpointing и возможность human-in-the-loop взаимодействия.

3. LangGraph Platform для managed deployment

Управляемая инфраструктура для развертывания LangGraph приложений. Предлагает one-click deploy, horizontal scaling, APIs для state management и built-in persistence. Доступны разные опции деплоймента: Cloud SaaS, Hybrid (SaaS control plane + self-hosted data plane), и полностью self-hosted решения. Интегрирован с LangSmith для мониторинга производительности.

4. LangGraph Studio IDE

Визуальная среда разработки для создания и отладки агентов. Включает граф-визуализацию workflow, интерактивное выполнение агентов, time-travel debugging. Работает как с локально запущенными агентами через LangGraph Server, так и с деплоями на LangGraph Platform. Поддерживает два режима: Graph mode для детальной отладки и Chat mode для простого тестирования.

5. Enterprise коннекторы и интеграции

Поддержка корпоративных платформ и расширенные memory модули с vector-based памятью. Vector-based memory использует семантический поиск для релевантного извлечения контекста, а summarization memory динамически сжимает длинные диалоги. Более 600 интеграций с различными источниками данных, векторными базами и cloud платформами делают LangChain пригодным для enterprise RAG систем.

В 2000 году Эрик Брюэр бросил бомбу в мир распределенных систем – CAP-теорему, которая разнесла в пух и прах все розовые мечты о совершенных базах данных. Три буквы стали проклятием каждого системного архитектора: Consistency, Availability и Partition tolerance.

Суть жестока, как приговор: можешь выбрать любые два из трех, но никогда – все сразу. Сеть упала? Либо система остается доступной, но данные расходятся по узлам, как пьяные матросы по портам, либо сохраняет согласованность, но умирает для пользователей.

MongoDB и Cassandra танцуют на грани, жертвуя согласованностью ради скорости. PostgreSQL с его синхронной репликацией предпочитает смерть хаосу – лучше упасть, чем врать. Amazon с их DynamoDB выбрал золотую середину eventual consistency: "Данные сойдутся... когда-нибудь".

CAP превратил проектирование систем в русскую рулетку с тремя патронами. Каждое архитектурное решение – компромисс между тремя дьяволами. И самое страшное? В реальном мире сеть всегда может упасть.

Как почистить Docker от мусора без потери данных

Docker со временем забивает диск кешем сборки, старыми образами и неиспользуемыми volumes. Иногда нужно пересобрать контейнер – но при сборке вылезает no space left on device. И если освободить место универсальным способом:

docker system prune -af --volumes

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

Если нужно аккуратно сократить занятое Докером место, есть три команды, которые удалят только откровенный мусор:

docker builder prune -af
docker image prune -af
docker volume prune -f

Что удаляется:
- Кеш сборки образов
- Неиспользуемые образы
- Volumes, не примонтированные ни к одному контейнеру

Что НЕ удаляется:
- Запущенные контейнеры и их данные
- Образы, используемые любыми контейнерами (даже остановленными)
- Volumes, примонтированные к контейнерам

Если вы как и я используете для генерации кода в основном Claude и начали замечать, что в последнее время он начал слишком долго сидеть над кодом и генерировать кучу ненужного (инструкции, описание проекта, схемы которые никто не просил) – есть простое решение.

Запретите создавать артифакты, весь код строго в код-сниппетах (путь к файлу в чат + исправленное содержимое в код-сниппете). Так генерируется только то, что нужно, без траты времени и токенов.

claude-code-telegram + 🦞 = ??

RichardAtCT/claude-code-telegram
312 звезд, MIT, Python.

Простая утилита, которая дает соединять запущенный на дев-сервере Клауде Код с телеграм-ботом. То есть, пока ты у монитора – можно ставить задачи в нормальном окружении VS Code по SSH, а потом следить и управлять всем просто из телеги на телефоне.

Пока не стал пускать нейронку в свою кодовую базу без плотного присмотра и добрался до OpenClaw. Штука хоть и простая, местами оказалась капризной, особенно если хочется поэксперементировать с ЛЛМ-провайдерами. Но раз на сервере уже бегал Клауде Код, разбираться со всем пришлось ему: конфиги, модели, провайдеры, права файлов, rate limits – все это правится не выходя из чата. Так я и настраивал одного робота другим, из Телеграма, вне чатов пришлось только получить ключ для OpenClaw-бота от @BotFather.

Потенциально, применений для OpenClaw масса – но пока будет работать у меня вместо ручного тестировщика в вебе и поднимать того, второго, если сломается.

APILayer – 408k звезд, MIT, курируемый список

Большая база бесплатных публичных API для учебы или пет-проектов:

- Trace Moe – по скриншоту находит из какого аниме кадр, говорит серию и тайм-код
- Frankfurter – курсы валют от ЕЦБ с историей, без ключа и лимитов
- Open Food Facts – состав, КБЖУ и штрихкоды продуктов со всего мира
- WallstreetBets – sentiment analysis комментариев реддита по акциям
- Chess.com – статистика игроков, история партий, рейтинги
- Mempool – комиссии, состояние мемпула, история транзакций биткоин-сети

И еще почти полторы тысячи вариантов.

Radiant – 50+ шейдеров для веба, MIT

Каждый HTML-файл – отдельный эффект. Черные дыры, рвущаяся бумага, spring-сетки – скопировал, вставил, работает; без npm и зависимостей.

https://radiant-shaders.com/

PowerShell-скрипт для очистки Windows от мусора

Win11Debloat за одну команду в PowerShell убирает предустановленные приложения, телеметрию, Copilot, виджеты, рекламу в настройках.

4.5k строк PowerShell, 71 файл, ноль внешних зависимостей – только reg-файлы для реестра, WinGet для Edge/OneDrive и Remove-AppxPackage для остального.

14 релизов за 3 месяца, issues регулярно закрываются.

Есть Sysprep-режим: Win11Debloat применяет свои настройки к образу Windows для установки на новые машины. Конфиги можно экспортировать и импортировать.

Поддерживается Windows 10 и 11.

Визуальный AI-редактор для Next.js/Tailwind

Onlook – open-source альтернатива Bolt.new/v0/Lovable.

25k звезд, 1.6k коммитов, Apache-2.0. Монорепо на Bun 1.3.1, стек create-t3-app: Next.js App Router + Drizzle + tRPC + Tailwind. Бэкенд – Supabase, пользовательские проекты исполняются в CodeSandbox. Раньше был Electron-приложением, в 2025 переехал в веб.

Для self-host нужны 4+ CPU, 8GB RAM (рекомендуется 16GB), 50GB диска, локальный Supabase, и ключи от OpenRouter и CodeSandbox. Плюс еще с десяток опциональных интеграций.

В коде две критических уязвимости – удаленное выполнение кода и SSRF в axios 1.12.2 (тот самый HTTP-клиент, который торчит в половине npm-проектов). Плюс SQL-инъекция в Drizzle ORM 0.44.7 и подделка JWT-токенов в hono 4.10.2, и кроме них, еще несколько помельче. Хороший кандидат для PR в большой опенсорс – с февраля в мастер-ветке не было новых коммитов.

За годы запусков продуктов и работы с нетехническими фаундерами, я заметил повторяющиеся факторы, которые из раза в раз срывают выход на рынок. И, как ни парадоксально, половина из них связана с ИИ.

Представьте, что пока вы работаете над фичей или фиксом, ваш нетехнический партнер или заказчик из лучших побуждений проработал эту проблему, общаясь с нейронкой, и теперь предлагает вам почитать трехчасовой лог своего общения с ChatGPT, потому что "кажется, там что-то важное". Какие еще проблемы возникают и что с этим можно делать – я расписал в статье на Хабре.

https://habr.com/ru/articles/1028284/

Шел 2020 год когда Cellebrite – израильская компания, занимающаяся цифровым шпионажем, громко заявила, что способна вскрыть Signal – якобы самый защищенный мессенджер в мире. Их инструменты покупают спецслужбы всего мира, от ФБР до ФСБ, и используют против всех, кого нужно – от собственных журналистов до громких несогласных. Создатель Signal – также известный как Мокси Марлинспайк (настоящее имя) – прочитал это заявление и решил разобраться в ситуации своими силами.

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

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

Никогда не оставляйте ваше шпионское оборудование лежать на улице без присмотра.

Питер Штайнбергер – автор OpenClaw, заполонившего интернет ботами-суетологами, для которых в конце прошлого года весь соло-фаундер-твиттер скупал МакМини. Кто-то из этих 🦞 наверняка стучался своими тентаклями к вам в телеграм и пытался что-то продать.

Совсем недавно Штайнбергера купили в OpenAI – делать уже закрытых агентов с клешнями. OpenClaw при этом продолжил жить своей жизнью в опенсорсе, отдельно от создателя, а сам Штайнбергер написал об этом прощальный пост, в котором рассказал, что это было его условием для перехода под крыло Альтмана.

Но за пару месяцев до этого поста он сделал другой интересный текст. "Shipping at Inference-Speed " – о том, почему он практически перестал обращать внимание на код, который пишут агенты, как на код, – и, по сути, стал фокусироваться на результатах, которые кодинг-агенты доставляют. Сами подходы, описанные в статье, сейчас не вызывают уже особого интереса – за почти полгода с выхода того текста часть стала мейнстримом, часть не выжила, оказавшись глупостью.

Интересно то, что в тексте сам он сравнивает, как все изменилось с современного вида Codex'ом и Клауде Кодом по сравнению с маем прошлого года. И интересно именно с ретроспективной точки зрения посмотреть на прошедший год – как с самописных поделок для генерации кода все перешли к корпоративным инструментам по подписке. Я прочитал и перевел его текст, самые интересные замечания на данный момент:

- "Я не читаю код. Я смотрю, как он стримится" – главный тезис поста и, наверное, новая норма для всех, кто хоть раз дал агенту сделать что-то серьезное. Если все при этом нормально покрыто тестами, то это даже безопасно.

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

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

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