Abriß II

Zweite große Abrißaktion, welcher der Vorbau und der hintere Anbau zum Opfer fielen. Freitag innerhalb von drei Stunden letzteres erledigt.

Samstag früh im dichten Nebel spektakulärer Kraneinsatz um Betondachplatte des Vorbaus in den Container zu befördern.

Vorbildliche Teamarbeit zwischen Z. und W. um den Vorbau bis auf die Grundmauern abzuknabbern.

Besondere Vorkommnisse: Zusammenbruch des Schleppdachs mit Z. obendrauf. Zusammenbruch eines Steinabsatzes, ebenfalls mit Z. obendrauf. Stuntquote für das Wochenende mehr als erfüllt.

Abriß I

Das Häuschen ist schon ein bisschen speziell. Es gibt nicht nur ein außen liegendes, aber unbenutztes, Klo, sondern auch ein innen liegendes, welches über keinen Wasserzugang verfügt. Ein Geheimraum ohne Zugang, welcher einstmals einen Öltank beherbergte, fügt sich zwischen Bad und Außenwand ein.

Jedenfalls fängt Z. schon einmal an, den Innenklobunker zu entfernen.

An one finger rotation gesture recognizer

Last year we developed the Raumfeld iPhone App. The goal was to build something that could replace our native controller completely. The main design feature of the native controller is the massive volume knob. Of course we wanted to have something similar in our App, so the designer created the volume screen with a big knob, as shown in the right picture.

To create a volume control, we needed a way to detect if the user performs a rotation gesture on the knob image. There is no default UIGestureRecognizer that detects such a gesture, so we had to implement a custom gesture recognizer. It was surprisingly easy – to be honest, the hardest part was to do the math right.

To track the finger movement, we need to check for every touch event, whether it is within the defined area. The gesture is rotating, so there is a center point m, the radius a which defines the minimum distance from m and the radius b which defines the maximum distance from m. Finally we need to calculate the angle ? between the startpoint and the current finger position (relative to m).

For the first check, we calculate the distance d from the center and make sure, that a < d < b is true.

The rotation angle is the angle between the two lines a and b. The arc tangent function atan() is the key:

Ok, that was the hard part 🙂 To implement a custom gesture recognizer, let’s have a look at the UIGestureRecognizer API docs, especially the subclassing notes. We just need to overwrite five methods

The key is touchMoved:withEvent: This method checks the distance of the touch event from the center point. If the touch is within the valid area, the angle between the start point and the current touch position is calculated. The result is sent to the delegate object of our class.

target needs to implement some kind of protocol to allow the gesture recognizer notification of movements:

And that’s the whole magic. To use the gesture recognizer, create an image of a rotating control and add a gesture recognizer to your view:

As soon as a gesture is detected, the delegate method is called and you can rotate the image according to the angle:

I’ve created a sample project on github, feel free to play with. Also make sure to read Ole Begemanns article about the UX details on gesture recognition.

Namensschilder für Polizisten: potentiell tödliche Waffen!!!1!!

Nein, ernsthaft. Wenn jetzt alle Polizisten in Berlin ein Namensschild tragen, kann jeder dahergelaufene Gelegenheitsmörder dem Polizisten das Namensschild entreißen und damit ein Massaker anrichten. Bodo Pfalzgraf, Vorsitzender der deutschen Polizeigewerkschaft demonstriert die von den Namensschildern ausgehende Gefahr an einem Eisbein.

Die Plastikteile könnten den Polizisten entrissen und als lebensbedrohliche Waffe eingesetzt werden.

Große Sprüche auch von Rainer Wendt:

Die Zwangskennzeichnung ist ein gigantischer Misstrauensbeweis in unsere Polizei“, sagt Rainer Wendt, Bundesvorsitzender der Gewerkschaft. Das Vertrauensverhältnis der Bürger in die Polizei sei hervorragend, die individuelle Kennzeichnung daher überflüssig.

Richtig! Es ist ja noch NIE vorgekommen, dass die Polizei versehentlich Demonstranten mit verprügelt hat. Nie! NIE! Ehrenwort! Die Leidtragenden sind letztendlich die armen Polizisten:

Einige Kollegen hätten sich beim Anschnallen im Auto an den Kanten in den Arm geritzt.

Ich muss mir erstmal ein Taschentuch holen… schnüff..

Huch, schon August?

