Finally, An Open Source Calculator

Microsoft has released the code for the Calculator app. This move is the latest in Microsoft’s efforts to capitalize on the Open Source community. Previous efforts have been the Open Sourcing of an extremely old version of DOS, and shoehorning Linux into Windows somehow in a way that’s marginally more user-friendly than spinning up a VM or popping over to your Linux partition. Oh yeah, Microsoft bought Github. Can’t forget that.

The release of the code for the Calculator app means now you too can truly verify all your calculations are correct. To build the Calculator app, you’ll need a Windows 10 computer and Visual Studio. You might think that this is the same code that’s been shipping for 30 years — it’s a simple calculator, right? Not so: the Calculator for Windows 8 had a strange and odd bug where the square root of 4, minus two, did not equal zero. Floating point is hard, kids.

Of special interest to the community, it’s now possible to disable telemetry sent from the Calculator app to Microsoft servers. Yes, the Calculator app knows you forgot how to divide, and wow man, six times nine, you needed help with that?  Fortunately, telemetry can be disabled in developer’s builds by disabling the SEND_TELEMETRY build flag. Now Microsoft won’t know you don’t do math so good.

At the time of this writing, we could not be bothered to contact Microsoft to find out when the pinball game or Ski Free will be updated and Open Sourced.

The Bakery That Runs On Emacs

When it comes to managing ingredients and baking at a professional bakery, we know that most people would turn to an SQL database and emacs.  Really, what else do you need? Okay, so maybe there are a few who would think that emacs couldn’t help you with this, so, here’s how [Piers] uses emacs and PostgresSQL to manage the day to day needs at his bakery.

[Piers] had tried a spreadsheet to keep track of things, but didn’t really like it when he had to create a new recipe:  “lots of tedious copying, pasting and repetition of formulae” is how he put it. As a ex-professional programmer, [Piers] was familiar with emacs and so set up a daily worksheet in emacs using org-mode. Each morning he runs org-capture to create the template for the day’s work. Some code in the org file (run with org-babel) can run a query on the database. He’s created some code to set up each day’s journal entry and to run the complicated database queries that he needs.

There is a list of things that [Piers] is working on next, including ingredient order management and accounting, but it works for him. And to stop any potential flame wars that might break out, it’s good to mention that the system does just that: It works for him. There are other possibilities. Take a look at Al’s Editor Wars article, or Elliot’s rebuttal, or, ignore the wars and read this article on baking with steam.

“Good Code Documents Itself” And Other Hilarious Jokes You Shouldn’t Tell Yourself

Code documentation — is there anything more exciting than spending your time writing extensive comments? If I had to guess, your answer is probably somewhere along the lines of “uhm, yes, everything is more exciting than that”. Plus, requesting to document your code is almost like an insult to your well thought out design, this beautiful creation you implemented so carefully that it just has to be obvious what is happening. Writing about it is just redundant, the code is all you need.

As a result, no matter if it’s some open source side project or professional software development, code documentation usually comes in two flavors: absent and useless. The dislike for documenting ones code seems universal among programmers of any field or language, no matter where in the world they are. And it’s understandable, after all, you’re in it for the coding, implementing all the fun stuff. If you wanted to tell stories, you would have chosen a different path in life.

This reluctance has even formed whole new paradigms and philosophies claiming how comments are actually harmful, and anyone trying to weasel their way out of it can now happily rehash all those claims. But, to exaggerate a bit, we’re essentially villainizing information this way. While it is true that comments can be counterproductive, it’s more the fundamental attitude towards them that causes the harm here.

In the end, code documentation is a lot like error handling, we are told early on how it’s important and necessary, but we fail to understand why and instead grow to resent doing it again for that same old teacher, supervisor, or annoying teammate. But just like error handling, we are the ones who can actually benefit the most from it — if done right. But in order to do it right, we need to face some harsh truths and start admitting that there is no such thing as self-documenting code, and maybe we simply don’t understand what we’re actually doing if we can’t manage to write a few words about it.

So let’s burst some bubbles!

Continue reading ““Good Code Documents Itself” And Other Hilarious Jokes You Shouldn’t Tell Yourself”

