The Course

The Web Applications course was eight sessions delivered bi-weekly over a single semester. Each session consisted of a lecture followed by practical work, where the students either worked on an assignment I had given them or developed their web app. By the second session, the students had pretty much settled into their teams of 2 or 3 members. (That was one thing I did enforce by the way. 2-3 students per team works really well, and I would not recommend going above 3.) The university infrastructure was relatively impressive and provided hosting software, databases, project management tools etc. Use of this infrastructure was optiona.

The Choices

When it came to deciding what application the students should develop, I allowed them to choose both their own topic and which technology they would use to implement it. I figured:

• When you give someone the freedom to choose their own topic, they’re much more likely to end up caring strongly for it, invest in it and make a good job of it.  Assigning them something risks sapping their creativity because they may have little or no interest in the topic.
• Nevertheless, I gave about a half dozen example topics. This gave both a feel for the kind of scope I was looking for and also some ideas to any teams who couldn’t come up with their own ideas. Using one of these examples had no effect on the final grade. Students were marked on their ability to understand the course material, put it into practice, write reports and present it to their peers; there were no prizes for originality.
• Allowing the students to choose their own implementation technologies was also a means to maximise their creativity. Programming languages, frameworks, operating systems… these are all ‘religious’ issues and every programmer has their own preferences. Enforcing the use of the university-maintained PHP/MySQL servers would have been a good way to create quite a few frustrated students who felt stifled and uninspired by the choice of tools. Of course, I made sure to verify all technology choices, in case a team wanted to use a completely unfamiliar or inappropriate technology.
• Finally, it was important for students to experience first-hand the consequences of their own choices. There are risks when embarking on a software development project:
  • Have we bitten off more than we can chew by choosing this topic?
  • Are we making a mistake choosing a cool but unfamiliar language?
  • Have we chosen a poor programming framework?
  • Have we picked the right ways of working together?
  • Is the infrastructure we’re using sufficient?
• Getting some of these wrong can lead to a project ‘failing’. Now, there’s a lot to be said for failure as a learning method. And also, what better time is there to make a mistake than in your formative/educational years? It’s a more forgiving time than when you have a career, that’s for certain. To be sure, some choices the students made wouldn’t work out, and, as long as they subsequently understood why, they serve as valuable lessons.

Outcome

As it went, the choices made by the students were varied and interesting. PHP was the most popular choice (roughly half the groups chose it), but other technologies like Ruby on Rails, Grails, .NET and JavaScript frameworks were also used. Furthermore, while few groups used the University’s hosting services, many elected to arrange their own. Clearly, they knew their own minds.

What I found particularly impressive, even though I wasn’t evaluating the students on this, was their originality and imagination. There’s clearly still a wealth of ideas for web-based applications out there if my students were a fair sample of the programming population.

I’ll leave you with a selection of the ideas to see for yourself (links correct at time of writing):

• Crowdstory: An application for the community-driven writing of stories. Allows voting and discussion on sections of the story.
• Div@: A place where you can discuss sites you disapprove of without linking to them (and thus giving them traffic) — instead, the app samples the target site as screenshots.
• MoPad: A mobile game controller system. Multiplayer games are hosted in the browser and you use your mobile device (e.g. smartphone, tablet) as the controller.
• Tourathon: An app which generates a tour of specific types of places between waypoints. For example, you can go on a pub crawl by specifying two points and requesting pubs/bars between them; a route which takes you along the pubs is generated. Integrates with Google Maps and Facebook (so you can share tours with friends).
• Yum.is: Taking photos of your food is a popular pastime. This app allows you to upload your food photos to the site and link them with places they’re served on Google Maps. You can also use GPS positioning to get a selection of photos (or yums as they’re known here) in your area.

I knew that PHP was popular, but was surprised by the extent to which it outshines all other languages. Taking these figures at face value, it seems that knowing PHP is essential to a career in web programming. But that’s hardly news.

Still, some things should temper any interpretation of this chart. The method used at W3Techs is not clearly made available, but they claim to automatically analyse the top-ranking 1 million websites for indicators of a technology (the HTML elements, URL structure etc). Without the method being made clear, it can’t be determined whether there are any problems with false positives (judging that a language is used by a site when it isn’t) or false negatives (failing to count a language that is used by a site). We simply have to assume the data is accurate.

Also, if we’re asking which languages do we need for a career in web programming, another thing to consider is that PHP is the language behind a lot of frameworks which people deploy on servers so they can avoid programming: all those WordPress blogs, MediaWikis and Drupal sites. It could be that many analysed sites are blogs or wikis whose maintainers have never needed even to touch the code. Still, it’s not uncommon that the need arises to delve into your framework’s innards in order to customise it or fix a bug.

Despite these reservations about the stats, I’m still happy to agree that PHP is the mostly widely used language and it should be part of your toolbox if you wish to make a serious career in web programming. Here’s two reasons to strengthen that notion:

You will probably maintain existing code

When you start a new programming job, you’ll probably begin working on an already existing system. It’s relatively rare to start a new system from scratch and choose whichever sexy technology you want; more likely, you’ll be handed an existing body of code, thus the choice of language is out of your hands. And if you’re using a framework, be aware that businesses have a knack for wanting a very specific bit of functionality from their software that the existing framework doesn’t quite provide, meaning there’s a real chance you’ll have to get hands dirty in the code anyway.

Programming languages have staying power

Hardware and software are both part of “computing”, but they often behave in very different ways. We’re used to the hardware industry as one which constantly reinvents itself every couple of years: what rules the roost one year is old hat a few years later (read the excellent Innovator’s Dilemma by Clayton M. Christensen for more on that). Programming languages are not like that. Writing software is a hard and expensive activity; once a program has been written and debugged, it becomes a dangerous and costly proposition to replace it with something new. Hence, programs tend to endure in ways that hardware never does. Languages like C, FORTRAN and COBOL have all been around since Elvis Presley was alive, but there are still billions upon billions of lines of code out there written in these languages. Why should PHP behave any differently? It’s hard to make predictions, especially about the future, but experience of the software industry shows that whatever language is widely-used today will remain so for a long time. Don’t bet on it losing popularity any time soon.

As of yet, my particular trainings are still offered with the understanding that content will be delivered mostly in English. I am in the awkward position of being able to speak a good deal of conversational German (thus I can deal with students face-to-face in the language), but trying to deliver a whole series of lessons in German would just compromise the quality of the teaching.

But I’m still learning. One day, very soon I suspect, teaching fully in German will be possible.