Oh, es ist ja Camp. Und gutes Wetter… Wir haben erstmal einen Graben gezogen, in der Hoffnung, dass das Zelt nicht absäuft.
Sehr cool: schon mit Kind 1 ein Throwie (LED + Batterie + Magnet) gebastelt und morgen für den Raketenworkshop angemeldet. Noch keinen Vortrag gesehen, aber dabei sein ist alles 🙂

Objective C: KVC und KVO

Ich empfinde das Eintauchen in die Welt von Objective C und Cocoa als sehr erfrischend, jeden Tag gibt es etwas neues zu entdecken. Wenn man sich mit anderen Entwicklern, die Objective C nicht kennen, unterhält, kommt aus der C++ Ecke garantiert die Frage: „Kann man dort Operatoren überladen?„.

Nein kann man nicht. Braucht man auch gar nicht. Operatoren zu überladen ist zweifelsohne cool, aber ich multipliziere nicht den ganzen Tag Matrizen, sondern baue Dinge für Endanwender. Das angenehme an Objective C ist, dass es bestimmte Real World Probleme sehr schön löst.

Key Value Observing ist so eine Lösung und es ist ein so verdammt einfaches Konzept, dass ich mich wundere, wie die Welt bisher ohne leben konnte… (Um es vorweg zu nehmen: GObject hat ein ähnliches Konzept und es gibt bestimmt noch mehr Implementierungen dieses Patterns).

Das Real World Problem kommt bestimmt jedem bekannt vor: man hat eine Klasse A gebaut und eine andere Klasse B muss benachrichtigt werden, wenn sich in A irgendetwas interessantes ändert. Bisher wäre das Herangehen, dass A eine Referenz auf B mitschleifen muss, damit Klasse A die Klasse B benachrichtigen kann. Das bringt natürlich das schöne Klassendesign durcheinander, eigentlich hat A mit B nichts zu tun und die Referenz auf B zu handhaben ist auch nervig.

In Objective C gibt es Properties, die Membervariablen und deren Getter und Setter erzeugen können:

Im obrigen Beispiel hat die Klasse „Foo“ ein Member „bar“ und @synthesize generiert die Getter und Setter, die dann so verwendet werden können:

Soweit, so trivial. Mit Key Value Coding kann man auf Properties programmatisch zugreifen. Das bedeutet, ich baue mir einen String zusammen, dessen Inhalt der Name einer Property ist und ich kann auf die Property zugreifen:

Das wird unheimlich praktisch, wenn man z.B. XML parsen muss und die geparsten Key/Value-Paare direkt via KVC in den Properties einer Klasse speichern kann.

Key Value Observing ist nun die Lösung o.g. Problems: man kann sich einfach von außen als Observer für bestimmte Properties einer Klasse registrieren und wird benachrichtigt, falls sich ein Wert ändert.

Das spart eine Menge Code und die beobachtete Klasse A braucht sich um Klasse B nicht kümmern und muss keine Referenz auf B mitschleifen.

Ich finde das ziemlich elegant. Das Klassendesign bleibt sauber und trotzdem ist es möglich, sich kreuz und quer durch alle Schichten der Anwendung über Zustandsänderungen benachrichtigen zu lassen.

Update: Es gibt einen sehr schönen Wrapper von Andy Matuschak: Block Callbacks for Cocoa Observers (via Ole Bergmanns hoch interessantem Twitterstream)

Der Einstieg in die iPhone / iPad Programmierung

Ich lese mich gerade in die Welt der iOS-Programmierung ein, „for fun and profit“ sozusagen. Die Hürde bei der Plattform ist etwas höher, weil man erstmal eine neue Programmiersprache (Objective C) lernen muss und zusätzlich die ganze Cocoa-API verstehen muss. Ich mache Dinge gerne gründlich, deswegen habe ich mir erstmal die Sprache an sich zu Brust genommen um dann in die iPhone-Programmierung einzusteigen.

Objective C macht auf mich erstmal einen sehr aufgeräumten Eindruck. Ich habe vorher C, Java und etwas C++ programmiert und von den Sprachen findet man einen guten Mix in Objective C wieder. Die umfangreiche Foundation- API ist vergleichbar mit dem, was man in Java vorfindet, trotzdem kann man bis auf C-Ebene hinunter. Die Objektorientierung ist angenehm gelöst, es heisst alles nur ein bisschen anders. So sind Protokolle z.B. das was man in Java Interfaces nennt.

