davemo

I love XState. It has solved so many problems in quite a few codebases for me, most recently it has become the backbone of a voice app I'm building for the banking sector. Thank you for all the time and effort you put into making it great.

I blogged[0] a bit about my experience with Finite State Machines, and about the architecture we landed on with XState and Mastra (although since publishing we have swapped to Pipecat).

[0] https://blog.davemo.com/posts/2026-02-14-deterministic-core-...

I've got a bunch of irons in the fire at the moment, most leveraging or built with agentic coding tools; my harness of choice these days is pi+codex.

- An internal apps platform built with bun, pg-boss, and railway

- A smart music setlist manager that downloads chord charts, creates spotify playlists, and automatically drafts emails with attachments and practice schedules

- A recruiting intelligence platform called Spotter that I built in a weekend[0]

- A voice-agent for a client in the banking sector, implementing deterministic workflows using openai realtime voice + finite state machines[1]

[0] https://www.youtube.com/watch?v=AOedMSddGDg

[1] https://blog.davemo.com/posts/2026-02-14-deterministic-core-...

Tommy drew a lot of inspiration from Chet Atkins who was really the pioneer of the bass+guitar "one hand band" style of playing. Tommy just improved on it a lot, adding more rhythmic elements, but to your point, yes, he was largely self-taught and driven to learn.

A good interview on his background: https://www.youtube.com/watch?v=py4T1qv9bnQ

I swapped to Bazzite on my gaming rig (5800x3D, 64gb DDR4, 4080 Super 16gb) and it's been fantastic. I tried going with Omarchy for a bit to try and have that machine do double duty as a dev/gaming machine, but I felt like the gaming experience on Omarchy is a second-class citizen compared to what the Bazzite experience is optimizing for, and I realized that the Hyprland setup and tiling window manager adds a lot more friction for my normal gaming needs. (I just want to have a few Path of Exile 2 windows open to tab between while gaming, and the tiling window setup in Omarchy had me hitting more hiccups between fullscreen and windowed mode than I care to troubleshoot on my gaming rig).

Immutability in OS updates is also something I didn't know I needed until I experienced it on Bazzite; pretty advantageous as a gamer using Linux with nVidia hardware these days.

This is my second go around on Bazzite, YMMV but I opted for Gnome over KDE this time and have had zero issues running the games I am into (WoW, PoE2) and no funky window management issues that I seemed to run into with KDE.

I'm considering a move to a Framework machine in the very near future, and still need to settle on a distro for dev; most of that is done on an M3 Max Macbook these days.

I was an avid user of Pipes and blogged a bit about the experience of using it to build an aggregated set of feeds from various employee blogs to feed into our company site back in 2009 [0]. It holds a special place in my memory alongside early internet greats like del.icio.us [1]

- [0] https://blog.davemo.com/posts/2009-04-06-yahoo-pipes-at-vend...

- [1] https://en.wikipedia.org/wiki/Delicious_(website)

I can appreciate the effort put into the goal of optimization shared in the post, even if I disagree with the conclusions. All of that effort would be much better directed at doing a manual (or LLM-assisted) audit of the E2E tests and choosing what to prune to reduce CI runtime.

DHH recently described[0] the approach they've taken at BaseCamp, reducing ~180 comprehensive-yet-brittle system tests down to 10 good-enough smoke tests, and it feels much more in spirit with where I would recommend folks invest effort: teams have way more tests than they need for an adequate level of confidence. Code and tests are a liability, and, to paraphrase Kent Beck[1], we should strive to write the minimal amount of tests and code to gain the maximal amount of confidence.

The other wrinkle here is that we're often paying through the nose in costs (complexity, actual dollars spent on CI services) by choosing to run all the tests all the time. It's a noble and worthy goal to figure out how not to do that, _but_, I think the conclusion shouldn't be to throw more $$$ into that money-pit, but rather just use all the power we have in our local dev workstations + trust to verify something is in a shippable state, another idea DHH covers[2] in the Rails World 2025 keynote; the whole thing is worth watching IMO.

