Perl Ecosystem Group - looking back a week later

A week ago I was sitting in a room in Nürnberg coding away on the Plat_Forms
2011 contest.  It's now time for me to collect my thoughts and consider how
well the Perl Ecosystem Group did or didn't do.

Our group was probably different from all the others in that before arriving
in Nürnberg none of us had ever met any of the other members of the team.
(Actually, that's not true - Rob tells me that we were both at the Nordic Perl
Workshop in Stockholm in 2008, but I'm afraid that much to my shame I don't
remember that.)  Andreas and his wife very kindly offered to put us up, and I
duly drove up from Zürich and arrived on Sunday afternoon.

After a little time chatting we got down to the serious business of deciding
which technologies to use and how to approach the competition.  We had
discussed this previously, but had not made a final decision on some of the
technologies.  The final deliverable had to be a VMWare image to run on VMWare
Server 2 and we needed to decide which operating system to use.  Since Andreas
was providing the server his opinion carried most weight here and so, whilst I
would have preferred a Ubuntu server, we settled on Gentoo.

I installed VMWare Server 2 on my laptop, but was not overly impressed.  It
took quite a while to set it up and get the console plugin installed in a
browser.  My hope was that we could all develop in the same environment as
that in which the final solution would be deployed.  In the end, I decided
that would cause more pain than benefit and that I would keep developing in
the VirtualBox image I have that runs Ubuntu.

Most of our other technologies were not hard to decide on.  We knew we would
be writing a web application and would need a database backend.  We decided to
use Catalyst, Plack, PostgreSQL and whatever bits of CPAN we needed.  We had
been postponing our decision on whether to to write our forms by hand or to
use the HTML::FormHandler module.  My concern was that I had never used this
particular module and, in my experience, whilst this sort of sugar can make
basic operations nice, simple and fast, deviating from the norm can cause
problems.  Andreas shared this concern, but had experience with using the
module and believed that it would be an advantage in general.  So we went with
it.  Part of my wanting to take part in this competition was to get back up to
speed with the state of the art in Perl-based web development.  The last time
I wrote a proper web site was (shortly) before Catalyst was around.

In order to hit the contest running, I had been (re)learning some of the
technologies we would use.  Some of them, such as Plack, were new to us all.
Others I had used a bit but wasn't really confident with.  Andreas had
suggested that looking at the 2007 competition would be an ideal warmup, and I
fully agreed.  Unfortunately, it turned out that we were all rather busy in
the time leading up to the contest and were not able to devote as much time to
this as we would have wanted, but what I did manage to do proved to be very
useful.  I was fairly sure, for instance, that we would need to register
users, log in and out, and update registration information.

Anyway, on Sunday evening we went out to dinner before turning in at a fairly
sensible hour.  I always plan to attend conferences fully rested so I can
enjoy the social aspects yet still make it in for the first talk of the day.
That never happens.  I planned to arrive in Nürnberg fully rested.  That
didn't happen either.  So I was very glad to have something of a lie-in on
Monday morning.

After breakfast Andreas and I continued looking at the technologies we would
use before loading up the car and heading to the venue in the mid-afternoon.
Being local, Andreas had thought it better to take something and not need it
than to want something which was sitting 10km away in his study.  Having a car
unusually devoid of a wife and children I had a similar thought, and so we
duly umplumbed the kitchen sink and reinstalled it in the smaller of the two
rooms that were available to us.  Our thoughts were that although there was
less room per team, the smaller number of teams might mean there was less
noise and fewer distractions.  To be fair to the other teams in our room, I
didn't really find myself unduly distracted by them, despite our fairly close
proximity.  It would be interesting to know what the teams in the other room
felt, but whenever I wandered in there for any reason, I don't recall noticing
it being at all noisy.

We didn't have time to unload the kitchen sink before needing to travel to the
train station to pick up Rob who was arriving from a minor detour to Berlin,
so we reserved our table and headed out.  Thankfully we had exchanged mobile
phone numbers and so we were eventually able to meet up with Rob, despite none
of us really knowing what the others looked like.  A short trip back to the
venue to properly unpack and set ourselves up, and then we went out for the
evening with the other Perl teams and one of the local Perl folk.

We went to a restaurant first, and then on the the Barfüsser which is a large
drinking establishment with its own onsite brewery.  Unfortunately, by the
time we got there they were closing shortly, though in any case we didn't want
to stay out too late.  We caught the tram back to Andreas' house, and then had
to set up Rob's environment.

Rob has a Mac, and we agreed that in order to keep our environments as similar
as possible he would try to develop on some sort of Linux box.  I don't recall
all the details, but we had options of VMWare Server 2 or VirtualBox, and
Gentoo or Ubuntu.  In the end, I believe, the one we managed to get working
first was a Ubuntu VM (basically the one I use) running on VirtualBox, but it
might have been on VMWare.  Then we needed to set up the database, install the
CPAN modules we needed and so forth.  Ultimately, this led to a rather later
night than might have been ideal.