Die Syntax ist etwas anstrengend, man merkt der Sprache deutlich an, dass die ersten Versionen vermutlich im C-Präprozessor implementiert wurden. Die vielen eckigen Klammern sind zwar erstmal ungewohnt, aber damit kommt man relativ schnell klar. Schlimmer ist, dass mit Objective C 2.0 ein Bruch erfolgte und Setter/Getter jetzt mit einem Punkt angesprochen werden können. Das spart zwei eckige Klammern ein, wirkt aber ziemlich inkonsistent.

Insgesamt ist die Sprache sehr mächtig, es gibt schöne dynamische Features. So kann man einer Klasse nachträglich Methoden hinzufügen (Categories), es gibt Dictionaries, wie man sie aus Python kennt und man kann auch mit dem for x in y Konstrukt durch solche assoziativen Speicher durchiterieren:

Als Buch kann ich Programming in Objective-C 2.0* von Stephen Kochan empfehlen. Das Buch hat den Anspruch auch für Menschen geeignet zu sein, die bisher noch nicht in C programmiert haben. Trotzdem vermittelt es alle wichtigen Aspekte in der zu erwartenden Tiefe.

Was die Literatur zur „richtigen“ Programmierung unter iOS angeht: der Markt ist erstmal sehr unübersichtlich. Es gibt viele Bücher, aber welches davon ist gut? Ziemlich hoch gelobt wurde in letzter Zeit IPhone Programming: The Big Nerd Ranch Guide*. Wer sich die 3500 Euro für ein 7-Tage Training auf der Big Nerd Ranch nicht leisten kann, ist mit dem Buch gut beraten.
Man merkt deutlich, dass es aus Schulungsunterlagen hervorgegangen ist, aber das ist kein Manko, im Gegenteil. Man hat sofort Erfolgserlebnisse und muss nicht erst 200 Seiten Urschleim wälzen, bevor man einen Button programmieren darf. Ich kann das Buch fast uneingeschränkt empfehlen. Einziger Kritikpunkt ist, dass es für meinen Geschmack etwas Tiefgang missen lässt. Ich habe das Buch zur Hälfte durch und bis jetzt wurde das Thema Speicherverwaltung, das allen iOS-Anfängern das Genick bricht, sträflich vernachlässigt.

Zur iOS-Umgebung selbst kann ich noch nicht so viel sagen. Es wirkt alles sehr durchdacht, allerdings muss man sich das lineare Denken abgewöhnen. Jeder Pups wird über einen Callback erledigt (er heisst nur Delegate), was einfache Probleme ein bisschen verkompliziert. Aber ich denke das ist nur Übungssache.

Die Dokumentation ist mindestens auf dem Niveau der MSDN, wenn nicht sogar besser. Man kann Beispiele mit einem Knopfdruck direkt in Xcode öffnen. Die IDE ist allerdings eine Zumutung, Xcode 3 ist ein Wirrwar von Fenstern, die man ständig zur Seite schieben muss. Ich frage mich welcher ADS-Patient für das Interface-Design verantwortlich ist.
Xcode 4 dürfte die nächsten Wochen das Licht der Welt erblicken, hier findet sich alles in einem iTunes-Artigen Fenster wieder, was sich wesentlich angenehmer anfühlt. Allerdings haben die Previews von Xcode 4 noch ein paar hässliche Bugs, so lange die Final noch nicht draußen ist, würde ich Anfängern raten, bei Xcode 3 zu bleiben.

Was braucht man, um erstmal loszulegen? Ein gutes Buch, einen intel-Mac / Hackintosh und früher oder später ein „richtiges“ iOS-Gerät. Es genügt ein alter iPod-Touch, aber ohne geht es kaum. Der Simulator kann bestimmte Dinge nicht (Gravitationssensor, Kamera) und verhält sich auch manchmal ein klein bisschen anders (ich hatte speziell bei der Maps-API Probleme). Danke an Semmi, der mir so selbstlos seinen iPod Touch zur Verfügung gestellt hat. Ich verspreche, Du bekommst ihn noch in diesem Leben zurück 😉

Als Entwickler kann man kann nur Anwendungen auf iOS Geräten installieren, wenn man ein Entwicklerzertifikat hat, das kostet pro Jahr 79 Euro. Das ist die einzige Kröte, die man schlucken muss. Ob das gerechtfertigt ist, vermag ich nicht zu sagen, aber man kann sich so ein Zertifikat auch teilen und dann bis zu 100 iOS-Geräte bestücken. Das klappt natürlich nur mit Leuten, denen man halbwegs vertrauen kann.

