I’m feeling profoundly tired after an exhausting practice weekend with the choir. The first concert is on the coming weekend, and we’ve been singing six hours non-stop on Saturday and four hours on Sunday, followed by a two-hour photo session. Apparently we need pictures for the website, but I loathe such events. Donning formal evening cloths on a hot June afternoon, perspiring and trying to look relaxed while feeling thoroughly stupid, and then being asked to be funny … just not my kind of thing at all.
But being exhausted from anything other than studying is a surprising change. And in fact, the bachelor thesis aside which is a whole new kind of animal anyway, this last term at UAS has been quite stress-free so far. In fact, it’s just short of being enjoyable.
We have already completed five out of seven practicum assignments for the “Certified Tester” module, and four of them were really a breeze. Just challenging enough still to be fun, but usually easily done within the practicum meeting, with an hour or so to spare. Oddly one person in our team of four has made a habit of not contributing anything. He just sits slightly detached from the rest of us, doing something else entirely, or looking on disinterestedly. I can’t say what goes on in his mind, but at least he’s not disturbing us while we’re doing the actual work. The other three of us are working together nicely though, with everyone weighing in on equal terms and nobody dominating or getting impatient with the others. And incredibly we still get a lot of work done this way. It’s very inspiring.
Only once we failed. Last Tuesday the practicum assignment asked us to write GUI tests for the small Tic-Tac-Toe Java/Swing application we had already tested twice earlier. Somehow we managed to waste an hour trying to recursively identify all Swing objects in the application (which was a part of the assignment, but probably not a central one), and then another hour not getting a test to run that checked whether a pop-up window appeared, which somehow necessitated creating a thread supposed to survive the closing of the main program. For once, we simply weren’t finished when the meeting was over. Fortunately, and to our utter surprise, the professor didn’t insist on our handing in a complete solution. She said she had seen enough to satisfy her, and in any case the assignment was just about demonstrating some of the difficulties of GUI testing. We nodded and said, yeah sure, GUI tests are hell. Glad to get off so lightly.
Still, for a couple of days this rankled. That experience in the last databases practicum in the second term aside where we had deliberately been set up for failure, I have so far usually had the assignment complete well before the start of the practicum meeting and always before the end. It’s also quite possible that in spite of what she said the professor let us pass simply because you just don’t put a spoke in someone’s wheel this late in the game. In fact I’ve heard professors say that much several times before–you weed out those evidently unfitted for this study program in the first few terms, then you do your best to let the rest pass. But then I decided I don’t care. We had proven in four previous practicum meetings that we have what it takes. You don’t have to shine every time. In fact, it’s entirely possible that it was a psychological hurdle above all. I am a backend person. I do hate programming GUIs. Having to deal with one under time pressure makes me behave like a rabbit caught in the headlights. Maybe that’s all this was.
In the IT security practicum my practicum partner and I did indeed manage to submit the second assignment (the 3DES routine) ahead of time as planned, though that involved a tense three hours of waiting in the practicum meeting of another group because we desperately wanted to submit our solution to the professor himself instead of to the often overly critical assistant. That didn’t work out, but we needn’t have worried. The assistant liked our work, because we had thoroughly refactored our code for DRY (don’t repeat yourself) and even written unit tests. Just the usual stuff to be sure (particularly DRY refactoring comes as natural to me as breathing by now), but apparently most other students don’t bother.
The third assignment seemed quite as easy at first. We had to use the Java security library to create keys for the RSA asymmetric encryption procedure, to encrypt a document using the symmetric AES algorithm, and send it, together with the RSA-encrypted and RSA-signed secret key, to another application that decrypted first the key, then the document itself using the key, and then verified the signature. A quite common procedure that happens behind the scenes in a lot of secure applications, and very instructive with respect to the contents of the lecture. And in fact we programmed it within just a few hours. And it worked more or less on the first try. Very nice.
Except the professor had provided a command line test of his own that we had to make pass. And that test blocked us for a couple of days. First it refused to run at all because it had been compiled in Java 9, and we’re all using Java 8. (Who wants to install a Java version that’s not long-term supported?) We asked the professor and he sent us a version compiled in Java 8.
And then the test refused to pass. We hunted down cryptic lowest-level error messages about DER octet strings for more than a day before we realized we were passing a wrong parameter in one place. It remains a mystery why our own tests ever passed, and why when we encrypted and decrypted we ever got the original file back.
Yet once we were done with that, the professor’s test still claimed it could not verify the signature. Now that was simply impossible. That Java library is very well documented and we did everything literally the way it was recommended in the documentation. Plus the secret key could actually be decrypted and used to decrypt the document, so why would verifying the signature–which after all is nothing but the flip side of encryption–fail? We went over the whole code again and again and again and could not find the error. The code did everything like everyone else did it. It worked. It was tested. So in the end we gave up and decided to submit our solution (which fulfilled about 99.5 per cent of the requirements for the assignment) and simply ask the professor why his test claimed otherwise.
Accordingly in the practicum meeting we tried again our best to demonstrate our work to the professor rather than the assistant, though of course that’s a chance game at the best of times because the two simply take turns. You can to a degree try to manipulate your position on the blackboard list of those who are ready to hand in their solutions, but in the end it’s basically a 50-50 chance. And we failed. With a sinking heart we talked the impatient assistant through our solution. And after we had shown him that our tests all passed and the routine did indeed produce the original PDF document as decryption output, he proclaimed himself satisfied and went to check off our names on the list of those having passed. He simply forgot to ask about the professor’s test!
We have never been out of a room so quickly. Just to be off before he had a chance to remember and ask us to show him this final test. Around the corner we burst into laughter. Two grown-ups giggling like school kids. Yeah, had we known it would work out this way we could have saved ourselves two days of debugging something we didn’t need, in the end. But on the other hand, we could rightly have been asked to make the test pass and we were really out of ideas there.
The same afternoon we basically completed the fourth and final assignment which was laughably easy in comparison. In a small program provided by the professor to illustrate the working of the Kerberos network authentication protocol, just implement four core methods so a token script faking a login process will run through, and do some logging and error handling to show it does. Once we had unconfused ourselves as to which session key was used exactly where in the somewhat confusing Kerberos protocol with its wealth of encrypted tickets etc. going to and fro, this took us just a few hours. Now we’re trying once more to hand in early, this afternoon, and if that works we’ll be all done with one of the two practica this last term.
I’ll say this however: In spite of their occasional hickups, the small assignments for this practicum support the lecture contents very effectively. There was no better way of understanding the logic and the intricacies of those procedures and algorithms than implementing them. I haven’t seen such a nice match between lecture and practicum since graph theory in the third term. Quite often the two have very little connection at all.
And I can’t say how happy I am to have finally, if very belatedly, have found the right practicum partner. With my first and long-term partner I felt always harried and patronized and had to fight to be allowed to do at least a part of the assignment my way. There is no way we could have worked together on the same piece of code because I am slow and he is absurdly impatient. The one or two times we tried it exploded within minutes. With my second partner it was rather the other way round. Save for his fascination with the technological side of the container stuff we did in the fifth term, it was usually me doing a good deal more of the work and hoping he would contribute at least something, and earlier than 48 hours before the deadline.
With my present partner I have finally found someone with whom I can work on equal terms. In fact, we do actually program together, taking turns typing, and the only small irritation is that she’s using a German keyboard while I prefer the US international layout. But other than that it’s unbelievably harmonic. No egos involved at all. No impatient snatching the keyboard or mouse away. No cries of “what are you doing there”. (Believe me, I’ve seen all that.) No, we just do what’s required, no more no less, in a very relaxed atmosphere, and I think we complement one another very well. And keep each other focused. My only regret is that this has come so late.
All in all this final term at UAS is really quite alright.