Давайте спочатку по псбішкам. От дивитесь ви на якусь плату, що там є?Купа якихось компонентів. Між ними доріжки. Воно живиться від постійного струму, наприклад батарейки. Тобто є + і -.Все починається зі схеми, це типу наш скетч системи. Діаграма архітектури, без конкретної реалізації. Після схеми будується лейаут, компоненти розставляються і між ними прокладається зʼєднання. Якщо говорити про просту плату, з двома шарами, то нижній шар (синій) це зазвичай земля, а верхній (червоний) це умовно +Фізично для зʼєднань використовується мідь, сама плата з текстоліту. В цьому прикладі є тонка доріжка і жирний полігон. В залежності від струму що протікає по цим доріжкам підбирається розмір/ширина, ну щоб не перегоріло наприклад. Ота маленька дірка зліва на платі пробиває до нижнього шару і поєднує резистор з шаром який йде до землі, верхній пін з права, куди втикається джерело живлення.Готовий проєкт експортується в пачку файлів що відправляється на виробництво для подальшого виготовлення плати та напаювання компонентів.Якщо зовсім по фронтендерськи, то компоненти це функції, а доріжки це те як ви збираєте функції до купи)
Якщо ви пішли дивитися на адженду ДоуДей, то там можна помітити, шо в мене нова робота. :) Так от, ми шукаємо 3д-дизайнера/інженера/моделера. В ідеалі крутого і з досвідом. Людину, яка б така: бісять ці дрони на карбонових рамах, не могли нормально зробити?! Людину, якій сопромат цікавіший, аніж блискучість поверхні (і недостатньо душну щоб вказати мені на недосконалість фрази 😁).В нас є прям кілька нагальних потреб, в основному під FDM-друк, але ми точимо зуби і на звичайний пластик з прес-формами, так що буде поле для професійного розвитку. Авжеж, в ідеалі ми шукаємо людину, яка це все вже дуже вміє і зможе підняти наш рівень розуміння проблеми прям сходу — ну але можемо порозмовляти, якщо ви займалися більше красою, але дуже зацікавлені в міцності/простоті друку/зручності використання.Всі варіанти ок: і якщо ви хочете виключно 3д займатися, і якщо у вас є інші зацікавленості/таланти. Ок поговорити про фултайм, або про почасовку/попроєктну, якщо ви дуже кльовий. 😁 Ідеально якщо ви в Києві, чи готові періодично бувати.Хочемо або портфоліо (з поясненнями чому це релевантно), або виконання тестового завдання.Мене навряд читають багато Здшників, але якщо у вас є такі знайомі, то киньте їм лінк на цей пост.
якщо вас теж задовбало шо Claude Code постійно недороблює роботу до кінця, то от вам скрипт для патчингу апки, який змінює зашиті промптина простих задачках різниці не побачите, але на чомусь більш складному змінена версія точно покаже себе краще, тест на скріншотіhttps://gist.github.com/roman01la/483d1db15043018096ac3babf5688881Patch: Output efficiency IMPORTANTBefore: "Try the simplest approach first. Do not overdo it. Be extra concise."After: "Choose the approach that correctly and completely solves the problem."Patch: Brevity ≠ thoroughnessBefore: "Lead with the answer, not the reasoning"After: Adds: "these guidelines apply to messages, NOT to thoroughness of code changes"Patch: One sentence ruleBefore: "If you can say it in one sentence, don't use three"After: "does not apply to the thoroughness of your implementation work"Patch: Anti-gold-platingBefore: "Don't add features beyond what was asked"After: "if adjacent code is broken or contributes to the problem, fix it"Patch: Error handlingBefore: "Don't add error handling for scenarios that can't happen"After: "Add error handling at real boundaries where failures can occur"Patch: Three lines ruleBefore: "Three similar lines better than premature abstraction"After: "Use judgment about when to extract shared logic"Patch: Subagent gold-plate (2x)Before: "don't gold-plate, but don't leave it half-done"After: "Do the work a careful senior developer would do, including edge cases"
Така історія, не можу не розповісти. 🤣 Є в мене маленька ip-камера китайська, фактично просто модуль, і в неї є проста веб-морда, і навіть RTSP якийсь — але мені того мало, я хочу нормальний шел туди і засетапити шось своє, бо лаг на тому відеопотоці просто жахливий.В продавчині на алі спитав, але вона каже “it’s not allowed” — і ми з нею домовилися поговорити завтра, напевно коли всі на роботі будуть. А поки переписувався, шось поколупався, задовбався і запустив Клавдія.Кажу — оце камера є, а доступитися не можу, з відкритого — телнет (чому телнет, а не ssh? кам’яний вік якийсь), але пароль явно не такий, як на вебморді. Дав йому пароль від веб-морди, але він спочатку якісь дефолтні паролі поперебирав в телнеті, а потім пішов колупати всілякі функції “покажи мені відео”, підставляючі туди шляхи типу ../../../../../etc/shadow, прям як описували в 99 році в журналі “Хакер”. 🤣Я посміявся, авжеж — ну 26 рік на дворі, навряд той софт вони з нуля писали, давно вже всі ці дірки позакривали, і пішов своїми справами займатися. Повертаюся до Клавдія хвилин через 10, а він знайшов метод audioPlayFile_base64 з аргументами {"file_base64": …, "file_path": …}, і виявляється, в ньому нема перевірок на file_path. То він згенерував новий /etc/passwd та /etc/shadow, записав, і отримав доступ по телнету. 👹Зізнаюся чесно, в мене ніколи не вистачало часу доколупати жодну з таких дірок, але з Клавдієм життя змінюється. 🤣Подивимося, що там not allowed, угу. 😁
Збирав на Мікротіку сетап для збільшення радіусу дії WiFi для машинки і стало цікаво потикати який-небудь симулятор розповсюдження радіосигналу. Безкоштовні примітивні, а комерційні дорогі.За пару вечорів і 30 баксів в токенах разом з Claude 4.6 зробили симулятор WebRF.Симулятор вийшов топовий. Можна обирати різні типи антен, задавати їх параметри, моделювати радіо перешкоди (верхні приклади на скріншоті) та прикидувати пропускну здатність каналу.Простенькі симулятори працюють по топографічним картам. Але у WebRF я додатково підтягую датасети про тип місцевості та забудову.На скріншоті видно як розповсюдження сигналу змінюється, коли враховуються будинки, ліси, озера, ріки і тд. На останньому прикладі видно наче вирізаний кут, але насправді там передавач стоїть біля Бессарабського ринку, який блокує сигнал в тому напрямку.Симуляція повністю виконується на клієнті, на GPU через compute шейдери у WebGPU.Більш за все мене вразило як ми за пару ітерацій зрізали час симуляції з пари секунд до 100мс. ШІшка проаналізувала специфіку задачі і переписала імплементацію по суті на рейтрейсинг. Від передавача діспатчиться декілька тисяч променів і їх розповсюдження калькулюється з урахуванням даних з текстур висот та типу місцевості, та забудови. Цей алгоритм класно паралелиться на GPU.Так шо я трохи посидів з Codex, але після цього проєкту перейшов на Claude 4.64.6 стабільно використовує скіли та суб агентів, кожну фічу пропрацьовує досить глибоко, але не забурюється в деталі як Codex.Моє розуміння RF propagation достатньо поверхневе. Тому шоб Claude не робив фігні яку я не можу перевірити, я давав йому задачу рісьорчити моделі пропагаціїї сигналу, переносити формули в код і писати тести. Але це все ще не означає, що він не робив фігні)Порівнявши результати симуляції з комерційним CloudRF я думаю шо WebRF має право на життя, діаграма сигналу сходиться.https://romanliutikov.com/projects/webrf/
Гарний приклад про який я говорив у минулому відео. Якщо ти робиш з ШІ щось в чому твоє розуміння десь нульове, то нічого не вийде. Хотів для машинки зробити стабілізацію відео, яка б працювала у браузері, на клієнті, в реальному часі, без затримки. Знайшов схожий проєкт на пайтоні, і засів з Codex портувати його на JS.Від Codex я канєшна в захваті. Ми з ним спланували портування з пайтону по TDD, щоб на кожному кроці бути максимально наближеним до оригінальної імплементації.Розробили фреймворк покадрового оцінювання та порівнювання якості стабілізації. Кодекс прям позадротськи підходить до вирішення задачі. Сам продебажив перфоманс, знайшов повільну частину в JS, переніс її в С++ і зробив невеликий WASM модуль. Але от результат вийшов дещо далеким від того що можна було б назвати стабілізацією. Звичайно стабілізація в реальному часі, лише по картинці — це нелегка задача, ще й так щоб воно працювало швидко і в браузері. З цікавого виявилось що порт кодексу в деяких місцях працює краще ніж оригінал. Але вцілому воно майже не відрізняється від нестабільної картинки. І отут я нічого не можу зробити, бо не розумію принципи роботи цих алгоритмів.Вийшло трохи покращити стабілізацію шляхом спеціалізації алгоритму під типові вібрації на машинках. Тобто стрибки вверх-вниз та кругова повздовжня вібрація, коли машинку кидає вліво вправо по кочкам.А так загалом, найкращий спосіб стабілізації — це інтеграція показників з гіроскопу. Тому буду пробувати цей шлях.Демо https://romanliutikov.com/projects/stabilizer/
Тестую систему стабілізації машинки. Відос з маневром поліцейський розворот і поясненням як реагують усі системи на кожному етапі маневру.Для дебагу на клієнті є девтули з візуалізацією всіх системи, в які ганяється купа телеметрії з машинки.Системи:Steering Shaper — обмежує швидкість і кут повороту на високій швидкості, щоб уникнути різкого заносуHill Hold — тримає трохи газу, щоб машина не котилася назад на схиліTraction Control — скидає оберти, коли колеса крутяться швидше, ніж машина насправді їдеYaw Rate — скидає оберти, коли машина починає крутитися або йти боком (бмвісти не зацінять)Slip Watchdog — виявляє занос і зменшує оберти, щоб повернути контрольABS — швидко пульсує гальмами, щоб колеса не блокувалися під час відтормажуванняCoast Control — плавно переходить у накат замість різкого гальмування двигуномSurface Adaptation — визначає, наскільки слизька поверхня, і налаштовує всі інші системи відповідноЦе звичайно оверкіл для машинки але прикольно дивитись як воно все працює)https://www.youtube.com/watch?v=lgILmvoZFMU
Непогані поради від розробника Claude:1. Працюйте паралельно. Запускайте 3-5 git worktrees одночасно, кожен зі своєю сесією Claude (головний лайфхак команди)2. Складні задачі завжди починайте з режиму планування. Якісний план дозволяє Claude часто реалізовувати все з першого разу 3. Постійно вдосконалюйте CLAUDE.md, після кожної правки просіть Claude оновити правила, щоб уникати повторних помилок4. Створюйте власні навички (skills) та команди (/slash commands) і додавайте їх в репизоторій проєкту5. Більшість багів Claude виправляє сам. Кидайте йому Slack-тред, логи docker чи failing CI з командою "fix"6. Покращуйте промпти: змушуйте Claude бути рев’ювером, просіть "елегантніше рішення", пишіть чіткі специфікації 7. Використовуйте subagents для складних задач та "use subagents" для більшої обчислювальної потужності 8. Аналітика без SQL — Claude вміло працює з BigQuery через CLI прямо в терміналі 9. Навчання з Claude: вмикайте пояснювальний стиль, просіть ASCII-діаграми, HTML-презентаціїЯ ще толком не працював з субагентами. Планування, рев'ю зробленої роботи, оновлення документації та skills вже використовую. Найбільший вихлоп поки що від планування та рев'ю.https://x.com/bcherny/status/2017742741636321619
Цікавий кейс, як ШІ знищує деякі типи бізнесу.Розробник Tailwind написав, що вони звільнили більшу частину команди, бо їх дохід впав на 80% з появою LLM. З його слів якщо так піде й далі то грошей їм вистачить десь на пів року https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957З одного боку сумно, з іншого якщо розібратись, то по суті їх дохід генерувався трафіком який заходив на сайт документації Tailwind на якому було посилання на їх платний продукт, що по своїй суті — преміальні темплейти з набором компонентів. Ну і через те шо люди більше використовують ШІ для документації та коду, то у них сильно просів трафік і їх преміальні штуки бачить і купує менше людей.Тобто по суті, ШІ забрав у них трафік. Це такий дзвіночок усім хто продає шось через наганяння трафіку. ШІ зрізає кути і дає вам потрібну інфу напряму.Добре шо воно працювало і команда отримувала гроші, але чесно кажучи продавати темплейти чи бібліотеки компонентів ну такий собі спосіб заробітку. Особливо коли треба тримати на плаву команду інженерів яка працює над супер популярним опен сорсним проєктом. Звучить так шо їм би треба було придумати як монетизувати сам Tailwind.
Продовжую тестування Claude Opus в копайлоті, на прикладі створення редактору 3D графіки, типу Blender.За приблизно $60 в токенах за останній тиждень ми зробили наступне:- OBJ та GLTF імпорт- Повноцінний процедурний редактор матеріалів- Перенесли рендерер в C++ з SIMD, скомпілили у Wasm і тепер рендеринг відбувається у воркері через OffscreenCanvas (не знав що можна шерити пам'ять між Wasm та канвасом, це дає можливість не робити повільне копіювання відрендерених кадрів з Wasm процесу у Canvas)- Туди ж запхали систему бейкінгу матеріалів у текстури- Додали всілякі UX покращення в редакторі типу vertex snapping та axis lock- Зробили історію undo/redo що має окремі стеки історії в різних частинах редактору- Пофіксили купу багів- Зробили headless версію рендрера для тестування редактору скріншотами, просто запускаючи wasm модуль в ноді- Поверх хедлес модуля зробили MCP сервер за допомогою якого Claude у процесі розробки може сам створювати і рендерити сцени для перевірки своєї роботи- Все без сторонніх бібліотекУ процесі розробки Claude доповнює файл .github/copilot-instructions.md який сам і використовує як гайд по роботі з проєктом.Це дуже допомагає, щоб він знав як працюють конкретні під-системи у проєкті, які проблеми часто вилазять і на які штуки треба звертати увагу.Спробувати можна тут https://romanliutikov.com/projects/ps1ender/За весь час я написав може 5 строк коду, а Claude десь під 30 тис
TGLIST.COM.UA
