2017-04-26

Mit dem Fahrrad aus der Saarbrücker Innenstadt zur Uni

Ich bin die meisten Tage des Jahres mit dem Fahrrad aus der Saarbrücker Innenstadt zur Uni und zurück unterwegs.  Für alle, die auch gerne mit dem Fahrrad zur Uni wollen, habe ich hier meine drei Lieblingswege auf einer Google-Karte zusammengestellt; Details folgen unten.



Und hier sind die drei Wege, sortiert von Nord nach Süd:

Der Schnelle: Am Meerwiesertalweg entlang

Ein nützlicher Weg, getrennt geführt neben starkem Autoverkehr.

Hier geht es lang: Vom Hauptbahnhof aus über den Bormannpfad (Alternative: durch Parkhaus Hela schieben), die Dudweilerstraße kreuzen und auf den Meerwiesertalweg.  Dort führt ein für Radfahrer freigegebener Radweg immer geradeaus mit zunächst moderater Steigung bis hoch zur Uni. Auf dem letzten Stück zwischen Uni-Parkhaus und Pforte wird es steil.

Ein Weg für: Normalfahrer, die schnell von A nach B wollen.

Aufpassen: Am unteren Ende des Meerwiesertalwegs sind zahlreiche Einmündungen, wo Autofahrer  insbesondere von den stadteinwärts auf der linken Seite fahrenden Radfahrern überrascht werden; erst ab der Jugendherberge wird es entspannt.  Der Weg am Meerwiesertalweg ist ein für Radfahrer freigegebener Gehweg, also gilt es, besondere Rücksicht auf die (wenigen) Fußgänger zu nehmen.  (Radfahrer dürfen zwar auch auf der Fahrbahn des Meerwiesertalwegs fahren, was aber wegen starken Autoverkehrs auf enger Fahrbahn keinen Spaß macht.)

Bester Moment: Wenn es auf dem Rückweg am Parkhaus entlang steil herunter geht – das ist der Rücksturz zur Erde.

Alternativen: Innenstadt über Scheidter Straße verlassen (siehe unten), dann über den Ilseplatz und Waldhausweg in den Meerwiesertalweg umschwenken.  Wer die Steigung am Parkhaus nicht mag, kann auch das Gelände der Sporthochschule erkunden.

Der Sportliche: Durch den Stadtwald zur Uni

Mein morgendlicher Weg zur Uni – steil und schön

Hier geht es lang: Die Innenstadt über Beethovenstraße/Blumenstraße verlassen (eine ruhige Strecke entlang Einbahnstraßen, die laut Verkehrsentwicklungsplan irgendwann zur Fahrradstraße ausgebaut werden soll), auf die Scheidter Straße wechseln und bis zu deren Ende immer höher fahren.  Hinter der Wendeschleife geht es in den Wald, wo wir sofort links an der Schranke vorbei auf einen asphaltierten Waldweg wechseln, der uns bis zur Uni führt. Der Weg führt steil durch den lauschigen Stadtwald hinauf.  Etwa auf halbem Wege geht es dann bergab, man rollt entspannt zur Uni herab, und lässt den Schweiß im kühlenden Fahrtwind zurück.

Ein Weg für: Mountainbiker, Elektroräder, Naturliebhaber.

Aufpassen: Der Radweg entlang der Scheidter Straße ist durch parkende Autos von der Fahrbahn getrennt; ausfahrende und parkende Autofahrer übersehen hier Radfahrer gerne.  Der Waldweg ist unbeleuchtet; Schnee wird spät geräumt.  Auf dem Rückweg geht es auf der Scheidter Straße steil bergab, also besser auf der Fahrbahn bleiben.

Bester Moment: Morgens im Wald den Berg hinauf.  Nichts zu hören außer Vogelgezwitscher.

Anschlüsse: Noch höher hinaus?  Auf den Schwarzenbergturm für ein kleines Workout und oben die Aussicht genießen.

Der Flache: Über Schafbrücke und Scheidt

Feierabendstrecke mit nur moderaten Steigungen, die Hälfte auf ruhigen Wegen.

Hier geht es lang: Die Innenstadt an der Saar entlang verlassen; spätestens an der Ostspange nach links abbiegen und auf die B51 nach rechts fahren. Auf dem Radweg geht es an der B51 eher unproblematisch immer geradeaus. Nach den Römerkastell geht es auf einer Fahrradspur leicht bergauf; danach geht es nach links in die Breslauer Straße, und dann gleich rechts auf die andere Seite der Bahnstrecke.  Jetzt kommt der schöne Teil: Es geht auf ruhigen Wegen durch Schafbrücke immer an der Bahn entlang, bis wir in Scheidt nach der Überführung links abbiegen und wieder mit leichter Steigung zur Einfahrt Ost der Uni fahren.