*=affiliate Link

OH HAI new job

Der letzte Chaos Communication Congress hat mir einen neuen Job beschert 🙂 Interessant ist auch, wie schnell so etwas gehen kann. Einen Monat nach dem ersten informellen Gespräch auf dem Kongress habe ich am Montag meinen letzten Arbeitstag in der alten Firma. Wie alles im Leben sind eben auch Kündigungsfristen verhandelbar.

27c3: Tag 4

OMG WTF PDF war ein prima Einstieg in den letzten Kongresstag. Julia Wolf hat vorgeführt, was mit PDF alles möglich ist. Leider ist sie so rasend zwischen den Folien hin- und her gesprungen, dass man beim Konsum der Aufzeichnung die Folien zur Hand haben sollte. Sie hat u.A. vorgeführt, wie man Dateien aufbauen muss, die gleichzeitig ZIP und PDF Dateien sind. Highlight war ein Executable vom Windows-Taschenrechner, das sie auch mit dem Acrobat Reader öffnen konnte und dieser den Inhalt korrekt dargestellt hat.

Es gab dann noch ein paar Überlegungen, was man noch machen könnte – u.A. die PDF-Engine von Druckern nutzen, um Portscans durchzuführen. Heise hat das so dargestellt, als ob das schon möglich ist, aber Julia hat lediglich gesagt „man könnte mal“. Ich bezweifle jedoch, das es so einfach möglich ist. In dem Druckern ist ja kein Acrobat Reader eingebaut, der für Sicherheitslücken und Parserfoo bekannt ist. Vielmehr nehmen Drucker das PDF nur an und wandeln es dann in ein Format, das sie nativ verstehen, also PCL i.d.R. Es würde mich stark wundern, wenn da nicht-grafische Elemente berücksichtigt werden (Javascript ect.).

Insgesamt jedoch schein PDF ein weites Feld für Experimente sein. Julia hat sich hauptsächlich den Acrobat Reader angeschaut, aber es gibt ja noch mehr PDF Interpreter auf diesem Planeten – nicht nur in Druckern 😉

Bizarr war „Cybernetics for the Masses„. Eine quirlige Dame anfang zwanzig hüpft nervös über die Bühne und erklärt, wie man sich in der eigenen Küche Implantate unter die Haut jagt. Die Materialwahl schein extrem schwierig zu sein, Rost ist ein großes Problem. Dazu gab es noch hilfreiche Tipps wie „kein Skalpell verwenden, lieber eine große Kanüle“, „Venen in den Fingern kann man prima mit einer Lampe finden“ und „nie alleine arbeiten, falls man mal das Bewusstsein verliert“.
L. hat diverse Implantate unter der Haut, z.B. Sensoren für elektromagnetische Felder. Wenn man so einen Sensor ein paar Wochen trägt, trainiert man das Gehirn so sehr an die Signale, dass der Sensor zu einem weiteren Sinnensorgan wird. Ich hatte von diesem Effekt schon mal vor 2 (?) Jahren in einem Biohacking-Talk auf dem Kongress gehört. Mir ist allerdings nicht ganz klar, was der Nutzwert so einer zusätzlichen Wahrnehmung ist.
Interessanter klang L.s aktuelles Projekt, sich einen elektrischen Kompass ins Bein zu implantieren. Gerade für solche orientierungslosen Menschen wie mich, wäre das ein prima Addon 🙂

27c3: Tag 3

Der Jahresrückblick ist für mich Pflichtveranstaltung, er bestätigt mich regelmäßig darin, dass der Mitgliedsbeitrag richtig investiert ist. Nirgends bekommt man mehr Verfassungsklagen und Lobbying für’s Geld als beim CCC 😉
Parallel dazu lief „A Critical Overview of 10 years of Privacy Enhancing Technologies“ und soweit ich das mitbekommen habe, war der Talk auch sehr gut, ich werde mir auf jeden Fall die Aufzeichnungen anschauen.

Danach wurde mit dem Deutschlandfunk „Was kommt nach dem analogen Radio?“ besprochen, was mich aber nicht sonderlich angesprochen hat. Es hat auf mich gewirkt, als ob der Deutschlandfunkt denk, er ist im digitalen 21. Jahrhundert angekommen und das Publikum ist der Meinung, Der DLF hat noch gar nichts verstanden, weil von „Sendezeit“ gesprochen wird.

