Favourite hammers
Posted: Mon Jan 23, 2012 3:13 pm
As in "... everything looks like a nail"
If you're anything like me, you have a couple of programming tools you use more often than most, or try to use over some other solution, because they're just that awesome.
Some linux-based ones to start you off:
Since I spend a fair amount of time writing scripts to co-ordinate starting/stopping processes, or rewriting someone else's script to make it a bit more generic and remove any magic, one of my favourites has to be dirname. Putting cd `dirname $0` at the top of your script means you suddenly don't have to worry about where you are when you run the script. You don't have to worry about "will it start in the right directory when I run it under cron?" It just works. Before I discovered this one, I had a giant case statement in base based on hostnames, to cd to the right location. Ugh.
The thing I try to find excuses to use more often, is inotify. Whenever we have a problem to solve that involves the filesystem, someone always decides the best way is to set up a job to run at some handwavy number of hours after the thing is supposed to have finished, and it'll all just work. Until that thing gets more complicated and you start having to move things around that you no longer understand six months later. And don't even get me started on trying to minimize periodic downtime when these things are involved. Inotify gives you an event "watch descriptor" and tells you when an event you have subscribed to happens on a directory. We recently had a task where we receive some daily data and need to copy it to another directory with a modified name, then synchronize that directory to a couple other servers. Of course, the "5 minute cron job" idea came out. Shortly after calming down, I discovered that someone has written inotifywait, an inotify interface for terminals, all packaged up in an RPM. Learning the interface, piping that into a while loop, getting the renames I needed to do on the files right, and running the rest of the logic sorted took a couple of hours from dev to running code.
Discuss
If you're anything like me, you have a couple of programming tools you use more often than most, or try to use over some other solution, because they're just that awesome.
Some linux-based ones to start you off:
Since I spend a fair amount of time writing scripts to co-ordinate starting/stopping processes, or rewriting someone else's script to make it a bit more generic and remove any magic, one of my favourites has to be dirname. Putting cd `dirname $0` at the top of your script means you suddenly don't have to worry about where you are when you run the script. You don't have to worry about "will it start in the right directory when I run it under cron?" It just works. Before I discovered this one, I had a giant case statement in base based on hostnames, to cd to the right location. Ugh.
The thing I try to find excuses to use more often, is inotify. Whenever we have a problem to solve that involves the filesystem, someone always decides the best way is to set up a job to run at some handwavy number of hours after the thing is supposed to have finished, and it'll all just work. Until that thing gets more complicated and you start having to move things around that you no longer understand six months later. And don't even get me started on trying to minimize periodic downtime when these things are involved. Inotify gives you an event "watch descriptor" and tells you when an event you have subscribed to happens on a directory. We recently had a task where we receive some daily data and need to copy it to another directory with a modified name, then synchronize that directory to a couple other servers. Of course, the "5 minute cron job" idea came out. Shortly after calming down, I discovered that someone has written inotifywait, an inotify interface for terminals, all packaged up in an RPM. Learning the interface, piping that into a while loop, getting the renames I needed to do on the files right, and running the rest of the logic sorted took a couple of hours from dev to running code.
Discuss