Ein Weg für: Entspannte Kilometerfresser.  Leute, die zum Ostteil der Uni wollen.

Aufpassen: In der Innenstadt sind entlang der Mainzer Straße wie auch an der Saar viele Fußgänger unterwegs, also Rücksicht nehmen. Der Abschnitt Römerkastell-Breslauer Straße ist verkehrsreich; beim Linksabbiegen in die Breslauer Straße auf eine Rotphase warten, dann den Extra-Wartebereich für Fahrradfahrer nutzen, um sich links einzuordnen. Von Scheidt zur Uni führt der Radweg getrennt auf der linken Seite entlang; Vorsicht bei Einmündungen.

Bester Moment: Auf ruhigen Wegen flott durch Schafbrücke.

Alternativen: Zwischen Römerkastell und City sind Preußenstraße und/oder Halbergstraße verkehrsarme Fahrrad-Alternativen zur B51.  Wer im Saar-Basar einkaufen mag, kann das Gelände im Westen über eine Pforte via Eschberger Weg und Im Heimerswald erreichen.  Statt des asphaltierten Radweges von Scheidt zur Uni kann man auch am Rückhaltebecken links abbiegen und einen unbefestigten Waldweg nehmen.

Anschlüsse: Sehr schöne Radwege gibt es die Saar entlang Richtung Saarlouis oder Sarregemuines.  Der Radweg nach Scheidt führt auf ruhigen Wegen weiter an der Bahn entlang Richtung St. Ingbert.  Alle Radwege sind ausgeschildert.

Hinweis: Als Rückweg (also von Uni zur Innenstadt) attraktiver, da (a) leichtes Gefälle (b) am Römerkastell weniger Kreuzungen und (c) der verkehrsreiche Abschnitt zwischen Breslauer Straße und Römerkastell ist schnell überwunden. 

2017-01-13

Twelve LaTeX packages to get your paper accepted

(with Abhik Roychoydhury and Aditya Kanade)

Why do some people get all their papers accepted, and others do not?  You may already know that in many disciplines, using the LaTeX typesetting system correlates with having your paper accepted (in contrast to, say, Word).  What you may not know is that there is a number of LaTeX packages whose usage may be crucial for success.  Here we go:
  1. The pagefit package.  This immensely useful package makes your paper exactly fit within a given page limit, applying a genetic search algorithm to reduce baseline distances, white space, font sizes, or bibliographic references until it exactly fits.  Just write \usepackage[pages=12,includingbibliography]{pagefit} and enjoy.  
  2. The autocite package. Cites all relevant work that needs to be cited.  The "citepc" option additionally cites the entire program committee, whether their work is relevant or not.
  3. The translate package.  Auto-translates your paper into a given target language (default is English).  Just type

2016-10-14

PostDoc Position, Software Testing and Analysis / Software Engineering

At my Chair at Saarland University, we currently have a PostDoc position available, to be filled during the Spring of 2017.  We are looking for applicants in all areas of Software Engineering, with a special focus on experience in
  • Software Testing and Analysis
  • Security and Privacy
  • Specification and Specification Mining
  • Data Mining and Machine Learning
Your job is to conduct bold and risky research, possibly interacting with the several great PhD students at the chair.  Our most recent projects include
If such work inspires you, and if you see chances to combine your expertise and creativity with ours, we'll be happy to hear from you.  Please have a look at the official announcement and apply before December 1.

2016-09-07

On Facts and Dreams in Software Research


Where is the economic argument in program verification research, and where are the salvation messages in software engineering research?

I just had the pleasure of attending David Rosenblum’s keynote at ASE 2016, in which he praised the power of probabilistic thinking (using stochastic reasoning to estimate risks and support decisions) versus an absolutistic view in which there is only 100% truth or 100% failure.  His takeaway message was that software engineers should embrace probabilistic methods and permeate them throughout the development process.

As a software engineer, probabilistic thinking is a central part of my day-to-day job – in development as in research.  Whatever I build and design, I think about how useful it might be, which benefits it may bring, and what the associated risks are.  In Software Engineering research, the dominating metric is usefulness, which eventually translates into an economic argument: What does it cost? What are the benefits? What are the risks?  These are day-to-day questions in software development, and my research is expected to provide facts to help answer them.

