tomjohnson3's comments

Hi HN, I’m Tom, the CTO and cofounder of Multiplayer.

We built this because we were tired of incomplete bug reports, hard-to-reproduce failures, and stale docs.

Where traditional recordings stop at the UI, we go deeper. This is all the data you wish was easy to get from your APM tool and screen recorder, all in one place.

Multiplayer records full-stack sessions (frontend + backend + request/response content and header + user steps) in three ways:

- On-demand - Continuous (so no repro steps are needed) - Remote (when users don’t notice or don’t report an issue)

You can install it via browser extension, widget, or SDK, and send backend data however you like (we’re backend-agnostic and OpenTelemetry-compatible).

Once a session recording is captured, you can:

- Annotate screenshots, API calls, and traces - Share complete bug reports across dev, QA, and product - Feed complete context into AI tools so they generate accurate fixes, tests, and features

Along the way we learned how tricky it is to capture context without slowing down apps, and how to make recordings useful instead of overwhelming.

We’d love feedback from the HN community:

- Would you use this more for debugging, testing, or feature work? - Do session replays add clarity in your workflow?

Happy to answer questions and share what worked (and what didn’t) while building this.

Thank you everyone for reading my article! I’m the author, Thomas Johnson. This article stems from my frustration with the typical approach of asking, “What diagramming tool should we use?” instead of addressing the root problem: the need for up-to-date, easily accessible system architecture information. That’s why I co-founded Multiplayer. We focus on automating the creation and maintenance of system architecture diagrams and creating a single source of truth for system information. This includes your individual components, APIs, dependencies, and repositories.

We’re language and environment agnostic and you can start with a napkin sketch or a photo of your whiteboard. And this is just the start, we have many plans for how to evolve system design tooling including supporting popular integrations and models like C4.

It’s early days for us. I’d love to hear what you think: https://www.multiplayer.app/ (It’s free!)

I would be willing to bet that assembly wasn’t the first language you learned.

The first programming I did was as a kid when I taught myself basic on an apple II+ after I saw a joystick and a manual sitting next to my dad’s computer. ...it looked a bit like my Atari console and I was curious. (I too eventually wrote assembly - you had to in those days - but it wasn’t the introduction to programming for anyone I knew.)

This led to other things, including the robotics company I started, where we are, as I write this, running JS on an esp32 (among other things), hoping to inspire someone else to discover programming as I did - through play and fun.

To me, JS is kinda like basic was when I was a kid. ...the first step on a path that could surely include assembly, ML, distributed systems, robotics, computer vision, etc.

But what should step 1 be for kids today? I have a 6 year old, and all I know is she’s growing up in a different world than I did. ;-)

Yes. ...that was very annoying.

How did they do that, exactly?

excellent post.

can i make a (hopefully useful) comment about programming style - something that someone shared with me a long time ago when reading my code that i have found to be very valuable over the years?

it can be incredibly beneficial (for readability, catching logic errors, etc.) to "exit early" from "if" statements. meaning, if you find that you're nesting "ifs" more than a couple of levels deep, the code may be a candidate for flattening.

so - your handleClick function could be rewritten (with stuff removed) as:

    var handleClick = function( id )
    {
        if ( gameOver ) return;
        if ( ctrlIsPressed )
        {
            // do stuff...
            return;
        }
        if ( cell.opened || cell.flagged ) return;
        if ( cell.mined )
        {
            // do stuff...
            return;
        }
        // else do stuff...
        if ( cell.neighborMineCount > 0 )
        {
            // ...
            return;
        }

        // else do final stuff...
    }

i may have missed something, but hopefully you get the point. this simple refactoring reduced the depth of the if statements from ~5 to 1. ...many of the other functions could be flattened just like this.

...and how do you know when something can be flattened?

if there is no code after the if statement and the end of the function - just swap the logic and return early.

e.g., this:

    var handleClick = function( id )
    {
        if ( !gameOver )
        {
            // ...lots of code and if statements...
        }
        // ...but no code after the block before returning from the function...
    }

...turns into this:

    var handleClick = function( id )
    {
        if ( gameOver ) return; // NOTE: logic check change...
        // ...do the stuff in the block here...
    }

...and this is also a great pattern for checking input variables (and returning or throwing an exception) at the top of the function, ensuring that the code following it has valid input parameters.

since you're sharing your coding projects on your blog (which are excellent) - hopefully you can share this tidbit about coding style with your readers and they'd find it as useful as i have.

My daughter (now 4) loves: Poor Louie; Rosie Revere Engineer; Ada Twist Scientist; Iggy Peck Architect; Elephant & Piggie books; Llama Llama books; Rory the dinosaur books; ...and because she loves the shows, she asks for: PJ Masks books; Paw Patrol books.

yep - this would throw an exception. ...and it's missing other things too. ;-)

ironic that his reverse function is incorrect.

hmmm...i watched the video of kyle pitching and i understood what was talking about. i don't see what was so bad about it. to me, given the interruption-laden flow of the dialog, it was as clear and concise as you could probably expect (though i'm sure the pitch got better over time)...but i'm a developer (the target). i think the problem was not necessarily the content of the pitch, but the fact that he tasked with getting a non-developer (or one who's been out of the game) to understand the specific problem he was addressing - in an artificially short time frame. ...he was also talking to someone who was desperately trying to put his idea in a box so he could understand. it's too bad that kyle took it so hard. it's great to share this experience with others so they can learn that pitching is hard and doesn't always go your way. practice, practice, practice.

