Archive for the 'Programming' Category

I would like to expand a little on yesterday’s discussion of the photo album software I am in the process of developing. Specifically, I’d like to talk about the server side changes that I’m planning on making in relation to the Plogger software that I currently use. Suggestions and additional ideas would be super great, so please suggest anything that comes to mind.

Plogger allows users to add images to an album in two ways: either by uploading an image one at a time, or by importing a number of images at once. I never use the upload feature, opting instead to import one or more albums at a time via SFTP. Plogger handles this process via an upload folder on the server side. One may either place images directly in this folder, or create sub-folders to better organize things during the import process. I tend to do the latter step, creating a sub-folder for each album that I create. At import time, Plogger scans the upload folder for items to be added, presenting the user with a list of the folders containing items to be imported. After selecting the desired folder to import, the user is given the opportunity to caption the pictures and move them into an album. Physically, the files get moved from the upload folder into an images folder. The resulting file structure looks something like this:

+ images/
--+ collection_1/
----+ album_1/
------+ image_1.jpg
------+ image_2.jpg
------+ image_3.jpg
----+ album_2/

There are a few problems that I can see with this system. First, thumbnail images aren’t placed in the images folder, but in a thumbs folder instead (which is up at the same level as the images folder). Unlike its sibling, the thumbs folder has absolutely no organization whatsoever. All of the thumbnail images are simply placed in this one folder, ad hoc. I’m not entirely sure what happens if two different images in two separate albums have the same filename. I wouldn’t be surprised if the name collision is not resolved cleanly.

The second issue is that the sub-folders one creates within the upload folder don’t get cleaned up when the images get moved during the import step. As a result, a bunch of outdated, empty folders build up over time. Highly annoying for an obsessive-compulsive organizer like myself.

Finally, what happens if two albums have the same name? Again, I’m not sure that the collision is handled cleanly. The results could be potentially disastrous. Separating two intertwined albums in the database would most likely cause a great deal of headache, and is something I’d rather not have to deal with.

So here are the changes that I am proposing for my new, custom system. First of all, thumbnail images will be placed with each corresponding album, in a nested “thumbs” folder (to keep the root album folder as clean as possible). Second, the upload folder will be properly cleaned out when importing images. Empty albums will be discovered and removed as necessary. Third, albums will be date stamped. For example, if I uploaded an album today using a folder name of “eno_river”, the resulting album name in the images folder would be something like “20060829_eno_river.” This would help prevent name collisions on the album level, and would provide a nice chronological ordering on disk (not that that really matters).

This is how I am planning on proceeding with my new album package. Thoughts? Suggestions? Both are most welcome. This project is still in the early stages of development, and things are still quite malleable.

Update: I want to emphasize that I will not be using the filesystem to do logical organization and naming for each album and image. My album package will use a MySQL database to accomplish this, storing caption data, album data, and EXIF data as necessary. The organization on disk is simply a convenience, to help keep things orderly. Kip makes some good points in the comments in this post, some of which may result in modifications to my current plan.

I’m slowly working on a replacement for the Plogger software that I’m employing here at this site. Plogger works well enough, but there are enough bugs and “misfeatures” in it to motivate me to write my own package. In the process, I’m learning how to manipulate the file system through PHP, and make use of various cryptographic techniques (for security purposes), both of which are new PHP topics for me. Thankfully, PHP makes all of it very easy.

Here are a few things I’m planning on changing in my new photo album package:

• Albums will be sorted based on date, providing a better chronological ordering.
• EXIF data will not be hidden by default.
• Photos will be better organized on the server side.
• The old “slashes in the photo captions” bug will be fixed.

Progress is slow, but I hope to have something working within the next month or so. I’m also working on a new theme for this site, which is also coming along nicely. It might debut along with the new photo album software, so keep your eyes peeled.

After graduating from school with a bachelor’s degree of computer science, I must admit that I knew virtually nothing about developing *NIX based applications (that’s UNIX / Linux based applications for the non-geeks out there). Granted, I did do a little bit of non-Windows based programming while in school, but it was always incredibly basic stuff: compiling one or two source files, or occasionally writing a make-file for larger projects (three or four source files). Having never had a Linux or UNIX box to play with outside of school, I just never got a chance to get my feet wet. Thankfully, my job at IBM has changed that.

