We’ve been tinkering with the campus search interface. Recently, we added a list of popular search terms from the previous day. It’s like a daily Zeitgeist right on the search page! Brilliant! Would something like this be helpful? Test out the new interface and let us know what you think! Go Search!
Yesterday, we updated the CAS interface. It’s now based on the Yahoo YUI CSS library. Working with the YUI library has been a blessing. We’ve converted most of our web applications, as well as any websites we create, and even a few we update, to use the YUI library. Next up to get converted to YUI, the portal… stay tuned.
From time to time we in WEBD poke and prod at some development stuff. We look at new technologies and new techniques that we feel might be able to enhance the campus web presence or the help our end-users in some manner. Today, we launched a “beta” of a new Campus Search page that we’ve been working on which was inspired by the folks at CSU, Humboldt. Go test drive our new search page today and let us know what you think.
Well, it’s be a long, hard road…but we are complete with “Phase 1” of our development of Omni. This application will help the Information Security department deal with the servers on campus. But that isn’t the interesting part. The best part was this is the first application to enjoy living on our new production server.
Previously we were deploying our Rails applications with Apache & FastCGI. It was functional, but not quite optimal. If the FastCGI processes weren’t routinely reaped they would just linger around sucking up RAM. We also ran into a slew of problems while trying to do simple things with Capistrano. All of these problems were our fault and stemmed from the fact that we never cleaned up our production/deployment model once we got things “working.” So we took the opportunity of a new server to get a fresh start on how we deploy our applications.
So, with a clean slate what did we fix/change?
Goodbye FastCGI! We’ve been using mongrel for local development and have been quite happy with it. It’s well written and well documented. We’re deploying behind Apache 2.0.x without using pen or pound in the middle. We are eagerly awaiting RHEL 5 which comes with Apache 2.2 and mod_proxy_balancer.
Running a cluster means that sessions are going to need to go in a central place accessible to each mongrel instance. We choose the database because it was drop dead simple. We’re using a 1.0.x pre-release of mongrel_cluster and it’s been a dream. The Capistrano recipes are so nice to have. We still marvel at doing simple things like cap update_current and have it “just work.” Obviously we’ve been living far too long with a spit and duct tape setup. Good riddance.
While we were working on Omni, Rails progressed from 1.1.x to 1.2.x. This was a big jump, but well worth it and allowed us to use a few less plugins. The story of taking our existing apps to 1.2 is a post for another day.
A number of things didn’t change. We’re still happy with Subversion and MySQL. Things that come stock with RHEL make our lives easier. Of course, we’re still on version 4 so we did need to upgrade Ruby.
In the last two days, we’ve launched two Rails apps. The first was Omni, a secret sauce intranet application designed to support staff in various issues. It’s been a bit of a beast having taken over 6 months to develop. It feels good to get v1.0 out the door and switch into a triage bug fix mode.
The second app is the Casper Pledge Form which I actually just put some finishing touches on and deployed. Roberta Roebuck was the actual designer/programmer behind the application.
Rails rocks. It make it easy to get stuff out the door and can really aid you in developing larger scale applications. Bug fixes and improvements are super easy with the development model and the logical placement of certain type of files. If you haven’t checked it out yet, do so today.
