Author: Sven Gregori

143 Articles

Telephone Plays The Songs Of Its People

April 12, 2019 by 4 Comments

Music, food, and coding style have one thing in common: we all have our own preferences. On the other hand, there are arguably more people on this planet than there are varieties in any one of those categories, so we rarely fail to find like-minded folks sharing at least some of our taste. Well, in case your idea of a good time is calling a service hotline for some exquisite tunes, [Fuzzy Wobble] and his hold music jukebox, appropriately built into a telephone, is just your guy.

Built around an Arduino with an Adafruit Music Maker shield, [Fuzzy Wobble] uses the telephone’s keypad as input for selecting one of the predefined songs to play, and replaced the phone’s bell with a little speaker to turn it into a jukebox. For a more genuine experience, the audio is of course also routed to the handset, although the true hold music connoisseur might feel disappointed about the wide frequency range and lack of distortion the MP3s used in his example provide. Jokes aside, projects like these are a great reminder that often times, the journey really is the reward, and the end result doesn’t necessarily have to make sense for anyone to enjoy what you’re doing.

As these old-fashioned phones gradually disappear from our lives, and even the whole concept of landline telephony is virtually extinct in some parts of the world already, we can expect to see more and more new purposes for them. Case in point, this scavenger hunt puzzle solving device, or the rotary phone turned virtual assistant.

Continue reading “Telephone Plays The Songs Of Its People” →

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

March 5, 2019 by 159 Comments

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” →

Never Mind The Sheet Music, Here’s Spreadsheet Music

February 2, 2019 by 7 Comments

Nothing says Rockstar Musician Lifestyle like spreadsheet software. Okay, we might have mixed up the word order a bit in that sentence, but there’s always Python to add some truth to it. After all, if we look at the basic concept of MIDI sequencers, we essentially have a row of time-interval steps, and depending on the user interface, either virtual or actual columns of pitches or individual instruments. From a purely technical point of view, spreadsheets and the like would do just fine here.

Amused by that idea, [Maxime] wrote a Python sequencer that processes CSV files that works with both hardware and software MIDI synthesizers. Being Python, most of the details are implemented in external modules, which makes the code rather compact and easy to follow, considering it supports both drums and melody tracks in the most common scales. If you want to give it a try, all you need is the python-rtmidi and mido module, and you should be good to go.

However, if spreadsheets aren’t your thing, [Maxime] has also a browser-based sequencer project with integrated synthesizer ongoing, with a previous version of it also available on GitHub. And in case software simply doesn’t work out for you here, and you prefer a more hands-on experience, don’t worry, MIDI sequencers seem like an unfailing resource for inspiration — whether they’re built into an ancient cash register, are made entirely out of wood, or are built from just everything.

Continue reading “Never Mind The Sheet Music, Here’s Spreadsheet Music” →

Crash Your Code – Lessons Learned From Debugging Things That Should Never Happen™

January 22, 2019 by 58 Comments

Let’s be honest, no one likes to see their program crash. It’s a clear sign that something is wrong with our code, and that’s a truth we don’t like to see. We try our best to avoid such a situation, and we’ve seen how compiler warnings and other static code analysis tools can help us to detect and prevent possible flaws in our code, which could otherwise lead to its demise. But what if I told you that crashing your program is actually a great way to improve its overall quality? Now, this obviously sounds a bit counterintuitive, after all we are talking about preventing our code from misbehaving, so why would we want to purposely break it?

Wandering around in an environment of ones and zeroes makes it easy to forget that reality is usually a lot less black and white. Yes, a program crash is bad — it hurts the ego, makes us look bad, and most of all, it is simply annoying. But is it really the worst that could happen? What if, say, some bad pointer handling doesn’t cause an instant segmentation fault, but instead happily introduces some garbage data to the system, widely opening the gates to virtually any outcome imaginable, from minor glitches to severe security vulnerabilities. Is this really a better option? And it doesn’t have to be pointers, or anything of C’s shortcomings in particular, we can end up with invalid data and unforeseen scenarios in virtually any language.

It doesn’t matter how often we hear that every piece of software is too complex to ever fully understand it, or how everything that can go wrong will go wrong. We are fully aware of all the wisdom and cliches, and completely ignore them or weasel our way out of it every time we put a /* this should never happen */ comment in our code.

