С помошью Claude Code (модель Haiku) на свет появилась питоновская программа, которая конвертирует текстовое описание схемы/платы для Circuits.CC в PNG картинку:
Screenshot from 2026-01-18 20-17-44.png
Как можно видеть это мне стоило $1.62 и заняло почти 7 минут работы API и полтора часа моего времени
Почасовая оплата "программиста" Claude Haiku в это случае получается почти 14 долларов в час...
P.S. Интересно, что Claude проверил программку по уже существующим примерам, причём примеры были сняты как скриншоты в браузере и были не выровнены по краям, но он сумел их сравнить с тем, что получается на выходе этой новой программки. Подробнее про саму программку: viewtopic.php?p=182260#p182260
You do not have the required permissions to view the files attached to this post.
Установил MCP-сервер Puppeteer, который должен помогать агентам Claude Code отлаживаться в браузере - с помощью него может кликать по элементам управления внутри странички и снимать скриншоты для анализа - вот что он мне говорит про то, что он может с ним делать:
● I have access to the MCP Puppeteer tool, which gives me browser automation capabilities. Here's what I can do with it:
Navigation & Viewing:
- puppeteer_navigate: Navigate to any URL
- puppeteer_screenshot: Take screenshots of pages or specific elements
Interaction:
- puppeteer_click: Click buttons, links, or elements
- puppeteer_fill: Fill in text input fields
- puppeteer_select: Select options from dropdown menus
- puppeteer_hover: Hover over elements
Advanced:
- puppeteer_evaluate: Execute JavaScript in the browser console
For GitLab, I could use Puppeteer to:
- Navigate to your GitLab repository (gitlab.com or self-hosted)
- View issues, merge requests, branches, etc.
- Create merge requests automatically
- Click buttons to merge PRs, approve reviews, etc.
- Fill in forms for creating issues or PRs
- Take screenshots to verify status
- Execute JS to interact with GitLab's web interface
Use cases for your project:
- Create and merge MRs directly from the web interface
- View repository status, branches, or pipeline results
- Automate repetitive GitLab web tasks
- Verify changes were applied correctly (by taking screenshots)
Would you like me to use Puppeteer to help with something specific on your GitLab repository?
Было бы смешно, если не было б так грустно. ИИ привлекают для написания требований по информационной безопасности. Это, блин, простыни, простыни пустопорожнего текста!
● Implementation Complete ✓
I've successfully implemented the Node.js backend for Circuits.CC. Here's what was created:
Files Created
1. nodejs/pcbdb-server.js - Main Express server with:
- Automatic database and table initialization on startup
- Two main API modes:
- GET /api/pcb?id=0 - Returns current board state (all latest cell values)
- GET /api/pcb?id=N&col=C&row=R&sym=S - Inserts action and returns updates since id=N
- Health check endpoint: GET /api/health
- Manual setup endpoint: GET /api/setup
- Proper error handling and graceful shutdown
2. nodejs/package.json - Dependencies configured:
- express (HTTP framework)
- mysql2 (with promises for async/await)
- dotenv (configuration management)
- nodemon (development auto-reload)
3. nodejs/.env.example - Configuration template for easy setup
4. nodejs/.env - Pre-configured with your MySQL root credentials
5. nodejs/README-pcbdb.md - Comprehensive documentation including:
- Installation steps
- API endpoint reference
- Testing examples
- Frontend integration options
- Troubleshooting guide
API Testing Results
All endpoints tested and working:
Test 1: Empty board (id=0)
→ Returns: (empty)
Test 2: Insert component (id=1, col=5, row=10, sym=65)
→ Returns: 5,10,65,2 (the new record)
Test 3: Insert component (id=1, col=6, row=11, sym=66)
→ Returns: 5,10,65,2 \n 6,11,66,3 (all records since id=1)
Test 4: Get current board state (id=0)
→ Returns: 5,10,65,2 \n 6,11,66,3 (all current cells)
Test 5: Poll for updates since id=2
→ Returns: 6,11,66,3 \n 7,12,67,4 (updates since id=2)
Key Features
- ✅ Automatic initialization - Creates database and tables on first run
- ✅ Security - Uses parameterized queries (prevents SQL injection)
- ✅ Connection pooling - 10 concurrent connections for efficiency
- ✅ IP tracking - Records client IP for each action
- ✅ Exact API compatibility - Matches PHP output format (CSV)
- ✅ Production-ready - Proper error handling and graceful shutdown
To Use
cd nodejs
npm start
The server will run on http://localhost:3000 with the API at /api/pcb
Next Steps
To integrate with the frontend, update www/sandbox.html line 48:
var db = 'http://localhost:3000/api/pcb?';
Or use a reverse proxy to maintain the existing URL structure.
✻ Cooked for 1m 40s
Интересно все же, как ИИ справляется с не совсем стандартными задачами? Я как-то до сих пор не подружился с темой ИИ-ассистед программирования, максимум - консультируюсь с гугловским ИИ по поводу алгоритмов.
Я тут на днях возился с задачей компрессии/декомпресии звуоквых семплов, причем компрессия на обычном компе (конкретно мне удобнее на питоне), а декомпрессия - на Z80. Семплы 8-битные.
Сначала советовался с гугловским ИИ, он мне подтвердил мою точку зрения - хаффмановское кодирование дельт. Но в то же время мне надо учитывать ограничения по быстродействию Z80, так что "в лоб" реализовывать не годится. Плюс тажке и противоречащие требования по размеру кода декодировщика.
Было принято компромиссное как по памяти, так и по быстродействию решение - декодировщик делать жестко закодированный, то есть все дерево кодов напрямую реализовано в куче условных переходов, приводящих в конечном итоге к записи в буфер результата той или иной константы.
Но в то же время, чтоб сократить размер такого декодировщика (чтоб не потерять выгоду от сжатия данных), кодами хаффмана кодируются не все имеющиеся дельты, а только топ самых вероятных. Для остальных маловероятных - один общий код-префикс, который говорит, что дальше надо прочитать из потока целый байт, который и использовать как конкретную маловероятную дельту.
И если побитовое чтение потока для разбора дерева получается достаточно эффективным, то вот читать целый невыровненный байт из битового потока на Z80 достаточно большой геморрой, т.к. все инструкции сдвигов только на один разряд, и аккумулятор 8-битный.
Тут в голову пришел интересный хак - а пусть эти самые полные байты маловероятных дельт хранятся в битовом потоке выровненно. То есть, когда возникает необходимость прочитать из битового потока такой байт, он читается не с того бита, что следует сразу после только что прочитанного кода, а из следующего байта в буфере битового потока. А после того, как он прочитан - следующие коды продожают читаться из тех битов, что еще остались в битовом аккумуляторе. То есть, получается, что биты в битовом потоке должны храниться не совсем последовательно.
Получилось эффективно - я фактически ничем не пожертвовал, т.к. логика чтения очередного байта в битовый аккумулятор при его опустошении совершенно никак не изменилась, и при этом я очень легковесно читаю цельнобайтовую дельту без какого-либо геморроя со сдвигами и комбинированиями частей невыровненных байтов. Единственной "ценой" этого стало лишь не совсем последовательный порядок битов в битовом потоке.
Ну и еще один хак был применен - для чтения байтов битового потока (для пополнения битового аккумулятора при опустошении или чтения выровненных байт) используется регистр SP и команда POP AF. Опять же, есть загвоздка, что SP сдвигается на два байта при выполнении команды POP, хотя в аккумулятор попадают данные только из одного байта. Но вместо того, чтоб корректировать SP, декодирование осуществляется просто в два приема - для декодирования первой половины звуковых данных битовый поток читается из нечетных байтов, а вторая половина вторым приемом декодируется из четных байтов, для чего просто вначале SP инициализируется либо четным, либо нечетным адресом.
Смог бы я все вышенаписанное объяснить ИИ? Смог бы он написать код НА ПИТОНЕ (не на асме Z80), который в свою очередь генерирует код хаффман-декодера для Z80 (ведь конкретный декодировщик надо сгененрировать в соответствии с полученным на конкретных данных деревом кодов Хаффмана). Скорее всего стандартное кодирование/декодирование хаффмана он бы без труда осилил, но вот кодогенерацию питон->Z80 да еще и с хаками непоследовательного хранения битового потока и чтения этого потока из перемежающихся байтов?
Только никак не пойму, насколько он эффективен будет для аудиоданных. Это из семейства LZ, который ориентируется на точно повторяющиеся последовательности, чего в аудиоданных очень мало, даже если взять дельты.
Зато у дельт аудиоданных сильно выражен перекос вероятностей, что выгодно для прямого этнропийного кодирования таких дельт.