Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Okay, ehrlich gesagt haben wir keine Ahnung, ob diese Fragen häufig gestellt werden. Wir haben zu selten unsere Strichliste dabei. Aber es sind zumindest Fragen, von denen wir denken, dass man sie haben könnte. Oder sollte. Kein Druck.

Ich habe meine iLearn-Anmeldung vergeigt. Was soll ich tun?

Auf der Über-Seite im iLearn steht die Kontaktperson für derlei Fälle, Jan Tikovsky. Schreibt ihm eine nette Mail, dann kümmert er sich drum.

Wo kann ich außerhalb der praktischen Übungen arbeiten?

Eine Übersicht über Rechner- und Arbeitsräume findet sich hier. Wenn im Grundausbildungspool (kurz "GAP", in der Hermann-Rodewald-Straße 3, Raum 105a/b) genug Platz ist kann man sich üblicherweise einfach hinsetzen und dort arbeiten. Wenn zu dem Zeitpunkt ohnehin gerade eine Programmierungsübung stattfindet, kann man sogar unseren Hilfskräften Fragen stellen. Toll!

Wie frage ich so um Hilfe, dass Leute mir gerne und schnell helfen?

Du hast ein Problem mit deiner Abgabe zu einer Hausaufgabe? Oder irgendein anderes Problem? Wende dich gerne, falls es passt, an die Hiwis in deiner Übungsgruppe oder, falls das nicht passt, per Mail an deinen Übungsleiter. Um die Wahrscheinlichkeit zu erhöhen, dass er dir gerne hilft, solltest du ein paar Dinge beachten.

  1. Erwähne deinen Namen. Im Absender steht oft genug nur "stuIrgendwas". Die wenigsten kennen alle stu-Nummern auswendig.
  2. Erwähne, in welcher Übungsgruppe von welcher Veranstaltung du bist.
  3. Liefere alle Informationen mit, die möglicherweise helfen könnten. Wir könnten sie auch im iLearn suchen, aber das ist aufwendig und bei der Anzahl von Mails, die wir so kriegen, schwer machbar und ehrlich gesagt auch einfach nervig. (wink) Bei einer problematischen Abgabe beispielsweise sind folgende Infos praktisch:
    1. Der Quellcode.
    2. Die genaue Testausgabe.
    3. Eventuelle Theorien dazu, was das Problem sein könnte.
    4. Schritte, die bislang nicht zur Problemlösung geführt haben.

Die Tips hier gelten übrigens nicht nur in unserem Kontext. Generell steigt die Wahrscheinlichkeit, dass Leute einem helfen, mit der Mühe, die man sich macht, ihnen alle möglicherweise relevanten Informationen zu liefern.

Warum funktioniert mein Test nicht?

Zunächst sollten alle Testdurchläufe bei Bedarf eine Fehlermeldung erzeugen. Diese könnt ihr sehen, wenn ihr auf den entsprechenden Durchlauf klickt.
In den meisten Fällen sollte die Fehlermeldung eigentlich schon erklären was falsch läuft. Ein paar Meldungen können aber trotzdem nochmal erklärt werden.

a) Fehler beim Kompilieren

Falls wir das abgegebene Programm nicht kompilieren konnten, wird diese (oder zumindest eine ähnliche) Fehlermeldung erzeugt:

Für Kompilierfehler gibt es normalerweise zwei Ursachen:

  • Falscher Klassenname: Prüft ob die hochgeladene Klasse genau so heißt wie in der Aufgabe vorgegeben.
  • Falsches Package: Ein Package darf nur verwendet werden, wenn das auch in der Aufgabe erwähnt wird. Besonders am Anfang werden wir noch kein Package verwenden. Die entsprechende Warnung in Eclipse könnt ihr einfach ignorieren. Später muss das Package genau so heißen wie in der Aufgabe angegeben.

b) Keine Programmiersprache ausgewählt


Wir akzeptieren nur Java-Code in den automatischen Tests. Eine Stolperfalle ist, dass auch im iLearn die Programmiersprache auf Java eingestellt werden muss. Hierzu müsst ihr in der kleinen Box oberhalb eurer Abgabe Java auswählen.

