Restklassenringe

Im ersten Semester lernt man im Informatikstudium Restklassenringe kennen. Diese bilden die mathematische Basis für diverse Kryptographie (beispielsweise RSA), aber auch anderes Zeug wie CRC. Gestern hatte ich im Forum mal ne oberflächliche Einführung in das Thema gegeben. Und damit das nicht verloren geht, will ich das hier nochmal posten. Wer also kein Informatik studiert, aber aus welchen Gründen auch immer wissen will, was modulare Arithmetik ist und wie man in Restklassenringen rechnet, hier eine knappe Einführung. weiter lesen »

Wie behandelt man eigentlich Akkus?

Die Frage hab ich mir grad letztens mal wieder gestellt. Man will ja die Lebensdauer seiner Akkus nicht unnötig verkürzen. Dass es den berüchtigten Memory-Effekt bei den aktuellen Lithium-Akkus nicht mehr gibt, ist ja mehr oder weniger bekannt. Was aber nun wirklich zu beachten ist, ist gar nicht so leicht heraus zu finden. Im Netz findet man teilweise widersprüchliche Informationen. Auch kann sich durch den technischen Fortschritt so einiges geändert haben (und so wie ich das sehe, hat es das auch). So findet man massig Material aus zweifelhaften Quellen und weiß hinterher nicht mehr so richtig, was man denken soll. Und weils so schön ist, spendiere ich dem Netz eine weitere fragwürdige Quelle. ;-)

Hier erstmal zwei Links, die vielleicht ganz interessant sind:

Folgendes meine ich, herausgefunden zu haben: weiter lesen »

“Daemon” und “Darknet”

“Wie ich sehe, sind Sie mit den Mordfällen Pavlos und Singh befasst. Um Ihnen unnötigen Aufwand zu ersparen, sage ich Ihnen: Ich habe beide getötet. Warum, werden Sie bald erfahren. Allerdings haben Sie ein Problem. Sie können mich nicht verhaften. Sie können mich nicht aufhalten. Denn ich bin tot.”

Vor einiger Zeit habe ich Neuromancer von William Gibson gelesen. Ein bekanntes, viel gelobtes Buch. Und um ehrlich zu sein, war ich enttäuscht. Mal davon abgesehen, dass es manchmal unnötig schwer zu verstehen ist und wirr erscheint (insbesondere am Anfang; wird später besser; so richtig in Fahrt kommt die Geschichte aber nie), ist dort alles, was Technik betrifft… merkwürdig bzw. unrealistisch. Gut, das Buch stammt aus den 80er Jahren, aber dennoch: Mir hat das Buch nicht sonderlich gefallen udn so hab ich die beiden Folgebände gar nicht erst gelesen.

Ganz anders ist es mit dem, was ich jetzt gelsen habe: Daemon und Darknet von Daniel Suarez. Suarez ist Softwareentwickler und das merkt man. Technisch gesehen hat das, was er schreibt, im Großen und Ganzen Hand und Fuß. Und für einen Informatik-Studenten ist es ausgesprochen angenehm, wenn man einen Roman liest, in dem Begriffe wie “IP-Adresse”, “Formatstring-Hack” und “Quellcode” in einem technisch nachvollziehbaren Zusammenhang stehen. Man kann die Bücher auch lesen ohne diese Begriffe zu verstenen. Wenn man sie aber kennt und sieht, dass sie richtig verwendet werden, ist der Roman nochmal so gut. Auch die deutsche Übersetzung macht das nicht kaputt (im Gegensatz zu Fachliteratur lese ich Romane lieber in der deutschen Übersetzung). Es gibt zwar ein paar Stellen, bei denen ich vermute, dass die Übersetzung etwas Merkwürdiges gemacht hat. Das ist eindeutig im Rahmen und tut dem Lesegenuss keinen Abbruch.