So today, we are going to look into our options to deal with such unanticipated situations, how we can utilize a deliberate crash to improve our code in the future, and why the average error message is mostly useless.

Continue reading “Crash Your Code – Lessons Learned From Debugging Things That Should Never Happen™” →

A Page-Turner On Kindle – One Step At A Time

January 2, 2019 by 6 Comments

You don’t have to be an avid bookworm to find use for an e-book reader. Take your local wedding band for example: with a big repertoire of songs to cover, you don’t really want to drag huge folders full of chords and lyrics around, tediously browsing through them to find the correct one for every new song. Even the biggest tree corpse enthusiast cannot deny the comfort of an e-book reader here. And since turning the page boils down to simply changing the content on a display, you don’t necessarily need to use your hands for that either. With that in mind, [mosivers] built a WiFi foot switch for his musician brother’s Kindle to flip backwards and forwards through the pages.

After jailbreaking the Kindle and installing busybox, [mosivers] set up a web server to serve two CGI scripts that write the previously recorded input events for forward and backward flipping respectively to /dev/input/event0, essentially simulating a touch screen press that way. The foot switch, as counterpart, houses a battery-powered ESP8266, acting as access point for the Kindle to connect to, and requesting those page flipping CGI scripts whenever one of its two buttons is pressed.

If you don’t like the idea of jailbreaking your device in order to change the pages without using your hands, you could of course consider combining a more mechanical solution with the foot switch concept. And in case you want to see more of [mosivers], have a look at his DIY talk box project we’ve covered earlier.

35C3: Safe And Secure Drivers In High-Level Languages

December 31, 2018 by 12 Comments

Writing device drivers is always a good start for a journey into the Linux kernel code. Of course, the kernel is a highly complex piece of software, and if you mess up your code properly, you might take down the entire system with you. User-space drivers on the other hand might not look as good on your CV, but they can help to work around some of the dangers and complexity of the kernel space. Plus, you don’t necessarily have to limit yourself to C to write them, especially if you are concerned about the usual C pitfalls and the security issues they can lead to.

With that in mind, [Paul Emmerich] is researching the concept of Linux user-space drivers for Intel’s 10Gbit network cards using other high-level languages, and recruits his students to write their final theses about the implementation details of as many languages as possible.

At last year’s 34c3, [Paul] already demonstrated the basics of writing such a user-space network driver for Linux, which serves now as reference implementation for his students. We won’t see Bash or JavaScript here, but we will see a brief summary of what it generally means to develop user-space drivers in C#, Swift, OCaml, or Haskell, along a more detailed insight from [Sebastian Voit] and [Simon Ellmann] about Go and Rust. A collection of each language’s implementation can be found on GitHub.

Since some of these languages bring their own memory handling and perform unpredictable garbage collection, performance and latency are two big topics to cover here. But then, the general concept is language-independent, so even if nothing in the world could ever make you give up on C, you might at least take away some new ideas for driver development.
Continue reading “35C3: Safe And Secure Drivers In High-Level Languages” →

Warnings On Steroids – Static Code Analysis Tools

December 12, 2018 by 11 Comments

A little while back, we were talking about utilizing compiler warnings as first step to make our C code less error-prone and increase its general stability and quality. We know now that the C compiler itself can help us here, but we also saw that there’s a limit to it. While it warns us about the most obvious mistakes and suspicious code constructs, it will leave us hanging when things get a bit more complex.

But once again, that doesn’t mean compiler warnings are useless, we simply need to see them for what they are: a first step. So today we are going to take the next step, and have a look at some other common static code analysis tools that can give us more insight about our code.

You may think that voluntarily choosing C as primary language in this day and age might seem nostalgic or anachronistic, but preach and oxidate all you want: C won’t be going anywhere. So let’s make use of the tools we have available that help us write better code, and to defy the pitfalls C is infamous for. And the general concept of static code analysis is universal. After all, many times a bug or other issue isn’t necessarily caused by the language, but rather some general flaw in the code’s logic.

Continue reading “Warnings On Steroids – Static Code Analysis Tools” →