tomjohnson3

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...
    }

...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...
    }

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

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: tom@webthriftstore.com

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.

good points...i definitely get chills (in a good way) going down 101 or walking around soma, etc., feeling the energy of the tech companies all around me. it was definitely a motivating factor when i worked there. (lo those many years ago.)

(btw, the other comments seem to focus more on the mythical finance vortex here, which i'd love to debunk someday...hence the sidetrack.)

as for being in the "same league," i guess i dunno know what that means, really - from the perspective of a person trying to get an idea off the ground. (and i write this having started/sold one myself, been an early member of a company that went public, been part of a flame-out...and been through plenty of ups and downs over my startup-oriented tech career).

both have great access to capital...great engineers...pently of startups (not a smattering) and plenty of spots for serendipitous meetings with interesting people (we got plenty 'o those). ...i think the rest is pointless d#ck measuring when it comes down to it. any location is really what u make of it anyway - as long as you're not in a bad one.

don't get me wrong, i'd love to just bump into ron conway or PG at my local coffee spot. perhaps they'd visit the good people of brooklyn someday...over a latte with a side of capacitors at the local hacker collective. ;-)

i'll throw down a few off the top of my head: foursquare, 10gen, etsy, a cool one called makerbot, stackoverflow, etc, etc., etc. ...but there are lots of little guys you probably haven't heard of yet popping out of columbia/nyu or the great design schools like pratt/etc. or coming out of the larger companies around here. it's actually an exciting time to be in the city...

listen, i love the valley. ...i just want people to know that my nyc is a creative and fun one. ...and you can live a happy/rich/fascinating existence here without touching a line of fintech code.

honestly, do these people look like they want to screw you out of your first million?

http://hackerspaces.org/wiki/NYC_Resistor

;-)

look at all those happy/helpful people, ready to volunteer their time and emotional shares to help you get your project off the ground. (and this is only one great hacker spot in the city.)

in my experience (~10 years in manhattan+brooklyn)...these are the kinds of people/groups that are here...looking to build stuff and have fun.

...but, of course, in a place as large as this, you'll find all types. (as you do in the valley too, really.)

whenever i read comments about nyc's best developers ultimately being sucked into the vortex of finance, i want to gag.

i can only assume that these commenters haven't spent much quality time here (or in finance - which is, for the most part, not glamorous, but rather soul-sucking)...or they have spent some time here and have a very limited view of the city.

nyc is more than just wall street, "silicon alley" and midtown. i've worked in several places (boston, london, atlanta, san fran)...and i've never come across as rich a mixture of people who "make stuff" as i have in brooklyn.

on a related note: it'll be interesting if stanford ends up winning the bid to open a campus in NYC. (i think the navy yard location would be perfect!)

btw, great coffee (and serendipity-friendly) spots in brooklyn: gorilla, cafe grumpy, ...a new place called rucola (serves stumptown), and many many more.

I've used java since 1995. I agree that some EE projects are overly-complicated (EJB, etc.) and make simple tasks seem difficult. ...However, there's usually a reason - and, the bottom line is that you probably don't need to use those projects anyway.

However, when u write a non-trivial app (more than a web front-end or REST API), java starts to shine: there are soooooo many open source projects available with friendly commercial licensing, good tools for debugging, etc.etc., that you save a lot of time by just incorporating things rather than writing things.

This is not to say other languages don't provide these features - rails has some nice momentum (growing list of projects), python too, and say what u will about msft, c#/asp.net is a good combo (VS.NET is a great dev environment, and there is a relatively small but growing open-source movement - and Mono is fantastic for cross-platform work).

...but i'd say that the massive amount of effort and open source projects in java have been a godsend for my work - especially recently - and saved me enormous amounts of time.

...also, I've found that recent groovy and grails versions have made web dev super simple...and u can call all your java code ease. (And groovy++ (statically typed groovy extension) makes groovy performance for a lot of thing as fast as java.)

But the bottom line is that u should choose what u r most comfortable with.

Java would be a fine choice. Especially java / groovy / grails...and ignore the java projects u don't need (EJB, etc.).

On another note, I think the one language that startups should avoid (again for more than a simple web app talking directly to a DB) is PHP. Just try to extend it...or talk to an external service. yes, you can wrap your services with REST APIs...or use something like thrift...and i know there are several successful companies that use it (facebook, etc.etc.) - and i've been part of companies that use it too...but i think PHP puts yourself in handcuffs that a startup shouldn't really need. ...and it creates a "silo" around web development - not a good way to get going.

my $0.02. ;-)