[0] https://youtu.be/gcwzWzC7gUA?si=buSEYBvxcxNkY6I6&t=1752

[1] https://stackoverflow.com/questions/153234/how-deep-are-your...

[2] https://youtu.be/gcwzWzC7gUA?si=9zL-xWG4FUxYZMC5&t=1977

Veni, Vidi, Vici

I submitted an application for w24 that fits in the "Developer tools inspired by existing internal tools" category but wasn't accepted. I suspect my pitch probably needed work, and I also haven't started building at all yet and submitted as a solo-founder which it seems has less chance of being accepted.

Here's the pitch and some details, in case anyone else is interested in the idea:

Supportal uses AI to generate internal tooling for startups that enables founders to scale customer-support without having to rely on engineering resources.

Given some simple input context like tech-stack and a database schema, Supportal uses AI to auto-generate internal tools which allow customer-support to easily answer questions about and take action on customer-data without needing help from an engineer.

Supportal offers founders a fully-featured self or cloud-hosted web UI.

Retool (https://retool.com), Zapier (https://zapier.com), Airtable (https://www.airtable.com), Superblocks (https://www.superblocks.com), and Google AppSheet (https://about.appsheet.com) would likely be primary competitors, although their products require heavy user interaction to build internal tools either through composition in a WYSIWYG editor, low/no-code solutions, or integrations expertise using a full programming language.

Although I'm no longer there, we actually evaluated and/or used all of these tools at Pulley, so I've had first-hand experience with their friction and where the gaps exist that Supportal would fill.

These tools are also all targeted at integrations-experts who have the technical knowledge to write code and spend time building the tool they want.

Supportal aims to generate the tooling you need intelligently via AI introspection and get you up and running with useful command and query tools to help your customer-support team take action and gain insights without help from engineering right out of the box.

My most recent experience comes building internal tools for Pulley; I built the initial version of the internal tools in ~3 weeks and added features to it within Pulley over ~2 years. Roughly ~2-3 months of full-time work spread over that time period.

Features were added as we identified gaps in our support agents ability to answer questions and take action, which often required dedicated engineering resources to help with, leading to a productivity loss for both groups.

That said, I haven't actually built out anything that would _generate_ tools like this yet, but I've done enough adjacent work in the codegen/AI space in the last couple years that I feel confident I could put the pieces together.

Merry Christmas to all my fellow hackers! :]

This may be slightly tangential but I recently discovered ncc[1] from vercel which can take a single node project and compile it and all dependencies to a single file.

As an added benefit it also collapses all contained dependencies license files into a single licenses.txt file too!

- [1] https://github.com/vercel/ncc

I have a friend who is a mail-carrier (which I think is the most accurate gender-neutral term) for Canada Post. She refers to herself often as "postie" as well, and her co-workers as "posties". :]

It comes in waves. I'm in my 22nd year of developing software and I can reflect on times when I felt incredibly confident and didn't shy away from sharing my opinions, and other times when I felt like it was better to remain silent because I had things to learn from others.

There are times for both speaking and listening in our careers; as I've progressed further in my career I have felt it is often more valuable to exercise active listening.

I’m a lifelong musician who recently started diving into the world of audio production. I like most music genres and try to experiment with producing a little from each.

Here are a few of my recent tracks that I think turned out ok:

- Rush-inspired synthwave: https://soundcloud.com/dmosher/rushing-in

- Lo-fi jazz/hip-hop: https://soundcloud.com/dmosher/the-soggy-sunday-swing

I’ve got some more experimental stuff up on Bandcamp as well: https://davemo.bandcamp.com/

haha this was epic! thanks for sharing :D

I’ve been working on my music production skills with a learn monthly class from Andrew Huang. It’s been good to push myself into production; I have many years of live music experience but haven’t spent a lot of time recording.