Ich habe mich dann zu „SIP home gateways under fire“ verkrümelt. Der Vortrag von Wolfgang Beck war etwas wirr, letztendlich wurden diverse Möglichkeiten für Source Routing Angriffe aufgezählt. Wolfgang hätte den Vortrag ruhig etwas ausschmücken können, denn nur mit blanken SIP-Schnipseln ohne weiterführende Grafiken, hing das Verständnis der Zuhörer stark von deren Fähigkeiten ab, SIP in Echtzeit von den Folien zu parsen.

Den „PS3 Epic Fail“ wollte ich natürlich nicht verpassen. Im Vortrag wurde die These aufgestellt, dass die Play Station erst das Interesse der Hacker auf sich gezogen hat, als der Linux-Support offiziell eingestellt wurde. Erst als sich Hacker den Weg zurück zur Playstation (Slim) „erkämpfen“ mussten, haben als Nebeneffekt auch illegetim kopierte Spiele auf der Plattform Verbreitung gefunden.

Den Vortrag solltet Ihr Euch anschauen, es wird ein Sicherheitsmechanismus nach dem anderen zerlegt und das Highlight ist, dass das Team soweit gekommen ist, den Private Key (der Konsole?) zu berechnen, weil die Crypto-Funktionen eine Konstante verwenden, die eigentlich eine Zufallszahl sein soll. Sie haben sich dann in der Q&A-Session etwas gewunden und meinten sie zeigen nur wie es gehen könnte, aber ich hatte den starken Eindruck, dass sie im Besitz des Keys sind (so hat es fefe auch aufgefasst). Es ist unklar, ob das der generische Signing-Key ist oder ein Key der individuell pro Konsole ist. Wenn man den Signing-Key veröffentlichen würde, hätte das natürlich erhebliche Auswirkungen: jeder könnte Software für die Playstation signieren, finanziell würden Raubkopierer natürlich davon profitieren. Es ist auch nicht klar, ob Sony das Problem jemals beheben kann, denn es wurden Wege gezeigt, wie man die Playstation auf beliebige älte Firmware-Revisionen downgraden kann, da ist es irrelevant, wie viele Updates Sony hinterherschiebt.

Der Talk „IMMI, from concept to reality“ war etwas bizarr, Daniel Domscheit-Berg stand auf der Bühne um den Talk für seine verhinderte isländische Partnerin zu halten. Nach dem Talk drifteten die Fragen jedoch relativ schnell zu Wikileaks und Daniels neuem Projekt Openleaks.org. Ganz interessant war, dass er aus ähnlichen Motiven wie Julian ein Buch schreibt: damit er von dem Geld eine gewisse Zeit leben kann und diese Zeit in Openleaks investieren kann (Julian schreibt ein Buch um seine Anwaltskosten bezahlen zu könnnen).
Es scheint mit Openleaks noch bis in den Januar zu dauern, dann soll die Webseite zumindest mit einer detaillierten Erklärung zum Projekt online gehen. Laut Daniel wird es auch Support-Formulare geben, falls man die Platform in der einen oder anderen Art unterstützen möchte. Ich denke da an Bandbreiten- und Storage spenden, ähnlich wie beim Wikileaks Mass Mirroring Projekt.

Running your own GSM stack on a phone“ schaut ihr Euch am besten selbst an. Harald Welte hat das Thema (wie immer) ziemlich gründlich durchgearbeitet. Herausgekommen ist eine „Ethernet-Karte für das GSM-Netzwerk“, also eine Möglichkeit, nur mittels eines geeigneten GSM-Telefons direkt mit dem Netzwerk zu reden. Also bis auf Layer1 (also die ganze HF-Technik) wird alles auf einem normalen PC implementiert.
Es existiert mit OsmocomBB ein ganzes Toolset, mit dem man GSM erforschen kann. „Make interesting stuff“ ist Haralds Aufruf an die Community. Das ist natürlich hoch interessant – eine Basisstation kauft man sich nicht mal eben um mit OpenBSC herumzuspielen, aber ein 20 Euro Handy um GSM besser zu verstehen, finde ich schon ein geeigneteres Spielzeug.

Pages: <<< 1 2 3 4 5 6 7 8 ... 96 97 98 >>>