Als kleiner Bonus habt ihr dann auch ein schönes Syntax-Highlighting in eurer Abgabe.

c) Der Style-Checker meckert

Manche Fehlermeldungen beginnen mit "The following output was generated checking the style of your code:"

Die meisten Formatierungsprobleme können in Eclipse recht einfach mit Ctrl-F (Cmd-F) behoben werden. Beispiele für Ausnahmen:

Name 'Ftemp' must match pattern '^[a-z][a-zA-Z0-9]*$'.

Hier ist das Problem, dass der Variablenname nicht mit einem Kleinbuchstaben beginnt. Zur Erklärung der Fehlermeldung: "^" steht für den Anfang des Namens, dann soll ein Kleinbuchstabe kommen, dann beliebig viele Buchstaben oder Ziffern, dann mit "$" das Ende des Namens.

In line 19: '}' should be on the same line.

Die (in diesem Fall zugegebenermaßen nicht sehr hilfreiche) Fehlermeldung hätte lauten sollen: '}' should be on the same line as the else keyword. Der Code hier sah folgendermaßen aus:

  19: }
  20: 
  21: else {

Die Fehlermeldung verschwindet bei folgendem Code:

  19: } else {

d) Der Test geht gar nicht

Es kann eine andere Fehlermeldung mit einem Fehlercode angezeigt werden. Üblicherweise ist das kein Fehler von euch (zur Ausnahme siehe b), sondern etwas ist an unserer Infrastruktur kaputt. Bitte meldet solche Fehler bei eurem Übungsgruppenleiter und/oder bei Nis (nbw@informatik.uni-kiel.de).

Warum Java? Ich finde <beliebige Sprache> besser!

Um mal aus dem Buch zu zitieren:

The purpose of this book is to teach you the fundamentals of programming. Along the way, you will become quite familiar with a particular programming language called Java, but the details of that language are not the main point. Programming is the science of solving problems by computer, and most of what you learn from this text will be independent of the specific details of Java.

Das fasst ganz gut zusammen, worum es uns geht: wir benutzen Java als das Beispiel, an dem wir Programmieren lernen wollen. Natürlich könnten wir auch andere Sprachen benutzen. Für Java haben wir uns aus verschiedenen Gründen entschieden:

  • Wir können an Java alles zeigen, was wir zeigen wollen.
  • Es gibt im Internet viele Ressourcen zu Java.
  • Java ist weiterhin eine der meist verwendeten Sprachen.

Wir könnten jetzt natürlich ewig über die speziellen Vor- und Nachteile von Java gegenüber anderen Sprachen diskutieren, aber ehrlich gesagt verbringen wir unsere Zeit lieber produktiv...

Warum Englisch? Ich finde <beliebige Sprache> besser!

Kurze Antwort: weil Englisch für Informatiker wichtig ist.

Längere Antwort: weil Englisch für Informatiker wichtig ist. Wirklich wichtig. Das geht im Studium los, sogar schon in dieser Vorlesung, und das nicht nur, weil die meisten zur Verfügung gestellten Materialien (Buch, Folien) auf englisch sind. Etwas weiter geschaut – ein Anspruch dieser Vorlesung ist, dass erfolgreiche Teilnehmende etwas mit Quellen wie der Java Language Specification anfangen können, welche, wie die allermeisten Sprachstandards, auf englisch gehalten ist. Auf wichtigen Foren wie Stackoverflow, welche sich Informatiker zu nutze machen können sollten, wird englisch gesprochen. Die Suche nach "programming" auf google liefert zum Zeitpunkt des Schreibens dieser Zeilen ca. 30 mal mehr Treffer als die Suche nach "Programmierung". Die allermeiste Software, ob open-source oder nicht, ist auf englisch dokumentiert und auf englisch "geschrieben" (Kommentare, Namen, etc.). So ist es z.B. auch bei Bewerbungen sicher nicht von Nachteil, wenn man darauf verweisen kann, im Studium von Anfang an (auch) mit englischen Materialien gearbeitet zu haben.