I’d classify my style as synth wave meets 80s arena rock for the current track I’ve been working on :)

My learning path is here [0] and I’ve also been uploading works in progress to my soundcloud [1]

[0] https://learnmonthly.com/u/dave-mosher-e2bc26/andrew-huang-m...

[1] https://m.soundcloud.com/dmosher

The author addresses this in the OP:

"We later learned that Google’s gRPC Team was working on a gRPC-Web spec internally. Their approach was eerily similar to ours, and we decided to contribute our experiences to the upstream gRPC-Web spec (currently in early access mode, still subject to change)."

I suspect anyone attempting to adopt this implementation is going to hit similar issues until a release is finalized.

The quote in context is: "Husbands and wives may allow their partners to fill the role of best friend, letting other relationships fall by the wayside (something I’ve tried to actively resist)."

It seems the author is advising against forsaking other relationships and placing the entirety of the burden to supply all of our friendship needs on our significant other. I think there's wisdom in diversifying our relationship portfolio the same way we do with investments.

If you are interested in learning more about Flow check out the docs [1] and github repo [2].

[1] http://flowtype.org/

[2] https://github.com/facebook/flow

If you'd like to use React + JSX + CoffeeScript I built a little workflow [1] using Gulp that works pretty nicely; it takes advantage of the backtick character in coffeescript compilation to let you do cool things [2].

[1] https://github.com/davemo/react-battleplanner/blob/battlepla...

[2] https://github.com/davemo/react-battleplanner/blob/battlepla...

I've got a LinemanJS [1] template [2] that gives you a really lightweight boilerplate and workflow for developing Angular projects; Lineman is like a smaller, focused version of Yeoman that also uses Grunt.

[1] http://www.linemanjs.com

[2] https://github.com/davemo/lineman-angular-template

I've got a couple [1] of screencasts [2] that go into detail on the integration side of things; I chose to integrate with Laravel (PHP) and MySQL purely for mass-market appeal but the lessons learned should be widely applicable to any stack:

[1] - End to End with Angular JS - http://www.youtube.com/watch?v=hqAyiqUs93c [2] - Security with Angular JS - http://www.youtube.com/watch?v=18ifoT-Id54

Glad to hear my efforts have helped you out; let me know if there are any other fundamental workflow / webdev topics that you would be interested in learning more about and I will add them to my screencast backlog :)

Between browserify and requirejs I've definitely had a more positive experience with the former but my experience is that both seem to be subject to scaling problems with even a trivial number of dependencies in play; I wish there was a really good sample project setup that would allow accurate comparisons between the tools at the scale they are frequently used at, but for now I choose to use simple concatenation and a simple namespacing tool [1] to avoid lengthy watch-time issues during development.

grunt-contrib-watch is a pretty vital part of my workflow, but I don't use the livereload options because I can't afford to lose that state in the browser.

[1] https://github.com/searls/extend.js

I wouldn't choose to use requirejs on a project where I was making choices about the architecture for reasons mentioned here [1], but the current project I'm on was setup similarly and loads over 350 .js and .tpl files via AJAX in development mode pushing the DOMReady to a staggering 7.5s. (This is inside of Rails 3.2 using the requirejs gem).

Every time I've encountered requirejs in an application this has been representative of my experience with the tool and the pain of having to wait that long every time I reload a page simply doesn't seem worth it to me. There's also somewhat of a mismatch between async loading assets in development and sync loading them in production which I've seen responsible for bugs that show up in one environment but not the other, and/or vice versa.

A couple of questions for you: do you think the r.js optimizer taking 2.5s to compile is related to the complexity of the dependency tree in your application or just the number of files being loaded? Also, considering the previously mentioned mismatch between dev/prod and async loading, do you think it is appropriate to use something like SPDY to obviate the pain of a lengthy DOMReady event in development?

[1] http://searls.testdouble.com/posts/2013-06-16-unrequired-lov...

