My approach to academic teaching

I recently read a fascinating post by Joel Spolsky entitled “Capstone projects and time management”.  It’s highly opinionated, as usual, but makes several interesting points about teaching computer science in academia.

He basically claims that academic computer science doesn’t teach you to use modern tools, or do version control, bug tracking, teamwork, planning, etc., etc., etc.  He repeats his frequent assertion that the academic world is almost completely divorced from the real world of software development.

I imagine he’ll get a ton of responses to his post, which is fine.  Somebody needs to whack the beehive every now and again, and I’m glad this time it won’t be me.

(I’ve been bumping into beehives lately, which is unfortunate.  I like causing trouble, but I hate getting into trouble, and I’m doing way to much of the latter.  Maybe it’s my premature entry into curmudgeon-hood.  Ginger thinks it’s way too early for me to be turning into such a grumpy old man.  But, you kids, get off my lawn!)

At any rate, most people who follow my blog are aware that my regular job is teaching software development training courses.  Roughly once a year, though, I get to play at being a professor at Rensselaer Polytechnic Institute in the Education for Working Professionals program in Hartford, CT.  That’s formerly Rensselaer at Hartford, formerly the Hartford Graduate Center.  In the late ’90’s I got my MS in CS there, at night, while I was transitioning from my career as a research scientist into my current business.

I teach a class called “Developing Enterprise Applications”*

*So all of our programs work on the library computer on a starship (rimshot).

The basic idea is that I try to show the students the current state-of-the-art in software development, based on my experiences.  Since I teach a lot, I can travel to 20 to 40 different companies a year.  That gives me a decent sense of what’s going on around me, along with blogs, podcasts, twitter feeds, and participating in the Groovy and Grails open source projects.

I’ve taught my Rensselaer class about half a dozen times so far, and it’s been completely different each time.  Most recently I taught it last spring (2009).  We talked about Spring and Hibernate, used a Subversion server to check in code (actually a Google code project, but that’s the same thing), ran lots of JUnit tests, added Ajax capabilities with prototype and, and briefly went over, of course, Groovy and Grails.  I write code during class which the students are free to use, and I keep notes on Google Docs, which I share with them.

Here’s the cool part, though.  There are no assignments, no exams, and no homework of any kind, with one exception.  At the end of the course, the students have to present an application they’ve written to the rest of the group.

The choice of project is completely up to the individual student.  I do give them a list of requirements, which are negotiable until about half-way through the semester.  Here’s a portion of this years’ list:

  • Use a framework (Struts, Spring MVC, JSF, Grails, RoR, or other)
  • Create an ORM layer (Hibernate, JPA, roll-your-own)
  • Test as much as possible (unit, integration, functional)
  • Ajax capabilities are a plus
  • Do something with web services (REST or SOAP; at least consume, generate if possible)
  • View templates are optional but preferred (Velocity, Freemarker, Sitemesh, whatever)

I’m quite flexible on the actual implementations, as long as the student clearly learned something and the implementation has some value.  Students can write in Java (most of my demos are in Java, so that tends to be a favorite), or .Net, or anything else they prefer, as long as they try to fulfill the requirements above.

My favorite requirement, however, is the Design Document.  This is very important to me because I want the students to tell me what worked, what didn’t, what they liked, and what they didn’t.  I want this to be a low-pressure opportunity to experiment, and if they’re truly experimenting, then not everything will succeed.  I want to know what they tried, even if it failed.

I do ask that one use case has to work.  I’m fine with experimenting, but there’s nothing like working code to motivate you.  Students (like most developers) tend to way overestimate how much they’ll actually finish, though, so I only ask for a single case to function correctly.

Regarding teamwork, I allow them to work in groups of one or two only.  My experience has been that groups of three or larger don’t finish in time, or one student winds up doing too much of the work.  I like the idea of doing a team project, but I haven’t figured out a good way to manage it yet.  Two person teams tend to work, both in scheduling and production.  Most students prefer to work by themselves.  I’m fine either way.

