Mike Protts’ design narrative: Server side programming
Cloud created by:
24 March 2014
The ten hour web server
As one of the main software developers at a small software house, I shared responsibility in training and development of the development teams. The courses chosen were both externally and internally produced, with pair programming being one of the key areas that helped with peer development.
The small software house performed a large proportion of training in house, and when possible training would reflect the ideas of 'extreme' programming, with pairs working together to develop functional specifications, code and documentation at the same time. The course I designed was aimed at this approach, although the documentation was not part of the scope. The course was designed to be suitable for remote delivery or self learning later. A lot of the time was spent in a 'kitchen' area, set up with snacks and seats for discussion.
Introducing experienced client side developers to server side development techniques would help with understanding client/server interactions and giving developers opportunities to work in other areas. The course was planned to be delivered part time, roughly two hours per day over two weeks. One hour would be coding and the rest would be group discussion and feedback.
I chose a less common language for the course, as this would remove issues of over familiarity for the students, but all being experienced programmers would be expected to pick up the language to a sufficient skill level very rapidly.
The first task was to write a simple 'hello world' program, in this case a web server, with a standard web browser to see the results. The students would then develop their web server following the internet standards, adding functionality piece by piece. Sample programs from each stage (typically one hours work) was made available for comparison.
Students would test other pairs code at certain stages, with rewards for good ideas. Feedback would be incorporated into design changes for the next session.
The students were a bit reluctant to use another language at first, but accepted this did avoid them coding without thinking ;-). They were rather pleased that they'd all managed a working web server at the end of the first session, even if it was limited to a fixed response (some had experimented with giving extra information). For some the idea of designing a program without a computer at hand was very hard to start with, and laptops were arranged to allow note taking.
The essential use of multi threading and handling multiple connections was a trickier area for those whose experience was very desktop focussed, but also was quickly translated into improved code.
Working from the internet specifications (RFCs) was also a new area, and showed up both the constraints and flexibility available for design, with very different solutions from different groups.
At the end of two weeks, the pairs all had working web servers, with different levels of functionality, security and performance, which allowed more discussion on areas that need to be considered for server side programming.
Later transfer of the course to self study proved rather restricting, and wasonly trid once, but has worked again in a group setting. Use online has also been challenging, although one group did have some success, but mainly with extensive use of Skype for video conferencing.
One of the main achievments was a high degree of engagement, by presenting a very challenging task with short timescale. None of the students believed the ten hour web server was possible at all (even with my creative use of time), but by the end of the second session they were discussing how many features they might manage.?
The sample stages I had produced proved of limited use in the group sessions, as there were always alternatives on offer, but was more useful with the smaller online group (two sets of pairs).
Once I'd introduced the tasks, the bigger group ran most of the work themselves, with the strict time constraints seen as making a competition more fun, so was self policed. The small online group tended to spend a lot longer programming and less time discussing ideas, so needed to be brought back with more direct guidance.
The only negative aspect of feedback as a group activity was the choice or programming language, but the requirement to pick up the basics in a couple of hours limits choice. It would be better to not sidetrack the primary learning goals, so I'm considering how I can allow use of familiar language, but still ensure thinking about code being written.
The structure of the course was not adatable for self learning, and needs more work for online use, but I would recommend the 'extreme programming' model as a useful pedagogical idea, and I'll look into the literature to see how it's been used elswhere.