Many of the workflow elements discussed in the article apply more to designers than developers; for example: live reload which is very useful in the context of rapidly iterating on design changes but quickly loses appeal when working on a rich-client web application using a JavaScript framework where you have long-lived state present in the page.

Much of the way the web is being built is evolving from static pages and presentation to full-blown applications running completely in the browser which is why there is such a shift to providing tools for visualizing complex pieces of browser operations like rendering, compositing [1] and painting [2].

I don't think there's any fundamental problems with the tools being developed, the reason workflows are broken is because many web developers aren't being empowered to learn web development fundamentals. I can't imagine starting out as a web developer in 2013 and trying to jump in with all of these abstractions, tools and workflow items to try and understand; it'd be like trying to jump in as a newcomer to Rails at the latest version without all the context of the changes that lead to design decisions that currently make up the latest iteration of "The Rails Way". [3]

I think tooling is in a pretty good place now; browser vendors need to start educating web developers about how to craft workflows and use the tools out there. My goal has been to try and educate more web developers about browser and web fundamentals [4] along with workflow fundamentals like automating tasks using Grunt. [5]

[1] http://www.youtube.com/watch?v=x6qe_kVaBpg

[2] http://www.youtube.com/watch?v=Ea41RdQ1oFQ

[3] http://words.steveklabnik.com/rails-has-two-default-stacks

[4] http://www.youtube.com/watch?v=Lsg84NtJbmI

[5] http://www.youtube.com/watch?v=fSAgFxjFSqY

I'm interested in understanding why you are "ajax[ing] in > 200 source files" in development mode? This provides a pretty poor developer experience IMHO; I've found a much better workflow in setting up a single concatenated unminified bundle for development using grunt-concat-sourcemaps [1] to provide source mappings that Chrome Developer Tools can browse.

This gives you the snappy page loads you'd expect with a single script element in the page, and still allows you to debug in your separate source files due to the sourcemappings. The only difference between javascript in development and production should be the minification step.

[1] https://github.com/kozy4324/grunt-concat-sourcemap

I'm just going to keep putting out casts for free, some will be Angular JS related in the future but my general idea is to focus on screencasts that will benefit web developers in general. Thanks for watching! :)

I've wanted to write a post like this for a long time, but my good friend @searls [1] beat me to it and has nailed all of the points with much more eloquence than I could have. Worth a read if you are at all wondering about javascript dependency management solutions (like require.js, browserify, etc..)

[1] http://www.twitter.com/searls

In addition to the first three tutorials I just put out another cast on tuesday, here's the full updated list:

* Part 1: Intro to Angular JS (50 minutes) [1]

* Part 2: End to End with Angular JS (52 minutes) [2]

* Part 3: Security with Angular JS (30 minutes) [3]

* Part 4: Frontend Workflows with Grunt and Angular JS (~60 minutes) [4]

[1] http://www.youtube.com/watch?v=8ILQOFAgaXE

[2] http://www.youtube.com/watch?v=hqAyiqUs93c

[3] http://www.youtube.com/watch?v=18ifoT-Id54

[4] http://www.youtube.com/watch?v=fSAgFxjFSqY

The goal of this and repository [1] is to educate web developers on how to use Grunt to craft their own workflows, and examine some higher level tools that provide additional features that are helpful when creating rich-client web applications.

By watching the screencast you will learn about:

* how to create your own frontend workflow using Grunt [2]

* how to create custom tasks with Grunt

* how to use Lineman [3], which utilizes Grunt, to create web applications that are portable between any backend.

* how to manually bootstrap the application we built in End-to-End with AngularJS [4] using angular.bootstrap

* how to effectively separate your code into many small pieces with singular responsibilities

[1] https://github.com/davemo/frontend-workflows-with-grunt-and-...

[2] http://www.gruntjs.com

[3] http://www.linemanjs.com

[4] https://github.com/davemo/end-to-end-with-angularjs