During the last class, each student (or group) hooks up their laptop to the projector, demonstrates the application, and then walks through the code.  I bring the donuts and coffee, and we all watch together and ask questions.

Then I give out the A’s.  If you clearly tried something ambitious, and you clearly learned something, and you fulfilled the deliverables above, then why not?  I only give out A’s and F’s, and the latter only happens if a student clearly left everything until the last minute, never came to class, and then tried to snow me with a rushed project.  My rule of thumb is that if I could do your entire project in a couple hours, you didn’t do enough*.  I get a student like that about once every other year.

*Of course, I have to pretend I don’t know Grails when I say that…

I find this a very easy, successful way to teach, and the students seem to like it too.

Grails Griffon Groovy Spring

SpringOne 2GX final thoughts

I wound up too busy to maintain my daily reports, but here are a couple of items I want to highlight as important take-aways from SpringOne 2GX. Rather than just recap sessions or dole out marketing-type praise, I’m going to focus on some things I learned that I didn’t necessarily expect.

  1. A lot of people who advocate Scala or Clojure over Groovy emphasize their scalability and features like immutable objects. Groovy’s @Immutable annotation takes care of the latter, and the gpars project handles the rest. You can use @Immutable right away. The gpars project is still pretty early in its lifecycle, but it’s going to be HUGE.
  2. By the way, despite the fact it looks like it’s pronounced “Gee-Pars” (and Paul King kept calling it that), I love the way Scott Davis kept referring to it as “jeepers” 🙂
  3. Twitter has reached “essential” status at conferences. This is the first conference I attended where I would have missed half of what was going on if I hadn’t been using my Twitter client the whole time (I use twhirl, btw, but I’m open to other possibilities). Most of the presenters (@glaforge, @graemerocher, @paulk_asert, @daveklein, @jeffscottbrown, @scottdavis99, @aalmiray, and several others that would come to mind if I thought harder about it) were continually tweeting good info. As a company, @ManningBooks did an excellent job, especially with their #hideandtweet game.
  4. As a totally unexpected (to me) underlying theme, the rise of non-relational databases is striking. Apparently, the major cloud providers (Google AppEngine, Amazon SimpleDB) have decided that relational simply doesn’t scale, so they’re going with “schemaless” solutions. I had no idea how significant that was until I heard enthusiastic support for the idea from the audience of one of the Amazon cloud computing sessions. I know a lot of DBAs who are in for quite a shock. So is Oracle, too, and that’s got to be a Good Thing.
  5. Like Grails recently and Ruby on Rails before that, the new Spring Roo project makes existing web development approaches look antiquated. Roo and Grails are siblings that will learn a lot from each other as they continue to grow. For example, Grails has an interactive console, but it isn’t nearly as cool as Roo’s. I’m sure that’ll change soon enough.
  6. The extraordinarily humility and friendliness of the Groovy and Grails core teams is charming. Everyone I met seems almost embarrassed to be having so much fun working on something they like so much. There’s none of the arrogance or elitism that characterizes so many other revolutionary groups, and they always go out of their way to help and answer questions. I love talking to them and really hope to be included as one of them some day.
  7. Speaking of that, sometimes timing is everything. I told Guillaume Laforge (Groovy team lead, for those who don’t know) that he was one of my personal heroes and nearly made him spit up his drink. Sorry, I didn’t get a picture. 🙂
  8. Griffon made several fans at the conference, especially among the existing Groovy people. I still think it’s a bit early for mainstream practice, but all the signs are favorable.
  9. October is definitely the right time to visit New Orleans.

I had a very good time at the conference and am already looking forward to the next one.

Griffon Groovy Spring

SpringOne 2GX Day 1

… or day 2, by the official count. Today was the first full day of sessions, though, so I’m counting from 1.

From now on, I can only comment on the sessions I attended. There were many parallel sessions I wish I could have gone to, but until I get one of those cool Time Turner like Hermione Granger had in the third Harry Potter movie, I still have to operate synchronously. I’ll just make some comments about each here.

