Downtime...

As some of you may have noticed, my Web host is having brain farts all over the place lately. None of my sites are very usable thanks to the poor quality of service and support on the part of my host right now. The problems seem to have begun around noon on Friday, September 19th. The symptoms include random HTTP 500 (internal server error) messages or extremely long load times.

I'm in the process of switching to a host that is more reliable. This new host is perhaps one of the best in the industry according to all of the reviews that I've read. Let's hope I have better luck there.

Make Your Own iPod-Compatible Audio Books Using Linux

I like music a lot. I think I always have, and I probably always will. I like to be able to listen to good music wherever I go whenever I want. Thanks to the wonders of technology, we have a myriad of portable media devices to choose from. I personally chose an iPod nano. It's a wonderful little toy.

Anyway, as much as I like music, sometimes I feel that my time could be better used doing things more productive than just listening to music. Once I realized I felt this way, I began looking into ways to get my audio books onto my iPod. At first I simply transfered over the MP3s that came straight from the CDs. But I soon realized that this wasn't the most effective use of the iPod's audio book capabilities. So the hunt was on for some good Windows software to convert my MP3 audio books into M4B format for the iPod.

Now, I'm a pretty cheap guy when it comes to paying for software (which is probably one of the main reasons I started using Linux way back when). I found a bunch of different "free" tools that claimed to be able to convert my MP3's, but few of them actually worked well enough for me to stand using them. Eventually, I found a (very round-about) routine that allowed me to turn everything into something my iPod could understand as an audio book. I followed this routine to convert several audio books and transfer them to my iPod. I never actually finished listening to any of them completely.

Last night I started fooling around with converting my DVDs into a format my iPod could understand. When I finally got The Bourne Identity converted properly, I tried to throw it onto my iPod from my wife's Mac. It told me that I would have to erase everything (because I used my own PC to transfer my files before), and I said it was ok. I didn't have any of my original .m4b files around anymore, and so I began looking for ways of creating those audio books (in Linux this time).

It wasn't long before I stumbled upon a particularly interesting post on this exact topic. It requires the use of mp3wrap, mplayer, and faac. Pretty simple, really. Here's what you do:

# mp3wrap outputfilename *.mp3
# mplayer -vc null -vo null -ao pcm:nowaveheader:fast:file=outputfilename.pcm outputfilename_MP3WRAP.mp3
# faac -R 44100 -B 16 -C 2 -X -w -q 80 --artist "author" --album "title" --title "title" --track "1" --genre "Spoken Word" --year "year" -o outputfilename.m4b outputfilename.pcm

Nice and easy, huh? Now to decipher it all.

# mp3wrap outputfilename *.mp3

This command will stitch a bunch of MP3 files into a single MP3. This makes it easier to have a "real" audio book on your iPod.

# mplayer -vc null -vo null -ao pcm:nowaveheader:fast:file=outputfilename.pcm outputfilename_MP3WRAP.mp3

This command converts that one big MP3 file to PCM (uncompressed) format. Somewhere in the output of this command, you will see something like AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample) which comes in handy for the next command:

# faac -R 44100 -B 16 -C 2 -X -w -q 80 --artist "author" --album "title" --title "title" --track "1" --genre "Spoken Word" --year "year" -o outputfilename.m4b outputfilename.pcm

Finally, this command turns the PCM file into an audio book (m4b) file. The 44100, 16, and 2 right after faac all come from that special line in the output of the mplayer command.

As much as I like the command line, I don't like having to remember all of those parameters and options. So I decided to create a utility script (written in Python, of course) to wrap all of these commands into one simple one:

# mp3s2m4b.py BookName mp3s_directory [--quality=0..100] [--artist="artist"] [--album="album"] [--title="title"] [--genre="genre"] [--year=year] [--track=number]

While this might still seem too complex for pleasure, it does reduce a lot of the typing involved with the other three commands. All of the thingies in square brackets (like [--quality=0..100]) are optional. My script runs the commands mentioned previously in order, and suppresses all of the scary output.

I've used my script 4 or 5 different times so far, and it seems to work great. You may download it here.

Sad Day for Religious Nerds

I recently decided it would be prudent for me to request permission from the Church of Jesus Christ of Latter-day Saints to redistribute a copy of the scriptures with the PyScriptures program that I have been working on recently. I didn't want to be held liable for any copyright infringement or other legal violations. So I decided to contact them a couple of weeks ago. Here is my message requesting permission:

