Kein Wi-Fi im Deutschen Museum Technik

Besuch im Deutschen Museum, allerdings kein Wi-Fi! Und UMTS reicht auch nicht aus, um direkt vor Ort realtime meinen Blogeintrag zu posten. Schade! Erst ein paar Meter neben dem Deutschen Museum reicht die Bandbreite aus. Das ist das, was Gunter Dueck meint: Wir brauchen eine bessere Infrastruktur: Wi-Fi stabil für jedermann immer und überall als Selbstverständlichkeit. Das muss das Ziel sein. Gerade an einem Vorzeigeort wie dem Deutschen Museum. Wenn wir es dort nicht schaffen, wo dann?

Auch nach „Deutsche Museums“-Apps suche ich vergebens. Nichts. Was ich im Web finde, reicht mir nicht. Hier muss erheblich nachgebessert werden, wenn wir unseren Vorzeigestatus und Anspruch auf didaktischen Mehrwert beibehalten wollen. Der Schritt ins Internet-Zeitalter erfordert erhebliche Investitionen. Der Gewinn ist gewaltig! Schüler und Studenten könnten die Exponate nicht nur während des Besuchs im Deutschen Museum goutieren, sondern auch zu Hause, in der Schule oder Hochschule, immer und jederzeit. Dann käme Leben ins Museumshafte!


—– Artikel wurde auf meinem iPad erstellt

Position:Sankt-Anna-Platz,München,Deutschland

#Froscon: WebApps statt Native Apps for Smartphones and Tabletts

Andrew Betts, Assanka.Net, Twitter @triblondon: „We’ve got a Website for that …„, subtitle: „The Financial Times Web app and the Future of the Mobile Web.

Betts entwickelte zusammen mit 2 weiteren Kollegen eine Web App (app.ft.com) für die Financial Times (FT). Bevor er seine hervorragende Lösung zeigte, ging er in seinem Vortrag zunächst auf die Geschichte der mobilen Web-Lösungen ein. Er begann mit WML, was auf den damals noch schwarz-weißen Geräten so grässlich aussah, wie auf einer seiner ersten Folien dargestellt, die Betts mit einem Blackberry Playbook abspielte (Nein, man braucht nicht immer Powerpoint! Das ist nur so eine Gewohnheit.):

Danach stellte Betts die weitere Entwicklung dar, die zuletzt wesentlich von Apple geprägt wurde. Die Usability gewann dadurch erheblich. Apple förderte allerdings nicht die Weiterentwicklung der Web-Standards, sondern erfand seine eigenen Native Apps. Usability wurde wesentlich voran gebracht, z.B. durch Overscroll for Reload, Swipe, Fling, Pitch, …

Die Nachteile der nativen Apps überwiegen jedoch gegenüber Web Apps:


Können wir das Web nicht so einfach benutzbar machen wie Native Apps?
One web app, a Million devices as Web browsers?

Betts präsentierte eine Lösung mit HTML5. Einige interessante Aussagen:

Man beginnt mit den Standards, stellt jedoch bald fest, dass CSS column nicht gut genug für anspruchsvolles Layout ist.
Content Balancing adressiert die Frage, wie der Bildschirm am Besten gefüllt wird. Die Lösung ist je nach Anwendung verschieden.
Swipe ist in JavaScript sehr schwer zu implementieren, aber es geht.
WeinRE ist eine OpenSource-IDE, mit der man sehr gut Plattform-übergreifend arbeiten kann.
Snapping article pagination wurde mit der Touchscroll-Library realisiert.
Offline Access ist ein wichtiges Thema. Log user actions into Local DB.
Ein App Manifest kann man sich vorstellen wie ein minimaler Client Server. 5 MB sind verfügbar, auch mit SQLIndexedDB, SQLlite, localStorage,…
charlesproxy.com hilft beim Verstehen der Apps.

Es gibt noch einige ungelöste Probleme.

Resumée: „The Web can do it, sometimes better than Native Apps can.“

Betts schloss seinen Vortrag mit einem
Zitat von Tim Berners Lee: „Don’t build native apps, build Web Apps.

#Froscon: Skalierbare Webanwendungen

Node.js ist ein Serverseitiges JavaScript-Framework, das man immer häufiger in skalierbaren Webanwendungen findet.

Session-Daten können in Cookies, in einem serverseitigen lokalen Filesystem, oder auf einem dedizierten Sessionserver gespeichert werden, der Sessionanfragen hauptspeicherbasiert (durchaus mit Durability), nonblocking, eventbasie, multithreaded realisiert. Damit können bis zu 100.000 req/sec geleistet werden mit weniger als 1 msec Response Time mit Standard Hardware. (Dafür sind sogar MySQL-Lösungen zu langsam.)

Der Vortrag von zwei triAgens-Mitarbeitern stellte eine skalierbare Open Source Lösung namens SessionVOC vor mit eingebauter Master/Master-Replikation (asynchrone Replikation) und automatischer on-the-Fly Garage Collection.

Nebenbei löst SessionVOC auch noch weitere Probleme: Hidden Field Ping Pong wird durch Formdata als Teilobjekte einer Session vermieden. Die Heterogenität von Webprojekten wird durch einen Programmiersprachen-agnostischen Ansatz gelöst. SessionVOC ist auch als Authorisierungsserver einsetzbar. Noncen (only once) verhindert ungewolltes mehrfaches Auslösen der gleichen Aktion.

Verwendete Frameworks: Node.js, Connect (structured like an onion), npm als Node Package Manager npmjs.org, …

Weitere Informationen siehe sessionvoc.org

Zum Vergleich wurde auch auf Express und Ruby Sinatra eingegangen.

—– Artikel wurde auf meinem iPad erstellt

iPad App BlogPress

Dieser Artikel wurde mit dem iPad App BlogPress erstellt. Das Einbinden von Fotos klappte auf Anhieb – was man leider nicht von allen iPad Blogger Apps behaupten kann.


—– Artikel wurde auf meinem iPad erstellt