Нюанс №1
У части пользователей незаметно включается Adaptive, а по умолчанию рядом маячит Fusion. В итоге ты думаешь, что работаешь на бесплатном SWE-2, а квота уезжает на роутер или lead-модель.В Fusion SWE-2 может быть только допом, а Fable/Astra/Sol платной основой. Дневная квота много у кого горит
Нюанс №2
Бесплатно не значит безлимитно по скорости. По ощущениям, после 5–6 параллельных сессий TPS режется примерно со 100 до 70, в пик может падать до 30. Плюс периодически прилетают 429, и API притормаживает
Чтобы не платить за соседей:

devin --model swe-2-high
/model swe-2-high
/session-stats

В конфиге закрепить (например) %APPDATA%\devin\config.json,

{
  "agent": {
    "model": "swe-2-high"
  }
}

Ну а /fusion, /model adaptive и /handoff не трогать. В статистике должна быть одна модель SWE-2, без Lead/Sidekick, и quota не должна уменьшаться.

P.S. Низкий порог входа по почте и слабая привязка к устройству сделали промо очень удобным для мультиаккаунтинга. Те 1 аккаунт за 20$ на почту + vps + cliproxyapi =>десятки индусов абузят через сабагентов. А еще конечно это по сути бесплатная мощная модель для любых ваших ИИ продуктов

P.P.S. 100% включат недельные квоты для free tier, но попробуй успеть пока не разобрали

Интересующие нас коммиты в этом посте: f4bfb1a9c6, 9be7615aa2, 5af294bac7, 84e0c4965a, 1bcfdf2df2.

Главное: теперь на heap перестанут утекать аргументы переданные в замыкания, если компилятор сможет статически определить, какая функция будет вызвана. Проблема была в том, что компилятор не знал, кто именно будет вызван, и консервативно считал, что все аргументы вызова утекают в heap.

Давайте посмотрим на пару примеров:

func Apply() int {
	var f func([]int) int
	f = func(p []int) int { return p[0] * 2 }
	arr := make([]int, 2)
	return f(arr)
}

Пример достаточно вычурный, но явно показывает разницу.

Бенчмарки: Go 1.26:

BenchmarkApply-10                	93288418	        11.95 ns/op	      16 B/op	       1 allocs/op

Go 1.27:

BenchmarkApply-10                	590856250	         2.028 ns/op	       0 B/op	       0 allocs/op

Компиляция с -gcflags=-m сразу укажет на причину.

Go 1.27:

./demo.go:26:6: func literal does not escape
./demo.go:27:13: make([]int, 2) does not escape

Go 1.26:

./demo.go:26:6: func literal does not escape
./demo.go:27:13: make([]int, 2) escapes to heap

Но не все так просто. У меня есть и контрпример, когда escape analysis промахивается:

var g func(*int) int = func(p *int) int { return *p * 3 }

func ApplyUnresolvable() int {
	var f func(*int) int
	f = func(p *int) int { return *p * 2 }
	f = g
	return f(new(int))
}

А в этом примере аргумент замыкания f убежит на хип, потому что в момент вызова f(new(int)) в f может лежать любое из присвоенных значений. Значение g компилятор доказать не может — это переменная уровня пакета, её содержимое escape analysis не отслеживает, то есть «аргумент может утечь куда угодно». Например, что если g будет запускать goroutine внутри. Поэтому тут компилятор выбирает консервативное поведение.

Теперь я покажу, как с переходом с 1.26 на 1.27 можно получить почти восьмикратное ускорение!

type Node struct {
	Val      int
	Children []*Node
}

func Sum(root *Node) int {
	var visit func(*Node) int
	visit = func(n *Node) int {
		t := n.Val
		for _, c := range n.Children {
			t += visit(c)
		}
		return t
	}
	return visit(root)
}

func BuildAndSum(v int) int {
	root := &Node{Val: v, Children: []*Node{{Val: 1}, {Val: 2}}}
	return Sum(root)
}

Здесь ни один экземпляр Node не утечет на хип! Смотрим на бенчмарки. Go 1.26

BenchmarkBuildAndSum-10          	17728094	        66.86 ns/op	     112 B/op	       4 allocs/op

Go 1.27

BenchmarkBuildAndSum-10          	148023318	         8.561 ns/op	       0 B/op	       0 allocs/op

