[{"authors":null,"categories":null,"content":"In 2013 I published a paper titled Beam Viewer Controls at Jefferson Lab through the International Conference on Accelerator and Large Experimental Physics Control Systems (ICALEPCS), held that year in San Francisco. The paper details a complete rewrite of the control system software responsible for managing beam viewer devices on the 12 GeV CEBAF particle accelerator at Jefferson Lab in Newport News, Virginia.\nYou can read the paper on ResearchGate: Beam Viewer Controls at Jefferson Lab. There is something genuinely satisfying — and very cool — about searching for your own name on a research database and finding a published paper staring back at you. For an engineer who spent years in the trenches writing C++ and debugging hardware signals, seeing that work preserved and indexed alongside physics research from around the world is a quiet kind of thrill.\nWhat Is Jefferson Lab? Jefferson Lab (formerly the Thomas Jefferson National Accelerator Facility) is a U.S. Department of Energy facility dedicated to nuclear physics research. Its crown jewel is CEBAF — the Continuous Electron Beam Accelerator Facility — a large electron accelerator used to probe the internal structure of protons and neutrons. At the time of this work, the lab was in the middle of a major upgrade from 6 GeV to 12 GeV beam energy, roughly doubling the machine’s experimental reach.\nRunning an accelerator of this scale requires not just physics expertise but an enormous amount of software. Control systems touch everything: magnets, power supplies, diagnostics, safety interlocks, and the devices I worked on — the beam viewers.\nThe Problem Beam viewers are physical devices inserted into the beamline to give operators and physicists a picture of the electron beam’s shape and position. Think of them as tiny fluorescent screens that you slide into the path of the beam to see a glowing spot. Over 140 of these devices were installed on the 12 GeV machine, along with Faraday cups, insertable dumps, and other devices that share the same basic mechanics: a motor drives them in or out, limit switches confirm their position, and cameras route video back to the control room. Complicating matters, some of the devices were thin and fragile enough that the beam at full power would burn right through. Failure to check beam power before moving a device could result in weeks of shutdown to clean and repressurize the beamline.\nThe legacy software managing all of these devices dated back to the 1980s. It was a sprawling system built in State Notation Language running on 20 Input/Output Controllers spread across the accelerator tunnel — roughly 9,000 lines of SNL code, 2,000 lines of C, and hundreds of configuration files. When a device failed, diagnosing it meant hunting through a maze of EPICS records. Adding a new device meant editing configuration files in dozens of places. The system was difficult to maintain and nearly impossible to extend cleanly.\nThe New Design My replacement system, the Insertables System, took a data-driven approach. All device configuration — type, position, hardware channel assignments, beam vulnerability — was consolidated into a single structured XML file. A C++ program called the Insertables Manager read that file at startup, constructed a model of the entire system, and ran a background coordination loop that responded to hardware events through EPICS Channel Access.\nThe key insight was organizing devices into C++ sets reflecting their current state: inserted, retracted, traveling, lost, hardware-protected. When a beam viewer was requested for insertion, the Coordinator checked the inserted set for any inline devices that needed to clear first, sent retraction signals to all of them, and only then allowed the viewer to move. When a device went lost — no limit switch response within a timeout — the system automatically limited beam current until an engineer resolved the hardware issue, and the status string told them exactly which device had failed and why.\nThe EPICS database was reduced from hundreds of configuration files to a handful of macro-driven templates. Adding a new device now meant adding a few lines of XML and loading one additional template file at IOC boot time.\nDebugging by Ear Here is something that did not make it into the paper.\nDuring development and testing, I would sometimes sit near the beamline with a laptop and test the software in place. When a viewer received an insertion command, the actuator would fire — and if you were close enough, you could hear it: a soft, definitive plunk as the device settled into position. I would watch my screen for the limit switch signal to confirm the move had registered in software, while listening for that sound to confirm the hardware had actually responded. If the plunk came without the software registering it, I had a wiring or configuration problem. If the software showed the move but there was no plunk, something was wrong on the hardware side.\nIt is a small thing, but …","date":1778286900,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1778356292,"objectID":"97447044f22769ae661f4dc10bdcc6bc","permalink":"https://mikejfromva.com/post/retrospective-2013-beam-viewer-controls/","publishdate":"2026-05-08T20:35:00-04:00","relpermalink":"/post/retrospective-2013-beam-viewer-controls/","section":"post","summary":"A retrospective on building control software for Jefferson Lab's 12 GeV CEBAF particle accelerator — the design of the Insertables System, debugging hardware by listening for actuator sounds at the beamline, and missing the ICALEPCS conference due to the federal government shutdown.","tags":["retrospective","jefferson lab","physics","science","c++","epics","personal"],"title":"Retrospective 2013: Software Built to Run a Particle Accelerator","type":"post"},{"authors":null,"categories":null,"content":"Back in the late ’80s I played a game called Cosmic Glob on my Atari 130XE. The Atari ran on a 6502 CPU — the same processor that powered the Atari 2600 game console. When people hear “Atari,” they usually picture that console, but Atari also built a line of full home computers, and in those days magazines dedicated to Atari computing used to come with pages of BASIC and assembly code that you could type in by hand. Manually. Every line. If you made a typo, you debugged it yourself.\nI typed in one such game — Cosmic Glob — and my brother and I wore it out. You can see a demo of it on YouTube. The gameplay was a riff on Asteroids: avoid the enemy, shoot everything, don’t die. But Cosmic Glob had a twist that I’ve never seen replicated anywhere. When you shot another player, instead of destroying them it pushed them — hard — in the direction you were firing. Your bullet was a physics impulse, not a kill shot. You could use that to run your opponent into an obstacle, or just knock them across the screen for laughs. My brother and I spent far more time harassing each other than actually fighting the enemy Glob. That little mechanic turned a solo arcade game into a chaotic social experience, and I’ve never forgotten it.\nEnter Claude Code Last week I subscribed to Claude Code Pro and decided to put it through its paces by having it recreate that game — Cosmic Blob, my modernized tribute to the 1986 original.\nI started with the simplest possible scaffolding: an asteroids-style ship with arrow key controls for rotate, thrust, and flip. I deliberately left out momentum — when you release the key, the ship stops immediately. That makes the game easier to follow and keeps the feel closer to the quick, snappy controls of the original rather than the floaty physics of classic Asteroids. Claude gave me exactly what I asked for, including a procedurally generated starfield.\nFrom there I built the game up one feature at a time: obstacles, synthesized sound effects, the Blob itself, a pause feature, and finally a second player. As the game grew more complex, bugs crept in. For example, when the game was paused it would continue playing sounds in an infinite loop. We tracked down and squashed each one.\nAlong the way I exhausted my five-hour token limit twice. Code generation is clearly more token-intensive than tasks like refactoring or targeted bug fixes, and this was not a small project. Something to keep in mind for future sessions.\nIn the end, Claude Code produced roughly 1,100 lines of JavaScript in a self-contained single-page app, organized cleanly with clear constants, well-named functions, and good separation of concerns. If I want to tune something — say, the Blob’s size or hit points — I can find it immediately.\nHow the Code Works The whole game lives in a single HTML file with no external dependencies. Here’s the structure at a glance.\nThe game loop. A requestAnimationFrame loop calls update(dt) and render() on every frame, where dt is the elapsed time in seconds (capped at 50ms to prevent physics explosions after tab switches). All movement and physics scale by dt, so the game runs at the same effective speed regardless of frame rate.\nAudio. There are no audio files — every sound is synthesized on the fly using the Web Audio API. Each effect is an OscillatorNode (usually a square wave for that 8-bit character) fed through a GainNode with a short volume envelope. The thrust sound uses a low-frequency oscillator (LFO) to wobble the carrier frequency, giving it that sputtering engine feel. All oscillators connect to a single masterGain node so pause and mute work cleanly without leaving any sounds dangling.\nThe push mechanic. This was the whole point of the exercise. When a bullet hits a ship, instead of destroying it, the code adds a velocity vector to the target in the bullet’s direction (pushVx, pushVy). That push velocity decays exponentially each frame (using Math.exp(-PUSH_DECAY * dt)), fading out over roughly two seconds. While a ship is being pushed it faces the push direction rather than the direction the player steered — a nice visual tell that something involuntary is happening. There’s also a kill-credit system: if a pushed ship dies while the push is still active, the shooter gets a 250-point bonus.\nUFOs that shoot back. I came up with a particularly nasty trick for the UFOs: shooting one doesn’t destroy it — it immediately turns and comes straight at you. The code computes the vector from the UFO to the shooter and sets the UFO’s velocity directly along that line at full speed. The practical effect is that a careless shot turns a wandering nuisance into a guided missile aimed at the person who fired. In a two-player game this creates a genuinely evil opportunity: bait your opponent into shooting a UFO, then watch it hunt them down.\nThe Blob. The enemy boss is a procedurally animated blobby shape. It’s drawn as a closed Bézier curve through a ring of 12 control points, each of which oscillates on its …","date":1778284800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1778358687,"objectID":"871b181d224e81d4d0843bba1de63ced","permalink":"https://mikejfromva.com/post/building-cosmic-blob-with-claude/","publishdate":"2026-05-09T00:00:00Z","relpermalink":"/post/building-cosmic-blob-with-claude/","section":"post","summary":"I used Claude Code to recreate Cosmic Glob — a two-player arcade game I used to type in by hand from a magazine on my Atari 130XE — as a browser-based canvas game called Cosmic Blob.","tags":["ai","gamedev","javascript","claude","retro"],"title":"Building Cosmic Blob with Claude","type":"post"},{"authors":null,"categories":null,"content":"Hey there, and welcome to my corner of the internet!\nI’m Mike Johnson, and I’ve decided to start this blog as a kind of public diary for my tech explorations. If you’ve stumbled across this site, you’re probably here because we’ve crossed paths somewhere in the software world, followed my link from LinkedIn, or maybe you’re just curious about what a lifelong technologist gets up to when curiosity strikes.\nWhat This Blog Is About I tend to post most often about programming languages and code—it’s where I live and breathe professionally—but my interests wander into interesting territories like quantum computing, cryptography, and computer architecture and assembly language. Think of this as my learning lab, written out loud. I’m approaching each topic with curiosity and a beginner’s mind, even after three decades in the field. Because that’s when the best learning happens.\nThe tone here will be casual and positive. No corporate speak, no pretending I have all the answers. Just genuine exploration, mistakes included.\nWhat Drives Me If you’re going to read my ramblings, you should probably know what makes me tick.\nMentorship matters to me. Throughout my career at places like Amazon, GEICO, Jefferson Lab, and Sun Microsystems, I’ve found that some of my proudest moments aren’t shipping features—they’re watching junior colleagues level up. When students or coworkers get unblocked and suddenly get it, that’s my favorite moment. I taught as adjunct faculty at Christopher Newport University for fourteen years, and my students knew they could always come to me for help, whether it was related to class or not. Some of my student reviews said I was “a total nerd” and “totally into geeking out”—guilty as charged. Others said I was “always happy to help outside of the class, even if it’s not related to the course.” That’s exactly how I want to show up for people.\nCollaboration is everything. At work, I’m known for building bridges between teams. I assume good faith, share information freely, and genuinely want all teams to succeed together. Some of my best work has happened when I’ve helped connect the dots between groups that didn’t even know they needed each other.\nAlways learning. I’m endlessly curious, especially when it comes to science, math, and technology. Whether it’s diving deep into Rust and Go, listending to Stanford AI classes on YouTube, or bootstrapping new services in AWS, I want to understand not just how things work, but why. That curiosity has taken me from writing device drivers for Sun’s HPC systems to implementing Chinese cryptographic algorithms in AWS KMS to architecting PKI services at GEICO. Every problem is a chance to learn something new.\nScience is real. It feels strange that I need to say this in 2026 to anyone, anywhere, so much more so on an engineering site, but it’s both true and necessary. Science is the foundation of technology and engineering. Nobel-winning physics papers on quantum mechanics lead to better LED monitors. Discoveries in genomics and evolution lead to better vaccines and safer food supply chains. Mathematical proofs lead to new cryptographic algorithms and better security when browsing the Internet. But even when science gives us problems instead of solutions, it is equally real, and equally right. Global warming is an existential threat. Worldwide pandemics will decimate populations unless we improve vaccines, and, just as importantly, vaccination rates. Whether we like it or not, the world is a complex place. Luckily, scientists excel at understanding the complexities and sharing their knowledge with the rest of us.\nInclusion matters in engineering. If your organization lacks diversity, they are exluding valuable talent and overlooking opportunities to build a better team. One of the toughest places I ever worked was Amazon. And yet, even in a performance-driven division like Amazon Web Services, diversity and inclusion were essential in everything we did. Taking intentional actions towards including a more diverse population, by race, religion, gender, and sexuality, will improve the morale of your team and focus them more on finding solutions for tough problems.\nA Bit About Me I’ve been writing code professionally for thirty years, and honestly, I’m just getting started. My journey has taken me through some incredible places:\nI began my career at Jefferson Lab (Thomas Jefferson National Accelerator Facility), where I managed high-speed data acquisition systems for nuclear physics experiments and later developed control system components for particle accelerators. It was existing and cool to write code that helps scientists probe the fundamental nature of matter.\nAt Sun Microsystems, I worked on high-performance computing systems, creating benchmarks and instrumentation to squeeze every ounce of performance from parallel CPUs and distributed memory. I even contributed to HPC conference papers and authored research on scientific numerical library performance. The work …","date":1768780800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1778326220,"objectID":"b40beee07c09cea2c816f4b6d18639a0","permalink":"https://mikejfromva.com/post/welcome_to_my_blog/","publishdate":"2026-01-19T00:00:00Z","relpermalink":"/post/welcome_to_my_blog/","section":"post","summary":"An introduction to the blog and its author — a software engineer with thirty years of experience across Jefferson Lab, Sun Microsystems, Amazon, and GEICO, writing about programming languages, cryptography, general computing, and computer architecture.","tags":["personal","science"],"title":"Welcome To My Tech Journey","type":"post"}]