Macoun 2011 Retrospektive

Kein Kommentar

Ich komme gerade von meiner ersten Macoun. Ich kannte die Konferenz bisher nicht und war mir unsicher, ob man für knapp 100€ wirklich eine vollwertige Konferenz bekommt. Diesbezüglich wurde ich aber wirklich überrascht. Das Organisationsteam hat hier wirklich hervorragende Arbeit geleistet. Chapeau dafür!

Die Location in einer Jugendherberge fand ich ebenfalls ziemlich befremdlich, aber auch hier bin ich positiv überrascht worden. Es gab Brezeln, Croissants, Kuchen und Obst sowie kalte und warme Getränke. Die Vortragsräume waren groß genug für die über 400 Teilnehmer und mit einer Ausnahme auch gut belüftet.

Auch die Umgebung fand ich recht angenehm. In den Pausen konnte man mit ein paar Schritten über die Straße ans Mainufer und dort etwas Sonne und Luft tanken um anschließend entsprechend relaxed zu den Vorträgen zurück zu gehen. Im folgenden noch eine subjektive Beurteilung der Vorträge, die ich ausgewählt habe.

Automatic Reference Counting – Daniel Höpfl

Sehr gut recherchierter und fundierter Vortrag. Es wurde gezeigt, wie man ein bestehendes Projekt auf ARC umstellt und welche Probleme mit ARC entstehen können. Toll fand ich, die Live-Demonstration des Verhaltens der verschiedenen ARC Attribute.

Kommunikativer Stabilbaukasten – Pascal Bihler

Live coding parallel in Objective-C unter XCode und Java unter Eclipse. Unterhaltsam und auch ein bisschen lehrreich. Ich hätte mir mehr Infos zur stabilen Verwendung von BSD-Sockets versprochen, falls das überhaupt möglich ist. Nach einem kurzen Einstieg ging es aber nur noch über HTTP-Requests, die natürlich die meisten Probleme der lowlevel Kommunikation vermeiden.

Die Möglichkeiten zur Verschlüsselung eines HTTP-Requests wurden kurz aber gut verständlich erklärt. Ich hätte mir etwas mehr Infos zur Erstellung von Schlüsseln gewünscht. Da aber live gecodet wurde, sind diese Punkte sehr schnell abgehakt worden.

Die Server-Implementierung erfolget mit Resty unter Eclipse. Wenn man das Framework nicht kennt, hat man aber schnell den Überblick verloren.

Volle Kontrolle mit und über HID – Matthias Krauß

Super Vortrag über die direkte Kommunikation mit HID Geräten. Sehr kurzweilig vorgetragen. Hat Lust auf die Entwicklung eigener HID Hardware gemacht. Schade nur, dass das alles nicht unter iOS geht.

Sicher nach iOS – Klaus M. Rodewig

Toller Vortrag für einen Einsteiger in das Thema. Ich habe mir danach gleich ein Buch zum Thema angeschafft und die aktuelle C’t Security gekauft.

Es wurde sehr schön dargestellt, wie und wann Verschlüsselung unter iOS funktioniert, wie man Thread-Modelling macht und welche Fehler durch schlechten Security-Code entstehen können.

Ich hätte mir etwas mehr Details zum Testen von Security-Code gewünscht. Schließlich hat der Dozent sich selbst als Hacker bezeichnet und dürfte ein paar Tools kennen, mit denen man Sicherheitslücken in der eigenen App finden kann.

Lokalisierung: Ein Hürdenlauf? – Felix Lotze / Oliver Gurtschmann

Tipps und Hinweise aus der Sicht von Übersetzern bzw. Linguisten. Eine App lokalisierbar zu machen, heißt nicht nur, dass man lokalisierbare Strings verwenden muss. Ein Übersetzer benötigt auch Informationen über den Kontext, in dem dieser String verwendet wird, sonst sind Missverständnisse möglich.

Ein weiteres Problem entsteht aus der Grammatik, wenn man parametrisierte Strings verwendet. Hier war die Empfehlung, die ich mitgenommen habe, dass man parametrisierte Strings möglichst selten einsetzt. Wenn man solche Strings verwendet, sollte man sich auf jeden Fall überlegen, ob diese so auch einfach auf andere Sprachen transportierbar sind.

Übersetzungen in verschiedene Sprachen sind unterschiedlich lang. Das führt im ungünstigsten Fall zum Clipping von Buttonbeschriftungen oder zur Verwendung von Fonts in unterschiedlicher Größe. Hier war der Hinweis hilfreich, eine Beschreibung in den Kontext des Buttons auszulagern, so dass sich der Button auf diesen Kontext beziehen kann.