To whom it may concern:

I would like to request permission to redistribute and use a database which contains the LDS standard works (scriptures only, not the bible dictionary, topical guide, or even footnotes). One of my personal projects relies upon a local copy of the scriptures in order to be useful at all, and I would like people to be able to use this program without fear of any sort of copyright infringement charges to any party. The goal of the program is to offer users of platforms other than Microsoft Windows a way to peruse and study the scriptures without requiring an Internet connection. I have tested it on Windows XP, Linux, and MacOS X and it works great. There are still some parts that need some work, and things could probably be optimized a bit, but works well enough considering that I've only been working on it for about a week and a half.

To learn more about this project, please go to http://code.google.com/p/pyscriptures/ where you can even browse the Python source code for my application (though you might want to do so on an empty stomach). The database is called 'scriptures.db' (http://code.google.com/p/pyscriptures/source/browse/trunk/pyscriptures/scriptures.db) and was created using SQLite in case you are interested in examining and verifying its contents. One of my main reasons for creating this database is that I noticed the database that The Mormon Documentation Project offers is missing some things, particularly all of the answers in Section 77 of the Doctrine and Covenants. I didn't want to find out what else was missing or modified. Perhaps the reason those answers are missing is because that's part of the conditions of redistributing the scriptures?

Please notify me as soon as possible if there are any objections to the use and redistribution of this database. If that is the case, I will delete this project immediately. However, if I may be granted permission to redistribute the database containing the unmodified scriptures, I would greatly appreciate a response which states what my rights are in this matter.

Thank you for your time! Have a wonderful day.

Sincerely,

Josh VanderLinden

Developer

I got my reply today:

Dear Josh VanderLinden:

Thank you for your email dated 9 June 2008 requesting permission to use a database containing the LDS Standard works to redistribute.

After reviewing your request we have determined that we must deny your request for the use of this material. Church policy does not allow its intellectual properties to be used as you are requesting.

We appreciate your intentions, but trust you will understand and support the decision of the Church in this matter.

Thank you for checking with us.

Bobbie Reynolds, Paralegal

Intellectual Property Office

Somehow I could see this coming. I was curious, however, to determine if there was a way I could avoid litigation by modifying the way the program operates. So I responded with this message:

Hello Bobbie,

Thank you for your reply. I'm sorry that the verdict was not in my favor, but I do understand completely. Otherwise, I wouldn't have asked in the first place. Before I remove the project from the Internet, I would like to ask one more question. Is there a way I could somehow make the program legal? I've noticed that other some programs for the scriptures don't exactly redistribute the scriptures with the program itself. Instead they seem to download the scriptures from scriptures.lds.org (or elsewhere?) on an individual level, and the individual who runs the program has to specifically tell the program to do so. Would that be a more appropriate route for my project to take? Or would that also violate the rules?

Thanks again,

Josh VanderLinden

After only a few hours, I received the following reply:

If I understand you correctly, this also sounds like a reformatting project, which is restricted. Thank you for requesting further clarification and for your compliance to Church policy.

Bobbie

So it looks like I will have to discontinue this project, or at least not allow other people to use my work and keep it all to myself. In compliance with the message communicated to me by the legal representatives of the Church, I have removed the project from Google Code, and it shall remain a project for my own purposes. My apologies go out to everyone who actually found this program useful and promising. I can't blame the Church for being strict in its policies--neither should you.

Opera Debian Repositories

Being a web developer, I have an obligation to ensure that the sites I build work on the wides range of popular web browsers as possible. Because of this, I often find myself installing the wonderful Opera web browser on my Linux systems. Now, I could just download it directly from http://www.opera.com/ each time there's an upgrade, but it is much easier to handle when running a Debian-based distribution thanks to the apt-get infrastructure. This article will explain how to set your Debian system up to be capable of automatically updating Opera any time there is a new release.

  1. Install the keyring. A keyring is simply a way to verify the identity of the repository. It kinda makes sure that you are installing from the server you want to be installing from, instead of a different server that has unauthorized packages. To install the keyring, run the following command as root (or with root privileges using sudo):

    wget -O - http://deb.opera.com/archive.key | apt-key add -

    Note: Copying and pasting the above command does not seem to play well. The dash immediately before the http://... is translated improperly on this webpage. It should just be a regular dash.

  2. Install the repositories. This part usually depends upon your particular flavor of Debian. I am running Debian Sid, so I install the Opera repository using the following line:

    deb http://deb.opera.com/opera/ sid non-free

    or if I am feeling brave, I can install the "unstable" testing version of opera with

    deb http://deb.opera.com/opera-beta/ sid non-free

    If you are running Debian “etch”, you would change sid to etch and likewise for other flavors of Debian. This line typically goes in the /etc/apt/sources.list file. Just put it on its own line. Some newer Debian systems prefer that you put this line in /etc/apt/sources.list.d/[repository].list (where [repository] would likely be opera in this case).

  3. Run apt-get update as root to make sure the repositories are working properly. If they are, you should see no errors or warnings pertaining to opera.com. If you see any such messages, try updating again.

  4. Install Opera. Run the following command as root:

    apt-get install opera

