-
МФО и онлайн займы: памят...
Форум: Курилка (Offtop)
Останнє повідомлення від: Bankwerta
7 годин тому
» Відповіді: 0
» Перегляди: 8 -
Sicher spielen bei SpinMa...
Форум: Курилка (Offtop)
Останнє повідомлення від: spinmamacasinologin-Blamp
10 годин тому
» Відповіді: 0
» Перегляди: 5 -
Die Cookie-Nutzung auf de...
Форум: Курилка (Offtop)
Останнє повідомлення від: spinmamacasinologin-Inoto
11 годин тому
» Відповіді: 0
» Перегляди: 3 -
Karta prywatności serwisu...
Форум: Курилка (Offtop)
Останнє повідомлення від: play-equaday
, 14:13
» Відповіді: 0
» Перегляди: 8 -
Pobierz aplikacje SpinMam...
Форум: Курилка (Offtop)
Останнє повідомлення від: spinmamacasino-Psymn
, 12:06
» Відповіді: 0
» Перегляди: 9 -
Ivibet im Test: Alles run...
Форум: Курилка (Offtop)
Останнє повідомлення від: ivybet-ideora
, 10:09
» Відповіді: 0
» Перегляди: 9 -
Erfahrungen mit der belie...
Форум: Курилка (Offtop)
Останнє повідомлення від: chickenroad-Heessy
, 09:36
» Відповіді: 0
» Перегляди: 9 -
Grasping Our Tracking Gui...
Форум: Курилка (Offtop)
Останнє повідомлення від: spinmachoapp-effogue
, 01:35
» Відповіді: 0
» Перегляди: 20 -
Learning about Spin Mama'...
Форум: Українські розробки
Останнє повідомлення від: spinmamacasinodeal-affox
, 00:01
» Відповіді: 0
» Перегляди: 13 -
New Space Discoveries
Форум: Курилка (Offtop)
Останнє повідомлення від: spinmamacasinodeal-affox
13-09-2026, 23:59
» Відповіді: 22
» Перегляди: 2,844
- Повідомлення на форумі:606
- Гіди форуму:269
- Учасники:331
- Останній учасник:ivybet-driesty
Привіт, спільното! Сьогодні хочу детально розібрати **ThinkPHP** — PHP-фреймворк, який в нашому регіоні часто залишається в тіні Laravel чи Symfony, але є абсолютним гігантом на азіатському ринку і має величезну кількість переваг для розробки сучасних веб-додатків.
Що таке ThinkPHP і чому він вартий уваги?
ThinkPHP — це легкий, швидкий та дуже гнучкий MVC фреймворк. Починаючи з версій 6 і 8, він був повністю переписаний: перейшов на строгу типізацію, сучасні стандарти PSR та повноцінне використання Composer.
Головні особливості:
1. Продуктивність: Він значно легший за Laravel. Якщо вам потрібен швидкий API без зайвого 'оверхеду', ThinkPHP завантажується і обробляє запити в рази швидше за конкурентів.
2. Потужна ORM: Вбудована ORM дуже нагадує Eloquent. Вона підтримує моделі, відношення, м'які видалення (soft deletes), автоматичні таймстемпи, події моделей та зручний Query Builder.
3. Інтеграція з Swoole / Workerman: Фреймворк 'з коробки' відмінно працює в асинхронному режимі. Ви можете запустити його як резидентну програму (daemon) і отримувати продуктивність на рівні Node.js або Go.
4. Маршрутизація (Routing): Гнучкий роутинг з підтримкою мідлварів (middleware), анотацій (annotations) та RESTful контролерів.
Як почати користуватись?
Встановлення дуже просте через Composer:
composer create-project topthink/think myappПісля встановлення ви можете відразу запустити вбудований dev-сервер:
php think runСтворення простого контролера `app/controller/User.php` виглядає дуже елегантно:
namespace app\controller;
use app\model\User as UserModel;
class User {
// Автоматично поверне список всіх юзерів у форматі JSON
public function index() {
return json(UserModel::select());
}
}Як бачите, синтаксис дуже чистий і зрозумілий.
Запрошую до обговорення! Якщо у вас є питання щодо цього фреймворку — задавайте, буду радий поділитися досвідом.
Привіт, спільното! Пам'ятаєте 2023-2024 роки? З кожної праски нам кричали, що Штучний Інтелект дуже скоро повністю замінить програмістів. Усі малювали красиві графіки, як корпорації звільнять 80% штату і залишать одного "промпт-інженера", який буде генерувати код цілими проектами абсолютно безкоштовно. Але реальність у 2026 році виявилася дещо іншою.
Сьогодні хочу підняти тему економіки ШІ: чому вартість токенів раптом виявилася більшою, ніж зарплата живого розробника?
Коли ми гралися в ChatGPT з простими запитами, все виглядало дешево і сердито. Але як тільки компанії почали впроваджувати справжні Agentic Coding системи (автономні агенти на кшталт Devin чи Antigravity, які самі читають величезний репозиторій, планують архітектуру і самостійно пишуть код), вони зіткнулися з жорсткою реальністю — вартістю контексту.
Сучасний комерційний проект — це не один файл `main.js`. Це сотні файлів, десятки тисяч рядків коду, документація, специфікації, залежності. Щоб ШІ міг адекватно працювати і розуміти зв'язки, йому потрібно "завантажити" весь цей контекст у свою оперативну пам'ять (контекстне вікно). Наприклад, щоб виправити один неочевидний баг, автономний агент може кілька разів прочитати по 100 000 токенів коду, спробувати рішення, отримати помилку від тест-ранера чи компілятора, і знову "пережувати" весь контекст, щоб придумати новий фікс.
Давайте порахуємо економіку
Потужні моделі (як GPT-4o, Claude 3.5 Sonnet або Gemini 1.5 Pro) коштують реальних грошей за API. Один запит з великим контекстом може коштувати 10-30 центів. Агент робить десятки або навіть сотні таких запитів на годину. Коли ви даєте ШІ автономну задачу на вихідні ("напиши і протестуй новий модуль інтеграції з платіжною системою"), ви можете вранці в понеділок отримати рахунок за API на $300-$500. І найгірше — він міг десь посередині застрягти в нескінченному циклі помилок і просто спалити ці гроші впусту, не давши готового результату!
Для стартапів та аутсорс-компаній це стало справжнім холодним душем. Виявилося, що найняти джуна або міда, який буде тиждень спокійно колупати цей модуль, часто дешевше (і прогнозованіше), ніж дати "повну свободу" дорогим LLM-моделям.
Звісно, ШІ нікуди не зникне і ніхто від нього не відмовиться. Він став неймовірним інструментом (сучасний Copilot, автокомпліти, швидка генерація бойлерплейту, написання regex-ів). Він реально підвищив продуктивність мідлів та сеньйорів на 30-50%.
Але утопія про те, що "ШІ працює безкоштовно", розбилася об суворі тарифи хмарних провайдерів. Ми просто змінили статтю витрат з "зарплатного фонду" на "рахунки за API". І чим розумніша і продуктивніша модель — тим дорожчі її "думки".
Чи стикалися ви у своїх компаніях або пет-проектах з неконтрольованим "вигоранням" бюджетів на ШІ? Що для вас зараз виявилося дешевше: платити за мільйони токенів чи платити класичну зарплату живому кодеру? Діліться своїм досвідом!
Привіт, SEO-спеціалісти та лінкбілдери!
Сьогодні пропоную обговорити біржі посилань та платформи для гостьового постингу, які активно працюють на українському ринку.
Всі ми знаємо **Collaborator.pro** — він став фактично золотим стандартом для закупівлі статей на українських (і не тільки) сайтах. Але цікаво почути ваш реальний досвід: чим ще ви користуєтеся для побудови якісного посилального профілю?
Ось невеликий список того, що я виділив для себе:
1. Collaborator.pro — беззаперечний лідер. Величезна база українських майданчиків, дуже зручний інтерфейс, видно трафік та SEO-метрики (Ahrefs/Serpstat/Moz) прямо в каталозі. Але комісія системи іноді здається зависокою, якщо купувати багато дорогих статей.
2. PRNEWS.IO — неймовірно крутий майданчик, якщо вам потрібні великі авторитетні ЗМІ (ТСН, УП, Корреспондент тощо) для PR-публікацій. Вони позиціонують себе більше як PR-платформа, ніж просто біржа посилань, але для SEO це працює ідеально.
3. WhitePress — польська платформа, яка дуже активно зайшла на український ринок. Мають хорошу базу унікальних сайтів, яких часто немає в Колабораторі. Зручно замовляти написання статей прямо у них всередині платформи.
4. Різні Телеграм-чати та локальні сітки — часто там можна купити посилання на невеликих регіональних порталах значно дешевше, ніж на офіційних біржах.
Який ваш досвід? Де зараз найвигідніше купувати якісні (не спамні) посилання? Чи, можливо, ви взагалі відмовилися від бірж і працюєте виключно через прямий аутріч (Outreach)?
Привіт, фронтендери! Сьогодні хочу детально розібрати тему, яка багатьом здається справжньою магією — створення та анімація 3D-персонажа на веб-сайті за допомогою WebGL.
Якщо ви хочете зробити інтерактивного маскота, який буде слідкувати за курсором або реагувати на кліки, вам не потрібно писати сирий WebGL-код на шейдерах (це боляче). Ми будемо використовувати **Three.js** — найпопулярнішу та найпотужнішу бібліотеку для 3D у браузері.
Ось покроковий гайд, як це працює під капотом:
Етап 1: Підготовка моделі (Не в браузері)
Перш ніж писати код, потрібен сам персонаж з "кістками" (скелетом, Rigging) та готовими анімаціями (наприклад, дихання, ходьба, вітання рукою). Це робиться в програмах типу Blender або Maya. Для вебу найкраще експортувати модель у форматі .gltf або .glb. Це формат, який оптимізований спеціально для швидкого завантаження по мережі.
Етап 2: Базове налаштування Three.js
Вам потрібно підключити Three.js та ініціалізувати три основні сутності:
1. `Scene` — простір, де все знаходиться.
2. `Camera` — ваші очі (зазвичай `PerspectiveCamera`).
3. `Renderer` — рушій, який малює сцену на `<canvas>`.
Обов'язково додайте світло (наприклад, `AmbientLight` та `DirectionalLight`), інакше ваш персонаж буде просто суцільною чорною плямою.
Етап 3: Завантаження моделі
Для завантаження формату glTF використовується `GLTFLoader`.
import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js';
const loader = new GLTFLoader();
loader.load('model.glb', function(gltf) {
scene.add(gltf.scene);
// Тут ми маємо доступ до моделі та її анімацій
});Етап 4: Анімація (Idle Animation)
Щоб персонаж дихав чи моргав, ми використовуємо `AnimationMixer` з Three.js. При завантаженні моделі (`gltf.animations`) ви отримуєте масив створених у Blender анімацій.
let mixer = new THREE.AnimationMixer(gltf.scene);
const action = mixer.clipAction(gltf.animations[0]); // беремо першу анімацію (наприклад, дихання)
action.play();Етап 5: Реакція на курсор (Слідкування очима чи головою)
Ось тут починається магія інтерактиву. Щоб голова персонажа поверталася за мишкою, нам потрібно:
1. Знайти кістку (Bone) голови або шиї у завантаженій моделі. Це можна зробити через `model.getObjectByName('NeckBone')` (ім'я беремо з Блендера).
2. Відслідковувати координати миші через подію `mousemove` на вікні. Нормалізуємо їх від -1 до 1.
3. У циклі рендерингу змінювати обертання (rotation) цієї кістки відповідно до положення миші.
window.addEventListener('mousemove', (e) => {
mouse.x = (e.clientX / window.innerWidth) * 2 - 1;
mouse.y = -(e.clientY / window.innerHeight) * 2 + 1;
});
// У циклі рендерингу плавно змінюємо ротацію:
neckBone.rotation.y = mouse.x * 0.5; // коефіцієнт, щоб голова не крутилась як у сови на 360
neckBone.rotation.x = mouse.y * 0.5;Етап 6: Кліки по персонажу (Raycaster)
Оскільки WebGL малює всю 3D-сцену на одному плоскому HTML `<canvas>`-елементі, ви не можете просто повісити `onclick` на руку чи живіт персонажа. Для цього використовується математичний інструмент **Raycaster**.
Він випускає невидимий "промінь" від вашої камери через курсор миші в глибину сцени. Якщо промінь перетинає геометрію персонажа — ми реєструємо клік.
Зареєструвавши клік (наприклад, користувач натиснув на маскота), ми можемо перемкнути анімацію в міксері — зупинити дихання і змусити персонажа помахати рукою (запустити інший `clipAction`).
Створення такого 3D-помічника може суттєво підвищити залученість користувачів (Engagement Rate) та зробити сайт запам'ятовуваним.
Хто вже експериментував з Three.js? Які були складнощі з експортом моделей чи оптимізацією?
Привіт, автомобілісти та колеги-вебмайстри!
Знайшов дуже корисний ресурс для всіх, хто має власне авто або професійно пов'язаний з автобізнесом в Україні — BlogRost (https://blogrost.pp.ua/).
Це великий, зручний та структурований каталог автомобільних сайтів України. Фактично, це спеціалізований агрегатор, де в одному місці зібрані найважливіші тематичні ресурси:
- СТО та автосервіси: можна знайти профільні станції технічного обслуговування, шиномонтажі та детейлінг-студії.
- Автозапчастини: каталоги інтернет-магазинів, авторозбірок та прямих постачальників деталей для будь-яких марок.
- Автосалони: офіційні дилери нових автомобілів та великі майданчики з продажу вживаних авто.
- Аукціони та пригон: сайти компаній, які професійно займаються пригоном автомобілів "під ключ" з аукціонів США, Європи та Кореї.
Дуже зручно, коли шукаєш специфічну запчастину або хочеш порівняти умови різних компаній з пригону, не перебираючи тонни реклами в Google. Ресурс виглядає свіжим і активно наповнюється.
До речі, якщо у вас є свій сайт автотематики — мабуть, варто туди додати свій ресурс для додаткового SEO та залучення цільового трафіку. Хтось уже користувався цим каталогом?
Привіт усім любителям активного відпочинку, риболовлі та просто водного транспорту!
Хочу поділитися з вами чудовим ресурсом — BoatPedia (https://boats.pp.ua/). Це унікальна україномовна онлайн-енциклопедія, яка повністю присвячена світу човнів, катерів, яхт та супутнього обладнання.
Що цікавого можна знайти на сайті:
- Моторні човни та катери: Детальні огляди різних моделей, їхні технічні характеристики, переваги та недоліки матеріалів корпусів (алюміній vs пластик).
- Яхти (вітрильні та моторні): Інформація для тих, хто мріє про море або цікавиться яхтингом як спортом.
- Надувні човни (ПВХ): Незамінний розділ для рибалок та мисливців. Як правильно вибрати, як доглядати, які бренди на ринку кращі.
- Човнові мотори: Огляди підвісних моторів (двотактні, чотиритактні, сучасні електромотори), поради з базового обслуговування та підбору гвинтів.
- Корисні статті: Правила безпеки на воді, поради з навігації, нюанси реєстрації плавзасобів в Україні.
Сайт постійно наповнюється новою інформацією, і це неймовірно круто, що нарешті з'явився такий спеціалізований ресурс саме українською мовою. Раніше доводилося шукати інфу по крупинках. Якщо ви власник катера або просто мрієте про власну яхту — дуже раджу додати в закладки!
Привіт, дівчата! (і хлопці, якщо читаєте). Останнім часом часто бачу дискусії серед дизайнерів щодо того, як має виглядати суто "український дизайн" у вебі.
З одного боку, після 2022 року у нас з'явився потужний тренд на айдентику: тризуби, калина, вишиванки, дуже багато жовтого та синього кольорів. І це було круто на хвилі патріотизму. Але з іншого боку, чи не здається вам, що ми іноді скочуємося в банальну "шароварщину"? Багато сайтів просто ліплять жовто-блакитні градієнти куди завгодно: від продажу бетону до стоматологій.
На мою думку, український дизайн — це передусім про бездоганний UX, мінімалізм, сміливі шрифтові рішення (як наші круті українські шрифти від Рудника чи Трегуба) та функціональність на рівні Дії чи Монобанку. Нам потрібна естетика, яка буде конкурентною на світовому ринку, а не просто експлуатуватиме фольклор у лоб.
Що ви думаєте про це? Яким має бути наш візуальний почерк?
Привіт, дівчата! (і хлопці, якщо читаєте). Останнім часом часто бачу дискусії серед дизайнерів щодо того, як має виглядати суто "український дизайн" у вебі.
З одного боку, після 2022 року у нас з'явився потужний тренд на айдентику: тризуби, калина, вишиванки, дуже багато жовтого та синього кольорів. І це було круто на хвилі патріотизму. Але з іншого боку, чи не здається вам, що ми іноді скочуємося в банальну "шароварщину"? Багато сайтів просто ліплять жовто-блакитні градієнти куди завгодно: від продажу бетону до стоматологій.
На мою думку, український дизайн — це передусім про бездоганний UX, мінімалізм, сміливі шрифтові рішення (як наші круті українські шрифти від Рудника чи Трегуба) та функціональність на рівні Дії чи Монобанку. Нам потрібна естетика, яка буде конкурентною на світовому ринку, а не просто експлуатуватиме фольклор у лоб.
Що ви думаєте про це? Яким має бути наш візуальний почерк?
Привіт всім! Сьогодні хочу підняти дуже холіварну, але неймовірно важливу тему архітектури баз даних — використання зовнішніх ключів (Foreign Keys, або просто "зв'язки таблиць").
В університетах та на курсах нас вчать, що реляційна база даних завжди повинна бути в третій нормальній формі (3NF), а всі пов'язані таблиці мають бути жорстко з'єднані між собою через `FOREIGN KEY`. Це робиться для того, щоб гарантувати так звану цілісність даних (Referential Integrity). Але на практиці, особливо в великих HighLoad-проектах або мікросервісних архітектурах, архітектори часто свідомо відмовляються від використання фізичних зовнішніх ключів на рівні бази даних.
Чому так відбувається? Давайте розбиратися більш детально, коли зв'язки — це беззаперечна користь, а коли — абсолютне зло і антипатерн.
Коли зв'язки таблиць — це беззаперечна користь (і навіть мастхев)
1. Гарантія цілісності даних (Data Integrity). Головне завдання зовнішнього ключа — не дати вам вставити в базу "сироту". Наприклад, ви не зможете створити замовлення (Order) для клієнта (User), якого не існує в таблиці користувачів. Аналогічно, ви не зможете випадково видалити категорію товарів, якщо в ній ще залишилися товари (залежно від налаштувань ON DELETE RESTRICT / CASCADE). Це гарантує, що ваша база ніколи не перетвориться на смітник з битими посиланнями, які потім викликають Fatal Errors у додатку.
2. Автоматичне каскадне видалення (ON DELETE CASCADE). Дуже зручна фішка для невеликих і середніх проектів. Видаляєте користувача — і база даних сама, на рівні ядра, видаляє всі його пости, коментарі, лайки та активні сесії. Вам не треба писати складну логіку в бекенді, обходити цикли та переживати, що десь забули почистити пов'язані дані. Це швидко і надійно.
3. Документація схеми та ORM. Коли новий розробник (або навіть ви самі через півроку) дивиться на базу з зовнішніми ключами через ER-діаграму, він відразу розуміє архітектуру проекту. Крім того, сучасні ORM-фреймворки (як Doctrine в PHP, Eloquent в Laravel чи Hibernate в Java) можуть автоматично генерувати моделі та їх зв'язки на основі цих ключів в БД. Це значно прискорює розробку.
4. Запобігання помилкам розробників на рівні ядра. Якщо у вас є баг в коді, який намагається записати неіснуючий `product_id` в таблицю кошика, база даних просто відхилить такий запит з помилкою `Constraint Violation`. Без FK цей "фантомний" запис потрапив би в базу, і потім ви б довго шукали причину, чому в кошику лежить товар без назви і ціни.
Коли зв'язки таблиць перетворюються на ЗЛО (і чому від них відмовляються)
Але якщо все так круто, то чому такі технологічні гіганти як GitHub, Shopify, або просто великі проекти на мікросервісах взагалі відмовилися від використання Foreign Keys?
1. Продуктивність та блокування (Performance & Locking). Це головна причина. Кожного разу, коли ви вставляєте або оновлюєте запис із зовнішнім ключем, база даних повинна зробити невидимий `SELECT` в пов'язану таблицю, щоб перевірити, чи дійсно існує там такий ID. При масових вставках (Bulk Insert) або дуже високому навантаженні (HighLoad) це створює величезний оверхед на I/O диска. Більше того, FK можуть викликати каскадні блокування рядків (Row Locks), що часто призводить до мертвих блокувань (Deadlocks) при паралельних транзакціях з різних потоків.
2. Складнощі з шардінгом (Sharding) та масштабуванням. Коли ваша база переростає один сервер, ви починаєте ділити її на частини (шарди). Наприклад, користувачі з США лежать на одному сервері (Шард А), а з Європи — на іншому (Шард Б). А що робити із замовленнями? Зовнішні ключі працюють тільки в межах однієї бази даних на одному сервері. Неможливо створити фізичний FK між таблицями, які лежать на різних фізичних машинах. Тому в мікросервісах або шардованих базах цілісність даних підтримується виключно на рівні додатку (код), а не на рівні БД.
3. Міграції та зміни схеми бази (Schema Migrations). У великій базі (сотні гігабайт або терабайти даних) змінити тип колонки, яка бере участь у FK, або додати/видалити новий зв'язок — це справжній біль. Процес `ALTER TABLE` з перевіркою констрейнтів може заблокувати таблицю на години, зупинивши роботу всього проекту. Набагато простіше просто зберігати ID як звичайний `INT` або `UUID` і підтримувати логіку перевірок в коді бекенду.
4. Проблема 'каскадного пекла'. Правило `ON DELETE CASCADE` звучить круто, поки хтось випадково (через баг в адмінці або необачний запит) не видалить базовий запис (наприклад, 'Компанію'). Тоді база мовчки, за лічені секунди, знесе сотні тисяч записів з 20 інших таблиць (співробітників, їхні фінансові транзакції, історію листування тощо). У серйозних системах використовують виключно 'м'яке видалення' (Soft Delete), просто ставлячи прапорець `is_deleted = 1` або `deleted_at = NOW()`. У цьому випадку запис фізично лишається в базі, тому FK іноді просто заважають.
Висновок
Для 90% типових проектів (CMS, блоги, корпоративні сайти, інтернет-магазини середнього розміру, CRM системи для малого бізнесу) зовнішні ключі — це ваші найкращі друзі. Вони захистять вас від купи помилок та сміття в базі. Економіка проекту виграє від надійності більше, ніж від гіпотетичної економії мілісекунд.
Але якщо ви будуєте HighLoad архітектуру, розбиваєте величезний проект на мікросервіси, плануєте шардінг бази, або стикаєтесь з проблемами продуктивності при записі десятків тисяч рядків на секунду — вам, скоріш за все, доведеться відмовитись від фізичних зв'язків у БД і повністю перенести відповідальність за цілісність даних на ваш бекенд.
Який ваш особистий досвід? Ви завжди ставите FK на автоматі, чи свідомо ігноруєте їх? Чи були у вашій практиці випадки, коли зв'язки вас реально рятували від катастрофи, або навпаки — повністю клали базу під навантаженням? Діліться історіями!
Привіт, спільното! Нещодавно відбувся реліз **Antigravity 2** від команди Google DeepMind, і я вирішив розібрати, що нового з'явилося в цьому надпотужному ШІ-асистенті для програмістів. Якщо ви пам'ятаєте першу версію, вона вже була крутою, але друга — це справжній прорив у сфері Agentic Coding.
1. Автономні субагенти (Subagents)
Найбільша фішка другої версії — це можливість Antigravity 2 самостійно створювати та керувати субагентами. Уявіть, що ви ставите задачу: "Розробити новий модуль для CMS". Antigravity 2 не просто пише код лінійно, він створює субагента-дослідника (researcher), який вивчає кодову базу, поки головний агент проектує архітектуру. Це дозволяє паралельно вирішувати складні задачі.
2. Планування (Planning Mode)
Тепер асистент став значно обережнішим із великими проектами. З'явився режим "Planning Mode", який змушує ШІ спершу провести глибокий аналіз (без написання коду), скласти детальний план імплементації (Implementation Plan), погодити його з розробником, і лише після Approval починати писати код. Це економить купу часу на переробках, коли ШІ "галюцинував" архітектуру на 10 файлів, яка не підходила до вашого проекту.
3. Нові інструменти взаємодії з файлами та терміналом
З'явилися круті інструменти, як multi_replace_file_content, що дозволяють вносити зміни у декілька незв'язаних блоків коду в одному файлі за один виклик. Це робить рефакторинг набагато швидшим. Крім того, ШІ тепер вміє запускати фонові задачі в терміналі і отримувати сповіщення, коли вони завершаться (замість того, щоб тупо чекати).
4. Інтеграція з браузером (Browser Subagent)
Antigravity 2 отримав можливість запускати браузерні сесії для пошуку інформації, перевірки роботи веб-додатків, читання документації, що недоступна просто через curl. Він сам клікає, скролить і аналізує сторінки, що неймовірно корисно при дебагінгу фронтенду чи парсингу.
5. Розширений контекст та пам'ять
Завдяки переходу на нове ядро (Gemini 3.1 Pro), контекстне вікно стало ще більшим, а головне — ШІ краще утримує увагу на деталях з початку розмови. Також з'явилися артефакти (Artifacts) — спеціальні markdown-документи (task.md, walkthrough.md), які ШІ веде як журнал проекту, фіксуючи, що зроблено, а що ще залишилося.
В цілому, Antigravity 2 — це вже не просто "розумний автокомпліт", а повноцінний мідл-розробник у вашій команді, якому можна делегувати не просто написання функції, а цілі фічі з архітектурним плануванням та тестуванням.
Хто вже встиг потестити? Які ваші враження від нових субагентів та швидкості роботи?