Nun, worum gehts? Matthew Sobol ist Chef einer großen Computerspielefirma. Und er ist totsterbenskrank. Er leidet an einer Krankheit, an der er langsam aber sicher stirbt. Kurz nachdem aber die Meldung über seinen Tod durch die Medien geht, geschehen merkwürdige Dinge. Der Daemon, eine verteilte KI, die Sobol auf Basis seiner Computerspiele entwickelt hat, erwacht zum Leben und verfolgt düstere Pläne. Der Daemon wirbt Leute an, begeht Morde und infiltriert Firmennetze. Der Daemon übernimmt die Welt. Und gewisse Leute versuchen das zu verhindern.

Das hört sich ziemlich nach schwarz/weiß-Malerei mit vorhersehbarem Plot an, aber genau das ist es nicht. überhaupt nicht. Diverse Plot Points erzeugen nicht nur Spannung, sondern weichen auch die zu Anfang scheinbar noch herrschende schwarz/weiß- bzw. gut/böse-Trennung auf.

Wie von einem Thriller kaum anders zu erwarten, gehen massenweise Autos kaputt und an Toten mangelt es auch nicht. Und wie von Science-Fiction zu erwarten gibt es immer mal wieder (oder andauernd) Technik die so (noch) nicht existiert. Aber Daemon ist mehr als nur ein Thriller mit starkem Technikanteil. Manche Teile lesen sich wie ein Computerspiel, andere sind in hohem Maße gesellschaftskritisch. Es ist ein intelligenter Roman, der nachdenklich stimmt. Gerade auch, weil er sehr real wirkt. Viel tennt uns nicht von der Welt des Romans — sowohl gesellschaftlich als auch technologisch.

Ich könnte jetzt noch in den Krümeln suchen. Ich könnte erklären, was technisch so nicht funktioniert (z.B. das Portieren einer Computerspiel-Auto-KI auf ein richtiges Auto) und warum die Features des Daemon übertrieben gut sind und kaum Bugs zu haben scheint. Oder ich könnte mich fragen, warum sich ein hochgradig verteiltes System zumindest an einer Stelle (kurz vor Schluss) wie ein zentralisiertes zu verhalten scheint. Ich könnte auch aufzählen, welche Kleinigkeiten man meiner Meinung nach an der Geschichte verbessern könnte. Das würde dem Roman aber nicht gerecht. Im Vergleich zu dem, was andere Romanschreiber fabrizieren, ist das lächerlicher Kleinkram. “Daemon” ist ein guter Roman. Die Geschichte erschafft im wahrsten Sinne des Wortes eine eigene Welt; sie ist spannend, gut erzählt und regt sogar zum Nachdenken an.

Kurz: Ein intelligenter Roman, der mir viel Spaß gemacht hat.

Agile: Wenn “agil” draufsteht…

… ist wohl nicht immer agil drin.

Dilbert.com

Leider wird Agile Softwareentwicklung oft so verstanden, wie in obigem nicht nur einmal zitiertem Dilbert-Comic. Mein Eindruck ist manchmal, dass das Wort “agil” dazu benutzt wird, dem Nichtvorhandensein einer strukturierten und durchdachten Vorgehensweise einen Namen zu geben. Aber genau das ist agile Softwareentwicklung eben *nicht*. Agile Softwareentwicklung heißt nicht einfach mal drauflos coden und hoffen, dass alles schon irgendwie gut geht.

Letztens hab ich auf heise eine interessante Umfrage gesehen, die genau das zeigt. Zumindest ist das meine Interpretation der Daten.

Nach der Umfrage nutzen 17% gar kein Vorgehensmodell. Dazu kommen die oben genannten Feigenblatt-Agilen und wohl auch ein paar Feigenblatt-Phasenorientierten. Wenn man jetzt auch noch bedenkt, wer die Fragen beantwortet hat (Tester, Entwickler, Manager, …), dann zeigt sich, dass Entwickler deutlich häufiger angeben, keinem Vorgehensmodell zu folgen. Da aber wohl die Entwickler diejenigen sind, die das am besten wissen sollten, vermute ich mal, dass die 26% (Entwickler, die angegeben haben, keinem Vorgehensmodell zu folgen) eher stimmen als die 17% (Durchschnitt über alle Rollen). Da klaffen wohl Anspruch und Wirklichkeit etwas auseinander.