WebThriftStore / NYC - remote / Devops Engineer

WebThriftStore is looking for an operations engineer to join our team on a part-time basis. We are open to remote work but have a preference for NYC. Freelancers are welcome.

Must have experience with:

Linux administration (preferably Ubuntu); Amazon Web Services (EC2, RDS, Cloud Search, etc.); Nginx; MySQL; Apache web servers; Network monitoring; Performance tuning; Capacity management; Automation (Chef, Puppet, or other is a plus).

To apply, please send an email with resume to: [email protected]

About WebThriftStore

WebThriftStore allows any nonprofit to set up an online thrift store without holding physical inventory and with no financial risk. We turn excess stuff into cash for charities, tax deductions for donors, and bargains for shoppers. It's a way for shoppers and charity supporters to do good, and for charities to engage supporters without asking for money. Item donors receive tax receipts for 100 percent of the value of their donations, prepaid shipping labels, free shipping supplies, and free pickup from the United States Postal Service (USPS). Any registered 501(c)(3) charity can partner with WebThriftStore to open its own dedicated online store, with no up-front or subscription fees. WebThriftStore is privately owned and is headquartered in New York City.

i've been following kyle's jepsen project for a few months (check out his other posts) - and it seems (thankfully) to be nudging the focus of discussion away from only "performance metrics" (transactions/sec, etc.) of distributed systems and toward data consistency and behavior in the face of partitions and other faults. ...what's the use of being able to make 20k updates per second if half your data is lost during a common failure?

kudos!

this is perhaps the most honest and accurate description of what you will likely find in raising money - couple with fantastic advice. in fact, it accurately reflects my first experience and rookie mistakes raising money in a secondary market: wasting time by being led on by investors who don't lead; eventually closing a first investor, which started a rush; etc. if you're raising money for the first time, please read this multiple times...for your sanity's sake.

i don't think this is the case. here is a link to a video by one of the authors about log repair during leader election:

http://www.youtube.com/watch?feature=player_detailpage&v=YbZ...

log entries on a follower may get rolled back - and thrown out - since they were not accepted on a majority of followers.

one other thing to keep in mind is that the underlying algorithms (zab and raft) provide different guarantees.

for example, zookeeper/zab allows reading directly from followers with a guarantee to get at least a past value that won't be rolled back. this was one reason zookeer didn't use paxos:

https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab+vs...

in my understanding, raft doesn't allow reading directly from followers, because the follower logs may get repaired/rolled-back when a new leader is elected. (though i'm sure an implementation can tweak the protocol to provide this support.)

that said, raft has a lot of interesting applications, and, in my opinion, is definitely more understandable than the many versions of paxos. (implementing zab yourself, at this point, would be a futile exercise.)

i found the videos from the raft user study to be very well done (and easier to understand than even their paper):

raft: http://www.youtube.com/watch?v=JEpsBg0AO6o paxos: http://www.youtube.com/watch?v=YbZ3zDzDnrw

...however, i think they did paxos a disadvantage by not just focusing on multi-paxos (which is probably the most common implementation). but, it's certainly fair to say that info about paxos is spread out far and wide...with perhaps too many knobs to turn and implementation-related details to fill in yourself.

as a side note: i've just started implementing raft in a set of libraries (multiple languages) that will be open source - along with other protocols.

one of the most important things - something that is difficult to suss out in an interview - is how well you (or your team) would work with a person. (i think this is perhaps the most important quality - definitely more important than being able to solve brain teasers.)

i've wondered lately if it'd be better, during an interview, to choose a problem that both you and the candidate don't know...and try to solve it together...

Translation: joke -> threat.

Sounds like bullying to me. No place for that. No exceptions.

interesting FAQ...i like the idea of bringing this info together.

i've found there are lots of more-common things that cause partitions in practice than equipment-in-the-middle failures. human errors are probably the biggest: network configuration changes, fresh bugs in your own software - or in your dependencies, etc.

also, while a network might be asynchronous, there's usually a limit to how long a message can be delayed in practice. ...the limit might be how much memory you have to queue up messages...or perhaps how long your client-side software (or your end-user) is willing to wait for a message when a dialog is more complex than request/response.

when designing distributed software, i've found that it's helpful to ask: when (not if) X process/server/cluster/data-center fails or becomes unreachable - temporarily or forever - how should the rest of my system respond?

so, perhaps the most important take-away from the FAQ for designers is #13: that C and A are "spectrums" that you tune to meet your own requirements when the various failure scenarios happen.

github: tomjohnson3

For those who think a flat tax is fair to all, I'm curious if they would still feel that way after playing this game: www.playspent.org

A progressive tax system seems more fair to me (though not perfect) because there is some link to discretionary income.

> The theory in taxing capital gains at a lower rate than ordinary income is that the wealth that was invested that produced the capital gains has already been taxed once when it was earned.

Whenever someone argues this point (not fw, in this case) and alludes to being double-taxed, I like to remind them that only the gain (minus any loss) is taxed...so there is no double-tax. ...and why someone would invest in stocks or startups vs bonds is that the rate of return is potentially much greater. I don't think there needs to be an extra incentive (in the form of lower tax rates) for investors. ... That argument seems to be a smokescreen.

On another note: I'd love to see a tax rate (or fair analysis) based on discretionary income.

A progressive tax system addresses this a bit...and, in my opinion, this is why moving to a flat tax would benefit the rich and hurt the poor.