By SURiCH

👁 Компьютерное зрение: как изменилась разработка за 7 лет Недавно вернулся к теме Computer Vision после паузы с 2018-19 года — и это как будто попал в другую эпоху. Делюсь впечатлениями. --- 🕰 Как это было тогда Помню то время: каждая команда варила свой собственный суп на основе OpenCV. Никаких стандартов переносимости — просто упаковываешь всё в DLL и молишься, что на другой машине указатели не поедут. А они ехали. Постоянно. void* или void** — классика жанра, от которой дёргался глаз. Документация? У коммерческих вендоров она была написана будто назло: половина методов задокументирована на уровне "смотри исходники", а исходников нет. Датасеты — у каждой конторы свои, в своих форматах, несовместимых ни с чем. --- 🚀 Что изменилось сейчас Переносимость моделей стала стандартом: → ONNX — универсальный формат обмена моделями. Обучил в PyTorch, задеплоил через ONNX Runtime хоть на Windows, хоть на ARM, хоть на браузер. Без боли с указателями → TensorRT (NVIDIA) и OpenVINO (Intel) — оптимизированный инференс под конкретное железо, с нормальной документацией → Triton Inference Server — стандарт для серверного деплоя CV-моделей как REST/gRPC сервиса Экосистема датасетов и моделей: → Hugging Face — GitHub для моделей и датасетов. Тысячи готовых CV-моделей в 3 строки кода → Roboflow — менеджмент датасетов, аннотация, аугментация, версионирование — всё в одном месте → CVAT / Label Studio — открытые инструменты аннотации с экспортом в десятки форматов YOLO из "крутой штуки" стал промышленным стандартом: → Ultralytics YOLOv8/v11 — Python-first API, одна строка для обучения, документация на уровне лучших open-source проектов. От того pointer-hell не осталось следа Архитектурный сдвиг: → CNN потеснили Vision Transformers (ViT) — трансформеры захватили и CV → SAM (Segment Anything) от Meta — zero-shot сегментация. Буквально: "сегментируй это" без дообучения → CLIP — модель, которая понимает связь текста и изображения. Основа для мультимодальных LLM Деплой: → Docker + Kubernetes стал дефолтным стандартом упаковки CV-решений → REST API вместо DLL — сервис за сервисом, никаких танцев с памятью --- 💬 Личное впечатление Порог входа упал радикально — junior сегодня за неделю делает то, на что у нас уходил месяц. Но сложность никуда не делась: она переехала из "как это вообще запустить" в "как это правильно оптимизировать и поддерживать в проде". Документация стала нормой, даже у отечественных разработчиков, а не исключением. Это, пожалуй, самое приятное изменение.

У меня скоро появится коммерческий проект по ai. Думаю сделать серию постов по этой теме: как сейчас обстоят дела при решении прикладных задач с использование нейронок. А для примера, сделать небольшую текстовую игру. Если тема интересна, ставьте реакции 👇

Смотрите, что у меня теперь есть 😎

А теперь про то, почему я решил сменить архитектуру, хотя даже бэта релиза ещё не было: Когда я только начал разработку, толковых инструментов в Unity для реализации DOTS не было. ESC (Entity Component System) появилась только в Unity 2022, а я на момент начала разработки использовал версию 2021 LTS. 1. Переходить на новую версию Unity из за пары сырых механизмом, идея такая себе, а тянуть сторонние библиотеки, которые не факт что нормально совместимы с Unity - идея ещё хуже. 2. Ещё год назад, при внутренних тестах, столкнулся с проблемами производительности, при генерации мобов. Они были решаемы, но требовали забить на оптимизацию под слабые смартфоны. Собственно, вопросы оптимизации тогда улетели в долгий ящик. 3. Даже на стадии альфа, проект начал разрастаться с огромной скоростью, несмотря на то, что первоначальных базовых механик не так много, но достаточно много требований к организации проекта (требований к тому, как я привык его организовывать). Сейчас, вернувшись к разработке, одна из первых вещей, которые сделал - сел разбираться с текущим положением дел в движке, и примера ради накалякал маленький проект на Unity 6. Моё удивление от того, что ESC довели до ума - было не передать. Таким образом, решено убить сразу двух зайцев - обновить версию Unity для проекта (а это тоже не всегда тривиальная задача) и на корню зарубить вопрос оптимизации геймплея, сменив архитектуру.

MonoBehaviour vs DOTS в Unity — что выбрать? MonoBehaviour — object-oriented (объектно-ориентированный) классический подход Unity: GameObject + Component + MonoBehaviour. Он простой, понятный и подходит для большинства игр, особенно прототипов, инди и небольших проектов. DOTS = Data-Oriented Technology Stack (Дата-ориентированный стек технологий) — подход, заточенный под производительность. Вместо привычных объектов — Entities, Components, Systems. Он нужен там, где на сцене очень много сущностей: толпы, RTS, симуляции, сложный AI. Если коротко: MonoBehaviour — проще в разработке DOTS — сложнее, но быстрее на больших нагрузках Когда выбирать MonoBehaviour: - нужен быстрый старт - проект маленький или средний - важна простота и удобство Когда смотреть на DOTS: - тысячи объектов на сцене - упор в CPU - важна максимальная производительность Вывод: Для большинства проектов хватает MonoBehaviour. DOTS стоит брать не “потому что модно”, а когда классический подход уже не вывозит.

Дневник разработчика: После наконец я закончил детальный анализ всех наработок (да, на это ушло время). - Из важного, мы переходим с Unity 21 на Unity 6. Уж очень много там вкусных плюшек. - Архитектура тоже переписывается с MonoBehaviour на Unity DOTS. Это позволит запускать одновременно большое количество мобов и не боятся за производительность. На следующей недели, надеюсь, закончу все приготовления и начну публиковать инфу о стартовом паке мобов и башен. By SURiCH