Zach Archer: Live Coding 500 Watts For ToorCamp

ToorCamp is a five-day open air tech camping event held every two years somewhere around the northwest corner of Washington state. Think of it as something like Burning Man, except you can survive for three hours without water, there aren’t a whole bunch of scenesters and Instagram celebs flying in on private planes, and everyone there can actually build something. Oh, and ToorCamp has delivery drones that will send you creme brulee. These mini creme brulees were probably made with the hot air gun hanging off a soldering station. Don’t worry, you’re getting fresh air that’ll balance out the heavy metal poisoning.

For last year’s ToorCamp, the biggest welcome sign was a 40-foot-long illuminated ToorCamp sign. This was designed, built and coded by Zach Archer, and he was at the 2018 Hackaday Superconference to give us the details on how he made it and how it was coded.

Continue reading “Zach Archer: Live Coding 500 Watts For ToorCamp”

Ludwig Promises Easy Machine Learning from Uber

Machine learning has brought an old idea — neural networks — to bear on a range of previously difficult problems such as handwriting and speech recognition. Better software and hardware has made it feasible to apply sophisticated machine learning algorithms that would have previously been only possible on giant supercomputers. However, there’s still a learning curve for developing both models and software to use these trained models. Uber — you know, the guys that drive you home when you’ve had a bit too much — have what they are calling a “code-free deep learning toolbox” named Ludwig. The promise is you can create, train, and use models to extract features from data without writing any code. You can find the project itself on

The toolbox is built over TensorFlow and they claim:

Ludwig is unique in its ability to help make deep learning easier to understand for non-experts and enable faster model improvement iteration cycles for experienced machine learning developers and researchers alike. By using Ludwig, experts and researchers can simplify the prototyping process and streamline data processing so that they can focus on developing deep learning architectures rather than data wrangling.

Continue reading “Ludwig Promises Easy Machine Learning from Uber”

Foundations For Machine Learning In English (Or Russian)

We are big fans of posts and videos that try to give you a gut-level intuition on technical topics. While [vas3k’s] post “Machine Learning for Everyone” fits the bill, we knew we’d like it from the opening sentences:

Machine Learning is like sex in high school. Everyone is talking about it, a few know what to do, and only your teacher is doing it.”

That sets the tone. What follows is a very comprehensive exposition of machine learning fundamentals. There is no focus on a particular tool, instead this is all the underpinnings. The original post was in Russian, but the English version is easy to read and doesn’t come off as a poor machine translation.

Continue reading “Foundations For Machine Learning In English (Or Russian)”

Supercon: Ruth Grace Wong and Firmware From the Firehose

Firmware and software are both just code, right? How different could the code that runs Internet-scale distributed web stuff be from the code that runs a tiny microcontroller brain inside a personal hydroponics device? Night and day!

Ruth Grace Wong works in the former world, but moonlights as a manufacturing engineer with some friends. Their product had pre-existing firmware that contained (at least) one bug, and Ruth’s job was to find it. The code in question was written by the Chinese PCB engineer, who knew the electronics intimately but who had no software background, providing Ruth an opportunity to jump head-first into the rawest of raw embedded programming. Spoiler alert: she found the bug and learned a lot about firmware along the way. This talk follows her along the adventure.

“The code is very well documented, in Chinese” but the variable names are insanely non-descriptive. Similarly, while the PCB engineer knows full well what a 24C02 is, if you’re a software geek that might as well be Chinese. As you’d expect, web searches came to the rescue on both fronts.

The bug ended up hiding in a logical flaw in the PWM-setting code inside an interrupt service routine, and it kept the fan from ever coming full on. Once found, it was easily fixed. But getting to the point where you understand the codebase deeply enough to know where to look is four-fifths of the battle. Heck, setting up the toolchain alone can take a day or two.

If you’re a fellow software type, Ruth’s talk (embedded below) will give you a quick glimpse into the outer few layers of the onion that is embedded firmware development, from a familiar viewpoint. Give her quick and value-packed talk a watch! Grizzled hardware veterans will nod along, and maybe even gain a little insight into how our code looks to “them”.

Continue reading “Supercon: Ruth Grace Wong and Firmware From the Firehose”