In other fields of computer science, such as software verification, the economic perspective is much less argued about.  Instead, the message touted is an absolutistic message of salvation: If you apply this technique, you will get a 100% guarantee that your software satisfies certain requirements – that the computation will be correct, that it will not crash, or that it will terminate within specific time bounds.  For developers and society, this message feels like the second coming of Christ: The day will come and all your problems will be gone.  

Up to now, there are great examples of how software verification works, and there are impressive examples of it being successfully used in practice; and just to be clear: By no means would I want to reduce these research efforts.  But the systems formal verification is applied to are still small and constrained; and getting it to scale and widen will require enormous human effort reshaping existing systems – before salvation comes repent.  Do we actually know how costly formally verified software is?  Do we know how to teach its techniques to developers who do not hold a PhD?  Can we estimate the risks it brings to rely on freshly written specifications, rather than on mature systems?  Might "good enough" software be good enough?  When talking to researchers in software verification, such economic arguments are frequently missing in the debate. But as a society, we need to understand where money is best spent, and answers to such questions could very well guide the field of software research.

Conversely, just as formal verification may benefit from introducing an economic perspective, Software Engineering may profit from adapting a stronger salvation perspective.  What is it that Software Engineering research could produce that would be seen as a salvation in software development – a significant reduction of costs or risks?  Recent topics that come to my mind are automatic software debugging and repair, steering development processes based on mining software histories, or massive automated test generation.  Can we translate our capabilities into grand challenges that will provide salvation in the future, possibly even including guarantees?  Yes, I know there are “no silver bullets” in software development.  But any great research community should pursue great dreams as well as provide facts – and in this, all of us computer science researchers are in the same boat.

2016-06-28

Spiegel Online nutzt unsichere Cäsar-Chiffre: So lassen sich Spiegel Plus-Artikel lesen, ohne zu bezahlen

Der Spiegel-Verlag wagt einen neuen Versuch, mit Online-Journalismus Geld zu verdienen: Mit "Spiegel Plus" werden einzelne Artikel aus dem Online- und Magazin-Angebot gegen Geld angeboten.  Ich finde das aus mehreren Gründen gut:
  • Guter Journalismus will bezahlt werden
  • Ich zahle lieber für Artikel, als dass ich mit Werbung zugefüllt werde; und 
  • Ich bin sowieso Spiegel-Abonnent und kann somit ohnehin auf die Artikel zugreifen.
Die Art und Weise, wie Spiegel Online seine Paywall implementiert hat, ist allerdings noch verbesserungsbedürftig: Jeder Depp mit elementaren Programmier- und Verschlüsselungskenntnissen (= ich) kann die Sperre bequem umgehen, und mit Verfahren, die sich in jedem Kindersachbuch zum Thema Verschlüsselung finden lassen:

1. Man nehme einen Mac und surfe mit dem Safari-Browser die gewünschte Seite an – etwa diese.  Es folgt die Zahlungsaufforderung.  (Dummerweise gibt es keine Möglichkeit für Abonnenten wie mich, sich einzuloggen – was die nächsten Schritte motivierte.)


2. Man schalte den Browser in den Lese-Modus (Shift-Command-R).  Jetzt kommt der gesamte Artikel – allerdings ist der zu bezahlende Teil verschlüsselt.
3. Offensichtlich werden hier einzelne Zeichen durch andere Zeichen ersetzt – Leerzeichen und Absatzzwischenräume sind nach wie vor erkennbar.  Gleich zwei Absätze beginnen mit "Jo" – offensichtlich ein häufiges Wort.  Nehme ich jeweils den vorangegangenen Buchstaben, erhalte ich hier "In".  Gleichermaßen wird "Tfju" zu "Seit", und "Ebt" zu "Das".  Die Entwickler haben den Text mit einer Cäsar-Chiffre verschlüsselt – jeder Buchstabe wird durch seinen Nachfolger ersetzt.  Das ist das einfachste und unsicherste Verfahren der Verschlüsselung – und eine Beleidigung für jeden Sicherheitsexperten.

4. Wir markieren den verschlüsselten Text und kopieren ihn in die Zwischenablage (Command-C).  Dann surfen wir zu einer Seite, die die Cäsar-Verschlüsselung entschlüsselt – etwa hier.  Dort fügen wir den kopierten Text ins untere Feld, geben "1" als Verschiebung ein, und drücken auf "Decode" – und schon erscheint oben der entschlüsselte Artikeltext.  Umlaute und "z" sind zwar noch kaputt, aber dies sei dem geneigten Programmierer zur Übung überlassen.


