The reaction from folks when I tell them the news has been mixed thus far. About half say you’ll never go back and you’ll go on to great things, and the other half think I’m crazy to leave a good job in a “recession.”

I explain it like this to the haters. You know the look a lion has in the zoo? Now, contrast that with a lion in the wild. The zoo is me at Notre Dame and the wild is what I’m doing now. There is nothing wrong with the zoo. It’s safe, fun and gives you room to grow. Everything is taken care of for you and all you have to do is show up. Over time, I was afraid this would lead to complacency and I didn’t want to go down that road.

I figured right now is probably the only time I would do this as I’m not getting any younger and the longer you do something the harder it is to leave. I figure if this doesn’t work out, I can always go back to corporate/higher-ed but if I can work for myself, why not?

I spent my first few days at Ordered List in Portland, Oregon for RailsConf 2008. This week is my first actual work week from home and it has been great. I’m amazed at the distractions I had in my office at ND. Take lunch for example. At every job I’ve had, lunch is the centerpiece of the day. It doesn’t matter how productive your morning was or whether or not you are hungry, you always take lunch around noon. I’ve been engrossed in what I was doing the past few days and forgot to eat until like 1 or even 2pm. I wake up around 8 or 9, work hard for 5 or 6 hours and then hit cruise control for the rest of the night, tweaking things I did during the day and prepping for the next.

I know I’ll miss the day to day interactions with my ND co-workers as they were a lot of fun but I guess that is what the weekends are for now. :)

Side note: A few people have wondered if joining OL will affect my blogging here and at RailsTips. The answer is yes, but in a good way. I’m hoping to have more time and energy for blogging. The only change around here is the “Hire Me” ad bug in my sidebar and the only change on RailsTips will be a sexy new design (by Steve) and a more stable web host to serve it from.

If you are interested, you can read the welcome post on the new Ordered List site that features our new services and the fact that it is now a “we” instead of a “me.”

The Trend

Now, with 13 sites live and another 16 in development, I am seeing a trend. Most pages on the web are more than just a title and some content. Thankfully, when originally developing Conductor, I tweaked some ideas that I liked from other systems and created page parts. Basically, we can put a page part in a template and a new tab will appear in the page editing area. The picture below has a main content area and three page parts (info, thumbnail and url).

The Problem

Nothing seems wrong with that idea, right? It allows us to store content in smaller chunks which gives developers more control over markup, which in turn gives designers more control over layout. Wrong. Exhibit #1: the edit window for a page using a faculty template on the law school website.

Below is an example page rendered in the template above.

We wanted to show things like biography, courses, and contact information in unique ways but not force content owners to mark things up uniquely. Because I assumed that all pages will be made up of huge content regions and not tiny pieces of data, the only way we could do that is by creating a page part for each item we wanted to store separately. This, as you can see in the screenshot above, caused a very tab happy interface. While this works, I believe it creates a sub par experience for the content owner (who does all of the updates). One reason I believe that is now the content owner has an entire text area, to fill in something as small as a website url, which could be better represented by a small text field.

The Solution

All of the above has led me to an idea. It might be something that sounds good as an idea but in reality would be awkward. It might also not be my original idea, as someone else could have used it somewhere in the same fashion I speak of, unbeknownst to me, but here it goes. All you need is a way to store data and a way to present data. Also, those two things are completely intertwined. How you want to display data affects how you want to store it. The more control you need when displaying data means the more separated the data needs to be stored.

Each piece of content that makes up a website needs two templates: one that determines how it is stored and the other how it is displayed. There could also be a third template that is how it behaves but I’ll leave that out for now. I think the ideal website management system has almost a form builder interface for developers to define what they need stored. From there, the developer should also be able to create the xhtml or xml or json templates that determine how the data will be consumed. The final piece of administration would be an area where content owners can fill in those created forms with glorious content.

The Use Case

Here is an example use case. Content owner wants to show courses on their website. Developer creates new content template called ‘Course’. They define the storage half of the template to be name and number as text fields, professor and semester as selects (from comma separated list of options), summary as a text area and order the fields how they should be presented to content owner. At this point, the content owner can begin entering name, number, professor, semester and summary for all their courses, while developer starts creating the other half of the template, which is how it should be viewed by site visitors. Developer dumps in xhtml, css, and javascript to view all the courses styled up to meet a designer’s every whim.

You might be thinking, uh, duh, this is what happens on every web application. Someone needs something stored, so you create your model and your controller and your views and you are good to go. You’re right, but that stuff always happens at the programmer level and requires a programmer to do it. What I’m thinking about would be at the software level and could be done by anyone with front end web development skills (xhtml, css and javascript).

The Conclusion

Once this beast was created, a front end web developer could build dynamic websites very easily tailored to a content owners needs and the administration of the website could be left in the hands of the content owners. The bad news is that I would have to start from scratch to build a pure version of what I just explained. The good news is I can get close to the same result using what I’ve already built in Conductor (more on this at a later date).

Bad Start

About three or four hours in, I realized that things weren’t going the way I wanted and that it was going to take a lot longer than expected to implement. The solution that I had come up with felt complex and was going to require a big rewrite to our theme system. Anytime something feels complex, I go back to the whiteboard because it usually means I haven’t fully thought it through. A bit frustrated, I went back to the whiteboard. This time instead of starting with how I would store the data, I focused on how I wanted to present the data (the interface that the end user would see). Again, you can see my scratching below.

Good Start

As I framed in the interface on the board, the problem started to seem simple and I came up with a new way of doing it that would require no alteration to our theme system or any other existing part of Conductor. Also, this new way makes more sense.

