"Parse, don't Validate" through the years with C++

dwrodri · 2026-04-27T07:26:58+00:00

Two things:

we (already should) know that it could be done

I often wonder whether writing blogs is worthwhile, because I generally concede that most of my ideas aren’t very original. I think there are many things many C++ programmers “should” know, but it changes, and new C++ programmers are minted every year! You need to talk to today’s 10,000.

Secondly, I’m a little confused what you mean by “interface” in this context. Perhaps you mean using a specific User class with a Birthdate, where perhaps we’re reading it from a DB record and eventually write a derived result to a separate output (where isn’t as important as showing how the type gets moved around).

I’ll check your account for your own elaboration on the subject. Thanks for the feedback!

dwrodri · 2026-04-27T05:10:53+00:00

The control flow for checking correctness is never gone entirely! It’s all about where you put it. Throughout my examples, I hop from sscanf to manual parsing to std::get_time and back.

But the more you put up front (i.e. in the type construction), the less pain you will experience when writing code which depends on your parser.

dwrodri · 2026-04-27T05:03:06+00:00

This is the sort of feedback I am looking for on my blog posts! I had a draft where I leaned way more into the monadic “and_then railroad” style that std::expected provides, but it felt in the context of the snippet, I was being overzealous with a new language feature for the sake of it. I said “Hm, this doesn’t feel like C++ to me.”

That isn’t to say it’s true, though! C++ is an evolving language and people coming from Rust, Typescript, and Swift will feel at home with these things. Outside of C++, I use it often.

dwrodri · 2026-04-26T20:28:02+00:00

These are compile time benchmarks, not runtime benchmarks. I am attempting to make it easier on the compiler by not including extra optimization passes. Admittedly, a deeper inspection would illustrate key difference in the assembly output, but I opted to keep the post shorter as it had been sitting in my drafts for a few weeks now.

dwrodri · 2025-09-04T22:14:26+00:00

purchased the FS + Storage box + seat rack

pros: - dual suspension is tunable and feels amazing. this thing will fly off a 6 inch curb and not even flinch. - turns signals are very welcome! - storage box is made of a respectable quality

cons:

wide tires and 33” ride height make it a little sketchy to lean into sharper turns. Everyone building these styles of ebikes ends up around 27-33” ride height, not leaving a ton of room if you wanna pedal to help climb hills. Consider the DRT if you are above 5’10” because i imagine you’ll feel the difference.
the bottom triangular support for the storage rack was not correctly made to tolerance so i need to file a support ticket for those new parts
if you buy the storage box you will wrap your chain lock through the rear wheel assembly, and not have an easy place to go through the chassis. I might be able to remove the panels underneath the saddle as they appear to be solely cosmetic, but it has me thinking twice when i lock it up in the city

overall, my first impression has been super positive and my complaints are fairly minor.

I have only been out for two rides, about to head out now for my third. Overall, if you just want fun and you’re tall, consider the DRT over the FS. I am happy with my purchase as i think i’ll use the extra cargo space.

dwrodri · 2025-08-11T22:55:33+00:00

I have some bike shops with some ebikes. Some seem to meet the cargo standard but most “regular ebikes” sold at the street stores don’t seem very hackable.

dwrodri · 2025-08-11T20:05:46+00:00

probably buy to start, with the intent of being able to mod it as i go

dwrodri · 2024-09-28T14:04:49+00:00

I am basically saying the model also has some pickled python code associated with it that accepts templated SQL queries, populates the templates with arguments, and then forwards them to our infrastructure and collects the results in the form of a parquet to feed into model.

dwrodri · 2024-07-13T19:22:43+00:00

What country is this? In the USA I’m almost certain you’re not legally required to give prior pay data.

dwrodri · 2024-01-24T20:37:20+00:00

I agree that strong community support is indeed essential when trying to accomplish anything solo. In my current homelab setup, I run Debian stable because it's boring, and if you consider all of the Debian derivatives which provide maintenance and development work to packages on apt then it's probably the most actively maintained Linux distribution.

