Today Google announced that the new Pixel 2 will pair with the famed Hitchhiker’s Guide to the Galaxy Babel fish. Dubbed Pixel Buds, Google’s new wireless headphones will translate up to 40 languages in real-time. While this blurring of science fiction and reality opens the door to remarkable multilingual possibilities, have you ever considered using a similar voice API to translate your own speech into code? I never would have dreamed this was a possibility, but I recently discovered a programmer who does exactly that.
Tavis Rudd, a Vancouver-based Director of Technology, demonstrates coding by voice in a 28 minute PyCon talk, now available on YouTube. Using text editor Emacs and DragonFly, an open-source Python-based speech recognition framework, and text editor emacs, Rudd overcame a hand injury that kept him away from the keyboard. He now spends about 50% of his time coding by voice, a split that should prevent recurrence of repetitive strain injuriy (RSI). It took Rudd about a month to learn, and it requires a revolutionary change in how you think about interacting with your IDE. RSI is a very real danger to those of who spend our days typing, however, and heading off a work-halting disability is worth the investment.
Check out Rudd’s demonstration for yourself while I go renew my passport and use my newfound polyglot powers.
On Friday, September 22nd, TDI founder Amanda Cinnamon spoke on the power of data visualization at “Seeing is Believing – a dialogue on using data to tell a story.” As part of the 4th Friday at 444 Speaker Series, she shared a spot with Jennie Hempstead of the Wright Brothers Institute. While Amanda focused on designing powerful graphics that illustrate the results of complex data analysis, Jennie spoke on live capture of ideas and conversations with graphical recording. The full proceedings can be viewed via the AFRL Facebook page at https://www.facebook.com/AFResearchLab/videos/1497541360282519/.
Back when I was a poor college student, I drove a car with the check engine light on. Now, I’m not saying that my check engine light came on, prompted a visit to the mechanic, and concluded with car repairs, as if it were a one-time event. This light was a permanent fixture of my beloved jalopy. You might be familiar with this type of “feature.” There must have been a time when the light wasn’t on, and I do remember taking it to AutoZone for a free OBDII readout, but once I discovered that the culprit was an “emissions error,” I decided that this little warning carried no meaningful information. I continued driving my trusty ride for years with no ill effects. I never thought twice about the light until a friend pointed out how the warning for a seemingly harmless, known error could mask a more sinister alert. Because the light was already on, I would have no indication of a new problem. Once the flaw in my logic was exposed, I decided it was time to pony up and get the repair. It turned out that the malfunction was not only affecting my emissions, but was also impacting my fuel economy and performance. If I had heeded the warning in the first place, I would have not only avoided unnecessary risk, but I also would have put a little gas money back in my pocket.
That car went to the scrap pile years ago, but I was reminded of that long-ago lesson in adulting today when I discovered a broken interpolation search algorithm. “But I have a test for that! How could this be?!” I exclaimed, to the coder who wanted to use my function. So I ran the test -not the test suite, but just the one single test. Sure enough – red light. That’s when it sank in that I had essentially been ignoring a check engine light for months. For quite a few of my tests, an exception was getting thrown from a destructor. However, because it only appears during testing, and only at teardown, I added it to my to do list, and kept driving the car. Meanwhile, the seemingly harmless, known error kept me from noticing the more serious problem with my algorithm.
It’s an easy mistake to make. We’re busy, deadlines loom, things need to get done. It can be tempting to gloss over compiler warnings, failed tests, or explainable exception errors. However, ignoring known problems, even the innocuous ones, is a bad practice. A better approach is to configure your compiler to treat warnings as errors, address failures as soon as possible, and catch your exceptions. If you take the time to deal with errors when they first appear, you will likely save yourself a real headache down the road, and you may happen to boost your performance in the meantime.