Tuesday dawned bright and early.  Well, it was early anyway.  Starting a
programming contest at 9am?  Really?  Anyway, We managed to arrive spot on
time and gathered with the other teams for details of the contest.  It all
sounded rather simple, but as always the devil was in the detail.  And
studying the requirements in more detail it became apparent that we were
unlikely to finish the entire spec, and so we needed to decide on where we
should focus.

There was a large section of the requirements devoted to the REST web
services, and we decided that we would like to implement that as fully as
possible.  I remember reading that last time many teams didn't manage to do
that, and I'm sure that the organisers would like to do a lot of the testing
via the web services.  So we initially split our work with Andreas working on
the web services, since he had some experience in this area, Rob working on
the database and ORM mapping in DBIx::Class, and I started on the web frontend
and the authentication, since I had recently looked at that in preparation for
the contest.

And, as it turned out, we continued in largely the same fashion for the rest
of the contest.

Now, it is unlikely that this was the best way for us to have divided up the
work, but since we had never worked together before, and were thus unsure of
each others' abilities, I don't think it was a particularly wrong decision.
However, had I known that things would end up that way, I would have ditched
HTML::FormHandler from the start and written my own forms.  As I feared, the
module caused me more pain than benefit and lead to me interrupting Andreas on
a number of occasions to ask for assistance.  And Andreas himself, on the
other hand, as the one who knew the module, never actually used it.

By Monday afternoon we had made some good progress, but then we all found
ourselves getting somewhat bogged down.  For me, the problem was the
authentication.  I was unable to use exactly the method I had used before, due
to the web services also needing to be authenticated.  But trying to expand on
the simple method I had used previously was causing problems.  The conundrum
was finally solved by altering the authentication to "self_check" - the
solution being found by Andreas, but I had wasted far too much time on the
problem and felt rather annoyed.  I think that Rob and Andreas both felt
similarly about the problems with which they were wrestling.  Rob was reading
the JSON (warts and all) and populating the database.  I forget what exactly
Andreas was fighting with, but no doubt it had something to do with the web

Anyway, by Monday evening we had all moved on and were making better progress.

Every fifteen minutes, one of the organisers would come around a ask for a
brief answer to the question of what we were doing ten seconds ago.  I
understand why they did this, and for the purposes of the study I was happy to
answer, but this did have two consequences - one expected and one not so.

The expected consequence was that every fifteen minutes you were distracted
and it took time to get back into the flow.  Now, writing web applications is
not the most taxing development task, and so often this distraction was
minimal, and it was he same for all the teams, but nevertheless, it was not
particularly welcome.

In part this may have been because of the second, less expected consequence.
Fifteen minutes might seem like a fairly long time, but after someone has come
around and asked you what you are doing a few times, and you have given them
basically the same answer, you start to feel that you really aren't making any
progress, and you become fairly keenly aware of how the time is passing.  Now
this might be a cue that really it could be time to move on to something else,
at least for a bit.  But often you feel that an answer might be just around
the corner, and that this is a rather important problem that needs to be
solved anyway.

I believe that the majority of the problems we had as a team that fall into
this category are problems that were fairly generic, that is they were not
related to this particular application, but would have been present in any
similar application.  To that extent, it is a shame that we did not have either
the experience to have previously solved those problems on another project,
nor the time to have solved the 2007 problem, which would also have given us
the solutions.  The good news is that now we have the experience and the
solutions, next time should be a doddle.

Having been up fairly late the night before, and in common with the other two
Perl teams, we didn't stay until midnight, when the contest shut down for the
night.  Instead we left shortly after 11pm, when the other two Perl teams had
already left, but pretty much everyone else was still there.

We didn't talk too much about the contest on the way home, but when we got
back we did discuss some of the problem we had had, and managed to come up
with a few solutions.  I also needed to spend a little time on a few
work-related matters and so, once again, it wasn't really an early night.

I'm not sure that any of us set an alarm, and so we woke up fairly late, and
didn't get back to the venue until about 9:45 or so.  We were the last team to
arrive.  By quite a margin, I believe.  We also had to park miles away, and so
we had a brisk walk to the building.  But these things managed to conspire
together to make the morning rather productive for us.  Unfortunately, hunger
started to get the better of us, perhaps together with a realisation that we
were not going to be able to complete all of the "must" requirements, let
alone the rest of them.

At about 3pm, we met together to discuss where we stood, and what we were
going to do in the last few hours we had.  We tried to knock off some of the
important outstanding items, and make the whole things as usable as possible.
Andreas had still been working on the web services, I had still been working
on the web front end, though Rob had joined me, focussing on the social
networking features.  We decided that Andreas would shortly stop development
work and concentrate on making sure the server would function properly and
that we could package up our results for delivery as required.  We further
decided that at about 5:10 we would all stop development work and let Andreas
get on with the deployment.