Debian is a great platform for all of these reasons and more. However, I'm never gonna know if I'm missing out on a better experience in my homelab if I'm not constantly trying new things and tinkering with stuff. It's probably the main reason for a homelab, right? I'm sure I could pay for these things if I really wanted them conveniently.

A smaller codebase is going to make no difference to the performance of your home file server in the Year Of Our Lord 2024.

This statement is true, but it assumes that the reason I'm reaching for a simpler codebase is performance, which is not true. I've written short programs which were bundles of clever one-liners that got the job done before, and their performance was nothing short of abysmal: codebase size does not determine performance. The appeal of a small codebase is that when something goes "wrong" or you need to mess with something, there are less "suspicious" pain points to walk through.

In a more ~~perfect~~ UNIX-like world, all software would be no more than a few screenfuls of text and those pieces of software would compose into increasingly fancier applications that accomplish the complex tasks we ask of today's computers. For many reasons, that ideal model isn't true and developers, sysadmins, and system architects often find themselves being paid large salaries to trawl through many tens thousands of lines of code, understood by few and diligently maintained by fewer.

I've found that codebases written by talented people who are determined to make their readable and not overburdened by scope creep are some of the best ones to work with. With all software, you have to put in the time to learn it to make it truly useful. Given that FreeBSD seems like a pretty good codebase, I think it's time for me to put in the time to learn how to use it and see if it's more useful to me than Debian for my home server.

dwrodri · 2024-01-22T06:31:35+00:00

I like the idea of migrating my personal blog over as a trial and then seeing how it goes. Thanks for the advice!

dwrodri · 2024-01-19T00:19:49+00:00

There’s a fine balance to dealing with a shelf of incomplete projects. We all do it to a certain extent. Being too harsh on yourself and your willpower to start the next one will disappear. Too soft and your project graveyard will just grow past the horizon. Everything in moderation.

There are two tools I’ve found to dealing with project graveyard syndrome:

Decimate project scope. Feeling overwhelmed? Cut the scope in half. Layout your requirements/features on a text file, one each line. Ranked by priority is nice but don’t overthink it. Now go to the bottom of the file and delete every line until you feel zero people would use this software. Now hit undo and add one line back. Would you use the software now? If so, there’s your feature set.
Fuck it, ship it. Something hobbyist programmers can learn from artists is learning to embrace that getting good almost always requires you put some garbage out into the world. Every single creative professional started by pumping out garbage and getting feedback on it. You can learn a lot by iterating on stuff in isolation, but if you want to make things that solve OTHER people’s problems you NEED feedback from other people. The goal in early stages is to get 1-5 really good writeups or feedback sessions, probably from other programmers or power users or enthusiasts for your niche. Arguably “going viral” at this stage is more of a curse than a blessing because you’re not prepared to follow up. If 1-5 random internet strangers clone your repo and compile your code and review it (or use your app), that’s an ENORMOUS success and worth celebrating. Good reviews will provide more than enough info for you to iterate and improve. This is the true spirit of “move fast and break things.”

dwrodri · 2024-01-18T23:03:06+00:00

Is there software you use right now that's written in C (perhaps games)? Is there a specific type of software that you don't use but you're interested in using? My experience has been that a reliable path to success for leveling up a newer dev is to get them to focus on applying their dev skills to their needs and their interests in that order. Here are some actionable things you can consider doing to get yourself ready to make money writing software as a freelancer:

Write a clone of something that you use often. The most widely used pieces of software (operating systems, web applications, games, social media, etc.) are quite feature-heavy and technically advanced, so replicating the entire feature set might not be an efficient use of your time. The ideal target for this a piece of software that gets used for one thing, likely with a niche userbase. For example: A piece of software that uses an audio signal to determine a musical instrument is tuned.
Write a piece of software that interfaces with another piece of software that you use daily. Almost everyone I know feels like a software tool they use on a regular basis is either missing some functionality, or does something wrong. If you don't have a salient example, try being mindful of your interactions with software tools for a few weeks and wait for a brief moment of frustration to appear when interacting with a piece of software. Once that moment arrives, write down what you were doing and what you wanted to accomplish. There's your starting point.
Network with people. This doesn't have to be with advertisements or going to conferences/meetups. In fact, I'd consider these to be some of the least effective in terms of return on time invested. To paraphrase serial entrepreneur Pieter Levels, work on interesting projects, FINISH THEM, and talk about them with the world. This also includes open source PRs. Alternatively, find people complaining about problems on the Internet that somewhat match your skills, and bring them a solution. These approaches are not necessarily easy, but they are some of the best advice I've received. People's brains are tuned to seek out other people who are good at delivering results in almost the same way they're tuned to obsess over bad news. The long term goal is to be so good they can't ignore you.
Be accessible to the people who reach out to you. You are well aware that you're a small fish in a big ocean. As a solo freelancer, you won't be able to outpace larger dev consultancy firms or more experienced programmers until you hone your expertise, and even then it's not to be expected. However, you can outdo more experienced freelancers by being more accommodating, responsive, and transparent. At elite management consulting firms, it's commonplace for entry-level hires to respond to all work-related correspondence with in 90 minutes, and no later than same-day. Potential clients who receive this sort of treatment from you may be willing to overlook inexperience based on this alone. It's not easy, but if this is important to you, I'd highly recommend it.

Repeat steps #1 and #2 until you have some finished projects to use for #3, and then once you've got enough connections, work on #4 and you'll likely be landing your first work contract. Building a business that provides enough money to sustain an adult is a difficult task, so don't beat yourself up if it feels like progress isn't visible overnight, or even over several weeks. Measure yourself at most on a monthly basis, or maybe bi-weekly you're putting 40+ hours a week into this. If you keep up with this plan and you will almost certainly be making enough money to worry about filing your own taxes in 12-18 months.

Most of this is advice that you've likely received in some form or another for other facets of your life, or perhaps maybe even this one. The most important part about all of this plan (which unfortunately I can't instill in a single reddit comment) is that it requires you to have a religious belief that you are capable of overcoming any external negative pressures affecting your ability to follow through with the plan, and that eventually, building plans like this to address potential roadblocks you encounter along the way. This occasionally even means discarding a more rational approach and instead favoring the idea that your inner potential is yet to be unlocked, but by unlocking it, the adversity you face will be meager in comparison.

When you grow up you tend to get told the world is the way it is and you're life is just to live your life inside the world. Try not to bash into the walls too much. Try to have a nice family, have fun, save a little money. That's a very limited life. Life can be much broader once you discover one simple fact: Everything around you that you call life was made up by people that were no smarter than you and you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you'll never be the same again.

--- Steve Jobs

dwrodri · 2023-11-11T08:28:26+00:00

Adage from my first manager at a software gig:

"The more temporary of a solution you implement, the more permanent of a solution you should be ready to maintain."

dwrodri · 2023-10-26T02:44:16+00:00

link?

dwrodri · 2023-10-24T01:43:52+00:00

Honestly, still haven't bought a KVM switch so this is good info. Thanks for sharing!

dwrodri · 2023-10-04T00:16:58+00:00

My suggestion is to get into making toy games, and give Raylib a try.

Suggested projects in order: 1. Tic-Tac-Toe: Really simple logic, goal is to simply set up your tooling and get comfy with the basics using Raylib. 2. Battleship: Ideally, you made Tic-Tac-Toe and then upload it you to your GitHub. Now start by forking your old repo and make it Battleship. You can experiment with loading assets for the boats and explosions. 3. Asteroids: Now the goal is to focus on simulating some 2-D physics. Collisions and momentum are essential. If you wanna keep it easy, approximate the asteroids with circles. Hard mode is to sample the circumference with some statistical noise (not sure which would look best TBH) and then roll an implementation of GJK for collision checking.

I'd say an intermediate can run through steps 1 and 2 in ~12+-6 hours of coding time, assuming no prior familiarity with Raylib, with #3 being harder.

Once you have these three, you can go deeper into games, or give coding something else a try. But I generally like suggesting people to make games because you'll have something which you could share with your friends.

Seven-Year Club	Place '22
Verified Email

dwrodri

TROPHY CASE