Schließlich ging es auch noch über die Lokalisierung von gesprochener Sprache. Hier müssen die Texte aus Bausteinen zusammengesetzt werden. Wo das zu Problemen führt wurde schön anhand von Zahlen in Deutsch und Englisch gezeigt.

Insgesamt ein guter Vortrag aber der Inhalt hätte meiner Meinung nach auch in kürzerer Zeit transportiert werden können.

Astronomie mit GLKit – Daniel Dönigus

Schon wieder eine „live coding“ Veranstaltung. Hier wurde eine komplette interaktive Visualisierung des Sonnensystems innerhalb von einer Stunde zusammenkopiert. Gerade bei OpenGL werden die Codeblöcke dabei extrem umfangreich, so dass man kaum etwas erkennen konnte. Für einen erfahrenen OpenGL Programmierer war es gerade so möglich, dem Ablauf zu folgen und die GLKit Objekte zu identifizieren. Leider ist daraus kein größeres Verständnis entstanden.

Den größten Nutzen dürfte man aus den Math-Routinen ziehen. Warum Khronos keine ähnliche Auxiliary-Library für lineare Algebra und Projektionen standardisiert hat, ist mir bis Heute ein Rätsel. Was mir an der GLKit Lösung nicht gefällt ist, dass die Funktionen nur für iOS verfügbar sind. Auf dem Mac muss ich also mit dem OpenGL 3.2 Core Kontext wieder eine andere Library verwenden. Das verkompliziert die Unterstützung beider Plattformen unnötigerweise zusätzlich.

Sehr intensiv wurde der GLKitBaseEffekt eingesetzt. Damit kann man auch wirklich schnell etwas sichtbares auf den Bildschirm bekommen. Der Hinweis, dass man alles noch einmal neu machen muss, wenn man eigene Shader verwenden will, kam aber erst auf Nachfrage zum Schluss. Hier empfiehlt sich – wenn man GLKitBaseEffekt unbedingt verwenden will – meiner Meinung nach auf jeden Fall die Einführung einer Zwischenschicht, um den Umfang der Codeänderungen möglichst gering zu halten.

Von dem Vortrag hätte ich mir wesentlich mehr erwartet. Dazu hätte man aber wahrscheinlich vom „live coding“ oder besser gesagt vom „live copy & paste“ Abstand nehmen müssen. Ich werde in Zukunft auf jeden Fall einen großen Bogen um Vorträge machen in denen eine komplexe Anwendung live erstellt werden soll.

Zeichnen auflösungsunabhängig – Frank Illenberger

Es ging in diesem Vortrag eigentlich nur darum, wie man horizontale und vertikale Linien mit Quarz 2D so zeichnen kann, dass sie scharf dargestellt werden. Das Problem dabei ist, dass die Pixel einer Linie durch die Kantenglättung in einer helleren Farbschattierung gefärbt werden, wenn die Linie das Pixel nur zum Teil ausfüllt. Die am üblicherweise für dieses Problem vorgeschlagenen Lösungen sind, das Ausschalten der Kantenglättung und das Verschieben der Punktkoordinaten um 0.5. Diese Lösungen sind aber beide nicht zufriedenstellend. Zum einen betrifft das Ausschalten der Kantenglättung auch diagonale Linien, bei denen die Glättung jedoch zu einem besseren visuellen Ergebnis führt. Zum anderen funktioniert das Verschieben von Koordinaten nur bei einer Zoomstufe von 100%, bei der die Punktkoordinaten den Pixelkoordinaten entsprechen.

Die vorgeschlagene Lösung transformiert Start und Endpunkt einer Linie in den „device space“ und führt die Verschiebung auf die Pixelmitte dort aus. Anschließend wird der Wert wieder in den „user space“ zurücktransformiert. Damit bekommt man Koordinaten, die bei allen Zoomwerten auf die Pixelmitte abgebildet werden.

Das allein reicht aber noch nicht für alle Fälle. Da die Kantenglättung mit Hilfe des Alphakanals durchgeführt wird, kommt es bei Linienbreiten, die kleiner als ein Pixel sind, an den Schnittpunkten zweier Linien zu einer dunkleren Färbung. Diesem Effekt wird durch die explizite Berechnung einer Farbe für die Linie begegnet. Werden die Linienbreiten nun auf Pixelmaße gerundet, findet kein Alphablending statt.

Dieser Ansatz wurde als finale Lösung dargestellt, um anschließend den Schwachpunkt dieser Lösung aufzuzeigen. Bei einer Zoom-Animation kommt es zu einer springenden Darstellung, wogegen die Kantenglättung eine weichere Animation produziert. Dieses Problem ist der Rundung auf Pixelkoordinaten natürlich inhärent, so dass hier auch keine Lösung vorgeschlagen wurde.

Alles in allem ein sehr interessanter Vortrag. Ich bin selbst schon einmal auf dieses Problem gestoßen und habe mir einen ähnliche Lösungsansatz überlegt. Ich habe das jedoch nicht mehr in der Intensität verfolgen können, wie es Frank Illenberger gemacht hat. Deshalb freut es mich insbesondere, dass ich offensichtlich nicht der einzige Entwickler bin, den die Kantenglättungsartefakte bei horizontalen und vertikalen Linien stören.

iOS 5 Appearance Customization – Ortwin Gentz

Solider Vortrag über die neuen Möglichkeiten in iOS 5 den Stil von Controls anzupassen. Dazu zählen das setzen der Tint-Color, die Verwendung von Hintergrundbildern und die Anpassung von Textstilen. Es wurden die Möglichkeiten zum Styling bestimmter Views oder ViewController demonstriert und deren Defizite aufgezeigt, die insbesondere beim gezielten Styling von UINavigationBars auffallen.

Anschließend wurde gezeigt, wie in der App „Wohin?“ das UI-Styling bisher realisiert wurde: durch „method swizzling“ mit der Objective-C Laufzeitumgebung. Mit den neuen Möglichkeiten in iOS 5 könnte der Aufwand für das Styling in „Wohin?“ laut Aussage von Ortwin Gentz um fast 50% von über 1400 Zeilen Code auf etwa 750 Zeilen Code reduziert werden.

Bye bye Subversion

Kein Kommentar

Bei der Versionsverwaltung von Sourcecode habe ich viele schmerzhafte Erfahrungen beim Einsatz von SCCS, RCS und CVS gemacht. SVN war für mich das erste wirklich brauchbare System für die Verwaltung von Quellcodeänderungen. Zur Beschäftigung mit kommerziellen Systemen hatte ich leider nie die Gelegenheit.

Die Nachteile von SVN erkennt man leider erst, wenn man mit einem größeren Team auf einem gemeinsamen Repository arbeitet. Vielleicht gibt es ja Projekte, bei denen eine kontinuierliche Integration von Änderungen die Arbeit mit einem gemeinsamen Versionszweig ermöglicht. Ich habe aber nie in einem solchen Projekt gearbeitet. Im Gegenteil, ich sehe sogar einen Nutzen darin, jedem Entwickler einen privaten Versionszweig zu spendieren. Zudem ist es nach meiner Erfahrung auch sehr hilfreich verschiedene Teilprojekte in eigenständigen Versionszweigen zu organisieren und Integrationen entsprechend hierarchisch durchzuführen.

Mit dieser Vorgehensweise stößt man aber schnell an die Grenzen von SVN. Dies liegt vor allem daran, dass bis SVN 1.4 das zusammenfassen (merge) von Zweigen von SVN nicht protokolliert wurde. Ab SVN 1.5 wurde zwar diese Protokollierung eingebaut, in der Praxis hat das bei mir allerdings bis zur letzten Version, die ich getestet habe (1.64), nicht funktioniert. Im Gegenteil, denn mit der Protokollierung wurden auch neue Möglichkeiten für Konflikte beim Zusammenfassen von Zweigen eingeführt. Es ist mir nie gelungen, technisch weniger affinen Kollegen zu erklären, was ein tree conflict ist und wie man solche Konflikte beheben kann. Vielleicht liegt es auch daran, dass ich es selbst nicht vollständig verstanden habe.

Nun bin ich kürzlich über den Vortrag von Linus Torvalds über git bei Google gestolpert. Unabhängig davon, dass Torvalds scheinbar gerne recht provokative Formulierungen wählt, musste ich ihm in den meisten Fällen spontan recht geben. Nebenbei fand ich den Vortrag gerade aufgrund seines eigenwilligen Stils sehr unterhaltsam.

Darüber hinaus habe ich auch eine interessante Mac Applikation für die Arbeit mit git und mercurial gefunden. SourceTree wurde von Steve Streeting entwickelt, der einigen vielleicht auch noch als ehemaliger Kopf des OpenSource Projekts Ogre 3D bekannt ist. Da ich unter Mac OS bisher keinen wirklich überzeugenden grafischen Client für die Versionsverwaltung gefunden hatte (Tortoise SVN gibt es leider nicht für den Mac), kam ich schließlich zu dem Schluss, SVN durch git zu ersetzen.

Es hat mich schon etwas überrascht, wie einfach es mir gefallen ist, diese Entscheidung schließlich umzusetzen. Die einzige Fragestellung, die ich nicht zufriedenstellend durch googeln klären konnte, war die Installation von git als Service bzw. Daemon. Eine WebDAV Installation war mir zu aufwändig und bietet keinen Vorteil, da ich für mein “Homeoffice” weder Authentifizierung noch Zugriffskontrolle brauche. Ich bin der einzige Nutzer und möchte lediglich die Entwicklungsstände auf meinem iMac und meinem MacBook synchron halten.

Die git-Dokumentation erklärt zwar, wie man git als Daemon mittels inetd konfiguriert, dummerweise wurde inetd unter Mac OS schon vor längerer Zeit abgeschafft. Zur Beschleunigung des Bootprozesses wurden init, inetd, crond und weitere alte Bekannte zum Überdaemon launchd zusammengefasst. Eigentlich eine gut Idee, nur habe ich keine launchd-Konfgurationen gefunden, die der inetd-Konfiguration entspricht.

In einem Code Kitchen Artikel wird zwar eine Konfigurationsdatei beschrieben, mit dieser Konfiguration wird der git Daemon aber mittels “RunAtLoad” bereits beim Systemstart geladen. Zusätzlich sorgt “KeepAlive” dafür, dass der Prozess umgehend neu gestartet wird, falls er aus irgendeinem Grund einmal beendet werden sollte.

Wo ist jetzt das Problem? Nun ja, ein Problem gibt es eigentlich nicht. Entspricht im Wesentlichen, auch der Art und Weise, wie Dienste (services) unter Windows aktiviert werden. Unter UNIX gibt es mit inetd aber eine elegantere Variante für Netzwerkservices. Ein Netzwerkservice wird ja üblicherweise durch eine Verbindung zu einem oder mehreren Standardports angesprochen. Damit nun nicht alle Netzwerkservices ständig gestartet sein müssen, lauscht inetd stellvertretend an allen Ports für die konfigurierten Netzwerkdienste und startet den entsprechenden Daemon erst bei Bedarf. Nämlich dann, wenn eine Verbindung zum entsprechenden Port aufgebaut wird. Da inetd durch launchd ersetzt wurde, muss launchd also auch eine solche Konfiguration ermöglichen. Nach kurzem Studium der man Page war ich dann auch in der Lage, die folgende Konfiguration zu generieren. 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>UserName</key>
	<string>beba</string>
	<key>GroupName</key>
	<string>staff</string>
	<key>Label</key>
	<string>com.git-scm.git</string>
	<key>Program</key>
	<string>/usr/bin/git</string>
	<key>ProgramArguments</key>
	<array>
		<string>git</string>
		<string>daemon</string>
		<string>--inetd</string>
		<string>--verbose</string>
		<string>--export-all</string>
		<string>--base-path=/Users/Shared/git</string>
		<string>--base-path-relaxed</string>
		<string>--enable=receive-pack</string>
		<string>/Users/Shared/git</string>
	</array>
	<key>Sockets</key>
	<dict>
		<key>Listeners</key>
		<dict>
			<key>SockServiceName</key>
			<string>git</string>
			<key>Bonjour</key>
			<array>
				<string>git</string>
			</array>
		</dict>
	</dict>
	<key>inetdCompatibility</key>
	<dict>
		<key>Wait</key>
		<false/>
	</dict>
</dict>
</plist>

Für eine Übertragung auf andere Systeme sollten ggf. die folgenden Einstellungen angepasst werden:

  • Der UserName sollte von beba in einen Benutzer geändert werden, der auf dem Zielsystem existiert und unter dessen Identität der git-Daemon laufen soll. Der Wertt staff für GroupName kann bei Bedarf auch angepasst werden.
  • Der Wert /usr/bin/git für Program muss dem Pfad entsprechen unter dem git installiert wurde. Mit Xcode4 wird git unter /usr/bin/git installiert.
  • Das letzte Argument /Users/Shared/git legt den Pfad fest, unter dem die zentralen git-Repositories abgelegt werden. Bei Bedarf können auch mehrere Pfade angegeben werden.
  • Die Option –base-path=/Users/Shared/git wird der Zugriff auf die Repositories ohne Angabe des Basispfads in der URL ermöglicht.
  • Mittels –base-path-relaxed kann der Basispfad angegeben werden, obwohl er mittels –base-path=… deaktiviert wurde.
  • Mit –enable=receive-pack wird schließlich die Übername von Änderungen durch den Server aktiviert. Da es keinerlei Zugriffskontrolle in der Konfiguration als inetd-Daemon gibt, sollte diese Option in öffentlich zugänglichen Netzten nicht verwendet werden.

Ich habe die Konfigurationsdatei com.git-scm.git.plist genannt. Diese Datei muss unter /Library/LaunchDaemons abgelegt werden. Die Installation erfordert also Administrationsrechte. Anschließend muss im Terminal der folgende Befehl ausgeführt werden, um die Konfiguration zu aktivieren: 

sudo launchctl load /Library/LaunchDaemons/com.git-scm.git.plist

Auf die Repositories kann nun mit Hilfe einer git-URL zugegriffen werden. Zum Auschecken eines kann beispielsweise ein Befehl nach dem folgenden Muster verwendet werden. 

git clone git://hostname/repository local_copy

Zur Deaktivierung verwendet man analog einfach den folgenden Befehl: 

sudo launchctl unload /Library/LaunchDaemons/com.git-scm.git.plist

Gravis Safety Pack Plus

Kein Kommentar

Als freiberuflicher Softwareentwickler bin ich darauf angewiesen, dass meine Macs funktionieren. Deshalb war es eine sehr unangenehme Erfahrung, als mein 2008er MacBook (non Unibody) am Abend des 5. Januar plötzlich nicht mehr starten wollte. Eine Folge von drei Tönen beim Einschalten sind ein Hinweis auf einen Hardwarefehler beim Hauptspeicher konnte ich schnell über Google in Erfahrung bringen. Gut, dass ich eine Garantieerweiterung auf 3 Jahre beim Kauf bei Gravis in München abgeschlossen habe.

Da der 6. Januar in Bayern ein Feiertag ist, bedeutete dies aber, dass ich den Rechner erst am Freitag, den 7. Januar zur Reparatur geben konnte. Das heisst mehr als 24 Stunden ohne MacBook!

Am Freitagmorgen bin ich also mit meinen Garantieunterlagen zum Gravis Store gefahren. Dort teilte man mir mit, dass die Wartedauer, bis das MacBook von einem Techniker angesehen wird, mindestens zwei Werktage beträgt. Erst dann könne man mir mitteilen, wie lange die Reparatur dauern wird. Also habe ich mich innerlich schon mal bis Dienstag von meinem MacBook verabschiedet. Schlechtes Timing. Aber dafür kann niemand was.

Andererseits sind sechs Kalendertage Ausfall für den Austausch eines Speicherriegels (Arbeitsaufwand ca. 5 Minuten, Kosten ca. 50€) schon eine Ewigkeit. “Aber es könnte auch schlimmer sein. Vieleicht ist es ja ein mechanischer Defekt der Steckplätze und das wäre dann ein deutlich höherer Aufwand.” warf der Techniker bei Gravis ein. Schon gut, dann warte ich halt.

Nun sollte ich in einer Minute erfahren, dass es tatsächlich viel schlimmer war. “Sie haben scheinbar die falsche Rechnung. Die Seriennummer stimmt nicht überein.” WTF? Ich habe nur einen 15″ MacBook 2008 bei Gravis gekauft. Außerdem bemerkte ich, dass die Seriennummern von Rechner und Garantieerweiterung auf der Rechnung ebenfalls unterschiedlich sind. Beide falsch! “In diesem Fall können wir die Reparatur leider nur unter Vorbehalt übernehmen” meinte nun der Techniker. Ob die Unstimmigkeit auf der Rechnung eine Reparatur auf Kulanzbasis erlauben würde könnte nur die Zentrale in Berlin klären. Erschwerend kommt hinzu, dass mein MacBook auch nicht in den Werkstattprotokollen auftaucht, obwohl laut Rechnung eine Speichererweiterung auf 4GB eingebaut worden sein müsste. Man gibt mir die E-Mail Adresse der Servicezentrale in Berlin, um den Fall zu klären und ich packe ziemlich angefressen meine Sachen wieder ein.