Since the conference is a combined one, I decided I should try to attend some Spring sessions as well as Groovy/Grails/Griffon ones. The first session I went to was “Overview of the Spring 3.0 Web Stack,” given by Keith Donald. This was a major overview, with some discussion of Spring MVC, Spring JavaScript, Spring Web Flow, Spring Faces, Spring Security, and even Spring BlazeDS Integration. That’s obviously way more that can be covered in one session, so a lot of the slides were really pointers to other presentations given later in the conference.

That said, after the introductory material he spent a fair amount of time on the new REST support in Spring MVC 3.0. I’ve been working with Spring 2.5 for some time, and I’ve played with the new MVC annotations like @Controller and @Service, but I hadn’t seen the RESTful ones yet.

To give us an idea what’s coming, Keith went over parts of the new sample application for Spring MVC 3.0, yet another version of their PetClinic app. For those interested in looking at it, the svn repository for the RESTful PetClinic is here. Feel free to check it out.

Keith spent a fair amount of time on ways to do the URL mapping, the new validator framework, and the new formatters that replace custom property editors. This isn’t the right post for a detailed discussion, so I’ll refer you to SpringSource for more details. The slides suggested the link , but that site didn’t exist when I tried to go there. Still, there’s tons of documentation on all the projects at the base URL.

It turned out there wasn’t time for much information about the other areas, but I did note that Spring JavaScript is really a spring-enabled front end on dojo, which is pretty cool.

(I can’t help automatically going, “Pain … does not exist … in this dojo!” Hopefully Spring JavaScript is also painless.)

It also turns out that the amount of configuration to get Spring Security working has been reduced dramatically. That can only be good news.

In the end, I’d say that Spring definitely lived up to its “Swiss Army Chainsaw” reputation, but I liked a lot of what I saw.

(I especially liked the introduction to Spring Roo that I saw later. See below for that.)

The next talk I attended was “Introduction to Griffon” by Danno Ferrin. I was torn there, because I really wanted to go see Paul King talk about Spring and web services, but I knew most of what Paul was going to say already. Besides, I can probably harass him with questions about the rest (no pun intended) tomorrow. 🙂

I do know something about Griffon. It started off as an offshoot of the Grails project, with the same value proposition: bring ease of development and convention over configuration to desktop development. I’ve had long email exchanges with Andres Almiray about Swing development, especially with Groovy’s SwingBuilder and working on and off the Event Dispatch Thread, which I’ve written about here a few times. I’ve only run the basic demos on Griffon, though, and hadn’t seen it presented in any official way yet.

Griffon is all about enforcing MVC architecture with desktop apps. It looks and feels a lot like Grails, but there are important differences. The project is only at version 0.2 (and only a beta for that at the moment), so it’s really early. Still, the basics of “MVC groups” (Danno wanted a better term for them, but I kind of like that one), event handling, deployment, and more are already in place.

The deployment story rocks, by the way. You can export your app as a jar file, as an applet, or even as a Java Web Start application automatically, and it’ll help you digitally sign the jars. That’s really cool. The whole technology is pretty slick, actually. It’s pretty much the only framework for desktop apps I know, though I believe there are a few in development. I suggest that anyone interested in desktop development (and there are far more people like that than most developers think) to check it out at its home page.

By the way, Danno had a great line that I just have to use in the future. He said at some point in the presentation he might have to switch from Bob Ross mode to Julia Child mode, meaning he wasn’t necessarily going to have enough time to paint in front of us, but rather would have to pull completed meals out of the oven. I knew exactly what he meant. 🙂

My feeling about Griffon is that it’s great, but it’s still very early in the development cycle and the documentation isn’t sufficient yet for actual work by people who aren’t closely involved in the project. On the other hand, Danno, Andres, and James Williams (not here) are all co-authors on the upcoming “Griffon in Action” book from Manning. I suspect that book will be as important to future Griffon developers as “Groovy in Action” was (and is) to Groovy developers.

