Slashdot co-founder turned teacher discusses teaching, Rails, and the new web

Visionary: Kurt DeMaagd, Co-founder Slashdot

Interviewed by: Robert Dempsey on 05/30/2007 by Email

Summary

Robert Dempsey of Rails For All got a chance to interview Kurt DeMaagd, a co-founder of the hugely popular Slashdot.org about teaching, Ruby on Rails, and the move of applications off the desktop and onto the web.

Interview

When did you start teaching at Michigan State University?

This was my first year teaching at Michigan State University. I just received my PhD from the University of Michigan a year ago.

What course(s) do you teach?

I have recently taught or will teach in the near future:

TC 361/861: Information Networks and Technologies. This is an introduction to basic communications protocols and applications. The 361 version of the course is targeted to undergrads, whereas the 861 version is tailored for graduate students.

TC 448: Special Topics on Scripting Web 2.0. Buzzword titles aside, this is a web development course using Ruby on Rails. It covers general design principles, programming in rails, and an introduction to databases.

TC 458: Telecommunication Management. The theoretical and practical aspects of telecommunication management.

What is the average size of a class?

My class size varies substantially depending on the topic and the level. For example, TC 448 was my smallest at 14 students. TC 361, however, will be around 80 students next semester.

What caused you to co-found Slashdot.org?

We didn’t really have a grand plan for Slashdot. It really evolved over small incremental decisions. First, Rob Malda had some news on his home page. Then we developed a separate site with user submissions. Next came comments. Then advertisers became interested. And so on. I think it is a great business model for any budding entrepreneurs. Start by doing something you love. Keep expanding it and see if the market wants to pay for it. If it succeeds, great! If it doesn’t, at least it was time spent on something valuable to you.

What considerations did you take into account when you chose to use Perl for Slashdot.org? Is Perl the power behind Slashdot.org today?

At the time we developed Slashdot, Perl was pretty much the only option for database-driven dynamic web sites. Its combination of easy database access and advanced text processing made it a logical choice for web development. Since then, a lot of competing languages have popped up, but it is still the engine behind Slashdot and it is still my favorite programming language.

Have you heard of Ruby on Rails? What are your initial impressions?

I taught TC 448 in Rails, and I had played around with the language a bit before. As a first language for web developers, I think Rails is a great choice. Although a basic interactive web site does not involve a lot of highly technical skills, it does require a lot of little pieces of knowledge. Rails, through its system of conventions, lets you skip over a lot of those little tasks. As a result, a beginning student can create an interesting web site with minimal effort. By getting that early taste of what computer programming can accomplish, it hopefully whets the students’ appetites to learn more.

Outside the classroom, Rails is also a good language for basic or intermediate level web sites. The generators, conventions, and libraries take a lot of the scut work out web development. For example, I have two students working on independent studies where they are developing a database with a web front-end for their employers. This is a great application for Rails. In such a case, the application design does not stray far the the standard Rails conventions. As a result, it is easy to make an attractive database driven application.

I’m not the first to say this, but I think that the real problem with Rails comes when developing more advanced sites. In many cases, commercial applications require a degree of complexity that goes beyond the auto-generated Rails code. Sometimes the standard Ruby conventions are inconvenient. Sometimes, Ruby’s smalltalk-like syntax can be annoying. I had several students run into such problems on their final projects, so these aren’t just theoretical problems. That said, all programming languages have problems when doing advanced application development. Ruby isn’t worse than any other languages. Yet anyone thinking of using Rails should bear in mind that many of the benefits of Rails no longer help with complex applications.

With companies like Google putting entire office suites online, how do you see businesses and users interacting with web applications, and do you see an eventual move of applications completely off of the desktop?

That’s a tough question. Ever since applications moved off the served with the advent of the desktop computer, pundits have been predicting the return server-based applications. Google has done a lot for the web based office suite, and it is now a competitive choice for people who only need the basic tools. I am confident that the set of features will continue to improve such that it will no longer be a key factor when choosing online versus desktop applications. Yet, the more traditional issues of ownership, performance, upgrades, reliability, etc. will continue to be an influence. As a result, for the near future, I can’t imagine a complete shift to online applications.

License: All rights reserved.

Go back to the list