Есть кто живой? Мы всё еще на связи, или тг официально мёртв как площадка?

Что такое отпуск? Может это миф? Может есть он где-то Только у других Третий день отпуска. И третий день меня поднимает звонок телефона в 6 утра. Кажется, скоро я выкину этот бесполезный результат аннигиляции стекла и пластика😢

Пост выходного дня 😁 Как превратить свой андрой, в полноценную Линукс среду? Termux - эмулятор терминала для вашего смартфона. Имеется свой репозиторий pkg, с большим количеством пакетов под различные задачи. Лично я использую в основном для того, что бы в поездках оперативно администрировать сервера, но возможностей у утилиты сильно больше. По Termux полно материалов в интернете, в том числе на русском языке, по этому не вижу смысле подробно разбирать. Но если в комментах будут интересные вопросы, возможно напишу пару постов 😜

Ухожу в отпуск на неделю 🥳 Не теряйте! До 6 апреля новостей скорее всего не будет😁

Немного разобравшись, на чем остановились в прошлый раз, резюмирую, что уже было готово: 1. Карта 2. Скрипты и логика движения enemy 3. Механика установки башен 4. Механика стрельбы и преднастройки башен Для выхода на первые тесты оставалось: 1. Меню строительства 2. Добавить инструменты разработчика, для dev-build версии игры. В идеале, я бы хотел ещё сделать редактор карт, но видимо эту идею отложу до первой бэты.

К стати, завтра постараюсь пост по Чикену сделать, если не запарюсь

И так, обещанный отзыв об использовании нейронки в разработки! Предыстория: На прошлой недели, на работе мне поставили задачу: - Нужно изучить вопрос внедрение AI-ассистентов в разработку. До этого момента я знал про то, что всё больше разработчиков переходит на использование ИИ-ассистентов, но времени разбираться с эти не было. Слишком много работы. А тут мне на радость поставили такую задачу 😁 На выходных раскурив интернет, пообщавшись с чат-ботами, и купив на пробу пару платных доступов, пришёл в итоге к связке Cloud Code + Cloud-opus. Не много потренировавшись, с этого понедельника пустил в бой, на одном из рабочих проектов... И теперь я не смогу работать по другому 😂 Слишком это удобно. Плюсы: + Время. То, что раньше занимало Неделю, теперь делается за один день. То, что занимало день, теперь занимает пять минут; + Понимание Великого и Могучего Русского языка; + Детализация результата проделанной работы. +/- Документирование. Этот пункт одновременно и плюс и минус. С одной стороне, нейронка очень хорошо выделяет основные вехи проекта, на основе коммитов и контекста самого проекта. С другой стороны, в структурированный документ, согласно какому-то шаблону - для неё сложная задача. Схемы, графики и так далее, для этого нужно выбирать конкретную нейронку, в конкретный момент. Минусы: - Не совершенство нейронок. Ассистент всё ещё требует сильного контроля со стороны основного разработчика. - Постоянные запросы разрешений. Я понимаю, почему это сделано, но это не спасёт от идиота между столом и креслом, который спросонья выдаст разрешение на дроп системы, просто не поняв о чём его справшивает ассистент. - Творческий подход - не в этом случае. - Сложно интегрировать в корпоративный сегмент Выводы которые я сделал для себя: Нейронки доросли до полноценных помощников. Один сеньёр + нейронка теперь способен заменить минимум трёх человек на проекте: Фронта, бэкэндира, и лида. Однако, необходимо строго следить за телодвижениями нейронки, иначе проект рискует превратиться сборную солянку из архитектурных принципов, и дублирующихся решений. Для соблюдения кодстайла, нейронке нужен обязательный пример (а как же иначе), в ином случае он начнёт пихать классы и решения туда где не надо. Пример: в документации к библиотеке Mediator (не путать с MediatR) указано, что для предотвращения ошибок, необходимо подключать DI в верхнем слое, например Presentation. Однако нейронка пытается запихать в Application. Что логично, но не в данном случае. Другой момент, что если проблему нельзя найти на глаз, и нужно выдвинуть неочевидные гипотезы, тут нейронка бессильна. Пример: У меня между двух сервисов запрос не проходил с кодом 401 (Не авторизован), хотя токен в заголовке корректный, Сервер всё пингует, других ошибок, исключений или комментариев нет. Как оказалось позже, из за наличия https эндпойнта на сервере, он принудительно перенаправлял все соединения туда. А так как хост тестовый, сертификат там не поднимали, сервер все запросы на этот эндпойнт просто отвергал как неавторизированные. И ещё одна мысль, я реально теперь боюсь потерять компетентность в вопросе разработки. Нейронки слишком удобный инструмент, что бы в какой то момент не расслабиться. Теперь про корпоративный сегмент: нейронки от исполняемой машины к серверу туда сюда кидают файлы и данные, с которыми работают (что очевидно), что в свою очередь противоречит корпоративным стандартам, по которым вся чувствительная информация, включая исходные коды, должна храниться внутри компании. Следовательно, это создаёт проблему для интеграции. Посмотрим как будет дальше у меня на работе, но в личных проектах я нашёл для себя бескомпромиссный инструмент 😝

Начал пробовать использовать нейронки для разработки. Вечном будет отзыв 😁

Закончил! Пока мне нравится как получилось🥳

Пришлось перекручивать кронштейны поверх коврика, что бы всё на места встало 😁