The short answer to the question posed in the headline: yes.
For the long answer, you have to do a little math. How much total time you will save by automating, over some reasonable horizon? It’s a simple product of how much time per occurrence, times how many times per day it happens, times the number of days in your horizon. Or skip out on the math because there’s an XKCD for that.
What’s fun about this table is that it’s kind of a Rorschach test that gives you insight into how much you suffer from automatitis. I always thought that Randall was trying to convince himself not to undertake (fun) automation projects, because that was my condition at the time. Looking at it from my current perspective, it’s a little bit shocking that something that’ll save you five seconds, five times a day, is worth spending twelve hours on. I’ve got some automating to do.
To whit: I use pass as my password manager because it’s ultimately flexible, simple, and failsafe. It stores passwords on my hard drive, and my backup server, encrypted with a GPG key that I have printed out on paper in a fireproof safe. Because I practice good cookie hygiene, I end up re-entering my passwords daily. Because I keep my passwords separate from my browser, that means entering username and password by cut-and-paste. There’s your five seconds, five times per day. Maybe two seconds, ten times, but it’s all the same. It shouldn’t take me even as long as twenty minutes to whip up a script that puts username and password into selection and clipboard for one-click pasting. Why haven’t I done this yet? I’m going to get on it as soon as I’m done with this newsletter.
But the this begs the question. If you spend up to twelve hours on every possible 25-second-per-day savings, when will you ever get your real work done? Again, math gives us the answer. One eight-hour workday * 25 seconds * 12 hours (pessimistically) of labor = 1.58 years before everything that needs automating will be. Next week’s newsletter might be a little bit delayed.
What do you see in the XKCD “Is it worth the time” table? Automate more, or step back from the cliff edge?
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
You’ve got a perfectly working software library to do just exactly what you want. Why aren’t you using it? Some of you are already yelling something about NIH syndrome or reinventing the wheel — I hear you. But at least sometimes, there’s a good enough reason to reinvent the wheel: let’s say you want to learn something.
Mike and I were talking about a cool hack on the podcast: a library that makes a floppy drive work with an Arduino, and even builds out a minimalistic DOS for it. The one thing that [David Hansel] didn’t do by himself was write the FAT library; he used the ever-popular FatFS by [Elm-ChaN]. Mike casually noted that he’s always wanted to write his own FAT library from scratch, just to learn how it works at the fundamental level, and I didn’t even bat an eyelash. Heck, if I had the time, I’d want to do that too!
Look around on Hackaday, and you’ll see tons of hacks where people reinvent the wheel. In this superb soundbar hack, [Michal] spends a while working on the IR protocol by hand until succumbing to the call of IRMP, a library that has it all done for you. But if you read his writeup, he’s not sad; he learned something about IR protocols. This I2C paper tape reader is nothing if not a reinvention of the I2C wheel, but isn’t that the best way to learn?
Yes it is. Think back to the last class you took. The teacher or professor certainly explained something to you in reasonable detail — that’s the job after all. And then you got some homework to do by yourself, and you did it, even though you were probably just going over the same stuff that the prof and countless others have gone through. But by doing it yourself, even though it was “reinventing the wheel”, you learned the material. And I’d wager that you wouldn’t have learned it without.
Of course, when the chips are down and the deadline is breathing hot down your neck, that might be the right time to just include that tried-and-true library. But if you really want to learn something yourself, you have every right to reinvent the wheel.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
The obvious rants against software or services “in the cloud” are that you don’t own it, your data isn’t on your own hard drive, or that, when the interwebs are down, you just can’t get your work done. But the one that really grinds my gears is that, at least for many cloud services, you just can’t play around with them. Why does that matter? Well, as a hacker type, of course, I like to fool around, but more deeply, I feel that this invitation to play around is what’s going to grow up the next generation of hackers. Openness matters not just for now, but also for the future.
Of course, it’s unfair to pin all of this on the cloud. There are plenty of services with nice open APIs that let you play around with their systems as much as you want — witness the abundance of amusing things you can do with Twitter or Twitch. Still, every day seems to bring another formerly-open API that gets bought up by some wealthy company and shut down. I built a nice “is it going to rain today” display out of a meter-long WS2812 strip and an ESP8266, but Dark Sky API got bought up by Apple and is going dark soon (tee-hee!) leaving me thinking of how I’m going to get easy weather data in the next few months.
Or take my e-mail annunciator. I wrote a little script that, when I have new mail that’s work related or from my wife (read: important), it displays the subject line on a VFD that I have perched on my monitor. This works with Gmail, which I have to use for work, because they support IMAP so at least I can do cool things with the mail once it reaches my server. But can I do anything with Google Groups, which we use for the Hackaday Tip Line? Fat chance!
So there’s good “cloud” and there’s bad “cloud”. Good cloud is open cloud. Good cloud invites you to play, to innovate, and to come up with the right solutions for yourself. Good cloud gives you access to your data. Good cloud is hackable cloud. Let’s see more of that.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
There’s a document I had to sign to wrap up a community responsibility in rural Oxfordshire. At the bottom, dotted lines for signature and date. My usual illegible scrawl for a signature, and scribble in the date below it. Then there’s the moment when the lady handling the form scans it with a puzzled face for a minute, before accepting it with a smile. She’s just been ISO’d!
Where I come from in England, it’s the norm to represent dates in ascending order: day, month, year. Thus the 4th of March 2021 becomes 04/03/2021 when written down on a form. This is entirely logical, and makes complete sense given the way a date is said aloud in English and other languages.
Meanwhile in America it’s the norm to represent dates in a different manner: month, day, year. Thus March 4th, 2021 becomes 03/04/2021 when written down on a form. This is also entirely logical, and makes complete sense given the way dates are pronounced in American English.
As someone whose job entails crossing the Atlantic in linguistic terms, I am frequently confused and caught out by this amusing quirk of being divided by a common language. Is 03/04/2021 the 3rd of April or March 4th? “Why can’t Americans use a logical date format!” I cry as in a distant transatlantic echo I hear my friends over there bemoaning our annoying European ways. It’s doubtful that this divergence has caused any satellites to crash, but it sure can be annoying.
Confusing Everyone For Over Three Decades
So I took a stand. A couple of decades ago I adopted ISO 8601 in writing dates, an international standard that’s been with us for well over three decades. It too is an entirely logical way to express time, but unlike the two mentioned earlier it’s not tied to any linguistic quirks. Instead it starts with the largest unit and expresses a date or time in descending order, and extends beyond dates into time. Thus the date on my form that caused the puzzlement was 2021-03-04. I’m guessing that here at Hackaday I’m preaching to the choir as I certainly won’t be the only one here using ISO 8601 in my daily life, but while we’re talking about alternative date formats within our community it’s an opportunity to take stock of the situation.
UNIX time is probably the most instantly recognisable of all our measurement schemes, being a count of seconds elapsed since the Unix epoch of 1970-01-01T00:00:00+00:00 UTC. Coincidentally this is also an auspicious date for many readers, as it’s our birthday. If I’d written the 4th of March on that form as 1614816000 though I would have been met with complete incomprehension, so aside from the occasional moment of coming together to observe a rollover it’s not something we use outside coding.
But it does lead neatly to another question: since UNIX time is most often expressed in text as a base-10 number, why on earth does our clock time work in base 60 for seconds, base 12 or 24 for hours, and then base 12 for months? Why don’t we use a base 10 metric time system?
It makes sense for our annual calendar and the length of our day to be derived from Earth’s orbit, as we use dates as a measure of season and times as a measure of the daily progress rather than simply elapsed periods. We owe our twelve-hour days and nights to the ancient Greeks and our 60 seconds and minutes to the ancient Babylonians, while our twelve months come from the ancient Romans. It’s clear that a 365.24-day year with four seasons doesn’t divide neatly into ten months, so we’re at the mercy of our own set of celestial bodies when talking about dates. But surely we could move on from ancient Greece and Babylon when it comes to the time of day?
Liberté, Égalité, Ponctualité!
Probably the most famous attempt at a decimal calendar came in the aftermath of the French Revolution; the French Republican calendar perhaps wisely stuck with twelve months but made each of them of three 10-day weeks, and then split the day by 10 hours, with each further subdivision being by base 10. The months each had 30 days, with the remaining 5 days (or 6 in leap years) being public holidays.
It came to an official end when the revolutionary government that had introduced it was replaced by that of Napoleon. Unlike other French Republican measurements such as the meter, it evidently didn’t provide enough advantage for its popularity to outlive its political origins.
There’s an interesting parallel in the decimalisation of British currency in 1971. Previously, a pound was 20 shillings, each of which were 12 pence. Afterwards, a pound became 100 new pence, and that’s stuck. Despite some people’s lingering nostalgia for the old system, the utility of decimialisation was self-evident.
The moral of the French time-decimalization story was that people simply use a calendar and time system to tell the date and time. When you need to do frequent arithmetic, as is the case with currency, distance, or weights, this is made significantly easier through decimals. But when nature hands you four seasons, you’re pressed into twelve months. Perhaps when we slip the bonds of Earth, we’ll use decimal Stardates, but in the mean-time, ISO might just be the way to go.
Thomas Edison famously quipped “To invent, you need a good imagination and a pile of junk.” Amen, brother. My personal junk pile (ahem, collection of pre-owned electromechanical curiosities) is certainly a source of spare parts, but also a source of surprise and wonder. Sometimes the junk itself spurs the imagination, but sometimes junk is just junk.
There are pieces of used gear that I bought for some particular plan, maybe a decade ago?, and totally forgot. While it’s fun to rediscover them — I bought six used super-soaker pump assemblies, and summer is just around the corner — the sad truth is often that the forgotten pieces were forgotten for a reason. Whatever kooky idea I had at the time has faded, and the parts are all that’s left.
But among these miserable creatures, there are some absolute gems. Parts that continually call out to be used. Bits that would fire even Thomas Edison’s imagination. Unforgetable junk.
Mostly, it’s their physicality that calls out to me. I have a stack of old 5″ hard drive platters, gutted, and converted into essentially a rotary encoder. For years, I used it as a USB scroll wheel on my desk, but most recently it has made reappearances in other goofy projects — a music box for my son that played notes in a row depending on how fast you spun it, and most recently a jog wheel for a one-meter linear motion project that hasn’t really found its full expression yet, but might become a camera slider. Anyway, when I needed a nice physical rotary encoder knob, the hard drive was just sitting there waiting to be used. Continue reading “Junkbox Confidential”→
We understand that SpaceX runs some contract missions for US gov’t agencies that don’t appreciate leaking info about their satellite’s whereabouts, but for non-secret missions, we don’t see the harm in letting the amateurs listen in over their shoulder. Maybe they’re doing it for PR reasons if/when something goes badly wrong?
Whatever the reasons, it’s a shame. Space has been open to hackers for a long time, knowingly in the case of amateur satellites, and unknowingly in the case of many other satellites which until the mid-90s had command channels that were unencrypted. (I’ll have to stick with “unnamed sources” on this one, but I do know a person who has rotated a satellite that he or she didn’t own.) There’s a lot to be learned by listening to signals from above, and while you can still decode weather satellite data yourself, it’s not quite as sexy as downloading images straight from a Falcon 9.
The cool hand for SpaceX to have played would have been to say “of course — we broadcast unencrypted as PR to our biggest fans” but it looks instead like they simply didn’t think that anyone would be listening in, and this caught them by surprise and they panicked. In 2021, with something as complicated as a space mission, that’s a little bit embarrassing. Anyway, to those of you who managed to get in before encryption, kudos!
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
I’m a firm believer in using the right tool for the job. And one of the most fantastic things about open-source software tools is that nothing stops you from trying them all. For instance, I’ve been going back and forth between a couple, maybe three, CAD/CAM tools over the past few weeks. They each have their strengths and weaknesses, and so if I’m doing a simpler job, I use the simpler software, because it’s quicker and, well, simpler. But I’ve got to cut it out, at least for a while, and I’ll tell you why.
The first of the packages is FreeCAD, and it’s an extremely capable piece of CAD/CAM software. It can do everything, or so it seems. But it’s got a long shallow learning curve, and I’m only about halfway up. I’m at the stage where I should be hammering out simple “hello world” parts for practice. I say, I should be.
Fortunately/unfortunately, some Hackaday readers introduced me to KrabzCAM through the comments. It’s significantly less feature-full than FreeCAD, but it gets the job of turning your wife’s sketches of bunnies into Easter decorations done in a jiffy. For simple stuff like that, it’s a nice simple tool, and is the perfect fit for 2D CAM jobs. It’s got some other nice features, and it handles laser engraving nicely as well. And that’s the problem.
Doing the simple stuff with KrabzCAM means that when I do finally turn back to FreeCAD, I’m working on a more challenging project — using techniques that I’m not necessarily up to speed on. So I’ll put the time in, but find myself still stumbling over the introductory “hello world” stuff like navigation and project setup.
I know — #first-world-hacker-problems. “Poor Elliot has access to too many useful tools, with strengths that make them fit different jobs!” And honestly, I’m stoked to have so many good options — that wasn’t the case five years ago. But in this case, using the right tool for the job is wrong for me learning the other tool.
On reflection, this is related to the never-try-anything-new-because-your-current-tools-work-just-fine problem. And the solution to that one is to simply bite the bullet and stick it out with FreeCAD until I get proficient. But KrabzCAM works so well for those small 2D jobs…
A hacker’s life is hard.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!