Zum Glück scheint, laut Umfrageergebnissen hierzu, für die allermeisten die Verwendung von Englisch kein erhebliches Problem zu sein, und sehr viele begrüßen ausdrücklich die Verwendung von Englisch. Tatsächlich kann Deutsch in der Informatik ziemlich grausam sein, mit Stapelspeichern, Programmbindern, und nicht zuletzt der Müllabfuhr, die die Halde regelmäßig von Abfall befreit. Trotzdem sind wir uns darüber im Klaren, dass Englisch eine zusätzliche Hürde sein kann, neben allen anderen Herausforderungen, die ein Studium so mit sich bringt. Von daher bemühen wir uns, den Einstieg so einfach wie möglich zu machen, z.B., indem Erläuterungen in Vorlesung und Übungen auf deutsch erfolgen, und wir auch auf deutschsprachige Literatur verweisen. Zum Schluss, vielleicht etwas zur Beruhigung, falls sich doch noch jemand Sorgen macht: in der Klausur werden Aufgaben auf englisch und deutsch gestellt, und Antworten können in beiderlei Sprachen verfasst werden.

Warum besteht in den praktischen Übungen Anwesenheitspflicht?

Kurze Antwort: wegen der Minitestate. Zitat aus der EvaSys-Umfrage vom WS15/16: "Ich finde das Losverfahren zu den Testaten sehr clever gelöst, da man nicht weiß, wann man geprüft wird und sich grundsätzlich immer vorbereiten muss."

Ganz lange Antwort: zunächst einmal nicht, weil es uns Spaß macht, Anwesenheiten zu kontrollieren, Leute zu gängeln, oder dogmatische Diskussionen über Sinn und Unsinn von Zwängen jeglicher Art während des Studiums und überhaupt zu führen. Tatsächlich ändern die knapp zwei Stunden Anwesenheitspflicht in der Woche, die ca. 10% der für ein 10-ECTS-Modul vorgesehenen nominellen work load entsprechen, wenig daran, dass Eigenmotivation & Selbstorganisation von Anfang an wichtig für ein erfolgreiches Studium sind und die Verantwortung für den Lernerfolg letztlich auf Seiten der Studierenden liegt, auch in InfProgOO.

Warum also dann Anwesenheitspflicht in den praktischen Übungen, wo dies doch in anderen Lehrveranstaltungen kaum verlangt wird, der verantwortliche Dozent (RvH) in anderen Veranstaltungen auch nicht auf die Idee kommt, Anwesenheitspflicht zu fordern, und wir generell bestrebt sind, unsere Angebote so gut zu machen, dass die Veranstaltungen auch ohne Zwang gut besucht sind? Antwort: primär, um einen (relativ) verlässlichen Rahmen für einen regelmäßigen, persönlichen Austausch zwischen Lehrenden und Studierenden zu schaffen, der bei uns unter dem Namen "Minitestate" läuft. "Austausch" mag hier zunächst etwas nach einem Euphemismus klingen, aber genau das ist damit gemeint: wir unterhalten uns und schauen gemeinsam auf Abgaben, damit beide Seiten wissen, wie der Stand ist, und wo evt. noch nachgesteuert werden sollte. O-Ton eines Testanden: "man geht aus einem Testat immer schlauer heraus als man herein gekommen ist."