Aber gucken wir mal genauer:

  • 27% der “agilen” nutzen ein “eigenes agiles Vorgehensmodell”. Soso…
  • 57% nutzen Scrum (weil es grad in Mode ist, das zu behaupten)
  • Nur bei 43% der “agilen” Projekten sind Unit-Tests vollständig automatisiert. Knapp 30% haben eine Automatisierungsquote unter 70%. Und nennen sich dabei “agil”.

Die genannte Statistik hat sich jetzt auf Tests konzentriert. Ich schätze mal, wenn man da in andere Richtungen fragt, wird man ein ähnliches Bild erhalten: Nicht alle, die behaupten, agile Softwareentwicklung zu betreiben, tun das auch.

Pi mal Daumen schätze ich also mal, ein Drittel der agilen sind nicht wirklich agil. Grob geraten sind wohl 50% phasenorientiert 20% agil und 30% gar nix. Und die Übergänge sind fließend.

Teilweise herrscht auch ein falsches Verständnis: Auf ner Firmenkontaktmesse hab ich auch mal gehört, “agil” sei ja gar nicht neu; früher nannte man das nur iterativ. Aber so ist es natürlich nicht. Die Aussage ist in etwa genauso richtig, wie zu behaupten, dass früher (“prozedural”) Klassen einfach structs oder records geheißen haben. Technisch mag das bis zu einem gewissen Grad stimmen (aber auch nur zum Teil). Jedoch hat sich die Denkweise geändert. Und die Denkweise ist es, die den großen Unterschied macht — sowohl bei der Objektorientierung alsauch bei der agilen Softwareentwicklung.

Nichtsdestotrotz gibt es auch Firmen, die Agilität richtig verstehen und richtig anwenden. Durch die ein oder andere Exkursion hab ich da auch schon welche kennen lernen dürfen. Effektiv ist in den meisten Firmen, die ich bisher kennen gelernt habe, Agilität zumindest ein Thema. Ich denke, man kann also behaupten Agile Softwareentwicklung ist mittlerweile im Mainstream angekommen. Nur heißt das eben noch nicht, dass alle, die sich “agil” nennen, das auch sind.

Gefangen, nicht gefunden! #20

Informatik

Anderes

  • Boa bin ich langsam. Das hier liegt schon seit Ewigkeiten hier um. Ein Punkt oben war noch “Die Delphi-Tage sind ausverkauft” (aus verständlichen Gründen hab ich das vor dem Posten wieder gelöscht; Anachronismen sind nicht sonderlich hilfreich) und WordPress zeigt den 16. August als Erstellungsdatum…

Warum manchmal unerklärliche Dinge geschehen

“Schon traurig, dass von mir als Informatiker manchmal als einziger Lösungsvorschlag ‘Stecker ziehen und wieder reinstecken’ kommt. — Und noch trauriger ist es, dass das auch noch hilft.”

Manchmal passieren Dinge, die uns unerklärlich, ja unglaublich erscheinen. In den letzten paar Tagen, durfte ich an ein paar WLANs rumbasteln und dabei sind diverse solcher Dinge passiert. Und das hat mich dann dazu gebracht, obiges zu meinem Cousin zu sagen. Das will ich mal zum Anlass nehmen und etwas darüber sagen, wie diese unerklärlichen Dinge geschehen.

Aber was ist denn nun passiert?

  • Der neue WLAN-Router tut nicht so, wie er soll. Zuerst kommt er ins Internet, aber das WLAN geht nicht. Dann geht WLAN aber kein Internet mehr. Nach ein paar mal neu Booten und Stecker ziehen und wieder reinstecken, tut es wieder.
  • Ein anderer WLAN-Router (gleiches Modell) hat laut LED eine Verbindung mit dem Internet. Das Kabel steckt aber nicht im WAN-Port. Netzstecker ziehen und wieder reinstecken und es geht.
  • Der selbe WLAN-Router ist per Ping zu erreichen, zeigt bei Eingabe der IP in den Browser keine Konfigurationsoberfläche (Timeout). Ein Reset behebt das Problem.
  • Bei selben Gerät ein Admin-Passwort eingerichtet (händisch in beide Edit-Felder eingetragen und gespeichert). Danach nimmt er das Passwort beim Anmelden aber nicht mehr an. Nach einem Reset nochmal versucht (diesmal langsam eingetippt). Selbes Problem. Dann Dummy-Passwort “abc” zum Probieren. Lustigerweise funktioniert das jetzt. Dann das Wunsch-Passwort nicht eingetippt, sondern per Copy’n'Paste jeweils eingefügt. Wieder “Benutzername oder Kennwort falsch”.
  • Einen WLAN-AccessPoint als Repeater konfiguriert. Datendurchsatz ca. 40kbps (ja 40kbps bei 802.11n und ner Entfernung von 20cm). Neu Starten hilft diesmal nicht. Zum Testen als AP-Client konfiguriert: selbes Problem. Zum Testen mit anderem AccessPoint verbunden: Klappt problemlos. Wieder zurück zum eigentlich gewünschten AccessPoint: Wieder ewig lahm. Neu Starten hilft immer noch nicht. Einen Tag später nochmal versucht: Klappt auf Anhieb.
  • Bei Verwendung des neues Repeaters friert der Rechner ein (Maus und Tastatur reagieren nicht mehr). Der Rechner war per Ethernet-Kabel mit dem Repeater verbunden. Selbst nach Abziehen des Kabels (also der Rechner ist mit dem Repeater nicht mehr verbunden. Beide stehen nur nebeneinander) besteht das Problem weiterhin. Ein bisschen WLAN lässt den Rechner einfrieren.
  • Auch ein DSL-Router war mal per Ping zu erreichen und per Browser nicht. Wieder behob ein Steckerziehen das Problem.

Aber wie kann das alles sein? Und was hat das mit Software-Entwicklung zu tun? Ich wage mich mal an eine Erklärung des Unerklärlichen. weiter lesen »

Agile: Definition of Done und Failure Mode Programming

Einer der Begriffe, die bei Agilen Softwareentwicklungsprozessen immer wieder zu hören sind, ist “Definition of Done” (DoD). Man soll also vorher definieren, was man unter “fertig” versteht. Das hört sich erstmal trivial an. Und der triviale Grund, dass man ansonsten aneinander vorbei redet, leuchtet auch jedem ein.

“Ist Feature X jetzt endlich fertig?”
“Ja, hab ich gestern eingecheckt.”
“Dann können wir morgen also deployen.”
“Neinnein, da muss noch die QA drüber. Da ist noch nix getestet.”

“Ist Feature Y jetzt endlich fertig?”
“Fast. Zu 90% ist es fertig. Ich muss nur noch…”

Wenn man einmal definiert, was “fertig” bedeutet, kommt es zu weniger Missverständnissen. Mal ganz davon abgesehen, dass man so auch leichter dieses “fast fertig” ausmerzen kann. Entweder ist ein Feature “done” oder eben nicht. Zu 90% fertig bedeutet ja meist, dass noch (weitere) 90% vor einem liegen. Das ist die so genannte 90-90 rule. Und diese ist nur zu oft wahr. Auch, wenn mans vielleicht nicht wahr haben will (mich teilweise auch noch eingeschlossen; ich arbeite daran).

Das ist alles klar und allgemein bekannt. Aber es gibt noch einen anderen Grund für eine DoD: weiter lesen »

Agile: Frequency Reduces Pain

Quasi alle mir bekannten agilen Methoden basieren auf einem weiteren grundlegenden Gedanken, der allerdings nur selten genannt wird, wenn Agile Softwareentwicklung erklärt wird: Frequency Reduces Pain oder anders ausgedrückt: “if it hurts, do it more often”. Integration, Tests, Schätzungen, Refactoring, alles das kann sehr unangenehm werden. Deshalb wird das alles in agilen Prozessen viel öfter gemacht — in kleineren, überschaubareren Schritten.

Integration kann man nicht vermeiden. Irgendwann muss man eben mal alles zusammenwerfen und gucken, ob es funktioniert. Je größer die Software und je später die Integration, desto schwieriger wird das Ganze. Deshalb macht man es viel öfter. Nämlich mindestens einmal täglich. Und auf einmal wird alles viel einfacher.

Schön zusammengefasst ist das außerdem in Gall’s Law:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Integration ist nur ein Beispiel. Das genannte Prinzip steckt in ganz vielen agilen Praktiken und ist außerdem der Grund dafür, dass agile Prozesse hochgradig iterativ sind: Wenn es schwer ist, Software fertig zu kriegen, dann kriegen wir sie eben alle zwei Wochen fertig. Wenn Schätzen schwer ist, dann schätzen wir eben alle zwei Wochen neu, aber dafür kleinere Arbeitspakete. Wenn Testen nervig ist, machen wir es zum Prinzip und schreiben Tests vor dem eigentlichen Code, sodass unser Code unweigerlich testbar wird. Wenn Refactoring fehleranfällig ist, machen wirs doch besser andauernd — immer mal wieder ein bisschen.

Softwareentwicklung ist wie Markklößchensuppe essen: Nicht alle auf einmal, sondern einer nach dem anderen.

Agile: Was ist das eigentlich?

In der letzten Zeit hab ich mich eingehend mit agiler Software-Entwicklung beschäftigt. Das hatte ich schon eine ganze Zeit lang vor, aber praktischerweise hatte ich von der Uni aus die Aufgabe mit ein paar Kommilitonen mir Scrum anzusehen und darüber zu referieren. Außerdem habe ich gerade an der Summerschool “Agile Software-Entwicklung” teilgenommen. Das hab ich dann mal zum Anlass genommen, mich etwas intensiver mit der Thematik zu beschäftigen.

Bei Agiler Softwareentwicklung gehen die Meinungen typischerweise stark auseinander. Je nachdem wem man zuhört, ist man geneigt entweder den einen oder den anderen recht zu geben. Beide Argumentationsweisen, beide Softwareentwicklungsphilosophien hören sich, für sich alleine betrachtet, vollkommen vernünftig an. Das hilft natürlich nicht sonderlich weiter, wenn man sich eine eigene Meinung bilden will und so schreibe ich das hier hauptsächlich, um mir selbst hier einigermaßen Klarheit zu verschaffen.

Ursprünglich hatte ich einen vergleichsweise langen Artikel geplant. Ich denke aber, dass mehrere kleinere Artikel eher gelesen werden als ein großer. Außerdem dauert ein großer Artikel immer so lange zu schreiben. Nachdem ich jetzt schon über zwei Monate immer mal wieder an dem Text sitze und immer noch erst etwa ein Drittel steht, habe ich mich nun entschlossen, eine Artikelserie daraus zu machen.

Die Artikelserie spiegelt meine momentanen Gedanken zu dem Thema wider. Ich kann nicht sagen, ob ich bei dieser Meinung, die ich hier mal herausarbeite, bleiben werde. Ich bin einfach selbst mal gespannt, wie ich zur Thematik stehen werde, wenn ich mit der Zeit mehr Einsicht gewinne. Nun gut. Ich hab jedenfalls einiges gelesen und mir meine Gedanken dazu gemacht. Los geht es mit einem geschichtlichen Überblick über die Thematik.
weiter lesen »

Summerschool “Agile Software Development”

Der FIT hat in diesem Jahr neben den schon mehrmals angebotenen — und im übrigen ebenfalls empfehlenswerten — Firmenexkursionen auch eine Veranstaltung zum Thema Agile Softwareentwicklung angeboten: Summerschool “Agile Software Development”.

Als ich die Ankündigung gelesen hatte, wusste ich sofort, dass ich da mitmachen wollte. Mit agiler Softwareentwicklung wollte ich mich sowieso mal beschäftigen. Außerdem sollte das Ganze auch sehr praxisnah sein. (Wenn man auf ner Uni studiert, sind wirklich praxisnahe Lehrveranstaltungen eher selten.) Und zum Dritten bot sich so mal wieder die Gelegenheit, mit ein paar Firmen in Kontakt zu kommen. weiter lesen »

powered by WordPress | QuickLaTeX | WordPress Themes