Once that completes, you should be able to launch Opera without a hitch!

Why I Like Python

For the past 8 years or so, I've been very much involved with programming using the PHP scripting language. It is a powerful scripting language that suits building websites very well. PHP has a huge set of useful built-in functions, and more recent versions support object-oriented programming. I first started teaching myself PHP when I got tired of having to build each and every web page on my site manually. I hated having to change dozens of web pages just because I added a new link to my navigation. All sort of reasons like this prompted me to investigate PHP. Little did I know then that this language would occupy so much of my time in the future.

I rapidly learned that PHP offered much more than just allowing me to update one part of my website to change all pages. I started tinkering with all aspects of what PHP offered, and I'm still learning about it. After many years of searching, I finally found a programming language that was easy, fast, and efficient for my needs.

Through the years, I continued to develop various applications using PHP. I attempted to write my own forum/bulletin board software while I was still in high school. If I may say so myself, the forum really had some awesome concepts behind it. But my problem was that I lost interest too fast. I also built a very large application that reduced a 1.2GB MS Access database down to less than 15MB using PHP and MySQL. The new application offered many enhancements over the previous system. For one thing, it was much faster. Second, it allowed multiple simultaneous users to modify the database. Three, so far it has lasted more than 3 years, compared to the 1 year maximum that the MS Access solution always seemed to hit before it crashed.

Using PHP, I helped revolutionize the way one of the companies I work for developed websites. I built a simple in-house web framework that supposedly reduced development time by allowing us to forget about the mundane details involved in virtually every website and just get to the developing. In a matter of two weeks (with a full class load and another job), I managed to write an e-commerce solution for the same company using PHP.

Basically, PHP has treated me well over the years. But this post is not supposed to be about PHP. If that's the case, why have I rambled about PHP this whole time, you ask? Well, it's mostly to demonstrate that I have a lot of experience with the language. I have a pretty good feel for what it's capable of and how I can accomplish most anything I need.

With all of that in mind, I've encountered my frustrations with PHP. They may seem petty and moot to most people, but they have turned out to be the determining factor in what scripting language I prefer. Here is a short list of things I now despise about PHP:

  • dollar signs ($) to signify variables -- while this is a useful feature, it becomes quite bothersome when you're programming all day long (at least it does for me). I'll get to why later.
  • using an actual arrow (->) to access attributes -- most other modern programming languages simply use a period (.) for this functionality. I'll comment more on this and why it frustrates me later as well.
  • lack of true object-oriented constructs -- in other object-oriented languages, like Java, if you have a string and you want to determine its length, you call the length() method of that string. In PHP, you call a function such as strlen($var). This sort of behavior plagues the language.
  • too many unnecessary keystrokes -- as I mentioned before, all mutable variables are preceded by a dollar sign ($). That is 2 keystrokes (shift and 4) every time you want to refer to a variable, wheres most languages nowadays have none). Likewise, accessing attributes of objects in PHP uses an arrow (->), which is three keystrokes (minus, shift, and .). Most other object-oriented languages only require a period (one keystroke) for such functionality. The main reason I make such a big deal out of the number of keystrokes is simple. The more keystrokes a program requires, the more likely you are to have bugs. The fewer keystrokes a program requires, the less likely it is that your program will be broken. It boils down to maintainability. Also associated with the number of keystrokes is the pure laziness within me and most other programmers.

These frustrations have been bothering me for several years now. I continued using PHP mostly because it's so widely supported, but also because I could not find a suitable replacement for it. I investigated a few others, but they apparently didn't have a great influence on me right now because I don't remember any names.