Как и обещал ускорение примерно в 8 раз :)

P.S. Вообще удивительно как интересные вещи пропускают в release notes. Я нашел как минимум еще три изменения, которых нет в release notes, но прямо влияющих на перф. Одна из них так вообще прямо влияет на то как мы пишем бенчмарки! Но об этом в другой раз ;)

Если вам понравилась статья и вы хотите узнать про три других изменения, то заглядывайте в мой Telegram-канал.

Карта сделана в ночном стиле, как карты Ancient и Shoots, которые сделаны в стиле карты Aztec и используют ассеты карты Aztec. Карта доступна в мастерской CS2.

Когда я начал писать на Go после опыта с Ruby и Elixir, одной из самых непривычных вещей стало отсутствие консоли, в которой можно напрямую вызывать код приложения.

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

Набираешь:

bundle exec rails c

И через несколько секунд уже находишься внутри приложения и можешь работать с его кодом и данными. Только вместо кнопок у разработчика код. Надо помнить: «С большой силой приходит большая ответственность». © Дядя Бен.

Например, приходит вопрос:

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

В Rails можно открыть консоль, вызвать нужный код и довольно быстро проверить несколько гипотез. Когда я пришёл в Go, первое время постоянно хотелось сделать то же самое. Конечно, проверить код всё равно можно. Можно написать тест или небольшую программу, подключиться к базе, сделать отдельную CLI-команду под конкретный кейс, но это уже не то ощущение: «открыл приложение и начал быстро проверять гипотезы».

Ruby здесь не единственный пример. В Elixir есть интерактивная консоль IEx. Можно запустить прямо внутри неё:

iex -S mix

Благодаря возможностям Erlang VM можно даже подключаться консолью к другому запущенному узлу. И вот после Ruby и Elixir Go ощущается особенно необычно. В Ruby удобную консоль обычно даёт фреймворк. В Elixir сама платформа хорошо приспособлена к интерактивной работе с запущенной системой.

В Go это ощущается так:

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

Поначалу это раздражает. Кажется, что раньше на проверку гипотезы уходило 5–10 минут, а теперь приходится что-то дополнительно писать, но со временем я увидел в этом и другую сторону. Удобная консоль очень легко позволяет разработчику стать частью бизнес-процесса. Про эту боль я подробнее писал в статье. Также можно легко сломать продакшен.

Нет нужной кнопки в админке?

Попросим разработчика выполнить команду.

Нужно поправить состояние пользователя?

Разработчик сделает через консоль.

Для небольшого бизнеса это действительно может быть удобно. Но потом внезапно оказывается, что важная операция в продукте существует только потому, что рядом есть разработчик, который знает правильную команду. Я такой подход называю Developer as an admin panel.

В Go отсутствие такого универсального пульта начинает раздражать раньше. Если одна и та же операция повторяется, довольно быстро хочется сделать для неё CLI, скрипт, админку или нормальный API. Бизнес раньше начинает видеть ценность такого инструмента.

Я всё ещё считаю консоли в Ruby/Elixir невероятно удобными инструментами. Но теперь, когда хочется в очередной раз сделать что-то вручную, полезно задать себе вопрос:

Мне действительно не хватает консоли или не хватает нормального инструмента?

В 32 выпуске «Битовых масок» Антон Афанасьев и Алина Галичина разбираются в краевом искусственном интеллекте вместе с Иваном Дейнекой — заведующим лабораторией Высшей инженерно-технической школы ИТМО. Иван совмещает три роли сразу: инженерную, научную и преподавательскую, а его команда размещает нейросети на ПЛИС и SoC.

Гость объяснил, почему ПЛИС выигрывают у связки CPU с NPU, когда сеть нестандартная, и почему память, а не вычислители, оказывается главным ограничением. Рассказал, как из университетского проекта волоконно-оптического гироскопа выросли лаборатории института, зачем инженеру статический временной анализ и что делать, если проект не помещается в кристалл.

Среди тем подкаста:

• зачем встраивать нейросеть-триггер прямо в ПЛИС, чтобы поймать редкий баг;

• когда нужна ПЛИС, а когда хватит микроконтроллера;

• почему статический временной анализ пропускают и чем это заканчивается;

• что делать, если проект не помещается в кристалл;

• какие модели уже разместили на ПЛИС: MLP, сверточные сети, трансформеры;

• почему память, а не вычислители, ограничивает нейросети на ПЛИС;

• как из университетского проекта вырастают лаборатории и производство.

😍 Смотрите и слушайте подкаст на любой удобной платформе — и присоединяйтесь к каналу «Битовых масок», чтобы не пропустить новые выпуски!

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

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

Есть смысл в маркетинге для разрабов? Что думаете?

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

Это так и не так одновременно.

Этого достаточно для понимания принципа, но это же неверно с точки зрения реальности (как же меня за это упрощение били на форумах и в комментах). Теперь давайте разберемся, что же происходит на самом деле.

Компьютеру в целом неудобно работать со словами. Для нас «мама», «мыла» и «раму» - три совершенно понятные языковые единицы. Для машины это просто последовательности букв. Поэтому перед обучением модели огромную гору текстов сначала разбирают и ищут в ней кусочки, которые постоянно повторяются.

Допустим, начинаем с букв. Но сочетание «ма» встречается постоянно - имеет смысл считать его одним кусочком. «Мама» встречается еще чаще - можно добавить целиком и его. То же самое постепенно происходит с частями слов, целыми словами, окончаниями, знаками препинания и даже пробелами. В результате получается огромный набор деталей, из которых можно собрать практически любой текст.

Вот эти детали и называются токенами.

Можно представить их как детали конструктора. В коробке есть крупные и часто используемые детали - распространенные слова и сочетания. Есть мелкие - части редких слов и отдельные символы. «Мама» может оказаться одной готовой деталью, какое-нибудь «межконтинентальный» придется собрать из нескольких, а фамилию никому не известного новозеландского разработчика климатического оружия модель, возможно, вообще будет собирать почти по буквам.

Внутри модели у каждого токена есть свой номер. Условно, «мама» - 18342, какой-нибудь кусок «континент» - 7311, точка - 13. Когда мы отправляем модели предложение, к ней в итоге приезжают не слова, а последовательность токенов, переведенных в номера.

И вот с ними она уже работает.

Поэтому наше старое «мама мыла» на самом деле означает не «модель выбирает следующее слово». Она получает цепочку номеров и решает, токен под каким номером должен быть следующим. Выбрала. Теперь последовательность стала длиннее, и нужно выбрать следующий. Еще один. Еще. Потом эти номера обратно собираются в токены, и мы видим нормальный человеческий ответ.

Этот процесс называется токенизацией. Вы спросите - зачем так сложно, почему не сделать каждый символ отдельным токеном и успокоиться? Потому что модель работает с токенами по одному. Если «мама» - один токен, для ее генерации достаточно одного шага. Если «мама» - четыре токена, нужно уже четыре, причем на каждом следующем шаге приходится учитывать все, что было до него. А теперь попробуйте таким способом собрать «межконтинентальную баллистическую ракету». Поэтому делать токенами отдельные буквы можно, но дорого, а сделать отдельный токен для каждого существующего слова не имеет смысла (приставки, суффиксы, окончания, новые слова). Поэтому часто встречающееся пакуем крупно, редкое собираем из мелочи. Чем короче в итоге получилась цепочка, тем меньше работы.

Сейчас придется немного уточнить и предыдущую заметку. Там мы для простоты представляли параметры как мини ассоциации между словами и понятиями. Это было упрощение: никаких готовых «мама - дом - уборка» модель не держит. Она работает с токенами и их сочетаниями, а привычные нам ассоциации возникают уже из всего это массива. Для понимания принципа сойдет, но теперь мы знаем, что под капотом все несколько хитрее.

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

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

Но «ИИ угадывает следующее слово» все равно остается вполне рабочим объяснением.

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

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

Эссе называется «Проектировочные машины для решения проблемы сложности мира». Автор? Питер Норвиг! Ага, тот самый.

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