As it turned out, I stopped by 5pm because I was concerned about the
deployment, and while Andreas was setting up the server I packaged up the
source code and repository.  Then Andreas started packaging the server image
itself.  Now whether the image being Gentoo just made it enormous, or perhaps
there was something else at play, I couldn't say, but zipping up the final
image just crawled.  It became apparent that we were not going to hit the
deadline of making the final zip file and checksumming it by 6pm.  The zip
process just for the image was taking well over 20 minutes.  In the end, we
sent the checksums for the two smaller zip files shortly before 6pm, the
checksum for the zipped image shortly after 6pm, and the checksum for the
final combined zip file after the group photographs had been taken.

So, how did it go?  Well, at the time I was a little disappointed, and I think
that Andreas and Rob felt similarly.  However, looking back on it, whilst
there are many things that I would do differently, I am not unhappy with what
we achieved.

And what are those many things I would have done differently, and what would I
have kept the same?

Looking at the team first, I'm not at all unhappy with how we performed
together.  We didn't know each other beforehand and had very little idea of
each others' skills, personalities, strengths or weaknesses.  I was very happy
to work with both Rob and Andreas - they are both very talented developers -
and I would gladly do so again.  However, looking at the Perl teams in general
- and this is something we discussed together afterwards - it may have been
wise for us to have mixed the teams up a little.  In the Shadowcat team there
was a wealth of knowledge about the tools we were using.  One member of that
team on our team would have helped us get over many of the stumbling blocks
that we hit.

And this brings up another interesting point.  In the real world, faced with
many of the problems we faced, I would have knocked up a short demo of the
problem and pasted (a link to) it in an appropriate IRC channel.  At that
point, I would likely have received a solution, or at least a strong shove in
the right direction, and I wouldn't have been at all surprised had it come
from someone who I could see sitting in the room next to me.  In return, I
would have been attempting to assist (probably) other people in a similar
fashion.  Due to the contest rules, none of the Perl teams worked that way,
and I feel we suffered for it.

Other things I would have done differently?  I think that next time I would
want to be sure that we were all developing on the same infrastructure and in
the same, or at least in compatible ways.  This didn't really cause great
problems for us, apart from a little wasted time, and one scary moment near
the end when a module needed to be upgraded, but that solution wasn't clear.

I would also have liked to have prepared more things beforehand.  Deploying to
the server and delivering the image didn't need to be worked out during the
contest.  RESTful web services were not a surprise, and getting authentication
of those, together with the rest of the app, could have been a copy and paste
job, rather than a debugging exercise.

We had a very basic looking design.  I know it's not a major priority, but it
probably wouldn't have been too much effort to make the app look better.

Partly because we were new to working together, and partly because of the
timing in development, we ended up with three ways of adding data to the app
at the intermediate level.  There was some code in the interactive part of the
web app, there was some code in the web service, and there was some code for
reading the JSON file.  That should, of course, have been abstracted more than
it was.  We had an ORM layer, of course, but we didn't have an add_member()
method, for example.  At least, not one that we all used.  The code
duplication was minimal, but we missed the chance to have a central point for
verification, for example.  Doing it again, I would have tried to put together
a more robust backend, but the time constraints did make this aspect a little

One of the questions we had discussed before the contest was concerning how
many tests we were going to write.  One of the things we all like to do as
Perl developers is to have reasonable code coverage from our automated tests.
For any important project this provides the safety net to show that the change
you have just made hasn't broken something.  It gives you the confidence to
refactor when required.  However, for this contest, we agreed that we should
probably focus on features rather than adding tests.  This is something I
would never do in the real world, and it proved to be quite an uncomfortable
way of developing.

Nevertheless, we did write some tests.  In fact, Andreas wrote quite a few for
the web services, and Rob also wrote some, but I don't think I wrote a single
test, which is completely alien to my usual style.  I looked at our code
coverage on Monday afternoon, and I think we had about 75%.  By the end this
was down to 65%.  Whilst those figures might seem fairly respectable, the
branch and condition coverage was way down in the single figures which hardly
bolsters confidence.

I found it quite a shame that we didn't get around to working on either of the
two more meaty problems in the requirements - the BNF parser or working with
the GPS coordinates.  Perl has a number of tools for working with BNF
grammars, one of which I was fairly familiar with a few years ago, and for
which I have code available on CPAN.  I expect either that, or one of the more
exciting newer tools would make fairly short work of that requirement, and I
plan to test this theory out at some point.  I wish I had done so during the
contest at the expense of some other work.

So, a week later, I'm fairly happy with what we accomplished, but I know that
we could have done much better.  In fact, I suspect that with the benefit of
the experience we gained in the contest, we could complete a similar amount of
work on a similar problem in half the time.  That would leave us with more
time to finish the requirements, or at least to get a lot further through

I'm now quite curious to find out how the other teams did, and to see the
analysis of the contest.  Many thanks to the organisers, the sponsors, the
other teams, and above all to Rob and Andreas.  Here's to next time!

Paul Johnson -

Perl Ecosystem Group



I am strongly interested to see results of the teams.
The links for the Internet-presentation of the solutions gives error.

My intersset is special, to see, which platform are more helpful to
finish the task in the given time. Which tools was used ?
Are there any programming example?

Yours Bernhard

We will publish the results here in a few months. A thorough scientific evaluation takes some time.

Ulrich Stärk