| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||
It’s been a while since I announced a release of randomplay, my command-line ‘itch a scratch’ music player. It is most useful for maintaining a random shuffle over many sessions—for example, I use it to make sure I don’t ever hear the same song in any three month period.
This new version features the much sought ‘back a song’ keybinding. It also announces the “random weight” preference of the current song as it plays.
A couple of weeks, I blogged about trying to create some babysitting coop software and “doing it right.” Despite knowing that I’d benefit from the discipline imposed by Python, I ended up coding it in perl and staying in my comfort zone. Still, it’s a lot less screwy than past things I’ve done.
It’s definitely not ready for prime time—barely tested at all; probably buggy; not feature complete; and not nearly secure enough. But I thought I’d announce it so it can start entering search engine indices. The past blog entry is already a #2 google result for babysitting coop software. (Apparently there is very little competition in this niche).
So. Announcing BabyOp: Software for Babysitting Coops.
I’m coding a new CGI application, tentatively entitled BabyOp. It is software to run a babysitting coop; I suppose it is a species of “social software.” The idea is to be able to track hours credits, schedule babysitting times, centralize contact information and other details about babysitting requirements.
I considered using something like Zope or Drupal for the application, but I’ve never liked developing exclusively through a web-interface and found myself having to do a fair bit of “actual” coding to get the results I wanted. I realize there is a command-line interface for Zope, but it’s really pretty limited. I had some plans a couple of years ago when I designed my wedding site in Zope to extend it to be more useful, but sadly never got around to it.
So I’m back in my comfort zone, perl. I’ve written a fair amount of unmanageable perl code, however, CoopOrder probably being a shining example (it was also my first perl program). I’ve certainly improved since then, and the fact that I’ve received several patches from others for randomplay suggests that my coding style is getting to a half-decent point.
I’d really like to get it right this time, though. One thing I’ve learned over the years is always to look for a module to do what you want before setting out to do it yourself, since chances are the module writer is a better coder than you (or at least, than me!). To that end, I’m using CGI::Application, HTML::Template, and DBIx::Abstract, among others. I’m also trying to keep things really granular and avoiding long subroutines. Certainly taking the HTML out of the perl code helps with that. I’m amazed at how often my code now just “works” on the first try, similar to esr’s story about his first look at Python (“Brace yourself: this code only took me about ninety minutes to write—and it worked correctly the first time I ran it.”)
I’m trying to figure out if it would be sensible to make this application more fully object oriented. Growing up in the ’70s and ’80s and having done a lot of database programming, I’ve always been unfortunately pathologically declarative. (My first major package was in Clipper—I was 13 years old). I find it a lot easier to modify a pre-existing object oriented package than to design my own.
But then again, does it really make sense to attempt an object-oriented design where there is really only one important “object” — in this case, the babysitting unit?
I know I said I was swamped until December, but there’s always a few minutes to release a new version of a package, right? It’s kind of like dessert—there’s always room.
I’ve released randomplay 0.49.
The new version adds a keystroke to pause playing and a keystroke to display the available keystrokes, and the ability to configure UTF-8 display of tags on or off.
I’ve also improved the documentation and filled in the sample rc file to give all available options.
By the way, Clint Adams, I would be happy to add Audioscrobbler support. Unfortunately, there is not yet any Net::AudioScrobbler perl module. I contacted the guy who is working on it and he said it’s not yet fit for public consumption, but will let me know when it is.
Randomplay is a command-line based shuffle music player that remembers songs between sessions.Randomplay plays your music collection (or execute any arbitrary commands on any arbitrary filetypes) in random order, remembering songs played across sessions. It also has many features to make command-line music playing more convenient, including recursive regexp searching for tracks and the ability to specify a certain number of tracks, bytes, or minutes to play. Randomplay will also generate a list of music files to be loaded onto a portable music player device. It includes a ‘random weighting’ feature, so your favorite songs are more likely to come up in the random shuffle.Randomplay is a convenient tool for the user who does everything in an xterm window or console and is constantly devising complex find/grep/sed command lines to play just the right set of songs.
Following are some example invocations of randomplay to give a general sense of its flexibility; see the manpage for more complete information:
Play all ogg files in dir1 and dir2 under your home directory, and dir3 under the base directory specified in ~/.randomplayrc, which have not been played for 15 days in random order with 5 seconds between songs:
randomplay --days=15 --pause=5 --player ogg=ogg123 ~/dir1 ~/dir2 =dir3
Play all ogg, wav, and mp3 files under the current directory (or base directory, if specified in .randomplayrc file) which have not been played for 10 days in alphabetical order, switch the ‘skip to next song’ keystroke to ‘G’ or ‘g’ and ‘quit’ to ‘q’ or ‘c’:
randomplay --norandom --key next=Gg --key quit=qc
Play all files under the current directory with the strings “frisell†and “bill†in the filename, in any order, (saves having to hunt down a file in a hierarchy), ignore whether the file has been played recently, but stop playing after 15 minutes:
randomplay --regexp 'frisell bill' -0 --maxtime=15m
Display 100M worth of music files, randomly sorted, without recording the history of tracks, using the default music directory (or the current directory if not specified):
randomplay --maxsize=100M --noremember --names-only
Play the last 10 songs played over again:
randomplay --last=10
Play songs test.ogg, test2.ogg, test3.ogg, and all files in musicdir in random order without weighting preferred songs:
randomplay --noweight test.ogg test2.ogg test3.ogg musicdir
Copy 128M of songs into a Neuros Audio Player, using positron:
positron add `randomplay --names-only --maxsize=128M`
Pick a random jpeg or png file that has not been displayed in the last week from the ‘images’ directory and display it with ImageMagick ‘display’ command:
randomplay --player jpg=display --player gif=display --days 7 ~/images
randomplay is listed on freshmeat.net.
You can download randomplay as a Debian package, or get it directly from the Debian archive.
You can take a look at randomplay, the main script, with nice highlighting, also see the changelog.
I’ve released randomplay 0.48. randomplay is my command-line ‘itch a scratch’ music player. It is most useful for maintaining a random shuffle over many sessions—for example, I use it to make sure I don’t ever hear the same song in any three month period.
The new version fixes a bug that prevented randomplay from advancing to the next track when the player subprocess itself spawned a child process (e.g., with ‘play’ which spawns ‘sox’). I use a bit of a hack to kill the child task and it’s children, but the standard way of doing this in perl—kill HUP => -$$ doesn’t seem to work when randomplay is called from a shell script and the child process’ output is redirected to null. Here’s the code in question (with the fix to kill children and grandchildren recursively):
# KillAll recursively kills the request process ID and all of its children/grandchildren/etc. # This is a bit of a hack--there should be a better way to do this, but I haven't found one. # Normally, kill HUP => -$$ should do the job, except this doesn't work when randomplay itself # is called from a shell script and all output from child processes is redirected to null. # This subroutine assumes that shelling out to ps is going to work, which may not be totally # safe--at the very least, it reduces the portability of the script. # Any suggestions for a better way to do this are welcome. sub KillAll { my $pid = shift; local $SIG{HUP} = 'IGNORE'; # don't want to kill ourselves here--shouldn't happen, but just in case. if (open PS, "ps -o pid,ppid |") { eof PS; # Force ps to run now. Otherwise it would run at the first read operation. kill HUP => $pid; foreach my $line () { KillAll($1) if ($line =~ /^\s*(\d+)\s*(\d+)\s*$/ and ($2 eq $pid)); } close PS; } else { # if we can't read the process table, just try killing the child process group kill HUP => -$$; } }
Thanks to Christopher Zimmermann for the patch to kill children recursively.
The latest version of salonify allows the web user to download each entire photo album as a ZIP file; also has better error/sanity checking and reorganized documentation.
A couple of annoyances that have appeared with recent upgrades—any suggestions? A quick scan of debian-user archives suggest others have similar problems but I haven’t seen a clear solution:
I’ve released randomplay 0.47. randomplay is my command-line ‘itch a scratch’ music player. It is most useful for maintaining a random shuffle over many sessions—for example, I use it to make sure I don’t ever hear the same song in any three month period.
The new version announces the current track and artist using xosd, if you have it installed. See this screenshot to see the effect (see lower right hand corner).
If you’re using the ssh_login_blocker script I posted on Monday, please upgrade to the current version. I actually posted an old version by accident. The primary differences are that the current version works even when your auth.log file is rotated, and the “bad username” and “bad password” checks both reset after an arbitrary time period (by default 5 minutes). If you don’t have this “reset time” set, ten bad passwords over a week could lock you out.
Sorry for posting the wrong version before!