Es wäre sicher denkbar, die Minitestate auch ohne Anwesenheitspflicht zu regeln, mit individuellen Terminvereinbarungen. Jedoch wäre dies zum einen weniger "clever" im Sinne des Eingangszitats; zum anderen, für uns zugegebenermaßen noch wichtiger, würde dies bei der Anzahl abzunehmender Testate pro Semester (im WS 15/16 waren es 643 an der Zahl) einen noch deutlich größeren administrativen Aufwand bedeuten, selbst wenn wir optimistischerweise annehmen, dass 95% der Terminvereinbarungen reibungslos klappen würden. Aber selbst hierüber würden wir noch nachdenken, wenn wir das Gefühl hätten, dass die Anwesenheitspflicht ein ernsthaftes Problem für Studierende wäre, und das soweit geäußerte Unverständnis der Anwesenheitspflicht (ist vorgekommen, deswegen dieser ausführliche Text) repräsentativ wäre. Tatsächlich scheint jedoch die breite Mehrheit der Vorlesungsteilnehmenden die jetzige Regelung nachvollziehen zu können und als zumutbar zu empfinden. Von 225 anonym abgegebenen Freitextkommentaren, welche in einer laufenden Umfrage im WS 16/17 abgegeben wurden, äußerte sich keiner (in Worten: keiner) zur Anwesenheitspflicht. (Übrigens auch nicht in Sachen "Englisch", siehe oben.) Bei einer Umfrage unter den Klausurteilnehmenden im WS 15/16 haben sich 75 von 113 Befragten explizit für eine Beibehaltung der Anwesenheitspflicht ausgesprochen (für die komplette Umfrage siehe http://www.informatik.uni-kiel.de/~rvh/downloads/UmfrageEndeWS2015-16.pdf). Wir bemühen uns auch, die praktischen Unannehmlichkeiten eines festen Termins in der Woche so gering wie möglich zu halten, auch z.B. unter dem Aspekt der Familienfreundlichkeit. So bekamen bisher immer alle Teilnehmenden von den möglichen Übungsterminen (in der Regel derer 10) einen ihrer Top-3-Wünsche (dank Informatik!), die meisten sogar ihren Erstwunsch. Und wenn es in Einzelfällen harte Zeitkonflikte gegeben hat, haben wir stets einvernehmliche Lösungen gefunden.

Schließlich auch nochmal die positive Sicht - über die man sicher beim Kaltgetränk trefflich philosophieren kann: das "Gruppenerlebnis" beim Programmieren und die unmittelbare Verfügbarkeit von erfahrenen Ansprechpartnern, ein Gutteil davon aus Steuergeldern bezahlt, können tatsächlich hilfreich sein. Dies vielleicht auch und gerade für diejenigen, die sonst eher "im stillen Kämmerlein" alleine an den Aufgaben sitzen würden. Und ja, es gibt sicher auch Leute, die schon vorher (fast) alles wissen, und es vielleicht zu recht als überflüssig empfinden, zwangsverpflichtet zu werden, gemeinsam mit ihren weniger vorgebildeten Studiengenossen Zeit im GAP zu verbringen. Aber denjenigen sei gesagt, dass nicht nur selbst Dinge lernen, sondern auch anderen Leuten Dinge zeigen Spaß machen kann - wir wissen, wovon wir reden. Und neben der Gelegenheit, seinen weniger schnellen Mitmenschen zu helfen, gibt es gegen eventuelle Langeweile noch Dinge wie das C4 System.

Schließlich noch ein paar praktische Hinweise zum Arbeiten im GAP: es ist ok und sogar gewünscht, sich nicht nur mit dem "Personal" sondern auch untereinander über Lösungsstrategien etc. zu unterhalten. Dabei sollte aber bitte Rücksicht auf andere genommen werden, insbesondere was die Lautstärke betrifft. Wer sich trotzdem nachhaltig gestört fühlt, möge bitte a) die Störer freundlich bitten, leiser zu sein, oder b) sich eine ruhigere Ecke im GAP suchen. Fall c), der/die aufsichtführende Mitarbeiter/in muss um Hilfe gebeten werden, ist auch denkbar, bisher aber noch nicht vorgekommen. Und schließlich: im GAP kann es bei voller Belegung und schlecht eingestellter Lüftung schnell stickig werden. Falls es unangenehm wird, bitte nicht zögern, dies kundzutun; der freundliche, normalerweise testierende Mensch am Dozententisch kann dann z.B. den Technikservice (http://www.inf.uni-kiel.de/de/service/technik-service) oder das Gebäudemanagement (Herr Groth, Tel. 2656) anrufen, in der Regel erfolgt dann schnell Linderung. Und jetzt danke für's Lesen bis hierher und viel Spaß beim Programmieren (smile)

  • No labels