Radio station work


At the radio station, my job is to make sure audio programs are moved into on-air servers. Doing this manually would be inefficient because of the sheer quantity of files, and existing software isn’t customizable enough for my taste. I had run into a brick wall with my existing system of manually updating shell scripts for each download, with each file producing a separate run-log (generated by piping stdout and stderr to a file at runtime), and all this being managed using a bash prompt over ssh.

The first thing I did was create a unifying bash script called mp3dl which would execute the redundant actions given input pertaining to the program to be downloaded, the actions being: using wget/curl/ncftp, converting, copying to on-air server, updating the file’s modification time, and finally removing the temporary download file. Input varies from site to site, as not everyone uses the same file nomenclature, and not all programs get downloaded everyday. Once this was complete, I set it up to be called by many of my shell scripts. It got more comfortable than before, but I felt as though it was still nebulous.

Every executive/manager needs a dashboard/heads-up-display. There existed a heads-up-display, but only a limited dashboard, and by that I mean that, although I could see the file times, and move in files that had already been downloaded or ripped from CD, but I was not able to easily look at log files, query the program’s usual download times, or make changes to the program’s download information. A database solution seemed the only way to go forward from here, since the dynamic nature of the information would be horrendous to manage with plain-text files and local variables defined in scripts.

In the process of building the database, questions naturally arose, some of which had not been given much thought beforehand. This rendered the newer software even more valuable, with unanticipated features such as the system’s ability to determine when a program should be run based on cron-like syntax, eliminating the need to run “sudo crontab -e nobody” each time a change needed to be made to the program’s download schedule. It only made sense to proceed in PHP, because shell scripting quote-escaping syntax gets really tedious after a while, whereas in php commands can be issued simply by using a `backtick operator`.

The development of this project has also had the consequence of teaching me to develop more generic methods. Instead of hard-coding things, I’m using more variables, creating more functions, etc… This has the added benefit of giving me reusable code.

What I haven’t done so much is object-orienting the whole thing, although in a sense I have by creative use of object-structures and arrays. PHP doesn’t care if you cast an array as an object, or blatantly violate scoping by adding a new member-variable to an object. It’s like “hey, no problem man”. Not to get down on Perl, but I find PHP simpler for most things because I learned it earlier. I still think Perl is an amazing language, but I find its syntax and huge symbol-vocabulary a bit daunting.

Oh also, It’s worth mentioning:



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: