Earlier this month I had the honor of giving a couple hundred prospective students some insights into what it is like to study at TUM. Before my short talk, some of the student initiatives presented exciting projects they are working on (Hyperloop or rockets, anyone?). Since I am almost done with my studies, I hope I had enough interesting stories to tell 😉 . While I have given talks for school groups quite regularly, this one was special: It is not that often that a mere Master’s student gets to speak in the biggest lecture hall on campus – and to be honest it is a bit frightening and really exciting at the same time.
The talk was part of visiTUM, an initiative initially started by TUM Junge Akadamie that aims to give prospective undergrads an insight into student life at TUM by hearing from an actual student. It is a really rewarding way to be more involved at TUM and help out the next generation of TUM students. The folks in charge of visiTUM are running a workshop every semester, so be sure to check them out if you are a student at TUM looking for an opportunity to volunteer.
In case they are helpful to anyone, here are the slides I used (almost exclusively pictures, so no puns this time I’m afraid 😛 ).
After really loving the experience last time, some friends from TUM and I decided to participate in this year’s edition of Hackaburg (a student-organized hackathon in Regensburg) as well. This time, we were a total of four friends back from undergrad: Ute, Christoph, Robert and me. Ute won last year’s Hackaburg with kooci (a gesture based voice assistant to help even people as untalented as me cook) and Christoph and I won the BMW Innovation Award with our team aMUSEmeasure working with brain waves. For Robert, it actually was his first Hackathon – so we had the perfect mixture of old tired veterans and fresh wide-eyed minds 😉
This year, we once more came without a concrete idea in mind, so while eating dinner we started brainstorming. We decided pretty early on that it would be fun to do something with hardware once more. After going through MLH’s list of hardware, we were intrigued with the myo armband which is able to recognize gestures. We borrowed two of those and started thinking about what we could do with them, settling on two different ideas: Either using them to compose music, or porting everyone’s child-time favorite Rock–Paper–Scissors so you can play it remotely.
Our final product: Employing two myo armbands, we recognize gestures of both hands and link them to music samples. You can compose your own tunes step-by-step: simply select the samples that you feel belong there. In order to make things even more interesting, you can also dynamically control the volume and adjust the speed of your creation by moving your arms up and down.
Without definitely deciding what to do in advance, we set forth and started implementing the parts that would be similar for both ideas. We settled on creating an application for MacOS, mostly because we had two Macs and none of us had ever done anything with MacOS before. Looking back, this might have been the type of decision that ends up costing you a whole lot of time and really putting your patience to the test.
The API for the armband forced us to use C++, while we needed to use Objective C to have access to the APIs which MacOS provides for playing sounds. In principle this sounds simple as Xcode offers support for this scenario. However, when we tried it, we were presented with cryptic error messages that told us we could not assign a RHS to a variable that had exactly the same type – supposedly there was no way to cast between the different types. After a lot of trial and error, we found an article that explained how to correctly wrap our Objective-C code in C++ (using among others the Pointers to Implementation idiom) and we finally got it to run.
As we were rapidly approaching the last 16 hours of the contest, we had a working command line application running that also managed to make some good noises. Nevertheless, we felt like our project would really benefit from a GUI to show the users what the software is doing at any given moment. This was where our decision to target MacOS came back to bite us (not just once but twice). Our first issue was that once we ported our code over into a GUI project and launched it in a separate thread, it was no longer able to connect to the armbands. At that time, what we did not know was that sandboxing caused this problem. It apparently applies to applications using Cocoa but not to command line tools. So after failing to make progress for a while, we decided we wanted to go for two separate executables as a workaround: One to process gestures, generate sounds and produce text that the other one can parse and display in a nicer way. While building this, I tried mocking the application that handles gestures and sounds by simply getting continuous input from top. The error message we were presented with was about not having sufficient privileges, so after wasting barely 6 hours we were able to get back to our initial setup with just one executable.
Now for the second problem: None of the people still awake at this point had any idea of how the drag&drop based tools for creating interfaces in Xcode worked (they are not as straightforward as it may sound). So everyone slowly lost faith and went to bed accepting the fact that there would be no GUI. Everyone, except for Robert that is, who apparently had a lot of midnight (or 3am 😉 ) oil to burn. When I came back the following morning, he had pretty much solved all the issues we encountered and presented us with a functioning GUI that just needed to be connected to the rest of the application, which we ended up doing in less than an hour.
After achieving this, we finally switched our samples one last time to make them harmonize better. Then, we demoed our application to two judges. (That is one of the things they had changed compared to last year: there were two rounds of judging with the first being more technical and with more time and the second round involving pitching in front of everyone on the big stage). While we were pretty happy with our results, the judges seemed considerably less so and did not even want to try the experience themselves. So we did not have too high hopes that we would make it to the next stage which made us all the more excited when we found out that we had in fact done it. And thanks to Ute’s kickass pitch and Christoph’s musical talents while demoing the experience (and of course also thanks to Robert and me doing what we do best – looking competent) we managed to convince the big jury once more and ended up taking home not just a lack of sleep and a lot of good memories but also some medals 🙂
In case you want to find out more, check out our devpost submission or head straight to GitHub for the code. If you speak German, be sure to give this article in the local paper a read too.
Every spring and fall students from leading technical universities across Europe head to another institution in the ATHENS network to take part in a one week intensive course on a topic of their choice. This March was the second time I had the opportunity to take part in this program. Two years ago I went to Télécom ParisTech to explore how information can be extracted from unstructured data sources such as the Wikipedia. I published a short writeup of that here.
This time around, I went to Technical University of Delft to look into how Data Science can be used to improve Software Engineering. The course was taught by Alberto Bacchelli who is SNFS Professor of Empirical Software Engineering at the University of Zurich and came back to TU Delft to teach two courses during ATHENS week. He is one of the leading figures in the field of Data Science in Software Engineering (also called Empirical Software Engineering) and has a ton of relevant publications.
A couple of weeks ago, I published a first article on code clones based on a paper I wrote a couple of terms back in my undergrad. If you haven’t read that one yet, give it a read first. In this part I focus on the different algorithmic approaches that can be used to detect code clones. And once more: All the stuff below is based on the German paper I wrote for a class on Software Quality, which is in turn based on the publications referenced in the paper and at the bottom of this page. Any gross oversimplifications and inaccuracies are entirely my fault.
So, what we have from the last post is an understanding of what code clones are, what different types of clones there are, and an understanding that we should try to avoid them if possible. Now, let’s take a look at how to detect such code clones in a code base (short of hiring someone to read code and just flag clones manually).
To do this we will consider four different approaches in increasing order of abstraction.
I’ve been keeping very busy since I moved to Norway for my internship, but today finally was one of those rainy October Sundays so I had the time to sit down and finally finish this post which I have been meaning to write for a little over a year but never got around to. Well, here it goes: All the stuff below is based on the German paper I wrote for this class, which is in turn based on the publications referenced in the paper and at the bottom of this page. Any gross oversimplifications and inaccuracies are entirely my fault.
Way back in the 6th semester of my Bachelor’s at TUM I had the opportunity to take a seminar class focusing on software quality. The general idea was to get a better understanding of what good code quality is and go beyond the notion of “a good developer know good code when they see it” and also to investigate if there are metrics that might be interesting. My topic was code clones and I was working under the supervision of a researcher at TUM who has published on exactly this topic.
What is a Code Clone?
First up, let’s define what we mean by Code Clone. One definition seems immediately obvious:
“Code Clones are segments of code that are similar according to some definition of similarity.” – Ira Baxter
However, that doesn’t really help us if we want a computer to analyze code to find clones. So let’s take a look at a definition used in literature that we can throw at a computer:
Type I clones: two segments are clones if they are identical save for whitespace and comments.
Type II clones: allow for consistent renaming of identifiers and changing the values of literals.
Type III clones: several statements may be different between clones.
Just a few weeks after coming back from my time abroad, I found myself travelling again for the weekend: In Regensburg (about 1h from Munich), Hackaburg was taking place for the second time. It is a student-run hackathon at OTH Regensburg. I had a blast there the last time, so I naturally decided to go this year as well.
Unlike most of the previous hackathons I attended, we already formed a team prior to the event – all of us Master’s students at TUM. Combined, our team has a little under 20 years of study time at TUM under the belt (which makes me feel kind of wise but also really old 😉 ).
The event kicked off with keynotes by sponsors and pitches by a couple of other participants looking for team members. Soon after, our team was sitting in a bar in downtown Regensburg, trying to think of what we wanted to build. While we had a bunch of decent ideas, none of them quite felt right. So, we decided to start over with a fresh mind the following morning.
Since I am at Waterloo this term I have the awesome opportunity to dive into North American Hackathon culture. The first event I took part in was Hack the North in the middle of September. It is Canada’s biggest hackathon and well known even in Europe.
After meeting a lot of awesome people at the team building and brainstorming session, I decided to form a team together with three full-time Waterloo students and we set out to pursue an education-related idea: Did your teachers in grade school ever reward you for doing well in class with stars and/or stickers? Some of our teachers went beyond this and rewarded their students with points that could be spent on rewards, such as pizza, movie days, and toys. This was the original idea for what later came to be called Points and Me; to create a elegant, approachable, and friendly system for rewarding students for excelling in academics.
So, a couple of other exchange students and me were asked to give a short presentation on our home universities and opportunities to go to Germany at The University of Waterloo. This post is an attempt to collect some of the relevant information so others can refer to it later.
This past Saturday, two friends and I took part in the German Collegiate Programming Contest. Since none of us actually trained much beforehand and it was the first ICPC-like programming contest for two thirds of the team (me included), we were not one of those teams that managed to solve almost all problems, but ended right in the middle of the ranking with a total of three solved problems (even though we were really, really close to solving four 😉 ).
Nevertheless, I’d like to share some insights into one of the problems the organizers of the GCPC came up with. I really like it because there is a beautiful algorithm that you can apply to it and (mostly because) it is somewhat StarTrek related 😉 . The problem I’m talking about is problem L of the GCPC 2016 which you can find in this PDF. The solution of course contains spoilers, so if the problem statement makes you curious I’d recommend giving it a try first and coming back later to see if you found a more elegant solution. If you are a TUM student, you can even run it against all the tests that were used in the contest on TUMJudge.
Earlier this month I attended Dragonhack in beautiful Ljubljana, Slovenia. It was a truly amazing hackathon and I got to know and work with a whole bunch of awesome people. Turns out the organizers made an aftermovie for the event which they have recently released and which I’m gonna share with you today. Try to see if you can spot me in the video, I haven’t found myself in it so far…
However, they also had a professional photographer at the venue who took over 200 photos, so there inevitably are also some photos of us. I’m gonna share the two best photos of us: One of our entire team deep in discussion and one of me on stage demoing our hack with my teammates in the background launching a last-minute effort to get our livedemo to work.