Danke, lieber Spiegel, dass Du Dich seit Jahrzehnten an die Speerspitze des deutschen investigativen Journalismus stellst.  Jetzt musst Du nur noch das Schlusslicht in Sachen Verschlüsselung abgeben, und Du hast meinen vollen Respekt.  Kleiner Tipp: Unser CISPA-Institut gibt gerne Hinweise zu sicheren Verschlüsselungs- und Zahlungsverfahren :-)

Update vom 29.06.2016: Matthias Streitz von der Spiegel-Chefredaktion hat sich bei mir gemeldet – er dankt für den Hinweis und will prüfen, ob ihnen "noch etwas Schlaueres einfällt als die Cäsar-Verschiebung".  Ich bin optimistisch, dass ihnen das gelingen wird.

Update vom 20.06.2016: Die "niedrige Paywall" ist auch von anderen beobachtet wurden.

2016-05-23

My first talk at a scientific conference: A complete and utter disaster

I am just returning from ICSE 2016 in Austin, Texas; and once more, I have been impressed by the great many research talks.  For many of the presenters, this might have been there very first talk, and I was happy to see that it went pretty well for everyone.  My very first presentation at a scientific conference did not go so well.  Actually, it was a complete disaster.  But it eventually made me a professor.

I think it was in 1994, at the German Software Engineering "SE" Conference.  I was a PhD student in my second year, and my advisor, Gregor Snelting, had asked me to present a summary of our group's research.  At this time, we had worked on semantics-based retrieval of software components: You would enter the desired pre- and postconditions of your component in a search field, and the system would automatically retrieve a suitable component.  The novelty was that we were using theorem provers to find possibly weaker preconditions or possibly stronger postconditions.  At the time, theorem provers were just about to enter the programming language space, so this was all new and unheard of.

So, here I was, standing on the stage, in front of about 100 German-speaking SE researchers, presenting the NORA system.  (NORA stood for No Real Acronym.)  And I would be showing how to search for a function given a simple postcondition – something like


This, as the specialist will immediately recognize, is the postcondition for a sorting function: The output a'[] is sorted (1), and also is a permutation of the input a[] (2).  I think I was right in the middle of explaining the formula, when I saw that some member of the audience had stood up, looking right at me.  Then, with a defiant look on his face. he shouted:

"When I want to search for a sorting function, I do grep sort!"

"grep sort" is a UNIX command, and it would mean to simply search through a list of textual descriptions to find a sorting function.  The audience was absolutely silent.  For a second.  Then, the whole room erupted with laughter. I peeked at Gregor, my advisor, who was sitting in the front row.  He crossed his arms and then grinned at me: How would I get out of this?  I stammered something along the lines: Well, that's of course true, but assume you have no knowledge of sorting, you don't even know that the word "sort" exist, then with our method, you would still be able to find something.  The shouter would just chuckle, shake his head, and then sit down.  The idea that a programmer could not now what sorting means did not stroke him as realistic.

I was just about to recover from that blow and about to put up the slide with the theorem prover diagram, when the next guy stood up, a mocking smile on his lips.  "Yes?", I said.

"You know, to me this looks like a solution looking for a problem."

Again, the entire room erupted with laughter. I don't remember how I replied, but it was just as unconvincing as before.   I was finished, publicly humiliated and ridiculed.  Putting together the rest of my dignity, I quickly showed the remaining slides.  I think I got some applause at the end, and even a question.  Still, for the rest of the day, I was marked.  Every time a participant saw me, a smile would flash over her or his face for a fraction of a second, remembering my ridicule.

"Who were these folks?" I asked Gregor.  "Congrats", he said.  "These were Professors Manfred Nagl and Jochen Ludewig, two really big shots in Germany's Software Engineering.  You managed to provoke them.  That's good."  – "Good?" I said.  "These folks just ridiculed me in the front of the entire audience.  How would that be good?" – "Well, we'll be known!", he said.  "Yes, but for what?" I replied.  All the way home, I would be furious at these two hecklers who had so rudely ruined my presentation.  And I vowed that one day, I would become a real big researcher, and I would have the last laugh over them.

Over the course of the next twenty years, I would be busy fulfilling my vow, and yes, it sort of worked – never again would a member of the audience shout stuff at me.  (But then, this may also be due to me never again presenting formal methods at a Software Engineering audience.)  

