Category Archives: programmieren

elektronik games leben programmieren

Mechanische Tastatur (mx-brown, tkl, red backlight, german) … arghhh

Ich habe ein Luxusproblem. Nachdem ich auf der Arbeit den Raum und damit meine Schreibtischsituation gewechselt habe, tippe ich auf einer externen Tastatur, anstatt auf meinem Laptop. Die Tastatur, die ich anfangs benutzt hatte, war hakelig, die Tasten klemmten hin und wieder. Es sollte also eine Neue her.

Ein Grund für mich mit einer mechanischen Tastatur, bei der man (wieder) auf richtigen Schaltern rumdrückt und nicht diesen Gumminupsies, die heute in Tastaturen üblich sind. Soweit so gut. Die Tastatur ist etwas lauter als vorher, dafür tippt es sich wunderbar. Die Tastatur auf der Arbeit hat einen Ziffernblock und war für eine mechanische Tastatur relativ günstig. Wohl auch, weil sie direkt von Cherry kommt, die die Schalterchen bauen.

Zu Hause hätte ich jetzt auch gerne eine mechanische Tastatur. Das trifft sich gar nicht schlecht, denn ich tippe im Moment auf einem Bluetooth-Keyboard von Apple (die Variante ohne Ziffernblock). Das Bluetooth-Keyboard würde seine Stärke aber viel eher im Wohnzimmer am AppleTV ausspielen, wo man endlich mit ‘ner ordnetlichen Tastatur die Suche benutzen kann, ohne das Gerät anschreiben zu wollen.

Zu Hause hab ich leicht andere Anforderungen, als im Büro und so hätte ich dort gerne eine andere Tastatur: Ohne Ziffernblock, mit rotern Beleuchtung der Tasten und deutschem Layout.

Ohne Ziffernblock, weil mich die breite Tastatur beim Zocken stört.

Mit roter Beleuchtung, da ich zu Hause öfter Abends am Rechner sitze, als auf der Arbeit und auch wenn ich blind Texte schreiben kann, hört es bei Sonderzeichen irgendwann auf. Außerdem hab ich festgestellt, dass ich hin und wieder bei gewissen Zeichen kurz auf die Tastatur schaue. Sehe ich die Tasten bleibe ich im Fluss. Wenn nicht, beginnt die Tastensuche im Dunkeln und ich bin raus. Das stört besonders beim Programmieren. Naja und rot soll es sein, weil rotes Licht die Anpassung der Augen an die Dunkelheit nicht kaputt macht. Außerdem kann ich blaue LEDs nicht mehr sehen.

Gerade zum Programmieren wäre englisches Layout dan vielleicht gar nicht schlecht, aber ich bin jetzt über 30 und da muss ich mich nicht an eine neues Tastaturlayout gewöhnen. Außerdem ist meine Geschwindigkeit auf der Tastatur beim Programmieren selten der begrenzende Faktor ;)

Ach ja … ich habe mir die Tastatur für die Arbeit in mehreren Varianten bestellt. Mit unterscheidlichen Schaltern, die sich unterschiedlich anfühlen. Ich mach die mx-brown-Schalter von Cherry.

Wieso verdammt nochmal baut niemand eine Tastatur mit diesen Eigentschaften? Die einzige Möglichkeit wäre entweder eine Tastatur mit englischem Layout zu kaufen und die Tasten zu tauschen. Das sehe ich aber nicht ein. Die Tastaturen sind schon teuer und dann noch mal mehr oder weniger sinnfreie 50€ für neue Tasten … neee. Alternativ könnte ich selbst die LEDs gegen rote tauschen. Damit kann ich dann die Garantie aber vergessen und ordentlich Zeit geht auch dabei drauf.

Im Moment mache ich daher erst mal nix und bastel mir vielleicht ein kleines Tastaturlicht, dass dann unter meinen Laptopständer kommt. Wenn sich das bewährt, fällt vielleicht die Bedingung der Beleuchtung weg, mal sehn.

programmieren

Geheimnisprinzip

Wer kennt es nicht, nachdem man sich in einem Thema eigentlich ganz gut auskennt und vielleicht auch schon mehr als die ersten Gehversuche hinter sich hat, geht einem bei etwas Grundlegendem ein ganzer Kronenleuchter auf. Das dann folgende Gefühl ist eine Mischung aus Freude, über die Erkenntnis und Zweifeln an der eigenen Intelligenz, weil man sowas Grundlegendes nicht schon früher Begriffen hat.