** update: James’s last name is Williams, of course. Also, he’s not a co-author on the book. He is a core committer on the Griffon project. **

The next talk I attended was Paul King’s presentation of “Industrial Strength Groovy.” As he explained, some of the reluctance to adopt Groovy that he finds in the business world is a fear that they won’t be able to use the tools they already adopted and really like. Paul went through a range of tool categories showing how that wasn’t the case.

He discussed lots of testing tools, including mocks like MockFor (built into Groovy), GMock, and EasyMock; injection with Spring or Guice; code coverage with Cobertura; build tools like Ant, Gant, GMaven, and Gradle, Hudson continuous integration, and lots more.

Here’s the best part, at least as far as you, the outside reader, is concerned. You can see all of Paul’s slides on SlideShare.

As an aside, I’m of the opinion that anything Paul writes is great. He has an excellent introductory tutorial for Groovy online in PDF form. He’s also a co-author on GinA (Groovy in Action), which doesn’t surprise me at all.

For the next talk I switched back to the Spring side and attended “Introduction to Spring Roo” by Ben Alex. Ben founded the Roo project, and as it turned out he also founded the Spring Security project. That’s quite a resume. He’s also an outstanding presenter. He doesn’t go for rah-rah tricks or false enthusiasm. Instead he has a very friendly, comfortable, low-pressure style that I find quite appealing. He reminds me a lot of Jason Rudolph that way, or even Guillaume Laforge.

I’d heard of Spring Roo, but didn’t know any details. My original thought was, “oh no, not another Java framework,” but decided to give Roo a try.

Let me just say flat out that I was very impressed. Roo’s best feature (okay, best is a strong term — one of its best features) is that it operates as an interactive command-line application with lots of help and hints available. You start up Roo at the command line (or in STS), type “hint”, and it tells you what it’s expecting next. Just keep hitting the TAB key to get more suggestions.

Essentially what Roo is about is building and configuring a Maven project with lots of AspectJ code generation to modify the source. It felt a lot like Grails, but using Java instead, and most of the code generation affected what happens at compile time rather than at run time. For example, it automatically generates getters and setters and toString() methods for domain objects. It generates the same sort of dynamic finders that Grails has, though you have to choose to add them. It automatically configures Spring JavaScript to do form validation. It uses the JSR 303 bean validation annotations to enforce what it wants. It configures databases for you, too.

I couldn’t help but feel that the Grails framework has been highly influential inside SpringSource. I can only assume that’s partly because Graeme Rocher is now one of their employees (after they bought G2One). At any rate, this was the first Java-based framework that I thought could provide serious competition to Grails. I still like Grails partly because I really like Groovy, and I think it’s always easier to implement anything in Groovy than in Java. Also, Grails has about 300 plugins at the moment, that do basically everything. But if you’re committed to Java, Roo looks like a great alternative. You can download it at the project page at SpringSource.

I only had a couple of criticisms. One was that you can replay your Roo scripts, which is cool, but there’s no way to automatically record them as you go. Expect that to change, since everybody seemed to want it.

The other came from the fact that I downloaded Roo while Ben was talking and was running the app along with him. Then, when typed

roo> perform eclipse

to generate an Eclipse project, I did the same and had to wait about 15 minutes (literally — that’s an estimate) while the underlying Maven engine downloaded the Internet. When I went to test the app in Tomcat, I exited Roo and typed “mvn tomcat:run” and waited again for tons more downloads, even though I have both Tomcat 6 and Tomcat 5.5 on my hard drive already. Finally, when I tried out the Selenium support (another great feature, btw) and ran “mvn selenium:selenese” I had to wait again as Maven did its thing. They all worked, and the delays all had to do with Maven rather than Roo, but yikes nevertheless.