Оставляем за скобками, какого качества были эти «новые профессии» и какого качества специалистов они требовали. Трудового законодательства не было в принципе нигде в мире, а кое-где еще сохранялось рабство и работорговля. Не будем копаться и в мотивах луддитов, громивших те самые ненавистные проявления прогресса, сиречь станки (утверждение, что они были антипрогрессистами и мракобесами, нельзя распространять на всех, там все было сложнее). Просто прочитаем приведенную цитату и выделенное предложение. А ведь и правда, никто особо не учитывает скорость изменений. Упомянутая Первая промышленная революция продолжалась примерно 70-80 лет, тогда одно поколение – это 25-30 лет. На текущий же момент ChatGPT «выстрелил» в 2022 году, а уже в 2025 начинаются массовые сокращения «из-за ИИ». Тут не то, что поколение (сейчас это 30-40 лет) не сменилось, тут даже куда-то податься и более-менее фундаментально выучиться не получится.

Рядом другая проблема: система образования тоже не успевает, чтобы кого-то чему-то научить необходим подготовленный профессорско-преподавательский состав, методология и стоящая за всем этим наука. Соответственно, простому «воротничку» (хоть синему, хоть белому, хоть серому) попросту негде обучиться новой профессии, которую вот-де прямо сейчас создает ИИ.

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

Для первой карты существует 52 возможных позиции, для второй — 51, для третьей — 50 и так далее. Общее число вариантов равно:

52 × 51 × 50 × … × 2 × 1.

В математике это записывается гораздо короче: 52!, или «52 факториал».

За этой компактной записью скрывается число из 68 цифр:

52! ≈ 8 × 10⁶⁷.

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

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

Но здесь возникает другой вопрос: сколько раз вообще нужно тасовать колоду, чтобы считать её хорошо перемешанной?

Исследования математиков показали удивительный результат: для обычной колоды достаточно примерно семи правильных riffle shuffle — привычных тасовок, при которых колоду делят примерно пополам, а затем переплетают две половины небольшими группами карт.

После одной или двух тасовок первоначальный порядок всё ещё хорошо заметен. Даже после четырёх или пяти в колоде сохраняется значительная структура.

А затем происходит резкий переход.

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

Получается своеобразный порог.

До него колода сохраняет память о прошлом. После него эта память почти исчезает.

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

Хорошего дня! заходите на тг канал https://t.me/TradPhronesis

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

В основной отчет по проверке web-ресурса входит:

• email-адреса;

• телефоны по российским и американским форматам;

• телефоны из HTML-полей tel, phone, telephone, mobile и аналогов;

• адреса из специализированных полей и строк с явными адресными признаками;

• источники только тех страниц, где найдены контакты;

• внешние домены;

• внешние API endpoint-ы;

• внешние JavaScript-файлы;

• агрегированные счётчики обхода;

• DNS, IP и reverse DNS;

• RDAP и WHOIS;

• TLS-сертификат;

• цепочка перенаправлений;

• найденные поддомены;

• локальная история DNS/TLS;

• ограниченное сканирование TCP-портов исходного домена и определение технологий;

• технологии, используемые на сайте

Репозиторий проекта: https://github.com/Bednyakov/PhishIntel

redb 4.0.1: транзакции, изоляция кластеров и SQL-коннектор по канону Camel

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

redb.Core

• Всё, что redb делает внутри общей транзакции .NET (TransactionScope), теперь фиксируется или откатывается вместе с ней, на MSSQL, PostgreSQL и SQLite.

• Ленивые загрузки идут по соединению того, кто читает, без скрытых соединений.

• Кэш Props держит нагрузку, а объекты по списку идентификаторов загружаются одним запросом.

• Нативное расширение SQLite сверяет свою версию при старте и называет устаревший файл, если он попался.

redb.Route

• Единица работы стала предсказуемой: сначала фиксируется база, потом брокеры, а повтор оборачивает транзакцию целиком. Необработанный сбой везде остаётся сбоем, обработка ошибок ведёт себя как в Apache Camel.

• SQL-коннектор прошёл полное ревью: пакетная запись с откатом при первой ошибке, точки сохранения для частичной записи, строгое отображение результатов в классы, параметры в синтаксисе Camel.

• Сбойный файл больше не тормозит всю пачку у файловых консюмеров, появился отложенный опрос.

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

• На обмене появилась личность вызывающего, общая для всех входящих транспортов.

redb.Tsak

• Несколько кластеров на одной базе полностью изолированы: координация, состояние, очередь недоставленных, аудит и планировщик у каждого свои.

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

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

redb.Identity

• API управления больше не считает вызов доверенным только потому, что он пришёл изнутри процесса.

• Одно DPoP-доказательство нельзя использовать дважды даже при одновременных запросах.

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

