Get out there, they said. Taste the real life, they said. It will be fun, they said. And they were so very right! In catching an internship at itemis, not only a wish came true, I also learned a lot about software development in an open-source project.
I‘m Eva, usually studying information systems and philosophy in Münster. Since I used Xtext and Xtend for developing a DSL in the context of my bachelor thesis, I was really curious what it might feel like to work at itemis AG.
To my delight, my term appeared to end early, so I took all my courage in both hands and sent an application to the itemis locations Hamburg and Berlin. After a week of hoping and crossed fingers, Sebastian emailed, if we could talk about a six weeks internship – and only another week later I arrived in Berlin.
After a tour through the bright and modern rooms of the itemis office in Berlin, Sebastian explained my first task: to add a small convenience to the Xtend editor. Programmers should be notified if they have named a class AbstractFoo but forgot to add the abstract modifier. So far, such a mishap might have slipped unrecognized into the build process and would have caused errors there, especially if test utilities were not declared abstract.
As a first step to my very first open source contribution, we phrased an issue report on GitHub, describing the problem and a preferred solution (have a peek: https://github.com/eclipse/xtext-xtend/issues/719). Immediately, Xtext contributors joined and discussed how and where to add this feature best.
With this new input, I started developing. The additional validator method was quickly written – but what I liked the most, was the time and actual wish to write some JUnit tests for that method. The advantages of test-driven (or at least test-oriented) development are widely and constantly preached, however, there is never time or effort left to do so for tasks in a university context. So, the green bar of the eventually successful (and admittedly quite simple) JUnit tests was a nice reward for the first day’s work.
Pretty motivated by this start, I extended my tests to more complex cases and refined my solution. I made it possible to configure the severity of the raised issue regarding the forgotten abstract between marking it as an error and ignoring it completely.
Afterwards, I could add one of my favourite Xtext capabilities: offering a quick fix to that issue and insert the missing modifier. That behaviour was covered by JUnit tests, too – of course.
After all this pleasure, the real challenge came: taming Git. Despite its very useful and powerful features and its quite straightforward workflow, committing my changes did not work for the first few tries. But with the help of the online community and supportive colleagues, I eventually succeeded.
To add my feature to the Xtend project, I forked the official repository and created a fresh branch to develop independently. There I would commit my changes in small, organised steps. For a later easy and fast-forward merge into the official repository, this branch would be rebased, putting my new changes on top of the most recent status (For more detail: https://github.com/eclipse/xtext/blob/master/CONTRIBUTING.md).
So far the straightforward theory. However, I got lost somewhere between creating my own branch and rebasing. Thus the commit history is way less neat than the theory promised.
Nonetheless I started a pull request to add my feature to the Xtend project, and I did not have to wait long until my request was commented (you can have look at this, too: https://github.com/eclipse/xtext-xtend/pull/724). Although I expected to have considered most things, the professional committers’ eagle eyes still saw room for improvement.
Beginning from formatting and styling the code according to their standard, on to meaningfully named methods and phrasing warning notes, to even fixing a bug in an older method I used.
At first I was surprised by the multitude of comments and how much I seemed to have forgotten to take into account. But above all it were so many comments, because they were very precisely to the spot in the code, and they always provided constructive notes on how to make it better. The Xtend guardians were very patient and supportive with my attempts to make fixes according to their remarks, despite my repeatedly struggling commits, which sometimes made the existent mistakes even worse.
But just because of that, I learned a lot about a correct Git commit workflow – a skill one does not acquire at university. Eventually, everything was corrected, and the commits were accomplished, so that my pull request was merged into the official repository and my feature got into the new Xtext 2.17 release!
And even more than that: Shortly after the merge into the official repository, the feature unfolded its full effect and pointed out some classes that were meant to be abstract for several years, but were never declared abstract. Thanks to the quick fix feature, these mishaps were quickly resolved and will not cause errors any longer.
It makes me really proud to have contributed something to an open-source project that I hold in high regard and which is used broadly. Besides, it was extraordinary how the remote and local Xtext community always offered helpful advice and ideas. I’m glad I got out here to experience this and to be able to contribute a bit more during the rest of my internship.
Do you also feel like you are facing new challenges, growing in your tasks and personally developing yourself? Then join our team!