Right now Roo is at version 1.0.0.RC2 and should be at GA some time in December, and that one will include docs. Until then it’s mostly blog posts and the associated forums. I’m definitely going to try Roo, though, when it’s ready.

This post has already gone on too long, so I think I’ll leave it at that. I’m enjoying the conference and am looking forward to more presentations tomorrow.

Grails Groovy

SpringOne 2GX Day 0

I’m at the SpringOne2GX conference ( in New Orleans this week. Monday (which they’re calling day 1 but I’m referring to here as day 0) consisted only of registration plus a reception and finally a keynote by Rod Johnson.

As a frequent NFJS attendee, the “reception” was a bit of a culture shock. One of the great appeals of No Fluff, Just Stuff is that there are no vendors present. This reception turned out to be purely a vendor reception, with wine and beer and light munchies. The vendors were all talking about Spring, of course, not Groovy or Grails. I didn’t find any of them particularly overwhelming.

The most amusing part is that one of the Platinum Sponsors was, of all companies, Microsoft. The Microsoft rep was sitting at a table by himself, with no posters or anything. He was sitting in front of a Mac (!).

When I asked him about the Mac, he showed me that it was running VMWare and a Windows 7 pre-release version. Then I asked him about he platinum status, in a rather obnoxious way.

“I can understand why Microsoft might want to be here,” I said, “but Platinum Sponsor? What’s up with that? What’s your goal?”

“We’re talking about our integration story,” he said.

“You mean web services?”

“No,” he said, and then proceeded to describe accessing MS apps via RESTful web services (or maybe just GETful — I didn’t get the details). He also mentioned some MS product I’d never heard of.

When I prodded again about the platinum sponsorship, he confessed that this isn’t really a large conference for MS, so the platinum sponsorship really wasn’t much money to them. Must be nice.

I also asked him why he didn’t have any posters or anything. He said that MS has a major developer conference coming up in a couple of weeks. When he went to get the stuff he needed for this conf, it turned out everything was already packed away. 🙂

The other big event of the evening was Rod Johnson’s keynote. That turned out to be a mixed bag, at least from my point of view. He spent the first 20 minutes or so reviewing the glorious history of Spring, focusing on a timeline and all the enthusiasm in the developer community. Now, I’ve been using (and teaching) Spring for years and I really like it, but this felt like a “fire up the troops” talk as though we were marketeers.

He did break for demos of Spring Integration, and tc server with the cool performance monitoring stuff, and a review of what’s new in 3.0. Then he set up the demo by Graeme Rocher, the extremely impressive lead of the Grails project.

To introduce the topic of Grails, Rod made an extremely odd segue. He mentioned how he was able to get “bacon ice cream” in the hotel (a real, of strange product). He somehow related that to a picture of three pigs, and said that pigs build brick houses, and that Grails is built on a brick foundation. That foundation included Spring of course, but he forgot to say anything about Hibernate. 🙂

Graeme, wisely IMHO, ignored all that. He showed how the latest version of STS (SpringSource Tool Suite) had very good Grails support. The version he showed will be released Wednesday. Graeme was great, as usual. The only problem I ever have with him is that he tends to make everything look easy, which can be a tad misleading. Still, the support looked solid, and as a community we desperately need that.

The one practical point I took from Rod is that apparently there’s going to be a developer version of tc server. I was really looking forward to checking into tc server, until I found you have to pay for it. I can’t justify that, especially when GlassFish has improved so much over the past few years and JBoss still works, too. Now if there’s a free dev version, maybe I’ll try it.

The biggest message I got from the whole evening, though, is that so far this is a Spring conference, not a Groovy/Grails conference. I hope that doesn’t carry through the whole way.

For me, the best part was finally getting to meet Guillaume Laforge, Paul King, and Robert Fischer in person. I also re-connected with Dave Klein and the indefatigable Andres Almiray. That rocked. The Groovy/Grails/Griffon (!) community is filled with great people.

I’ll try to update this blog periodically as the conference goes on. Any comments, of course, are welcome and appreciated.