Christian, Steve, and Anthony, from the Hibernate development team, have commented on my postings about the trouble I’m having getting things to work. I’m not sure what ‘seem swoon by “academic woe”‘ means, and I think that trying to get Hibernate into the undergrad curriculum will do more to help it grow than writing patches, but I take their point: less venting would be more productive.
So, my apologies—I’ll wait until the next day from here on in before blogging my experiences. In the meantime, though, let me throw it open: what could/should I have done four weeks ago to get my students over the learning curve more quickly? More to the point, what can I do this coming January, when the next generation joins the project? I believe it took this term’s students an average of 30-40 hours to get their first (trivial) app going with Eclipse, Ant, JUnit, Hibernate, Tapestry, and Tomcat, which is a third to half of the time they’re supposed to spend on the course in total. Options I see are:
- Just accept that getting your first Java web app to run is a full-term venture, and try to find room in the curriculum for _two_ courses (one introducing the tools, the second putting them into the proper software engineering context). The problem with this is that the curriculum is pretty crowded already…
- Hand students a working self-contained starting point (but then when things go wrong, they won’t know where to start debugging);
- Have each student pick just one part of the tool stack and master it (but then they don’t learn how to build complete web apps, and are lost when bugs arise out of interactions);
- Simplify the tools, esp. their configuration, and their interactions. A lot of recent articles and books have complained that the Java web app tool chain has grown too complicated (see Better, Faster, Lighter Java, for example; there are lots of others). However, I haven’t yet seen consensus on what to do about it.