Hi, I’m Mark. By day, I work as a Senior Product Manager at Microsoft, working with technologies such as Microsoft Intune, PowerShell, and Microsoft Graph.
Outside of work, I am a developer hobbyist, PC gamer, "dad" to two sweet cats (Walter and Diddy Kong), comic book fan, home automation enthusiast, and husband.
In late 2022, I was working my day job when I received an email with a QR code I needed to read and access. No problem. The only issue was that I needed the QR code's contents on my PC, not my cell phone. I thought of two options to solve this:
Both of these options worked fine, but both had caveats. The first option took too many steps, and the second option was placing trust in a website/service I knew nothing about.
As a heavy PowerShell user, I had been wanting to learn Python for quite a while at this time, so I figured that this was a great opportunity to build a small tool that solves a problem AND could help me learn Python along the way. A few months of learning and tinkering with Python led to the release of my first open-source QR code app, QRDecoder.
QRDecoder was a simple tool that allowed you to take a screenshot of a QR code on your screen using the Windows Snipping Tool and view its contents without using your phone or a 3rd party website.
QRDecoder is no longer updated or under active development, but the app and source code can be found remains available on GitHub. It can be forked, referenced, and repurposed as needed under the MIT license.
After shipping a handful of QRDecoder updates, I quickly learned the Python was probably not the best tool for the job here. In short, Python scripts aren't designed to be easily packaged as Windows apps for distribution. They aren't packaged as a Windows "app", and they don't offer any built in UI frameworks out of the box.
It was possible but was prone to problems during the multi-step build process. At a high-level, the process came down to wrapping a python script (and required libraries) as an executable, and then using tooling to convert the exe to an MSIX app. Each layer of conversion adds more potential for incompatibilities, performance issues, or unintended behaviors.
Why didn't I just use the executable? Why did it need to be an MSIX app? The Microsoft Store automatically signs MSIX apps with a trusted developer certificate during the app verification process. Meaning that if I wanted to publish the app to the Microsoft Store for free, it needed to be an MSIX. My main takeaway was that Python is much more effective as a scripting language than for delivering an object-oriented, UX-driven Windows app.
This led to the decision to port QRDecoder to C# and .NET, with the goal being to provide a more "Windows-native" app experience for users (and for myself as the developer). After starting the port, I began thinking about more possibilities and features since a 1:1 port isn't super fun, like-
QRDecoder should read more barcodes than just QR codes.
QRDecoder be able to not just read, but also create barcodes QR codes.
QRdecoder should offer multiple tools for decoding QR codes.
Since this new application was now being built from the ground up and would support more than just QR codes, it would need a new name. I wanted something odd that rhymed, and a name that could directly translate into a URL. After ~15 minutes of brainstorming and trying to come up something unique, I landed on barcodrod.io (pronounced barcode rodeo 🤠).
*Note: I have never claimed to be a marketing or branding expert. Or web developer for that matter.
barcodrod.io was released in December 2022, and I have been actively supporting and adding new features since. Since then, it's been installed on thousands of PCs, and is used by people all over the world daily, spanning across 40+ different countries.
I hope you find barcodrod.io useful. If you run into any issues, want to suggest a feature, or discuss the app, feel free to visit the official barcodrod.io GitHub repository or send me an email.
QRDecoder and barcodrod.io