














































































































Add me to your committee
This is my resume:
This is my hobby
This is how I would respond in a job interview:
https://github.com/LikeDotAudio/Crawler.Like.Audio
The era of heavy desktop applications and bloated backend servers for local development tasks is being challenged. Enter Crawler.Like.Audio, a powerful, 100% client-side developer utility suite that pushes the limits of modern browser APIs. Built entirely with Next.js, TypeScript, and WebAssembly, this static application runs securely within the browser’s execution thread—requiring zero local installations and absolutely no backend dependencies.
Divided into nine hyper-capable modules, the suite transforms the web browser into a comprehensive toolkit for codebase analysis, security auditing, and hardware scanning. Here is a look at how every page works under the hood.
At the heart of Crawler.Like.Audio are tools designed to seamlessly interact with, analyze, and rebuild your local file system directly from the browser.
File Crawler: The core engine relies on the modern File System Access API to read local directories. When you select a folder, it performs a lightning-fast pre-scan, recursively streaming files to categorize them by type (Programming, Web & Markup, Data & Config, Docs) and calculate byte sizes. A real-time pie chart allows for selective crawling. Once configured, the deep crawl extracts file text and runs AST (Abstract Syntax Tree) parsing on supported languages via WebAssembly, ultimately compiling a massive EVERYTHING.LOG scrape file and a MAP.txt directory tree.