The last laugh, though, never came to be. Two years ago, as I last met Professor Nagl and Professor Ludewig, I asked them whether they would still remember how we met the first time, with me on the stage, and them standing up in the middle of the talk; and I wanted to thank them for how their comments had fueled and ignited my ambition for decades.  Of course, they would not remember a thing.  For them, it was just a minor laugh among many.

2016-04-17

The new ICSE Erdős penalty, or why we should create incentives for frequent reviewers

Ever heard of Paul Erdős?  The 20th century Hungarian mathematician is not only known for his numerous contributions to Mathematics, but also for his multiple collaborations, engaging more than 500 collaborators.  Frequently, he would just show up on their doorstep, work with them for some hours, and then get a joint paper out of that.  A low Erdős number indicates academic closeness to Erdős, and is something one can brag about at academic venues.  Yet, if today, Paul Erdős knocked on your door, and asked whether you would like to work with him, you should avoid any collaboration with him – if you work in Software Engineering, that is.  Why is that?

The International Conference on Software Engineering, or ICSE for short, is the flagship conference of the field of Software Engineering.  If you want to publish and present your greatest work, this is where you submit it.  An ICSE submission is reviewed by three peer researchers, whose assessment eventually determines whether your work is accepted or not.  Even if your work gets rejected, you at least get detailed reviews and high quality feedback.

Over the years, ICSE has observed that there were authors who apparently were way more interested in the reviews than in getting their papers accepted; authors who would submit up to ten papers, of which none got in; but the authors would at least get thirty reviews, all for free.  This motivated ICSE to install a new limitation: Any single author can now appear only on up to three papers.  If you have four papers ready for submission, then you are supposed to select the best three.

The ICSE program chairs argue that few authors and even fewer acceptances would be affected by this decision.  But the problem with this decision is not the factual impact.  It is the potential impact.  What if a modern Paul Erdős knocked on your door and offered you to work with him?  You'd have to say no, because he would have too many co-authored submissions already.  What if you could not submit to the past conference, because you were the one organizing it, and still have work that wants to get published?  What if four of your students all have great results at the same time, results that should be shouted out to the world?  Well, too bad: you can only submit three of them, causing depression in the fourth student how is left out.  None of these is likely to happen, but the fact that it could happen is causing concerns and anxiety, and rightly so.  An open petition asking ICSE to revert its new rules has gained dozens of supporters overnight. (Disclaimer: me too.)

The Software Engineering community has members who have literally devoted their lives to Software Engineering research.  They have no spouses, no kids, they work day and night.  The boys would be out for a skiing weekend, and the girls would be out in their summer clothes – these folks are busy on the paper that they hope will make them famous.  They serve on program committees, they write reviews, they organize conferences, they help others on their PhD theses.  They are amazingly productive both on their own work as well as on the work of others.  And these are the men and women whom the new ICSE rules send the message: Thank you, but no, thank you.

The problem of ICSE – and our community in general – is not so much an abundance of papers.  It is the lack of reviews.  It is our publications that determine our academic worth; much less so teaching; and even less so service. Great papers get you tenure and a raise, whereas great reviewing might get you a committee dinner.  Rationally thinking, why should one spend time on reviews while one might just write papers that would get reviewed by others?  Fortunately, the large majority of our community is still driven by the Categorical Imperative: We profit from the reviews of others, so we review their papers, too.  What we don't like is members who game the system by not only submitting lots of papers, but also not participating in the review process.

Therefore, what our community needs to do is twofold.  First, we need to think about reviewing processes that scale well and get high-quality reviews.  The ICSE program board model is a step in the right direction; a VLDB-like journal model might be even better.  Second, we should not penalize researchers for their own productivity; but instead create incentives for researchers who spend great effort on reviews and service.  Rule by the carrot, not by the stick.

Such incentives for service should not be monetary (these wouldn't motivate researchers anyway); nor should they result in a different reviewing or acceptance process (this would be perceived as unfair).  But how about raising the limit of submissions if you have a co-author who is also a frequent reviewer?  Or allowing reviewing volunteers to apply for a one-day extension to the conference deadline?  (You'd get plenty of applications on the last day :-)  Or provide "fast track" journal reviewing for those authors who sport a status of "distinguished reviewer"?  With such incentives, if a prolific reviewer like Paul Erdős knocks on your door, you would not boot him, but embrace him instead.