When the whole Ruby on Rails bandwagon was rolling through town, I decided to hop on to see what all of the hubbub was about. I started studying the Ruby script language, and I found that it had some really neat things about it. It uses a more solid approach to object-oriented programming, which I really liked. I also noticed that it employs some intriguing structures for accomplishing things in ways I've never seen before. Despite these things, Ruby still didn't seem like a viable replacement for my PHP. It didn't come up to snuff in performance in many cases, so I essentially abandoned it.

For at least a year now, I've been interested in learning Python. I've heard a lot about it over the years, but I just never seemed to make the time to actually sit down and study it. That is, not until about the beginning of August of 2007. After I made my decision that Ruby and Ruby on Rails weren't quite up to par for my needs, I stumbled upon the Django Project, which is a web framework similar to Ruby on Rails, only built using Python.

I decided this was my chance to actually sit down and learn a little about this "Python" so I could see what it had to offer. I mostly used Django as my portal to Python. As I started learning Django, I became more and more familiar with the way Python works and how I work with Python.

At some point in time, I decided that I actually liked Python, and my wife let me buy some really cool books to help me learn it. By the beginning of October 2007, I had convinced my supervisor at work to let me start building websites using Django instead of our home-grown PHP framework.

And here comes a story. This is the main reason I blabbered about my experience with PHP so much at the start of this article. Again, after all these years, I feel very confident that I can do just about anything I want efficiently and elegantly with PHP.

Back in October of 2006 (after using PHP for some 7 years), I was asked to write a PHP script to parse some log files and output various bits of information in a certain format. After maybe a week, I had a script that did the job fairly well. Most of the time it worked, but there were occasions when it didn't and I had to fix it. The script turned out to be 365 lines of code with very few comments scattered throughout. It's also a maintenance nightmare, even for me.

In October of 2007, I rewrote that same script in Python. After only a couple days, the script seemed to be perfect. It did its job, and it did it well. With comments for just about every single line of code, the Python version of the script took up a mere 118 lines of code. Take out the comments and it is 56 lines of code. The script is several times more understandable and maintainable than its PHP counterpart. I also believe that it is much more efficient at doing its task. Keep in mind that I had only been using Python for about 2 months at this point in time.

It's been through various experiences like the log parser that I have decided I prefer Python over PHP. Obviously, I'm not quite as comfortable with it as I am with PHP, but I don't feel too far behind. Now, less than 6 months after deciding that we'd use Django at work, I don't think my supervisor could be happier. Building a typical website with our PHP framework takes between 1 week and a couple months. Thanks to Python and Django, most of our websites can be "ready" within just a few hours. That time assumes that the website's design itself is ready for content to be put into it and also that the client does not require custom-designed applications.

Python and Django have helped revolutionize the way we do things at work, and I can hardly stop thinking about it. Python fixes nearly all of the frustrations I had with PHP. The frustrations it doesn't take care of are worth the sacrifice. Python is capable of object-oriented programming. It uses a period (.) to access object attributes. Variables are not preceded by some arbitrary symbol.

Also, the fact that Python code can be compiled to bytecode (like Java) is enormously beneficial. Each and every time a PHP script is executed, the PHP interpreter must parse the code. With Python, the first time a script is executed after an edit, the program is compiled to bytecode and subsequent executions are faster. That is because the bytecode is processed directly by the Python Virtual Machine (as opposed to being compiled to bytecode _each_ time and then executed). Python also offers a vast amount of standard library functions that I would really appreciate having in PHP. But from now on (at least for the foreseeable future), I will try to do all of my scripting in Python and leave PHP for the special cases.

Here It Is

Alright, alright... the idea of maintaining a blog has always seemed somewhat cool and somewhat retarded at the same time to me. Most of the time, I have no idea why people think blogs are so important. Other times, however, I find them to be an invaluable resource. Being a nerd, I love to learn. There are oh-so-many situations that I'm put in from day to day that require me to stunt my possibilities for growing my knowledge. Thanks to deadlines and lack of funding, my jobs almost always seem to require "just the basics." This provides absolutely no opportunity for me to learn and grow.

I think that a lot of people are put in the same sort of situation all the time. That's when certain creative individuals keeping a blog seems like a good idea. It's a way for people to discuss the progress and findings they make on their own time. We can learn about a lot of interesting (albeit often useless) ideas from blogs. I hope that my ramblings on my blog will be of some use to various individuals around the world.