Over the past few weeks, I’ve been doing a great deal of Linux programming, thanks to the cross-”platformedness” of one of the projects I’m working on. And this project is way more complicated than your typical school assignment. I’m now horsing around dynamically linked libraries, also known as “shared objects” in Linux land, like nobody’s business. Not only that, the project itself is essentially a multi-threaded shared object, making it all the more exciting. I’ve learned more about g++, ld, and ldd in the past few weeks than I ever knew before.

Unfortunately, debugging multi-threaded shared objects is easier said than done. The debugging tools in Linux (at least the ones I’ve played with) all suck so horribly. They make you really appreciate the level of quality in Microsoft’s Visual Studio debugger, or better yet, in WinDBG (this thing is hard core, and it’s what the MS developers actually use in practice). Fortunately, printf() always saves the day.

One cool trick I recently employed to debug a library loading problem I was having, is the LD_DEBUG environment variable. If you set LD_DEBUG to a value of versions, the Linux dynamic linker will print all of the version dependencies for each library used for a given command. If you have a Linux box, try it out. Set the LD_DEBUG environment variable, then do an ls. You’ll be amazed at the number of libraries that such a simple command involves.

Although Linux development can be frustrating at times, I’ve already learned a great deal and consider my experiences a great success. If I come across any more useful tips (like LD_DEBUG above), I’ll try my best to post them here (as much for my sake as for yours). Until then, you’ll find me knee-deep in my Linux code. I’ve got a few more bugs to squash.

I just saw a commercial on TV for a (presumably) local college, and they touted their program by showing a bunch of “video game developers.” This motley crew of students looked no older than 20, and one girl commented “Can you believe we get paid to play games?” The people who put together this advertisement clearly understand nothing about the game development industry. I would hazard to guess that game developers spend less than 5% of their time actually playing games. Few people, if any, get paid to play games; the real glory, as well as the real money, is in development. And game development isn’t an easy task.

In college, I had the privilege to take two computer graphics courses. Both were challenging, and both gave me a new appreciation for game development. The folks who create today’s game engines are literally pushing the envelope in computer graphics. I shudder to think of how complex the math is behind games like Half-Life 2, Far Cry, and Quake 4. To think that your average college kid can do this fresh out of a no-name school is a little hard for me to believe.

My dad pointed me to an excellent article entitled The Perils of JavaSchools. Although it’s a little lengthy, the article is an incredibly worthwhile read on why schools that teach Java as the primary programming language are, to some degree, dumbing down the future generation of computer programmers. My alma mater took this route, but I was fortunate enough to be in the class before this change was made. I picked up C++ first: both on my own (by learning Visual C++ and MFC) and in school (my first programming courses were all taught using C++). After learning the intracacies of C++, learning Java was incredibly simple (almost too simple, in fact). I believe I passed my “Java for C Programmers” course with an A+; a feat that required very little effort on my part.

Once one knows about pointers, objects in Java become rediculously easy to discuss. As does the entire programming language itself. Java is a fine programming language (it fixes a lot of the brokenness in C++), but to know C++ is to feel enabled. I can wield the mighty sword of pointers and memory management; something that many Java programmers do not, and quite possible can not, ever do. I’m not saying that Java programmers cannot become successful C++ programmers; I’m simply making the point that there are more Java programmers who cannot pick up C++ than there are C++ programmers who cannot pick up Java.

Again, I highly recommend the article. The author also has an incredibly enticing reading list, which he uses to train managers in his company. There are a number of books there that look really great. I hope to begin reading The Mythical Man Month, the masterpiece written by Fred Brooks. It’s one that I’ve been meaning to read for a long, long time.

This holiday weekend, I made some progress on the next version of Paper Plus, my wallpaper changing program. There are a number of improvements that I want to make to the program, which will hopefully make it a little easier to use. I specifically want the program to:

• Run in the system tray
• Change the wallpaper on Windows startup
• Change the wallpaper every X minutes / hours

I got the first item working this past weekend, and I hope to get the other two working soon. These features will certainly be a welcome addition to the program, making it somewhat more user friendly.

Before I ever began my programming career, I had a sneaking suspicion that an abundance of coding at work would lead to decreased programming activity at home. And I fear that this is indeed becoming the case with me. I write a mixture of C++ and Perl all day long, five days a week. This level of productivity really taxes my mind, and it has recently resulted in an increase of non-computing related activity each evening. I’m reading books more often (Prince Valiant has certainly helped in that arena), and I’m watching more TV than I used to. I even occasionally go outside! Things like Googlebar Lite and my toolbar tutorial are slipping as a result. I dislike it, but my motivation for programming after 5:00 PM has dropped greatly. Weekends provide some level of salvation, but is that enough?