Von einem solchen Moment möchte ich an dieser Stelle berichten. Seit ca. einem Jahr, bin ich raus aus der Uni und drin im Berufsleben. Dort basteln wir an einer Platine, auf der ein Microcontroller werkelt, einem eingebetteten System, wie man so schön sagt. Da man an der Uni von den sog. Best Practices nur wenig mitbekommt, hab ich mir zwei Bücher geshoppt, von denen sich eins auf eingebettete Systeme und das andere auf reine Programmierung bezieht. In beiden, geht es im Grundsatz darum wie man Dinge macht und warum man sie so macht. Und bei der Lektüre ist mir ein Licht aufgegangen im Bezug auf das Geheimnisprinzip.

An der Uni wurde mir in der Informatikvorlesung die Programmiersprache Java serviert und in diesem Rahmen wurde uns früh begebogen, dass wir das Geheimnisprinzip zu wahren haben. Das hieß hauptsächlich, dass wir vor die Variablen der Attribute in unseren Klassen das Schlüsselwort “private” geschrieben haben. Seit jeher hat sich in meinem Hirn der Gedanke manifestiert, dass das Geheimnisprinzip hauptsächlich aus Sicherheitsgründen wichtig ist. Gleichzeitig fand ich das sonderlich, weil auch wenn andere Klassen innerhalb eines Programms durch “private” nicht direkt auf die Variablen zugreifen konnten, programmierte man doch immer Get-Funktionen, die den Wert dennoch zurück lieferten.

Erst vor ein paar Monaten, bei der Lektüre eines der beiden Bücher – keine Ahnung bei welchem genau – fiel der Groschen. Beim Geheimnisprinzip geht es nicht hauptsächlich um Sicherheit, sondern um Modularität.

Was ich vorher schon verstanden hatte, war, dass man um das Geheimnisprinzip einzuhalten seine Klassen so programmieren musste, dass eine andere Klasse die Innereien nicht einfach lesen kann, sondern über eine Funktion gewissen Informationen anfragen muss. Das beschränkt sich aber nicht auf Java und objektorientierte Sprachen. Auch z.B. in C gibt es z.B. das Schlüsselwort “static”, mit dem man Variablen und Funktionen innerhalb einer Datei (nicht Klasse) vor dem Zugriff aus anderen Dateien schützen kann.

An hardwarenaher Programmierung lässt sich der gewonnene Vorteil gut veranschaulichen. Nehmen wir eine Digitaluhr mit Display. Das Programm enthält dabei sinnvollerweise mehrere Abstraktionsebenen. Auf der unteren ebene befinden sich die Treiber für die verwendete Hardware. Um z.B. Zeichen auf dem Display auszugeben, müssen erst die angeschlossenen Pins des Prozessors als Eingang oder Ausgang programmiert werden. Auch möchte man eine Tabelle Hinterlegen welche Segmente des Displays eingeschaltet werden müssen, um z.B. eine 2 darzustellen. Ziel ist ein Treiber, der die nötigen Pins initialisiert und wenn man ihm eine Uhrzeit übergibt diese auf dem Display darstellt. Von außen betrachtet reichen dafür 2 Funktionen, init() und printTime() könnten sie heißen.

Das aber ist die Sicht von Außen auf den Treiber. Im Inneren deutlich mehr Funktionen geben, z.B. eine um die Datenrichtung der Pins festzulegen, eine um die Ausgabepins auf die richtigen Werte für die Initialisierung des Displays zu setzten, usw. Sorgt man jetzt dafür, dass anderer Code von außen wirklich nur auf die init()- und printTime()-Funktionen zugreifen kann, sprich, man hält sich an das Geheimnisprinzip, ergibt sich extrem modularer Code.

Wechselt man z.B. auf ein Display eines andren Herstellers, dessen Hardware anders angesteuert werden muss, so muss trotzdem nur der Treiber neu geschrieben werden und solange der neue Treiber wieder init() und printTime() zur Verfügung stellt, muss der Übergeordnete Code nicht geändert werden.

Es geht also beim Geheimnisprinzip hauptsächlich darum den Code Modular zu halten, um Teile möglichst Rückwirkungsfrei austauschen zu können. Indirekt führt das wahrscheinlich auch zu mehr Übersicht und zu besserem und besser wartbarem Code und dient somit bestimmt auch der Sicherheit. Hauptgrund dafür ist aber Modularität.

Und ich frage mich immer noch: “Hat uns das wirklich keiner gesagt? Hat man es uns gesagt und ich hab es nicht verstanden und wenn ja, warum?”