Hacker News new | comments | show | ask | jobs | submit login

I'm the kind of nerd who greatly prefers writing automation code to doing anything remotely repetitive. (I'm afraid to work out the actual timings because I'm pretty sure that I often spend more time coming up with the automation than just doing the task would take).

I've got a script that automatically rips, converts and stitches together audiobooks from the library so that I can play them on my phone. It just beeps periodically to tell me to put the next CD in.

I also had a batch job that downloaded Doonesbury cartoons (including some delay logic so I wasn't hammering the server) and built a linked series of html pages by year and month. I've ported it to a couple of other webcomics so that I can binge read.

I also write a lot of LaTeX macros, doing things like automatically import and format code from a github gist into lecture notes (something like \includegist{C,<path/to/gist>), or autogenerate pretty PDF'd marks summaries for students from my home-rolled marks. database.

Another thing I like is building little toys to demonstrate things for students, like a Mathematica page that calculated the convergence rate and error for the trapezoidal rule (numerical integration) with some pretty diagrams.

I once wrote a bunch of lisp code to help with crypto puzzles (the ones that use a substitution code, and you try to figure out the original text). The code did things like identifying letter, digraph and trigraph frequencies, allowed you to test substitutions, etc.

As developers, we tend to focus on these big integrated projects. But one of the biggest advantages that people who can code have is the ability to quickly get a general purpose computer to assist with individual tasks. I write an awful lot of code that only gets run a handful of times, yet some of those projects were the most pleasure I've ever had writing code.

I go about automation in even less efficient way.

I spend many months doing repetitive tasks. And than I realize I should automate them, and proceed to spend hours coming up with scripts/tools to automate them.

Happens way too often...

There are some really clever people here, but as a general rule, you can't truly automate something until you can do it manually to the point where you're fully aware of all the snags and exceptions that may occur.

Once you reach that point, it then becomes a matter of trading-off how much time/money/effort it will take to automate the task against what benefit you get in return.

Agreed, but it's important to include one criterion in the trade-off calculation: I'd much rather be writing automation code than doing most automateable tasks (i.e. repetitive, simple decision tree). Even if I don't save any time, or even if it actually costs me a little time, I count it as a win. Especially since I often discover useful tools and techniques (holy smokes! Someone already wrote a parser for this weird thing I'm playing with!) that end up being valuable later in a completely unrelated project. True story: some colleagues wanted to integrate a departmental Moodle server with some bespoke scheduling software we were running. Turned I already had most of what we needed, because a year earlier I'd gotten irritated at hand-loading class lists into Moodle and hacked together a bunch of code to directly translate entities from one database to the other. I'd even generalized it into a bunch of types and tables that I didn't really need because OCD. All that 'hobby' code ended up being really valuable later.

I believe there is also merit in spending a lot of time repeatedly doing something, before proceeding to automate that workflow. Because only through that, you gain a deep understanding of 'edge/exception' cases which you can directly code into your script later on to manage.

Check out the ski rental problem, it will explain how much manual work to do before automation is right.

I tried googling for this and didn't find anything - do you have a link?

Sure thing.


[...] The ski rental problem is the name given to a class of problems in which there is a choice between continuing to pay a repeating cost or paying a one-time cost which eliminates or reduces the repeating cost. [...]

> I've ported it to a couple of other webcomics so that I can binge read.

Maybe this can save you some trouble:



Cool! Maybe you'll enjoy something such as Sikuli. It basically lets you automate the actions to take on your desktop or laptop visually. It's based on OpenCV and has a simple interface to use.

At least in the US, the Overdrive app for android let's you rent audiobooks from the library so you can play on your phone. No need to rip or convert.

Yes, and I use it quite a lot. My local library system, however, has a huge collection of CD audiobooks, many of which aren't available (at least in Canada) on Overdrive or Hoopla. I run my script in a window when I'm working on other things so it's trivial to just feed the disk monster. The audiobook then just shows ip in my Dripbox, ready to play.

Just a PSA for anyone who happens across this: There are some apps for Android that understand and play multi-file audiobooks just fine. I use Smart Audiobook Player and it works great.

I'd be really interested in that audiobook script. I have some that are ripped but not stitched together. I want to get to the point where all my audiobooks are one file.

I usually do one file per CD. You can usually just cat .mp3 files together, although some apps that expect non-standard metadata can get confused (mp3wrap is a more robust solution). 'cat *.mp3 > disk.mp3' (assuming that ls order is the order you want. Or 'cat first.mp3 second.mp3 last.mp3 > all.mp3') Other formats (like m4a) can be stitched together using utilities like ffmpeg.

Please share them macros, that would be gold

>(I'm afraid to work out the actual timings because I'm pretty sure that I often spend more time coming up with the automation than just doing the task would take).

You can use this calculator to estimate how much time is worth investing in automating a particular task =)


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact