Notizen und Gedanken von Andreas Marc Klingler

Schlagwort: Softwareentwicklung

Code-Rea­li­tät

In Vor­le­sun­gen hört man ja ab und zu Hor­ror-Geschich­ten über „die Rea­li­tät”™. Man lacht dann meist dar­über und fragt sich, ob es denn stim­men kann, das in frei­er Wild­bahn wirk­lich der­ma­ßen unglaub­lich schreck­li­cher Code exis­tie­ren kann. So blöd kann ja kei­ner sein.

Letz­te Woche habe ein sol­ches Bei­spiel erlebt, bei des­sen Code-Ana­ly­se ich minu­ten­lang nicht mehr aus dem Lachen her­aus­kam. Auch wenn Wei­nen wohl ange­mes­se­ner gewe­sen wäre.

Es ging um eine Web­platt­form, die trotz 8‑Kern-Sys­tems mit 32 GB RAM kaum noch benutz­bar war auf­grund extrem lan­ger Ant­wort­zei­ten im Minu­ten­be­reich. Ein Haupt­pro­blem war eine Meho­de, die fol­gen­des gemacht hat:

  • Lade zu Beginn erst­mal alle Objek­te aus der Daten­bank in eine Variable.
  • Lade, weil’s so schön ist, auch direkt alle abge­lei­te­ten Objek­te abge­lei­te­ter Tabel­len in Variable.
  • Füh­re diver­se Trans­for­ma­tio­nen mit allen die­sen Objek­ten aus (deren Sinn sich mir nicht zu 100% erschlos­sen hat).
  • Fil­te­re ca. 80% der Objek­te raus.
  • Füh­re mit der ver­blei­ben­den Objek­ten wei­te­re Trans­for­ma­tio­nen durch.
  • Ermitt­le schließ­lich die Anzahl der Ele­men­te, die in der „Haupt­va­ria­ble” noch drin sind, und …
  • ver­wen­de die­sen Wert nie wieder.

Über­flüs­sig zu sagen, dass auch die ande­ren Varia­blen über­haupt nicht ver­wen­det wer­den. Tja…

Will­kom­men in der Rea­li­tät! (Flucht­mög­lich­kei­ten sind nicht ausgeschildert.)

(Nach­trag: Zum The­ma: devopsreactions.tumblr.com, codinghumor.tumblr.com uvm.)

All­mäch­ti­ges Frontend

Ich expe­ri­men­tie­re seit eini­ger Zeit hin und wie­der mit Java­Script-Frame­works wie Angular.js oder Ember.js. Dar­in kann man mitt­ler­wei­le kom­plet­te MVC-Anwen­dun­gen schrei­ben, die kom­plett im Brow­ser lau­fen kön­nen und ggf. höchs­tens noch per JSON/XML mit einem Ser­ver-Skript zur per­sis­ten­ten Daten­spei­che­rung kom­mu­ni­zie­ren müs­sen. (Wobei auch das teil­wei­se schon lokal geht.)

Ein inter­es­san­ter Aspekt, der mir heu­te Abend bei einem Gespräch auf dem Angular.js-Meetup gekom­men ist: Es gibt einen Trend, immer mehr Logik in das Front­end (→ Brow­ser) zu verschieben.

In den meis­ten Web­an­wen­dun­gen wird der­zeit die meis­te Logik im Backend in einer eigen­stän­di­gen (Skript-) Spra­che geschrie­ben und dar­aus HTML-/JS-/CSS-/usw.-Code erzeugt und vom Brow­ser ger­en­dert. Zwar wird die Dar­stel­lung zwar oft noch per Java­Script ger­en­dert, aber die wesent­li­che Logik liegt im Backend.

Die Java­Script-Frame­works lau­fen dage­gen voll­stän­dig im Brow­ser ab. Dar­aus folgt dann aber auch, dass die gesam­te Logik öffent­lich wird. Jeder kann sich im Brow­ser durch die Java­Script-Datei­en han­geln, die kom­plet­te Logik nach­voll­zie­hen, auf Schwach­stel­len ana­ly­sie­ren und gar kom­plett her­un­ter­la­den, ver­än­dern und woan­ders mani­pu­liert hochladen.

Das eröff­net neben­bei völ­lig neue Mög­lich­kei­ten zum „Platt­form­klau” oder zu Angrif­fen, bei denen man nicht mal mehr ande­re Sei­ten nach­bau­en muss, weil man sie kom­plett auf einen eige­nen Ser­ver kopie­ren kann. Schnell noch eine Ver­tip­per-Domain regis­trie­ren und dann mal schau­en, wer sich so anmel­det. Die Anmel­de­da­ten kann man dann auch gleich spei­chern, um damit auf der rich­ti­gen Platt­form frem­de Nut­zer­kon­ten über­neh­men zu können.

In die­sem Zusam­men­hang lohnt sich auch ein Blick auf die Sei­te nobackend.org, auf der bereits Ideen und Lösun­gen gesam­melt wer­den für eine Welt, die voll­stän­dig ohne Backend auskommt.

Die Idee fin­de ich für eini­ge Anwen­dungs­fäl­le ganz inter­es­sant und ich wer­de das auch wei­ter­hin beob­ach­ten. Aber es fühlt sich irgend­wie komisch an, eine Platt­form so leicht kom­plett kopie­ren zu kön­nen. Viel­leicht bin ich da aber auch nur zu vor­ein­ge­nom­men, weil ich es bis­her anders nicht ken­ne. Mal schau­en, wie sich das entwickelt.

Exzel­len­tes Blog über Soft­ware­tech­nik und ‑ent­wick­lung

Vor eini­ger Zeit bin ich auf ein wun­der­ba­res Blog gesto­ßen, dass ich allen ans Herz legen möch­te, die Soft­ware auch ent­wi­ckeln: Joel on Soft­ware.

Es han­delt um Soft­ware­tech­nik und ‑ent­wick­lung sowie einer grö­ße­ren Epsi­lon-Umge­bung davon. Vie­le Arti­kel sind Augen-öff­nend und zumin­dest ich habe in den gut vier Wochen, in denen ich das Blog „aus­ge­le­sen” habe, sehr viel erkannt und gelernt. (Unte­re ande­rem auch gute Grün­de dafür, war­um man in der Pra­xis oft Din­ge tut, für die es im aka­de­mi­schen Bereich aber auch gute Grün­de gibt, sie zu verpönen.)

Auf der Haupt­sei­te gibt es in der zwei­ten Spal­te eine sehr lan­ge Lis­te auf gute Arti­kel aus ver­schie­de­nen Berei­chen. Ein guter Anfang. Über die Archiv-Sei­te kann man dann geord­net alle Bei­trä­ge ab März 2000 lesen.

Ursprüng­lich habe ich an die­ser Stel­le auch noch eine Aus­wahl her­vor­ra­gen­der Zita­te aus dem Blog anbrin­gen wol­len. Ich habe mich bei der gro­ßen Men­ge, die ich mir her­aus­ko­piert habe, nicht mehr ent­schei­den kön­nen und gebe daher allen Inter­es­sier­ten lie­ber den Rat, das Blog selbst aus­zu­le­sen. Man kann sich ja auch damit Zeit las­sen, die Arti­kel lau­fen ja nicht weg. :-)

Mana­ged­Ob­ject­Con­text von Core Data mit Sto­ry­board in XCode 4.2

Um Core Data in einer iOS-Anwen­dung benut­zen zu kön­nen, muss man die Kom­po­nen­ten des Core Data-Frame­works instan­ti­ie­ren, was nor­ma­ler­wei­se im Appli­ca­ti­on Dele­ga­te geschieht. Nor­ma­ler­wei­se wird dort in der Metho­de did­Fi­nish­Laun­ching­Wi­thOp­ti­ons das erzeug­te NSMa­na­ged­Ob­ject­Con­text-Objekt den View Con­trol­lern über­ge­ben, damit die­se es für Zugrif­fe auf die Daten­bank nut­zen können.

Die Stan­dard­lö­sung, die auch in vie­len Doku­men­ten von Apple noch vor­kommt und von der die­ser Code stammt, sieht wie folgt aus:

Wei­ter­le­sen