I am thinking of it as a message from the writer to the user, and doing so gives me a little chuckle as I remember there is a human on the other side of the code that makes my server run.
It's funny, the first time, maybe. But if you use software all the time then such 'funnyness' becomes irritating. I'm trying to imagine working hard on trying to solve some issue for someone, mistyping a command and getting crap like that thrown back at me. Imagine all your software would return its errors laced with profanity.
If you write code for yourself then that's one thing, as soon as you write code for potential distribution to a large audience (cron is present on just about any unix machine) then I think you should restrain yourself from trying to be funny (or at a minimum from having your software by proxy call people names).
Call me old fashioned, it just doesn't work for me.
(Jobber author here.) It's...interesting that this is the aspect that has gotten the most discussion so far. But thank you, jacquesm et al., for your feedback. I certainly don't want this to turn people away from Jobber, so I'll change it. Computers are frustrating enough; we don't need to add more aggravation!
On the other hand, IMO, the biggest profanity you can put in an error message is an error code and nothing more. Now THAT is how to mistreat your users!
Yeah, I'm with you on that TBH. There's nothing like a good bit of condescension from a developer to really win over their users. It was sad a few decades ago, and it's still sad now.
I suspect we are going to see some upheaval in core services in the coming years...I'll be curious to see if systemd.timer takes the place of cron or if something else does. There is a good argument to be made for at least updating cron.
Best of luck on your startup! It looks like your goals for Ikura are more ambitious than mine for Jobber --- e.g., Jobber doesn't spawn multiple instances of a job like Ikura does.
Congrats on shipping. Looks interesting - great idea to replace 'cron' itself with a better implementation.
(Shameless plug) - for those people that have to stick with cron (and cant switch to Jobber) and need status report and error handling I have a SaaS that handles this. See my bio for details.
This looks very cool. Congrats on shipping. As a non-developer, (honest question) how does this compare to Airbnb's Chronos? I noticed you used Golang, and I'm guessing they have a better frontend. They taut "managed distributed solution". Any other differences?
Thanks for the congrats! Actually, it's not shipping quite yet --- it's still in beta.
Jobber is really just cron + support for error-recovery strategies like exponential backoff + support for getting the job execution history. It is very simple to deploy: it consists of just two (native) binaries, and has no dependencies (well, other than Bash).
Chronos also supports these additional features (although I don't know about exponential backoff), but Chronos is much more ambitious than Jobber. Probably the biggest differences are that Chronos supports farming jobs out to other nodes and that it supports dependencies between jobs. And of course Chronos has a nice GUI. On the other hand, I imagine it's a bigger deal to deploy, although I haven't done so myself.
So, if you have a bunch of related jobs that need to run on multiple nodes, Chronos would probably be best. Otherwise, try Jobber!
"When discussing jobs, by “job error” we mean the failure of a particular run of a job, whereas by “job failure” we mean a job that jobber has decided not to schedule anymore due to one or more recent job errors."
The "do one simple thing and do it well" principle worked best for the simple needs of late '70s OSes.
In 2014 it ends up with MORE (not LESS) complexity, built on top of those simple tools to coordinate them to do anything useful. And of course they're not even that smart in how they work together...
Like "make" has grown configure and autoconf and all that cruft (because we "kept it simple").
Cron already covers all my job scheduling needs, yes. You can do all the "recover thing" in the scripts called by cron, without the need of complicating 99% of cases that don't need such complication. "Keep it simple, stupid" is still valid for 2015, in my opinion.
About your off-topic comment: autoconf/automake adds crazy complexity. I avoid it as much as possible, using just Make (it allows you context detection and lots of conditional handling, without complicating things).
autoconf is insane. Just write your own configure script... Keeping it simple does not need to cause abominations like autoconf. I was glad to see the new ntimed project is not using it. Here's a comment from the custom configure script:
# Handwritten configure script.
# =============================
#
# Before you suggest I use tools for this, please read:
#
# https://www.varnishcache.org/docs/trunk/phk/autocrap.html
# and
# http://queue.acm.org/detail.cfm?id=2349257
#
No thanks.