Wieder Zuhause bin ich erst einmal Ratlos. Außer der Unstimmigkeit auf der Rechnung spricht alles dafür, dass ich Gravis einen falschen Rechner unterjubeln will. Ich gehe noch mal in den Keller und suche den Originalkarton des MacBooks, den ich aufgehoben hatte. Die Seriennummer auf dem Karton stimmt mit der meines Macbooks überein. Aber auf dem Karton ist auch noch ein Serviceaufkleber von Gravis für die 4GB Speicher, die ich einbauen lassen habe. Und dort befindet sich eine Garantienummer. Und die stimmt mit der Auftragsnummer auf meiner Rechnung überein. Gotcha!

Noch am Abend des 07.01. setze ich mich hin und schreibe die E-Mail an die Gravis-Zentrale. Um meine Angaben zu belegen, füge ich Scans der Rechnung und des Kartons bei. Dummerweise ist jetzt erst mal Wochenende. Am Montag, den 10.01. bekomme ich eine Eingangsbestätigung von Gravis.

Bis zu einer Antwort sollte es allerdings noch bis zum folgenden Montag, den 17.01. dauern. Inzwischen habe ich mir bereits notgedrungen ein neues MacBook gekauft. Am Morgen des besagten Tages erhalte ich einen Anruf aus Berlin. Ein Gravis Mitarbeiter meldet sich und teilt mir mit, dass er sich wohl entschuldigen müsste. Die Rechnung sei falsch ausgestellt worden und ich könnte mir im Gravis-Store in München eine korrigierte Rechnung ausstellen lassen. Na super! Aber wenigstens haben sie sich entschuldigt.

Mein neues MacBook hat jetzt AppleCare. Nach den Erfahrungen mit Gravis erscheint mir der Preisunterschied plötzlich gar nicht mehr so gravierend. Für den Privatanwender mag die Garantieerweiterung von Gravis ja eine Alternative sein. Aber wenn man beruflich von diesem Rechner abhängt, dürfen solche Komplikationen einfach nicht auftreten!

Plan B Theme für WordPress

Kein Kommentar

Die erste Version des Themes für dieses Blog ist nun aktiviert. Das Thema generiert HTML5 und verwendet einige CSS3 Techniken. Deshalb hatte ich erwartet, dass es momentan mit relativ wenigen Browsern funktionieren wird. Während der Entwicklung habe ich es eigentlich nur mit Safari auf dem Mac, iPhone und iPad getestet.

Bei den ersten Tests mit Firefox habe ich festgestellt, dass abgerundete Ecken (border-radius) und Verläufe (gradient) nicht dargestellt wurden. Warum Firefox immer noch die inzwischen ungültige Syntax für diese Eigenschaften verwendet, obwohl die aktuellen Standardentwürfe schon seit einiger Zeit die neue Syntax vorschlagen, ist mir ein Rätsel.

Mit IE7 habe ich erwartungsgemäß keine abgerundeten Ecken, keine Verläufe und keinen Schlagschatten. Die Hintergrundfarben für den Kalender wurden scheinbar nicht akzeptiert. Ansonsten bin ich aber schon etwas überrascht, wie gut die Darstellung im IE bereits ist.

Das Layout passt sich mit Hilfe von CSS Media Queries an die verschiedenen Bildschirmgrößen an. Der folgende Code zeigt das entsprechende CSS:

@media screen and (max-width:719px) {  /* small */
  ...
}

@media screen and (min-width:720px)
              and (max-width:959px) { /* medium */
  ...
}

@media screen and (min-width:960px) { /* large */
  ...
}

Abhängig von der Bildschirmgröße wird nun eines der drei Layouts gewählt. Das funktioniert in Safari, Chrome und Firefox sogar beim Verändern der Fenstergröße.

Es geht los

Kein Kommentar

Nun ist es endlich soweit. Mein Blog ist online. Hier möchte ich ab sofort über meine Erfahrungen zu mobilen Geräten und Anwendungen berichten. Als Softwareentwickler werde ich meinen Schwerpunkt natürlich auf technische Themen setzen. Da ich mich zeitgleich selbstständig machen werde, hoffe ich aber auch, die eine oder andere Erkenntnis über das Marketing von mobilen Lösungen zu gewinnen.

Meine erste Aufgabe besteht nun in der grafischen Gestaltung dieses Blogs. Dabei soll die Unterstützung von mobilen Plattformen einen besonders hohen Stellenwert bekommen. Meine nächsten Beiträge werden sich also erst einmal mit diesem Thema auseinandersetzen…