Bitte benutzt Emojis überall! Wirklich! Überall! Besonders auf den Systemen, bei denen die Emojis vom Emoji Cheat Sheet unterstützt werden 😉
Es gibt glaube ich kein Emoji, das es nicht gibt… Welches sind eure Lieblings-Emojis?
Bitte benutzt Emojis überall! Wirklich! Überall! Besonders auf den Systemen, bei denen die Emojis vom Emoji Cheat Sheet unterstützt werden 😉
Es gibt glaube ich kein Emoji, das es nicht gibt… Welches sind eure Lieblings-Emojis?
Responsive Design ist zur Zeit anscheinend das Allheilmittel, um mobile Varianten von Websites anzubieten. Zugegeben, es hat einige Vorteile, was die Wartbarkeit der Codebasis angeht und es ist auf den ersten Blick sehr charmant, nur ein einziges kombiniertes Set an HTML Templates verwalten zu müssen, das mit CSS Media Queries dann die jeweils richtige Darstellung auswählt.
Jedoch gibt es auch eine andere Sicht der Dinge. So haben 37signals bei der Entwicklung der mobilen Variante von Basecamp Next – ihrem Flaggschiff Produkt – eine parallele mobile Viewschicht gebaut, die heftig optimiert und vom Umfang her reduziert ist. In seinem Artikel beschreibt Jasons Zimdars, wie sie jeden einzelnen Screen angeschaut und für die mobile Benutzung optimiert haben, um die beste Performance herauszuholen. Er erläutert auch einige grundsätzliche Strategien und Überlegungen, die aus dem Projekt hervorgegangen sind.
Bei Basecamp Next betrifft die Optimierung auch „nur“ die Viewschicht. Models und Controller der Rails App werden weiterhin mitbenutzt. Somit hält sich der Overhead noch einigermaßen in Grenzen.
Das Ganze erinnert mich an die verschiedenen Ausgabekanäle bei Generierungs-CMS wie zB FirstSpirit, die für die verschiedenen Varianten dann auch noch statisches HTML (oder JSON oder XML oder oder oder) rauspusten und verschiedenste Anwendungsszenarien abdecken können. Hier bedeutet jeder Ausgabekanal ebenfalls zusätzlichen Aufwand und zusätzliche Templates.
Natürlich ist eine parallel zu betreibende Variante ein nicht zu unterschätzender Kostenfaktor beim Launch und auch im späteren Betrieb. Daher sollte man schon einen entsprechenden Anwendungsfall haben, in dem eine solche Optimierung entsprechend Sinn ergibt. Sollte dies der Fall sein, zeigt der Artikel, welche Performancegewinne bei einer dedizierten mobilen Variante zu realisieren sind.
http://37signals.com/svn/posts/3269-behind-the-speed-basecamp-mobile
Interessant ist auch der Artikel zur grundsätzlichen Performance von Basecamp Next und den verwendeten Technologien wie zB HTML5 pushState statt dem Neuladen von Seiten oder dem Hin- und Herschicken von JSON. Die Vorgehensweise grenzt beinahe schon an negatives „Partial Caching“ auf der Clientseite. Wobei auch die Caching Strategien im Detail erläutert werden. Viele der Optimierungen sind übrigens auch wieder in die öffentliche Rails Version zurückgeflossen.
Die neue jQuery Version steht seit dem 18. April zum Download bereit. Es haben sich einige Änderungen ergeben, die vor allem auch mit der Abwärtskompatibilität Schluss machen. Viele Entwickler haben darauf gewartet, dass endlich die vielen Hacks und Sonderwege für alte Internet Explorer Versionen entfernt werden, damit der Code wieder schlanker und damit natürlich auch performanter werden kann. Aber: Die IE Unterstützung beginnt jetzt tatsächlich erst mit Version 9…
Um aber weiterhin jQuery auch mit älteren Browsern einsetzen zu können, wird nach der 1.9er Version eine 1.10er kommen, in der auf jeden Fall Sicherheitsupdates und kleinere Bugfixes weiter gepflegt werden. Die 2.0er Version ist übrigens API-kompatibel mit der 1.9er Version und das jQuery Migrate Plugin kann hier ebenfalls beim Update unterstützen.
Eine immer größere Bedeutung kommt den jQuery Plugins zu. Viele Funktionen werden hierüber nachgerüstet und manche Seiten sind ohne jQuery Plugins gar nicht benutzbar. Um der immer unüberschaubarer werdenden Flut an Plugins Herr zu werden, gibt es mittlerweile ein zentrales jQuery Plugin Repository, in dem die Plugins auch bewertet werden können. Unter plugins.jquery.com findet ihr die Übersicht und auch die Bewertungen der einzelnen Erweiterungen.
Im Forecast Blog haben die Entwickler der populären Wetter-App ihre Gedanken zur Entwicklung für mobile Geräte zusammengefasst. Sie widersprechen der weit verbreiteten Meinung, dass native Apps der einzige „Way to go“ ist, wenn man schnelle und performante „Apps“ für mobile Geräte entwickeln will. Ihre eigene App ist als HTML5 App implementiert, fühlt sich aber wohl für die meisten Benutzer wie eine native App an. Sie nennen es: „Eine App, die man aus dem Web installiert“…
Sie geben am Ende des Artikels einige Tipps, wie man das erreicht. Ich fand besonders interessant, dass es wirklich auf einen „hybriden“ Ansatz hinausläuft, der nicht zwischen nativer App und Website streng unterscheidet, sondern durchaus Dinge wie GPU-Optimierung von CSS Transformations berücksichtigt. Auch das Look-and-Feel sollte möglichst Elemente beider Welten vereinen, damit man beim User keine falschen Erwartungen weckt.
Insgesamt ein sehr interessanter Ansatz, den man bei eigenen Entwicklungen berücksichtigen sollte.
http://blog.forecast.io/its-not-a-web-app-its-an-app-you-install-from-the-web/
Es gibt einem schon zu denken, wenn man sieht, wie groß die Unterschiede sind. 200 Kalorien in Form von Broccoli sind schon was anderes als 200 Kalorien als Snickers Riegel. Wenn es denn mal ein ganzer Riegel wäre…
Wenn man das so drastisch vor Augen geführt bekommt, bewirkt es ja vielleicht was… 😉
Wenn ihr einen Google Account habt, könnt ihr mit der Google Maps Engine Light herumspielen und eigene Maps zusammenstellen. Hier könnt ihr Layer mit eigenen Informationen über das Kartenmaterial von Google legen und diese Informationen auch noch elegant und flexibel stylen.
Ihr könnt verschiedene Karten abspeichern und wieder laden und sie nachher dann auch freigeben. Entweder privat an andere Collaborators oder auch Öffentlich im Web.
Oldie but Goldie. Man muss glaube ich nicht viel dazu sagen und es mit einem Zwinkern im Auge lesen. Ein Körnchen Wahrheit steckt in jeder einzelnen Regel.
…enter Josh Berkus 🙂
http://www.databasesoup.com/2013/03/20-rules-of-software-consulting.html
Auf websec.io habe ich letztens einen interessanten Artikel über die Respect Validation Engine gefunden. Laut dem Beitrag handelt es sich um die de-facto Standardbibliothek zum Validieren von User Input in der PHP Community. Ich kannte sie bisher jedoch noch nicht, deswegen wollte ich gerne auf die umfangreiche Library hinweisen. Vielleicht hilft sie ja in dem ein oder anderen Projekt.
Die Bibliothek kann einfach per Composer als Dependency zu einem bestehenden Projekt hinzugefügt werden und bietet jede Menge interessanter Validierungsroutinen „out-of-the-box“. Natürlich ist sie auch flexibel erweiterbar durch Callback Funktionen. Und natürlich kann man verschiedene Validierungsregeln verketten oder auch bestimmte Regelketten zur Wiederverwendung zentral definieren.
Innerhalb eines Zend Framework oder Symfony Projekts kann Respect auch deren Validatoren mitbenutzen, sofern sie installiert sind.
Für Beispiele lest ihr am besten den Beitrag und schaut euch das Projekt auf github an:
Viele von euch kennen sicherlich David Heinemeier Hansson, den „Erfinder“ von Ruby on Rails und Partner bei 37signals. Er hat mit seiner „opinionated software“ eine Menge bewegt und natürlich auch viele Menschen provoziert.
Ich selber oute mich hiermit als kleinen (oder großen) DHH und 37signals Fanboy. Daher fand ich es sehr spannend, die für David 5 wichtigsten Bücher mal im Überblick zu sehen.
http://37signals.com/svn/posts/3375-the-five-programming-books-that-meant-most-to-me
In der Kürze:
Ich werde mal schauen, dass ich die fehlenden Exemplare noch besorge und mal durchschaue. David geht in seinem Beitrag natürlich noch genauer auf die Bücher ein. Also schaut auf jeden Fall rüber 😉
Künstler als Minensucher.
http://www.davidairey.com/massoud-hassani-mine-kafon/
Der Künstler Massoud Hassani hat ein Minensuchgerät aus Bambus entwickelt, das selbständig ganze Areale auf Minen absuchen kann und damit in Kriegsgebieten nach dem Abzug der Soldaten die Gegend wieder sicher für die Zivilbevölkerung machen kann.
Moleskine Stop-Motion mit Making-Of
http://www.davidairey.com/rogier-wieland-suus-hessling/
Ein tolles Stop-Motion Video zum Thema Moleskine Notizbücher inkl. Making-Of. Krasser Design-Prozess und krass, wieviel Aufwand in so „kleinen“ Stop-Motion Projekten steckt.
Parkinson’s Voice
http://parkinsonsvoice.org
Ein interessantes Projekt, bei dem Parkinson mithilfe von Stimmenanalyse diagnostiziert werden soll. Dadurch kann man die Krankheit früher erkennen und früher behandeln, wodurch die Lebensqualität der Betroffenen stark verbessert werden kann.
Man kann sich zwar nicht mehr daran beteiligen, aber auf der Seite kann man das TED Video anschauen und mehr darüber erfahren. Spannend.