Native App vs. HTML5 Webapp – Forecast.io Artikel

Forecast.io

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/

Google Maps Engine Light

Google Maps Engine Light

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.

https://mapsengine.google.com/map/?pli=1

Respektvolle Validierung

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:

Die 5 wichtigsten Programmierbücher für DHH

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:

  • Smalltalk Best Practice Patterns
  • Refactoring
  • Patterns of Enterprise Application Architecture
  • Domain-Driven Design
  • Are Your Lights On?

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 😉

The Tide and its Taker

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.

 

Pick Your Battles – Mature Technology is worth something

Zef Hemel von Cloud9 IDE, bzw. jetzt LogicBlox hat einen interessanten Artikel über Softwareentwicklung und Technologieentscheidungen geschrieben.

Er weist darauf hin, dass es einen Unterschied gibt, ob man eine Technologie einsetzt, weil sie dem Projekt hilft oder ob man sie einsetzt, weil man die Technologie ausprobieren möchte.

Seiner Meinung nach hat man zwei Optionen:

  • Eine geile App mit einer langweiligen, bewährten Technologie bauen
  • Eine langweilige, bewährte App mit einer Cutting-Edge Technologie bauen

Aus seiner Sicht verkraften die wenigsten Projekte beides…

  • Eine langweilige App mit langweiliger Technologie sorgt für Langeweile und Unmut bei der Entwicklung
  • Eine Cutting-Edge App mit Cutting-Edge Technologie birgt zuviel Komplexität und zuviele Unwägbarkeiten

Ein interessanter Standpunkt. Wie seht ihr das?

Der Artikel ist sehr umfangreich und bietet eine Menge Stoff zum Nachdenken.

Pick Your Battles by Zef Hemel

In summation:

  1. Don’t underestimate the value of mature technology. Things will break, and you will have to fix them. It’s bad enough if your own code is a problem, it’s worse when the problem is a poorly understood “feature” of your platform of choice.

  2. Don’t optimise prematurely. Don’t choose C because it’s faster. Don’t use MongoDB because, supposedly, it scales better. Don’t cache until you’re sure you have to.

  3. Be pragmatic. Technology like node.js and Redis have many great uses. If you hit one of their use cases: limit their scope to what makes sense. There’s no need to go all-in at all costs.