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.
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. ;-)
The first language I learned was machine code. Just saying. And I was in no way programmer. I was just a scientist trying to get some digestible data from the device used in my experiments. As the time went by I got Assembly, C, Turbo Pascal etc. I knew about basic but have never used it.
I first started programming when I taught myself at 3 years old digital logic. I started with just combinatorial logic (I was 3 after all!) but in one week I graduated to sequential logic.I still remember the spark of pride on father's eyes when I showed him the ALU I just created, he still told me to do better. Several ISA and micro-architecture later and half a dozen of languages created ( I remember fondly Beethoven,it was OO, this was before Simula) I started to get good at it. But then Gerda, my dear _Lehrerin_ had to go back to Germany (something about her father) and I had to start first grade so I set those juvenile games aside. I think they still somehow shaped the gentleman I am today.
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.
Thanks for the kind words, and thanks for sharing! That is a cool pattern. I definitely have a little too much nesting going on in that function, and it could use some refactoring.
I've always felt funny about multiple return statements though, which is probably one reason why a pattern like this doesn't usually come to my mind when considering how to refactor code. I've always liked having one exit point at the end of functions because programmers naturally expect a function to return at the very end. I think minimizing the number of return statements is generally a good thing, but perhaps I have been too strict about applying that rule.
"programmers naturally expect a function to return at the very end"
I disagree. I expect a function to return at the moment the final result is known. The decisions and logic are over. I shouldn't have to glaze over even a single extra line of code, because the work has already been done.
That's a fair point. I guess the main argument in favor of single return statements in modern programming languages is ease of debugging and logging. Like most things in programming, you have to consider the trade-offs. A few return statements isn't the end of the world, but after too many you might just want to make some more functions.
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 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?
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!)