Intelligent Systems, the Internet, and All That

Three weeks into my fourth term, and I can already say that I will be as busy as ever. Granted, there is one course less than in earlier terms. But the new and exciting things we are doing this term more than make up for that in intensity and involvement.

Computer networks was a course I expected to be full of dry, arcane technical details, very much the way operating systems was last term. In fact though the course has been a pleasant surprise in almost every way. The atmosphere is relaxed, the professor has a decent sense of humor, and the subject is a lot more interesting than I would have considered possible. I had thought computer networks would be all about technical stuff, sockets, protocols, and all that. It is that, too. But the professor is following a teaching classic, Computer Networking: A Top-Down Approach by James F. Kurose and Keith W. Ross, and as the subtitle indicates we are learning primarily how the internet works. Come on, where isn’t that fascinating? I have used the world-wide web almost every day since 1997, but in 20 years I had never quite understood what actually goes on in there. Or what happens, under the hood, when you send an e-mail? Our first homework assignment had us write an e-mail client in Java, using SSL security and base64 encoding. It took some figuring out, but hey, along the way I really talked with an actual SMTP server and I actually manually sent an e-mail complete with attachment, using sockets, MIME types, headers and so on. And now I can truly say I know how the e-mail magic works. Ain’t that something? Far from being specialized knowledge relevant only for specialists, it’s in fact almost of general educational value.

Our “compulsory choice” module is on adaptive systems–machines that learn, say to play a game, which is the choice example because it’s comparatively easy to set up as an environment: The rules are limited and well-known. The format of this course is five weeks of lecture on the theory and algorithms of some prominent approaches to machine-learning, namely Monte Carlo tree searches (evaluate the next game move by simulating random outcomes), reinforcement learning (learn by backpropagating costs and rewards of your action), and neural networks, which in fact do nothing less than simulate the inner workings of the human brain! All of these are hot topics of current developments in articifial intelligence. Not just thinking machines, but also operating on huge amounts of information (“big data”) is based on these concepts. So I find this quite fascinating and am rather glad I selected this module.

The flipside is that succeeding in this course will be quite a challenge. The professor expects us to find, each one of us individually, a field of interest and then do almost a small machine-learning research project before the end of the term: Master the relevant literature, set up an experimental environment, do the programming, document the results, give a 20-minute presentation en lieu of an exam, and submit a written paper. Enthusiastically I bought myself no less than four books, browsed the internet for hot topics, and started to learn Python. So far I have absolutely no idea what I’m going to do, but I should have one about two weeks hence, or the rest of the term won’t suffice to actually do the research and the programming. And the professor is setting the bar very high: To succeed, you have to model the environment correctly and efficiently, document your approach and your results in a scientific way, and arrive at conclusions that are valid, complex, and, to quote him literally, “non-obvious”. Needless to say I find the proposition rather daunting. And I find it hard to even find the time to do the reading and thinking!

It is maybe rather unfortunate that the regular curriculum for the fourth term prescribes a course on intelligent systems that as least partially covers the same ground as my compulsory choice module. For in comparison it’s rather theoretical and dry. That’s in fact almost funny, because as I wrote a few weeks ago I expected intelligent systems to be quite enjoyable, much more so for instance than computer networks. But so far the lecture covers well-known stuff at a snail’s pace: First-order logic, Prolog programming, graph theory, i.e. search algorithms. And the more advanced stuff, if we ever get to it, is very likely to be exactly what we are doing in adaptive systems. Well. Worse things can happen than hearing the same things twice. Let’s embrace it as didactic repetition.

The bulk of our workload this term however is again software engineering, now part II. The lecture itself covers primarily project management skills plus some techniques like continuous integration, version control etc. we have already been using for a long time. It’s nearly laughable that something as basic as Git (the most popular version control software right now) is on the curriculum for the fourth term, when we have been using it from day one. For all of 24 hours when we started programming together with a quadratic equation solver in the first term we exchanged source code files per e-mail or USB stick. On the morning of the second day I registered a Bitbucket account and created our first Git repository. How could anybody live without version control for longer than that?

It’s the software engineering practicum, i.e. the software project we are building, that’s taking most of our time. It’s huge, complex, and in the frontend it involves technology we are barely familiar with, above all the Angular framework that’s written in Typescript, a language that transpiles to Javascript to run the application in a browser.

