First off, the learning curve for getting a basic app using Rails up and running is very low. Since it’s shot to the mainstream, there are many great tutorials available, as well as several great books out now and coming soon.

The main reason I like Ruby is because of it’s syntax. It’s so natural and free-flowing, and it makes perfect sense. As David Heinemeier Hansson says, it’s beautiful code. And Rails takes full advantage of that. Ruby is also completely object-based — everything’s an object, even strings and numbers. This makes it much more natural to, say convert back and forth, or run alteration methods on them:

length_in_seconds = mins.to_i*60 #convert minutes to integer and multiply by 60
person = "dave scott"
person.capitalize
puts person
# prints: Dave Scott

Even testing variables for empty values is much simpler and more natural:

if (var.empty?)
...
end

Ruby syntax includes the ? and ! operators, which give humans visual clues as to what a method does. The ? on the empty?() method tells us that this is a test — it’s asking the variable a question: Are you empty? Similarly, the ! operator, through common convention, indicates that a function does something destructive (whether that’s deleting something or changing a value permanently, or something else entirely).

And Rails makes it so easy to get everything up and running. Generators are the single greatest thing I’ve seen in web development recently. Say we wanted to create a recipe application that stored our recipes in a cookbook:

# rails cookbook
# rails script/generate scaffold Recipe

Those two simple commands will generate all the application files we need, and even generate a working CRUD interface. Of course, it doesn’t look pretty, but that’s not the point. The point is that this gives us the foundation to build our app on. We don’t have to worry about recreating database connection functions, writing and hooking up CRUD functions, or writing the code to display the interfaces for these — the generator does it for us. Now we can extend this app, while still retaining the full functionality of a CRUD interface, replacing a piece at a time.

I can’t tell you how much faster and easier the development process is using these tools, but I can try. For example, I recently finished writing a web app for a local church. This web app enabled members of a program that the church sponsors to interact with each other and plan gatherings. The app is written in PHP and all told contains over 30,000 lines of code, most of which is your traditional “templatey” mess of spaghetti — PHP interspersed with HTML. It works, and it works well, but with my recent endeavors in Ruby and Rails, I decided to recreate at least a part of it in Rails to see what we can do.

So, I picked the largest portion of the site — the “call list” (this is a list of all the past attendees of the gatherings that this group holds, which is sortable, paged, and has several functions associated with each member) — to recreate in Rails. Each member can be toggled between an OK to Call state and a Do Not Call state. Each member also has comments associated with them, which are editable. There are other functions, but they are secondary. These features are the thrust of the call list, and what I was shooting to replicate.

In PHP, these functions represent roughly 900 lines of code. In Ruby/Rails, I can accomplish the same tasks in less than 100 lines of code, including display, and an AJAX request to toggle the call state. The page is identical from a user standpoint — I can toggle call state, sort, page, and view, add, and edit comments. As a bonus, I’ve also got code that allows me to add, edit, and delete attendees built-in to the app due to the Rails generator, which, in my PHP app, adds another 300 lines of code, but is less than 20 in the Ruby/Rails version.

Now, I won’t say that I’ll stop PHP development, because after all, it’s what I started in, and I still have fondness for it, but I’m beginning to come around to Mr. Hansson’s way of thinking: If I’m going to be programming day in and day out, I should be able to really enjoy it. And working in Ruby and with Rails makes it much more enjoyable. Looking at beautiful, compact, readable code that just makes sense is what it’s all about.

That all being said, once Snaps! 2.0 is out the door, look for a Snaps! on Rails to follow…

Also, the Snaps! Gallery project page is now up and running to coincide (roughly) with the initial commit of the development code. You can visit the Snaps! project page here. The project page also sports a couple new screenshots of the current development code.

Currently, I’m working out the technical details and schema for the new user permissions setup that Snaps! 2.0 will use, as well as trying to figure out an elegant way to template the admin section without having to re-write it. The way it was written initially did not take into account the possibility that it would ever be templated, so it’s really gonna be a task to convert it to a template friendly form. Which is exactly why I think I’m gonna have to rewrite it.

Since initially writing it, I’ve learned a lot more about good coding practice and code libraries. For instance, I didn’t know how really terrible the DB class from PEAR was until I saw the benchmarks comparing it to straight SQL statements and other code libraries. So, with that in mind, I’ve switched over to the ADOdb library for database access. What this gains is: a much faster library, which results in a faster Snaps!, and better portability between database servers, which was one of my main goals in the original versions of Snaps!, but which DB doesn’t enforce very well. ADOdb’s design, by default, forces you to re-examine your queries and write them in a manner to fit ADOdb, rather than the database server you are using. ADOdb takes care of making it work with the various servers.

Along with that switch, I’m also re-examining all my code to try and remove as much extraneous and repetitive stuff as I can, in an effort to slim down and speed up Snaps! (not that it was ever slow, but…). And of course, I’m adding several features, two of which are complete and ready to unveil!

Woo! New Features!
So, the first thing that’s completed and working was a user-requested feature way back when: album thumbnails. So, the implementation I’ve created allows 3 “modes:”

1. default (folder image as in previous versions of Snaps!)
2. random (Snaps! selects a random image from the album)
3. selected (You select an image to use for the thumbnail of each album - if an album doesn’t have a selected thumbnail, it defaults to the folder image)

The second new completed feature is a Recently Added section on the front page of the gallery. This section shows the 5 most recently added images (go figure). You will have the ability to enable or disable this feature, as well as change the number of images shown.

Along with these new features, the screenshot (at end of this post - click for big version) shows an early version of the new default theme for Snaps!. I’ve taken a lot of time to develop the themes as well during this rewrite. Snaps! has always been templated, to allow for easy customization, but this rewrite will allow you the option of not only customizing, but also installing themes. You’ll be able to download themes, upload them to the templates directory and then select them from your administration area to change the theme on-the-fly. For those not graphically-oriented, or who aren’t coders, this is a great leap forward in being able to customize your gallery.

Along with the new color scheme, the new default theme will sport a new logo (rough early version in the screenshot), and a new set of icons from the fabulous Silk icon set by Mark James.

And of course you can expect the same XHTML and CSS valid official themes, as well as the super-easy web-based installer and web-based administration that you’ve all come to know and love.

You can probably expect an early-early beta sometime in the next few weeks, along with the new Labs website rollout soon.

When Snaps! 2.0 is ready for public release, the new project pages will also go online, with an updated look to match the new Snaps! Gallery default theme (which, I must say, is looking rather nice ). Stay tuned here for more details, and maybe a few teasers…

Beginning in January, development on Snaps! will resume an active status and many of the features our users have been looking forward to will be implemented. Along with those features, and items on the todo list, Snaps! will be receiving many functionality updates to its user interface.

I don’t want to give away too much, but I’ll say that the whole thing is going to be much faster, and it will use a generous amount of AJAX for its user interface. Hopefully, if I can do everything I’ve got planned, the gallery will be a much more interactive piece of software, and it will be more fun to use and administer than a traditional piece of web software.

Along with the new features I can’t discuss, the planned feature upgrades will be implemented, such as unlimited sub-albums, album preview images, a more extensive user permissions system, along with some better comment spam protection (Captcha). So, stay tuned to the Devlog here for more updates into the new year.

1. Provide a running log of our development on current and future products and projects.
2. Provide a means to explore and discuss web technologies.
3. Solicit discussion about web design in general.

Hopefully, we’ll be able to forge a good relationship with our readers and provide a lot of information on what’s going on behind the scenes at TSG.