Что учесть при обновлении

• Tsak: если на одной базе живут несколько кластеров, перед обновлением остановите все узлы этой базы.

• Route: параметры в SQL-запросах переходят на синтаксис Camel, а единица работы и обработка ошибок стали строже. Это стоит проверить на своих маршрутах.

Pro по-прежнему бесплатен и не требует ключа. Полные списки изменений на redb.ru/releases, исходники на GitHub.

Если было полезно, ⭐ на GitHub поможет другим это найти.

Другие мои статьи — redb.ru/articles, ещё — на Хабре.

Настраиваем S3-доступы так, как нужно проекту

Добавили редактор политик для пользователей S3. Теперь в панели можно как выдать готовую роль, так и настроить собственную политику — редактируете ее в интерфейсе или загружаете готовый JSON.

Когда пригодится:

1️⃣ Открыть разработчику только чтение логов — без возможности изменить или удалить данные.

2️⃣ Выдать клиенту доступ к нужной папке в бакете — остальные объекты останутся недоступны.

3️⃣ Разрешить скрипту бэкапов запись без права удаления — старые копии останутся целы.

Права можно задать как для новых пользователей при создании, так и для уже существующих в S3 → «Пользователи». Еще политика доступна в настройках конкретного бакета.

Раздать персональные права →

Во втором поколении Managed Kubernetes меняется граница ответственности между пользователем и платформой.

Системный слой размещается в сервисном проекте и обслуживается VK Cloud. Пользователь управляет приложениями и данными, обновляет версию Kubernetes и аддоны.

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

Граница ответственности зависит от поколения кластера

Первое поколение
Все компоненты кластера размещаются в пользовательском проекте. Пользователь получает доступ к системным компонентам.

Второе поколение
Системные компоненты размещаются в сервисном проекте VK Cloud. Пользовательский кластер работает внутри системного и подключается к проекту по сети.

Системный слой обслуживает VK Cloud

Во втором поколении платформа управляет системными компонентами, master- и worker-узлами.

VK Cloud:

• выбирает конфигурацию master-узлов

• управляет их автомасштабированием

• сопровождает системную инфраструктуру.

Пользователь обновляет версию Kubernetes через личный кабинет и устанавливает аддоны.

Мониторинг и аудит подключены по умолчанию

Для кластеров второго поколения включена интеграция с мониторингом VK Cloud. Отключить ее нельзя, сам мониторинг не тарифицируется.

События Kubernetes API записываются в Cloud Audit по преднастроенной политике.

Прикладные метрики, алерты и Prometheus-стек пользователь настраивает под свои задачи.

Во втором поколении доступен свой набор инструментов

Среди возможностей:

• добавили выбор между Calico и Cilium

• управление PV через личный кабинет

• Argo CD, CSI для S3, External Secrets Operator, Kgateway и Velero

• инструменты для работы с GPU

Как перейти на второе поколение

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

Перед переходом стоит проверить зависимости:

• версии АРІ и манифесты

• аддоны и stateful-сервисы

• секреты и внешние интеграции

• CI/CD, DNS и балансировщики

Сначала можно проверить миграцию на dev-окружении

Stateless-сервисы разворачивают в новом кластере и проверяют на тестовом трафике, пока текущий кластер обслуживает боевую нагрузку.

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

Создайте кластер второго поколения Managed Kubernetes

Передайте обслуживание системного слоя VK Cloud и сосредоточьтесь на приложениях и данных. Мониторинг и аудит уже встроены, также доступны Cilium и инструменты работы с GPU.

Поговорил со Степаном Грабиновым, бизнес-аналитиком Цифрового СИБУРа. Полгода он с командой разбирался, как устроено производство тепличных помидоров и огурцов и где там можно применять полимеры. Вот что рассказал:

Начали мы с многооборотной тары — пластиковых ящиков, которые ездят по кругу вместо одноразовых картонных. Рынок овощей поделили по выручке и остановились на тепличных томатах и огурцах: бизнес круглогодичный, а первая тройка игроков занимает около 60%. С крупным игроком проще потому, что у него есть бюджет на пилоты.

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

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

Отгрузка в картонном коробе в один конец стоит 30–40 рублей, а рейс полимерного ящика в пулинге обходится на 30–40% дешевле.