In the last four days I fought a desperate and lonely battle trying to induce Angular to map the data arriving from the backend via HTTP to Typescript classes in the frontend, and to make these classes observable using a shared message service, so any client who subscribed to this service would receive update events. Angular is a fast-moving target, so this marathon started with trying to reconcile the conflicting advice from about two dozen blog entries and Stackoverflow discussions. When I had finally decided on the pattern I found least difficult to understand, and had implemented it, I had no idea whether it worked (or to be honest, how it would work if it worked). And didn’t have any idea about testing Angular either. So I tried to improvise a small script, call a few methods that would cause changes and thus change messages to be emitted. I failed signally, which is an euphemism for I was banging my head against a brick wall for hours. While my programming partner seemingly was able to visualize our backend data using our frontend Typescript classes, I was unable to even call methods on the same classes–the error codes varied between “undefined” and the infamous “X is not a function”.

After hours of staring at nonsensical browser console messages it finally dawned on me that we had, all of us, been fooled by Javascript. Even my programming partner, usually the genius in our group, had assumed that the inconspicuous json() method in Javascript was somehow able to magically transform a JSON string into a complex Typescript object complete with instance variables and member functions (methods). Whereas in fact, and quite credibly, all json() does is create a dumb literal Javascript object with exactly the properties named in the JSON string. So while that object contained all the data, and thus looked rather like it were indeed what we wanted it to be, it was in no way even related to our Typescript class model. These classes were never instantiated–in fact they didn’t even have constructors. Yes, you may laugh now, should frontend be your thing–but we were all of us brought up with full-blown object-oriented languages where objects are instances of classes and not just objects.

So after I had my rubber duck moment trying to explain this to my wife, I spent the next morning manually mapping the JSON string to our Typescript classes, quite an effort considering that our class hierarchy is very deeply nested. Then I realized the next problem, namely that calling object constructors instead of having the objects be created by the framework meant I could no longer use dependency injection (automatic creation of dependent objects by the framework) to provide my message service to the classes that should use it to send messages. So I spent another two hours finding out how you still get a singleton (an object existing only once in the entire application) from that message without using dependency injection. For a message service that is created several times in different places instead of just once in a central location is simply no use at all. And having solved all that I still had no idea whether my message service in fact did anything at all!

So I passed the afternoon trying to learn testing Angular using the Karma and Jasmine tools. Hardly very intuitive for someone used to the very basic jUnit testing framework for Java, not to mention the problem or asynchronous method calls. But I slowly figured it out. In the evening I was finally able to test my message service. After all that it was hardly a surprise that it didn’t really do much at all …

I went to bed the second time in three days after a day full of frustration with the feeling I hadn’t achieved anything. And rightly so, because I had really no idea what I was doing. All I could do was monkey-see-monkey-do based on things other people had posted on the internet, and lot of trial and error at that. But at least now all the secondary obstacles were out of the way. I had a working frontend model and I had a testing environment. I could finally at least see what the stuff I copied from the internet did, provided it did something.

In the morning during the adaptive systems lecture (which at that moment was a not all that exciting because we were just applying algorithms) I read some of those blog entries again, and with the help of comparing against my test outcomes I slowly started to reconstruct what was happening, and what I wanted to achieve. And finally the pieces started falling into place. It always takes a long time for me to understand something new and unfamiliar, particularly when it’s as unintuitive as Javascript syntax and asynchronous web technology. But once the Gordian knot starts to unravel, I usually find that by then I already have all the necessary pieces stored somewhere in my mind and can fit them together quickly. From that moment it took me only minutes to discard three quarters of what I had written so far as completely unnecessary and reshape the remaining quarter so that it did what I wanted. And then I had my working shared message service, and the tests proved it. And I felt great.

But the long and short of it is that doing just my part of the work for this project and this sprint (a term from agile software engineering, a certain period with a defined goal) took me fully two days and some hours. Granted, this was my share for the entire two weeks this sprint is running, or even a little more, so I am now more or less free to concentrate on other courses for a week or so.

But it’s more than just time that goes into such a coding marathon. It’s a lot of mental energy, plenty of coping with frustration, a good deal of being unable to unwind even in the evening, and some heated discussion with the other team members. And since the code I’ve written will be reviewed by the others–or at least my former programming partner, who eats code for breakfast–I’m not even sure yet it’s really over. There is always this period of tension, this nervousness of whether my work will stand his critical scrutiny. I shouldn’t feel that way, I know, but I do. Before my code is accepted and being merged back into the development branch of our code base, there is always the chance that I will have to do parts of it–occasionally all of it–all over again.

So that’s the four courses I am attending this term. In addition, there is the tutorial course we are teaching for the technical CS freshmen. It’s not very involved, since it’s all about basic math terminology and concepts, but it’s still about three of hours a week for reading the lecture contents, doing the homework assignments and tests for ourselves, so we know what we’re talking about, and then the 90 minutes of actually being there.

Take all that in addition to having a house, three kids, and a wife who’s working as well, and you may imagine that even with one course less I am still busy as hell!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s