Conclusion

So what am I trying to get at? I think this has taught me the difference between good software and bad software. Bad software starts with the developer thinking how they are going to store the data and technically make it work. Good software starts with the end user. It firsts figures out what will be the easiest way for the user to learn and use the feature and then figures out technically how to do it. I don’t think this is a revelation or that I’ve never built anything in this manner. I am sure, though, that I wasn’t as aware of this before when building applications.

Don’t start technical and force implementation. Start with the interface and let things come naturally.

Some people might be surprised by this but my favorite part of the new nd.edu isn’t the unobtrusive JavaScript or XHTML Strict doctype. It is the content. Not the text necessarily, but the videos. I have learned more about the University and the really cool things that are happening here in the last 3 months than my first 2 years. Whether or not you like the University of Notre Dame, you should go to the “What would you fight for?” archive and watch them. There are 7 and they are each 2 minutes long. It’s really cool stuff.

I like that the place I work for is a part of the things mentioned in these commercials and that I get to help share the message.

Newscenter 16

Deleting the Files

Also, if you are bored and looking for something to watch, below you can check out me deleting the files around 11:55PM on Monday night.

Hallway Baseball

Late Night Footage : August 13, 2007

Late Night Footage: August 14, 2007

• My Photoset

ND vs. MSU

• My Photoset
• Matt’s Photoset
• Matt’s YouTube Video
• Leaving Spartan Stadium YouTube Video

Here’s a little tip if you want to see some serious web 2.0 action for a good cause (I hate myself for saying web 2.0): Today, at 1:15PM, the Notre Dame Forum on the Global Health Crisis is going to be webcast live on the Forum website.

On the left side of the webcast is an area where you can take your own notes and on the right is a photos area that live updates as pictures get added. This page is streaming video (it is the year of video), ajax live updating photos, and using ajax to save all your notes for the forum (it will even email you all your notes with timestamps after things settle down).

If you are on campus, go to the forum and if you aren’t, watch the live webcast and enjoy some web 2.0 goodness (ok, I promise I will never say that again on this blog).

Recap

• Ruby On Rails
• Mongrel
• Caching
• AJAX
  • Webnotes (live adding)
  • Photos (live updating)
• Gradiants
• Great Content
• Great Cause

Page Caching

Page caching is very agressive. All that is required to use page caching in a Ruby on Rails application is to add a call (caches_page :index) in your controller. Yep, that’s it. Not only is it instant, but it caches the entire page and stores it as an html file in your public folder. I remember learning about page caching in the Chicago Rails Studio and having one of those, that is so simple I can’t believe I didn’t think of that moments.

I knew the Forum’s website would receive far more traffic than updates, so I decided to use full page caching and then blow away the entire cache whenever certain model records were modified. This approach solved the issue of having to figure out what pages needed to be expired and what pages didn’t. What evolved is a really simple plugin which worked great, so I thought I would share it.

How To Use

• script/plugin install http://svn.addictedtonew.com/public/plugins/addicted_to_caching/

• Check the list of protected entries in the plugin and make sure that it won’t delete anything in your public folder that you need.
• Add acts_as_cache_clearer to any model that should clear the cache if any of its records are modified.
• Generously add caches_page to all your controllers where needed

How It Works

Because page caching uses the public folder to store it’s cached files, all that is need to clear the entire cache is to remove each entry (file or folder) in the public folder that is not suppose to exist. The plugin contains a PROTECTED_ENTRIES array which determines which entries are not to be deleted in the public folder.

Reason #1: Stadium Behind the Scenes Tour

Reason #2: Tickets Arrive

Reason #3: SI Cover

Sports Illustrated has picked the Irish #2. They predict a Notre Dame vs. Ohio State national championship. Time will tell.

Well, that was a year ago. Now, which seems ten years since that day, all those questions have been answered. Not only do I love my job, but my co-workers have become my friends and I have not been assigned anything that I felt I was ill prepared for. In fact, when I look back at what I have learned and accomplished in the past year, I feel amazed and blessed. Not often do I find people who enjoy what they do for a living more than I do. So what have I done? Below is a list of projects that I developed over the past year at Notre Dame (all were designed by Jim).

On top of these eight completed works, I have three other projects which are 90% finished (Department of Chemical and Biomolecular Engineering, Office of Student Affairs and the Sponsored Travel App), one (Dean’s List App) which is completed but not public, and several that I was involved in, but only played a small part. Considering the size of a few of these projects, it is pretty cool that I have averaged one project a month. Here’s to next year and what I hope will be many more after that! *Raises the horchata high*

My Favorite Drive

My favorite drive of the day was the first. Charlie only sent Darius (our halfback) onto the field for like one play as the Irish marched right down the field for a touchdown. The entire drive was no huddle and each set had four or five wide receivers. Change is good.

My Attendee

Records were broken left and right and I screamed the majority of the game. I attended the game with my father-in-law, Brady Parker, a before the game nuetral fan, yet I often heard him hollering right along with me during the game. ND football is contageous right now! The final score was 49-23 ND.

• View my photos of the game on Flickr

Way to go Irish!

Jeff Samardzija made this amazing one handed reception on Saturday against the Boilermakers. I came straight out of my chair when he snagged this. It looked to be an overthrow and somehow he stretched his long arm out and pulled it in. Also, I’d like to tip my hat to the national player of the week, Brady Quinn (29/36 for 440 yds., 3 Td’s). Go Irish!

P.S. I love Dreamweaver 8.