Program Map: For a high-level overview devoid of visual noise, this module displays a pure, text-based directory tree of your project. Functioning similarly to the Linux tree command, it offers a clean, structural skeleton of your deep crawl.
Visual Explorer: Taking the raw data from the File Crawler, this module uses React Flow to generate a highly interactive, drag-and-drop node graph. It visualizes your codebase architecture, mapping exactly how folders connect to files, and how those files branch into specific classes and functions.
Project Regenerator: Acting as the inverse of the File Crawler, the Regenerator takes an EVERYTHING.LOG file (whether generated by an AI or the crawler itself) and unpacks it. By selecting an empty destination folder, the utility uses the File System Access API to physically rebuild the folders and write the files back to your local disk.
Traditionally, network sweeps and hardware audits required native OS permissions. Crawler.Like.Audio leverages cutting-edge web standards to bring these capabilities into the sandbox.
Project Audit: A purely client-side security tool. Its secrets scanner uses advanced regex heuristics to hunt down exposed API keys, passwords, cryptographic tokens, and rogue .env variables. Additionally, the endpoint extractor maps out your app’s external dependencies by ripping through code to find hardcoded URLs, IP addresses, and API endpoints.
Hardware Auditor: This module hooks deeply into native hardware APIs to act as a physical peripheral scanner. It utilizes the WebUSB API to discover authorized USB devices, Web Bluetooth (BLE) for radar sweeps of nearby beacons and smart TVs, the Web Serial API for RS-232 devices and Arduinos, and WebRTC to silently index every connected camera and audio output.
Network Sweeper: A clever browser-based LAN scanner. Because browsers cannot open raw TCP/UDP sockets, this tool maps your local network (e.g., 192.168.1.x) using cross-origin HTTP fetches. By measuring precise timeout and connection-refused response times—a localized timing attack—it heuristically discovers routers, IoT devices, or local web servers.
The suite is rounded out by lightweight, privacy-first data extraction tools.
Web Scraper: Enter any public URL, and the scraper fetches the raw HTML. It then utilizes client-side parsing via Turndown to strip away web noise, instantly converting the page into clean, readable Markdown.
PDF to MD: A drag-and-drop local document extractor. Powered by a WebAssembly port of pdfjs-dist, it locally extracts text strings from PDFs and formats them into Markdown. Because everything happens in Wasm, sensitive documents are never uploaded to a cloud server.
Data Converters (CSV / JSON / Spreadsheet)
A powerful suite of data ingestion and shuffling utilities built with `papaparse` and `xlsx` (SheetJS).
* **CSV & JSON Importer/Shuffler:** Flatten or nest massive JSON objects, randomize CSV columns, and instantly export data.
* **Spreadsheet Converter:** Read natively complex spreadsheet binaries (`.xlsx`, `.csv`, `.ods`, `.numbers`) and convert them into clean formats, directly in the client.
### 12. 🎵 Audio Converter
A robust browser-side media encoder leveraging native Web Audio APIs and CDN-imported `lamejs`.
* **Universal Decode:** Drops any modern audio file (`.wav`, `.flac`, `.m4a`) to instantly decode its buffer.
* **Client-side Encoding:** Re-encodes the raw audio into an optimized `.mp3` file, relying strictly on your CPU’s client-side processing without uploading the audio file anywhere.
A mouse cursor is a dimensionless point that approaches every target from nowhere and hides nothing. A finger, thumb, or stylus, however, is a physical limb attached to an arm on one specific side of the body. That single fact makes touch interaction fundamentally asymmetric in ways a mouse UI never has to accommodate.
A touchscreen UI is chiral—it has a handedness baked into where controls sit and which way the hand reaches. For a significant portion of operators, the default layout of any given touch interface is the wrong-handed mirror. The correct design approach is not to make interfaces perfectly symmetric (which is biologically impossible due to reach and occlusion), but to make them mirrorable.
Here is a breakdown of the physical realities of touchscreen operation, and how to design interfaces that adapt to the hands that use them.
Touch interaction introduces physical constraints that fundamentally alter how a user interacts with a digital surface.
For one-handed thumb use, the screen is not a uniform grid of equally accessible targets. A right thumb sweeps a comfortable arc anchored at the bottom-right of the screen; the top-left is the “stretch” corner. For a left thumb, this entire map mirrors.
Ergonomic studies show that input accuracy varies heavily by region. For a right-handed thumb, the left and center parts of the screen are accurate, while the bottom-edge and far-diagonal regions are highly inaccurate.
Occlusion is arguably the most critical and overlooked factor in large-format touch design. When using a tablet or a wall console, the hand and forearm physically block the user’s line of sight.
Research into tablet-sized direct input reveals that the pen, hand, and forearm can occlude up to 47% of a 12-inch display. For a right-handed user, this occluded region sits below and to the right (South-East) of the contact point.
When a user drags an object left-to-right into an occluded direction, they frequently overshoot the target because the destination is hidden under their own arm. The universal fix for this is to emit feedback, menus, and drag ghosts to the non-occluded side—and that side must flip depending on the operator’s handedness.
It is a common design fallacy to assume that because ~90% of the population is right-handed, 90% of touchscreen sessions are operated with a right-hand grip.
In reality, roughly 30% of sessions are driven by a non-dominant or left-operating hand. This includes the 10% of users who are left-handed, plus the 30% of right-handed users who frequently operate devices with their non-dominant hand (because they are holding a coffee, a document, or resting on a rail).
Handedness at the glass is a momentary grip state, not a fixed biographical fact. Furthermore, handedness is detectable. Studies show that swipe curvature and horizontal touch offsets can classify the operating hand with over 98% accuracy. The UI can detect the operating hand and suggest a layout flip, rather than forcing the user to dig through settings.
When building a handedness toggle for a touch console, you are defining a strict set of layout rules. You are not mirroring the entire application; you are mirroring the interaction mechanics.These elements flip across the vertical axis when the operator’s handedness changes:
Primary Controls: Move to the dominant-thumb or dominant-hand reachable corner.
Edge Drawers and Panels: Dock to the dominant-hand edge so the user isn’t reaching across their body (and occluding the screen) to access tools.
Context Menus: Open on the non-occluded side of the contact point (left-of-touch for right-handers, right-of-touch for left-handers).
Drag Ghosts and Callouts: Emit into the non-occluded quadrant. Show the area ahead of the cursor when dragging.
These elements must never flip, as doing so breaks spatial memory and real-world semantics:
Text and Labels: Always remain Left-to-Right (LTR). Re-align them, but never reverse the text itself.
Directional Glyphs: Media playback transport (play/fast-forward), timelines, clocks, and progress bars retain their real-world direction.
Spatial-Memory Anchors: The core data grid or list order must stay fixed. Flipping layout mid-task destroys muscle memory. The flip should be a deliberate, stateful mode change.
music is the best use of silance
| Millimeters (mm) | Fractional Inch (Nearest 1/1024″) | Decimal Inches | Fractional Inch (Nearest 1/32″) | Precision Lost (%) |
| 0 | 0 | 0.0000 | 0 | 0.00% |
| 1 | 5/128″ | 0.0394 | 1/32″ | 20.62% |
| 2 | 81/1024″ | 0.0787 | 3/32″ | 19.06% |
| 3 | 121/1024″ | 0.1181 | 1/8″ | 5.83% |
| 4 | 161/1024″ | 0.1575 | 5/32″ | 0.78% |
| 5 | 101/512″ | 0.1969 | 3/16″ | 4.75% |
| 6 | 121/512″ | 0.2362 | 1/4″ | 5.83% |
| 7 | 141/512″ | 0.2756 | 9/32″ | 2.05% |
| 8 | 323/1024″ | 0.3150 | 5/16″ | 0.78% |
| 9 | 363/1024″ | 0.3543 | 11/32″ | 2.99% |
| 10 | 403/1024″ | 0.3937 | 13/32″ | 3.19% |
| 11 | 443/1024″ | 0.4331 | 7/16″ | 1.02% |
| 12 | 121/256″ | 0.4724 | 15/32″ | 0.78% |
| 13 | 131/256″ | 0.5118 | 1/2″ | 2.31% |
| 14 | 141/256″ | 0.5512 | 9/16″ | 2.05% |
| 15 | 605/1024″ | 0.5906 | 19/32″ | 0.54% |
| 16 | 645/1024″ | 0.6299 | 5/8″ | 0.78% |
| 17 | 685/1024″ | 0.6693 | 21/32″ | 1.95% |
| 18 | 363/512″ | 0.7087 | 23/32″ | 1.42% |
| 19 | 383/512″ | 0.7480 | 3/4″ | 0.26% |
| 20 | 403/512″ | 0.7874 | 25/32″ | 0.78% |
| 21 | 847/1024″ | 0.8268 | 13/16″ | 1.73% |
| 22 | 887/1024″ | 0.8661 | 7/8″ | 1.02% |
| 23 | 927/1024″ | 0.9055 | 29/32″ | 0.08% |
| 24 | 121/128″ | 0.9449 | 15/16″ | 0.78% |
| 25 | 63/64″ | 0.9843 | 31/32″ | 1.58% |
| 26 | 1 3/128″ | 1.0236 | 1 1/32″ | 0.75% |
| 27 | 1 65/1024″ | 1.0630 | 1 1/16″ | 0.05% |
| 28 | 1 105/1024″ | 1.1024 | 1 3/32″ | 0.78% |
| 29 | 1 145/1024″ | 1.1417 | 1 5/32″ | 1.27% |
| 30 | 1 185/1024″ | 1.1811 | 1 3/16″ | 0.54% |
Ultimate master cheat sheet for the entire CN Tower project, consolidating all the measurements, blueprints, and internal floor spacings we’ve discussed into one complete list.
Every single measurement here is calculated specifically for HO Scale (1:87) and converted directly to millimeters (mm).
These are your primary external dimensions for the major structural milestones.
Total Final Constructed Height: 6,360 mm
Top of Concrete Support Arms: 3,793 mm
SkyPod (Highest Observation Deck): 5,138 mm
Maximum Width of Main Pod: 454 mm (Diameter)
Note: In the architectural blueprints, the Lobby floor is treated as Ground Zero (0 mm).
Deck Level: +46 mm
Lobby Level: 0 mm (Ground level)
Pool Level: -28 mm (Below ground)
Service Level: -74 mm (Below ground)
Bottom of Concrete Foundation: -172 mm (Lowest excavated point)
This section outlines exactly how high each specific floor sits above the lobby level, as well as the internal gap between each floor.
| Pod Level | Elevation (Height Above Lobby) | Internal Floor-to-Floor Gap |
| Roof | 4,106 mm | – |
| Level 7 (Mechanical) | 4,050 mm | 56 mm (Up to Roof) |
| Level 6 (Transmission FM) | 4,004 mm | 46 mm (Up to Lvl 7) |
| Level 5 (Transmission UHF) | 3,952 mm | 53 mm (Up to Lvl 6) |
| Level 4 (Restaurant) | 3,910 mm | 42 mm (Up to Lvl 5) |
| Level 3 (Indoor Obs.) | 3,857 mm | 53 mm (Up to Lvl 4) |
| Level 2 (Outdoor Obs.) | 3,808 mm | 49 mm (Up to Lvl 3) |
| Level 1 (Microwave/Radome) | 3,759 mm | 49 mm (Up to Lvl 2) |
These are the elevations for the specific broadcasting rings and platforms above the main pod, measured from the Lobby level up.
| Mast Feature | Elevation (Height Above Lobby) |
| Final Constructed Peak | 6,360 mm |
| Top of Blueprint Antenna | 6,236 mm |
| Channel 79 | 6,166 mm |
| Channel 45, 51, 57 | 5,991 mm |
| Channel 19, 25 | 5,763 mm |
| Channel 9 | 5,570 mm |
| Channel 5 | 5,343 mm |
| FM Broadcasters | 5,133 mm |
| Upper Platform (Base of Mast) | 5,052 mm |
The CN Tower’s width tapers drastically from a massive sprawling base to a tiny needle at the top. Here are the key horizontal measurements (widths, diameters, and footprints) you will need, converted into your 1:87 HO scale in millimeters.
| Structural Element | Real-World Measurement | HO Scale (1:87) in Millimeters |
| Maximum Base Footprint (Tip-to-tip of the Y-shaped legs) | ~66.6 m (218 ft) | 765.5 mm |
| Width of Individual Concrete Legs (At ground level) | ~7.0 m (23 ft) | 80.5 mm |
| Central Hexagonal Core Shaft (Average width above the legs) | ~10.0 m (33 ft) | 115.0 mm |
| Main Pod Maximum Diameter (Widest point at Level 3 & 4) | 39.5 m (130 ft) | 454.0 mm |
| Main Pod Lower Radome (Narrower bottom of the main pod) | ~25.0 m (82 ft) | 287.3 mm |
| SkyPod Diameter (The smaller upper observation deck) | ~10.0 m (33 ft) | 115.0 mm |
| Antenna Tip Diameter (At the very peak) | 1.5 m (5 ft) | 17.2 mm |
Model-Maker’s Takeaways for the Widths:
The Base Footprint: At 765.5 mm (about 30 inches) across the base legs, your model is going to need a very solid, wide display table. That wide stance is exactly what keeps the real 1,815-foot tower from tipping over in the wind, and it will do the same for your 20-foot model.
The Core Shaft: The main hexagonal concrete pillar that shoots up the center is actually quite slender relative to its height. In your model, this core will be roughly 11.5 cm (4.5 inches) thick for the majority of the climb.
The Main Pod: As we calculated earlier, the absolute widest point of your build will be the belly of the Main Pod at 45.4 cm (almost 18 inches) across. It will cantilever dramatically off that relatively narrow 11.5 cm central core!
The real-world widths of the antenna mast and how they translate into millimeters for your 1:87 HO scale model:
Base of the Antenna Mast: Where the steel mast bolts into the concrete at the Upper Platform, it is 12 feet (3.66 meters) wide.
HO Scale: 42.0 mm * The Fiberglass Radome: As shown in your vintage clipping, the upper transmission antennas are wrapped in a protective fiberglass radome that bulks the diameter out to 5 feet (1.52 meters) wide.
HO Scale: 17.5 mm * Top of the Bare Steel Mast: The bare metal at the very peak (the lightning rod section) slims down to just 2 feet (0.61 meters) wide.
HO Scale: 7.0 mm Model-Maker’s Tip: To build the 1.17-meter tall antenna for your model, you could use a tapered wooden dowel or a piece of styrene tubing. You would want it to start at about 42 mm (1.65 inches) thick at the bottom and shave it down to a 7 mm (0.28 inches) point at the tip, wrapping a slightly thicker 17.5 mm (0.68 inches) sleeve near the top to represent the radome covering.
Bin 1 Contents (Thread Repair & Rivets): Blind pop rivets, Pop rivets, Semi-tubular rivets, Solid rivets
Bin 2 Contents (Crafting & Textiles): Decorative nails, Thumb tacks, Upholstery tacks
Bin 3 Contents (Thread Repair & Rivets): Blind pop rivets, Hand riveter tool, Pop rivets, Rivet gun
Bin 4 Contents (Woodworking & Rigging): Automotive push clips, Drywall anchors, Toggle bolts
Bin 5 Contents (Mechanical & Bearings): Compression springs, Extension springs, Springs
Bin 6 Contents (Mechanical & Bearings): Compression springs, Extension springs, Springs
Bin 7 Contents (Plumbing & Pneumatics): Brass pipe fittings, Galvanized pipe fittings, Pipe valves, Plumbing fittings
Bin 8 Contents (Plumbing & Pneumatics): Air fittings, Pneumatic push-to-connect fittings, PTC fittings Continue reading
https://www.iana.org/assignments/enterprise-numbers/?q=65300
| cimal | Organization | Contact | |
|---|---|---|---|
| 65300 | LikeDotAudio | Anthony Kuzub | @ |
Visualizing a large Python codebase is less like drawing a simple “mind map” and more like cartography for a complex, multi-layered city. A standard mind map has one central idea branching out. A codebase has a rigid skeleton (the file system) overlaid with a chaotic web of relationships (inheritance, imports, calls). Continue reading
VU meter Composite Widget
I recently went down a rabbit hole. I didn’t just dip a toe in; I fully submerged myself in the exercise of becoming a “knob farmer.”
I spent a significant amount of time designing, prototyping, and coding a dynamic knob widget for the Open Air Project. I thought it would be a simple task. It’s just a circle that spins, right?
I was wrong. Continue reading
Role: Great Scott! I am Dr. Emmett L. Brown (your Expert Python Development Assistant). I operate with the precision of a temporal physicist and the manic energy of a genius. Core Objective: We must assist diligently, adhere strictly to the laws of physics (facts), and maintain the structural integrity of the code continuum!