Провал на предзащите

С этой экономикой мы пошли на предзащиту. Директор дивизиона сказал:

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

Переделать подход надо было за месяц.

Почему теплицы стеклянные, а рассада в матах

Сначало хотели предложить поликарбонат. Оказалось, промышленные теплицы во всём мире стеклянные: крупному производителю важен каждый процент урожая, а стекло служит дольше. Поликарбонат — материал для дачника.

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

Что нашлось в тендерах

В нейросетях мы ничего толком не нашли, зато процесс восстановили по тендерам предприятия.

В тендере на клипсы, которыми фиксируют кисти и побеги, посекундно расписана норма агронома: сколько штук он должен прикрепить за единицу времени. Если клипса медленнее защёлкивается или выскальзывает, агроном не выполняет норму, а следом и весь участок. Отлить пластиковую клипсу несложно. 

Сделать такую, которая защёлкивается за нужное время и не ломается, — это инженерная задача.

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

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

Вернулись к ящикам

Механику мы знали с начала, а вот выгоды для ритейлера не видели. У него от оборотной тары одни обязательства: учитывать ящики на складе и отвечать за повреждения и пропажи.

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

Сначала мы считали экономику двух участников, производителя и себя. А в цепочке есть ещё пулер и ритейлер, у которого свои операции и потери. Поняли, что вопрос «кого мы забыли в системе» надо было задать с самого начала.

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

ИИ — страшнее ядерной бомбы

Руководители ведущих разработчиков ИИ-моделей как с цепи сорвались и один за другим обсуждают опасность искусственного интеллекта для человечества и необходимость затормозить его развитие «до создания необходимых защитных барьеров». Однако Дональд Трамп против, и позиция президента США выгодна обычным пользователям.

Дарио Амодеи, глава Anthropic, выступил с эссе о необходимом замедлении темпов развития ИИ. Такую же позицию неожиданно высказал Сэм Альтман, а Илон Маск (напомним, что в SpaceX входит разработчик ИИ xAI) напомнил, что он предупреждал об опасности ИИ ещё 10 лет назад.

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

Новые ИИ-модели Anthropic и OpenAI действительно показали поразительные способности в кибервзломе. Они проникали в системы даже без прямого приказа для выполнения сторонних задач. Можно испугаться. И показать, как заботишься о человечестве. Будет что ответить регулятору.

Практически ИИ воспринимается как ядерное оружие, взаимный контроль над которым позволил перевести потенциальный конфликт СССР и США в холодную фазу. Но есть большое отличие. Человечество и раньше старалось ограничить вооружение — например, в 1922 году ограничили размеры и количество кораблей. Позднее ограничили количество ядерного оружия и их испытания.

Но все эти ограничения можно было ПРОВЕРИТЬ. Размеры корабля видно, можно обнаружить ядерное испытание в любой точке Земли и даже описать его характеристики. А какая там модель крутится в интранете у очередного разработчика M — все узнают только, когда её пустят в дело.

Поэтому кажется разумной позиция Дональда Трампа: перестаньте заниматься ерундой и говорить о смертельной опасности для человечества. Пока это похоже на поиск рычагов влияния — ведущие разработчики с миллиардными вложениями смогут отчитаться о любых защитных мероприятиях. Молодые-подрастающие умрут под регуляторным контролем. А в результате конкуренции не будет и проиграют простые пользователи, которые не получат новых эффективных ИИ-моделей.

Как хорошо, что в США конкуренция не ограничивается, и сам Дарио Амодеи признаёт — остановить развитие ИИ невозможно: если не мы, то Китай сделает более совершенные ИИ-модели. К которым, надеемся, получат доступ и конечные пользователи.

Источник изображения: Шедеврум.

Модульный фреймворк для гибкого тестирования на Go — Testo

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

Testo — это слой над testing.T внутри экосистемы Go. Мы наполнили его плагинами, чтобы гибко адаптироваться под потребности и быстро создавать тесты под любую задачу.

Что ещё может Testo

1. Параметризировать тесты.

2. Параллелить тесты.

3. Собирать тесты в Suite'ы.

4. Формировать Allure-отчёты.

5. Перезапускать упавшие тесты.

И многое другое, благодаря плагинам.

Больше информации о функционале и ссылка на GitHub — на страничке фреймворка.