Archiv der Kategorie Technologie/IT

Apple, Flash – ich bin nicht alleine

Auch andere haben sich mit diesem Thema in den letzten Tagen befasst.

Zum einen gibt es einen Artikel auf TUAW, zum anderen auch einen umfangreichen Blogbeitrag. Gerade letzterer verfolgt ähnlich meinem Beitrag nicht nur die iPad/Flash-Thematik, sondern auch die allgemeine Performance in iPhoneOS als auch Mac OS X. Die herausragendsten Passagen sind sicherlich folgende.

Serlet didn’t name any specific guilty plugins. Just “plugins”. But during the week at WWDC, I confirmed with several sources at Apple who are familiar with the aggregate Crash Reporter data, and they confirmed that “plugins” was a euphemism for “Flash”.

In other words, in Apple’s giant pile of aggregate crash reports — from all app crashes on all Macs from all users who click the button to send these reports to Apple — Flash accounts for more of them than anything else.

Jo. Warum kommt das jetzt jedem so bekannt vor.. :( Ein weiterer Grund: Apple musste auf Adobe warten, bis die sich endlich mal dazu bequemen, eine 64-Bit-Version herauszubringen. Da das ja bekanntlich nicht der Fall ist, Mac OS X aber 64-Bit laufen soll.. musste eine entsprechende Abstraktionsschicht für Browserplugins (also ein eigener Flashprozess..) her. Die Alternativen wären gewesen: Kein 64-Bit-Safari oder gar kein Flash.

It’s a chicken-and-egg problem. Publishers use Flash for web video because Flash is installed on such a high percentage of clients; clients support Flash because so many publishers use Flash for web video. Apple, with the iPhone, is solving the chicken and egg problem. For the first time ever, there is a large and growing audience of demographically desirable users who don’t have Flash installed. If you want to show video to iPhone users, you need to use H.264.

Machtpositionen sind manchmal zu was nützlich.

Und zuletzt spricht er über die Performanceproblematik von Flash/Mac OS X*. Ingesamt doch ein bisschen interessant zu lesen.

* Da geht es um die Sache mit der fehlenden H.264-Unterstützung in Form einer Public API, Flash auf die Mac Hardware zugreifen kann. Während das natürlich unschön ist, erklärt das aber immer noch nicht die beschissenen Laufzeitverhalten. Wenn eine Flash-Anwendung keine (H.264)-Videos und hochauflösenden Bilder hat, warum sind die Performancestats so beschissen?

Apple und die Sache mit Flash [Update]

Nun wissen wir endlich alle, wie der neuste Wurf von Apple heißt: nicht iTablet, kein iSlate sondern iPad. Okay, eigentlich hätte man auch iPod Touch Pro nennen können, den mehr ist es – erstmal – auch nicht. Klar, ein größeres Display und die daraus resultierenden weiteren Möglichkeiten, die die Apps/UI damit bieten, sind es dann schon.

Weiterhin scheint sich Apple aber zu sträuben endlich auch Flash auf ihre mobile devices zu bringen. Während es bei der iPod Touch/iPhone-Palette durchaus verständliche Gründe aus Sicht der Performance und auch der Usability gibt, werden diese Gründe bei iPad natürlich geringer. Warum also sonst?

Performance

Leider haben Flashobjekte immer wieder die Angewohnheit, sowohl CPU- als auch RAM-lastig zu sein. Ob das nun ein Problem vom Flashplugin oder vom zuständigen Entwickler ist, das kann man so natürlich nicht sagen. Dazu kommt, dass Adobe sich nicht imstande sieht, für Nicht-Windows-Systeme eine ordentliche Version es Flashplayers herauszubringen.

Oder um es mal am Beispiel zu nehmen: Es ist definitiv nicht normal, dass ein Flashspiel wie Farmville auf einem iMac Core 2 Duo mit knapp 3Ghz und 4 GB Ram gerne mal 50-150% CPU und das Flash-Plugin alleine (also ohne Browser) über 200 MB beansprucht. Und zwar im “ohne Details”-Modus. Youtube-Videos sind da mit 40% und nicht nennenswertem RAM-Verbrauch gelinde gesagt überschaubar.

Diese Probleme könnten auch auf dem iPad oder iPhone auftreten, ein Umstand, den Apple definitiv vermeiden will. Performance-Killer sind nicht erwünscht (irgendwie auch verständlich).

User Interface (UI)

Flashanwendungen sind immer für eine Interaktion mit einer Maus konzipiert. Wie sollen die mit einem Touchpad harmonisieren? De facto bedeutet das, das eine Reihe von Flashanwendungen nicht “funktionieren”, weil das Plugin keinen richtigen Unterschied zwischen Bewegen und Klicken oder Rechtsklick vermitteln kann bzw. das “Mauszeigerziehen” überhaupt nicht in der Form vorhanden ist. Und iPhone/iPad spezielle Gesten sind komplett unbekannt. Eine große Inkonsistenz – und von Adobe habe ich in der Richtung noch nichts gehört. Das ist auch nicht im Sinne von Apple, die ein konsistentes System anbieten wollen.

Stichwort Konsistenz: Selbst die einzelnen Flashplayer haben alle eine eigene UI und Benutzerführungslogik: Zusammenfassend kann man wohl sagen, dass der Play-Button meistens links ist. Mal darf man zoomen, mal gibt es Vollbild, mal darf man spulen. Manchmal ist der Button rund, mal ist er eckig. Das passt ebenfalls nicht in die konsistente und einfache Welt des iPhones – und iPads.

Nicht zu vergessen sind natürlich noch diese “Hammer-Player-mit-jedem-Schnickschnack-der-möglich-ist”-Flashanwendungen, bei denen definitiv ein Koller vorprogrammiert ist.

Die Alternative, einfach die Funktionen zu reduzieren, ist natürlich eine Sache von Adobe und vom dem Entwickler. Und, nein, nicht wirklich eine Option (die genutzt würde).

Festzuhalten ist also: native App > Web App > Flash App

Flash für alles und nichts

Flash ist eins der meist verbreitesten Internetplugins, und tatsächlich haben viele Seiten ein Flash “versteckt”.

  • Werbung (und danach kräht außer der Werbebranche nun wirklich keiner nach);
  • komplexe Anwendungen (wie etwa auch o.g. Farmville), die wohl als native bzw. Device-optimierte App wesentlich besser geeignet wären;
  • Flashvideoplayer;
  • “Ich-wusste-es-nicht-besser”-Statements.

Letzteres sind Dinge wie Navigationsmenüs oder “Webseitenlogos” in Flash, die in der Regel ein gutes Statement zur Inkompetenz aufweisen. Der Großteil ließe sich mit HTML/CSS/Javascript auch lösen (und ja, das Web bietet auch kostenlose(!) Frameworks für Animationen) – und das zu einem Bruchteil der benutzten Browserperformance. Aber Unkenntnis und das Flash-Buzzword bieten halt leider viel Potenzial für solche Lösungen. Nur einige hoch angesetzten (oder utopisch?) Anforderungen müssten wirklich Flash nutzen; und natürlich nur aus Flash bestehende Anwendungen. Diese Webseitenbetreiber wissen aber auch, dass sie damit eine Reihe von Leuten ausschließen (und sei es nur mangels großem Display). Kann sich jemand wirklich und ernsthaft die ZDF-Mediathek als Flashanwendung vorstellen? Auf dem iPhone? Auf dem iPad? Letzteres vielleicht, aber auch nur wenn die Auflösung mitspielt, denn Flash hat stets eine fixe Größe. Eine native App würde wohl jeder vorziehen, wohl auch zu Recht..

Am Beispiel: Die gesamte Produktpalette von Google wäre sicherlich nicht so erfolgreich, wenn sie Lösungen aus Flash nutzen würde. Man stelle sich das vor, Google Mail oder auch Microsofts Outlook Web als eine große Flashanwendung. Unfassbar, jeder würde den Kopf schütteln.

Als Fazit: Alternativen – und was wohl dahintersteckt

Als eine die Alternative für Flash ist HTML5/CSS3 anzusehen, welches u.a. eine starke Unterstützung für “Anwendungen” im klassischen Sinne anbietet.; beispielsweise Datenbank-API, File-API und natürlich das Video-Tag. Apple ist auf den Zug aufgesprungen, als sie das iPhone (in der ersten Version, wohlgemerkt!) mit dem hauseigenen Browser WebKit ausstatteten. Unterstützt mit der Tatsache, dass sie ein paar Ergänzungen in ihrer MobileSafari im Vergleich zum normalen WebKit machen, besitzen iPod/iPhone/iPad damit einen leistungsstarken Browser. Nicht ohne Grund setzt auch Google in Adroid auf diese Browserengine, wenngleich mit anderer Javascriptengine.

Der Browser selber hat im Gegensatz zu Flashplugins (die quasi ja nur eine Schnittstelle zu einer anderen Anwendung herstellen) den großen Vorteil, dass sein UI durch das Betriebssystem gesteuert wird. Im Gegensatz zum Flash, wo dies jeder Entwickler selber macht.

Flashvideo? Brauchen wir nicht, der HTML5-Videotag macht’s möglich. UI-Effekte wie Transformationen (größer, kleiner, verschieben, Farbwechsel) mit Javascript oder sogar Flash? Brauchen wir nicht, geht mit CSS3. Eine Flashapp zum Speichern von Daten (serverseitig)? Braucht man nicht, geht auch mit HTML5/Javascript. Außerdem gibt es integrierte Offline/Online-Sync-Möglichkeiten.

Für mich sind mögliche Offline-Webanwendungen ein Killerfeature für mobile devices, denn warum soll “Netz nicht verfügbar” immer bedeuten, das ich jetzt machtlos bin?

Um wieder zum Anfang anzuknopfen: Man hatte natürlich gehofft, das Apple ein Flashplugin für das iPad anbietet bzw. es unterstützt. So wie es im Moment aber aussieht, ziehen sie – mehr oder weniger direkt – gegen Adobe in den Krieg und setzen dabei weiterhin komplett auf HTML5 bzw. auf native Apps. Da die Geräte – glücklicherweise – eine gewisse Machtposition im Sektor der online mobile devices besitzen, sind die Anbieter von Diensten auf Alternativlösungen angewiesen, falls sie die doch große (und vor allem: sehr wichtige) Zielgruppe nicht ausgrenzen wollen. Davon können im Ende alle profitieren, wenn die *** proprietäre Flashgeschichte schwindet und stattdessen kleine, Client-performante und offenere Lösungen entstehen.

Übrigens: Auch Google setzt bekanntlich auf HTML5. Nicht nur Google Gears wurde entwicklungsplanmäßig in die Tonne gehauen, sondern auch Neuentwicklungen entstehen alle im Fokus der HTML(5)-Features. Das neue Google Voice (leider ein unschöner US-only-Kandidat) bietet VoIP. Kein Flash, pures HTML/CSS/Javascript.

Und mal ehrlich: Vermisst jemand wirklich das Flashplugin auf dem iPhone? Oder: Nutzt jemand wirklich Flash auf einem anderen Smartphone so intensiv, das es notwendig ist? Wenn ja, für was?

Update, 29. Januar 2010

Tatsächlich gibt es Ansätze, wie man Multitouch und Gesten in Flash umsetzen kann. Denn eine Maus und einen Mauszeiger findet man auf Multitouchgeräten nicht – um Gegenteil: man hat mehrere Pointer. Das bedeutet aber nicht, das vorhandene Flashanwendungen das alle nutzen würde, haha. Zu früh gefreut.

Featurities meets Fallstrick: Die Spring Security 3.0 Konfigurationsodyssey

Mit dem Majorrelease 3.0 wurde dem Modul Spring Security eine Menge von neuen Features angeignet. Spring Security ist die Modulkomposition, welches für das Java Framework Spring quasi die gesamte Authentifizierung, Autorisierung, Legitimierung jedwegiger Art ermöglicht.

Leider wurden mit dem Release 2.x auf 3.0 eine Reihe von API-Changes vollzogen. Zugegeben, die waren auch sicher alle sinnvoll, weil Komponenten wie die Authentifizierung weiter geteilt wurden und man somit wesentlich flexibler ist, neue Anforderungen zu ermöglichen (Baukastenprinzip). Aber die Dokumentation ist – gesamtheitlich betrachtet – irgendwie immer noch mies und oft nicht aktualisiert. Oder man findet im Internet einfach nur (alte) Beispiele.

Die http-Direktive

Im Namespace von Spring Security existiert das Tagelement http, mit welchem man kurze, knappe und verständliche Konfigurationen anlegen kann. Der Vorteil liegt klar auf der Hand: Man muss nicht alle Beans, Listener und Provider anlegen, denn das geschieht automatisch. Tja, wären da nicht ein paar Einschränkungen in der Funktionsvielfalt.

Konkretes Beispiel: Remember Me

Just wurde das Minor-Release 3.0.1 veröffentlicht, und nur wenige Tage später zu erfahren, dass Remember Me kaputt sei. Egal, fahren wir erstmal weiter mit 3.0.0.

Laut Dokumentation ist es am einfachsten, wenn man die Direktive remember-me (Security Namespace) innerhalb der http-Direktive (Security Namespace) verwendet. Ohne irgendeine Angabe wird ein stinknormales, Cookie basiertes Tokenverfahren ohne (echten) privaten Schlüssel verwendet. Reicht für den ersten Einsatz erstmal auf, soll ja erstmal funktionieren.

Fehlermöglichkeit 1a: Man loggt sich ein, und es passiert nichts (kein “RememberMe”-Cookie).
Lösung: Wenn man einen eigenen Auth-Filter einsetzt, muss man diesem auch den RememberMe-Service “setten”. Außerdem muss der SecurityChainFilter (web.xml!) auch auf die login-Seite verweisen. Es dürfen auch keine Filter bei der Konfigurierung von intercepted Urls (speziell hier: login, logout) gemacht werden.

Fehlermöglichkeit 1b: Es passiert noch immer nichts?
Lösung: Vielleicht wurde vergessen, einen Parameternamen für den Request zu setzen. Der Standardname ist ein typischer Springname, der natürlich unschön ist. Und den kann man nicht über die RememberMe-Direktive setzen, also muss man eh einen eigenen Service definieren. Bäm. Referenzierung geht dann zwar noch, aber für mehr ist die RememberMe-Direktive dann nicht mehr zu gebrauchen.

Fehlermöglichkeit 2a: Man besucht die Seite ohne Login, aber mit Cookie – und die Loginseite kommt (Log sagt kein gültiger Auth).
Lösung: Man kann der Log trauen, wenn sie zwar beim Einloggen nun einen Token ablegt (kann man zum Beispiel sehr einfach mit diesem Firefox-Addon inkl. Editor(!) verifizieren), dieses aber beim erneuten Besuchen der Seite (bzw. ohne JSPSESSION-Cookie) nicht verwendet bzw. wird nicht erkannt. Schlussendlich half u.a. das Umbenennen der Userservices-Bean in “userService”. Außerdem sollte die Loginseite keinen Filter/Access haben (s.o.) Lieber 2x prüfen!

Fehlermöglichkeit 2b: Es erscheint eine Ausnahme, dass der Key falsch sei.
Lösung: Dazu muss man wissen: Sobald  man eine individualisierte RememberMe-Konfiguration nutzt, wird auch der Key nicht mehr vernünftig auf alle Komponenten (Provider, Filter, Manager) gesetzt. Beim Anlegen wird also der eigene Key verwendet, beim Auslesen der Standardkey. Yes! (s.o.)

Fehlermöglichkeit 3: Man besucht die Seite ohne Login, aber mit Cookie – aber wie in 2 nur die Loginseite.
Lösung: Im Logger/Debugger kann man nun feststellen, dass zwar das Cookie gefunden wurde, das Token gefunden und validiert wurde aber dann keine Rechte existieren – aha? Wahrscheinlich fehlt im Provider noch ein zusätzliches Setting der Komponenten. Am besten von RememberMe Service/Filter/Provider jeweils alle möglichen Properties durchgehen. Jaja, wie gesagt.. ;)

Fehlermöglichkeit 4: Das Ausloggen (beispielsweise logout.html) hat nach Aktivierung von Rememberme plötzlich keine Auswirkungen mehr.
Lösung: Zwar wird die Seite gefunden, aber es wird kein “Logout” gemacht. Auch hier sollte man prüfen, ob ein SecurityChainFilter (web.xml) auch für die logout-Seite greift.

Fehlermöglichkeit 5: Das Besuchen der Seite wirft einen Fehler (ggf. “mit weißer Seite”), dass keine neue Session erstellt werden kann.
Lösung: Richtig, nach einem Request ist ja dann auch zu spät. Das Attribut create-session in der Direktive http sollte daher auf “ifRequeried” gestellt sein.

Fazit:

  • SecurityChainFilter immer prüfen
  • Intercepted Urls prüfen
  • RememberMe-Direktive innerhalb der http-Direktive ist quasi abgesehen von der services-ref unbrauchbar.

Anmerkung:

Natürlich kann man sich das Problem mit den SecurityChains vom Hals schaffen, indem man stupide ein /* filtert. Das hat jedoch zur Auswirkung, das Spring Security auch jeden verdammten Request anguckt; bei zusätzlichen (statischen) Inhalten wie Javascript, Stylesheets, Bildern, Flash u.ä. ist das ein Overhead, der unnötig ist.

Tags: , , ,

Die Diplomarbeit als Video

Geht nicht? Doch! Mit Hilfe des Visualisierungstool Gource (Open Source) lassen sich von SCMs wie Git oder Subversion sehr ansprechende Visualisierungen erzeugen. Es gibt auch einen netten Link, wie man das unter Mac OSX ans Laufen bekommt (man braucht dafür MacPorts).

Diplomarbeit – Quo vadis?

Unsere betreuende Professorin der FH Köln bietet eine Weiterentwicklung/Fortführung unserer Diplomarbeit an, vor allem hinsichtlich Erweiterungen der graphischen Darstellung (andere Graphen, neue Graphen) sowie neue Arten von “Mustern”. Bei Interesse einfach bei ihr melden.

Unabhängig davon habe ich selber damit angefangen, das Projekt nach zubauen neu zubauen. Das Projekt steckt allerdings noch in den “anfänglichen Anfängen” ;) und konkurriert daher noch nicht wirklich als Fork o.ä. Voraussichtlich wird die Neuentwicklung auch zunächst nur zum Sammeln & Analysieren sein, und die Daten entsprechend exportieren können, damit es mit dem vorhandenen Programm kompatibel ist. Aber wie gesagt, noch ist da nichts zu sehen.

HTML5 & Forms

Als Ergänzung zu meinem XForms-Vortrag in der FH, hier ein paar nette Details zu den Neuerungen von HTML5/Forms. Jaja, was für eine Überaschung. Okay, nach dem Tod von XHTML2 (und demnach die Integration von XForms in XHTML) auch wieder nicht…

Ganz allgemein scheint Dive Into HTML5 aber auch empfehlenswert zu sein, wenn auch noch in Arbeit. Nett gemacht.

Tomcat Webapp Deployment/Build

Im Zuge eins kommenden Artikels/Howto über Webapp Deployment/Build suche ich noch bestehende Lösungen, gerne auch Scripts a la Ant. Auf letzterem basiert auch meine bisherige Vorgehensweise..

Update: Inkl. dem Buildprozess.

Große ZIP-Datei verschicken – eine Google-Odyssee

Ein ehemaliger Kommilitone wollte ein paar Dinge geschickt haben; gesagt, getan: 36 20 Megabyte. Seltsamerweise wollte das Mac-like Drag ‘n’ Drop des Verzeichnisses nicht. Die Fehlermeldung, das “googlemail.com” nur 34 Megabyte zulässt, veranlasste mich daher, etwas aufzuräumen. :) Aber auch die 20 Megabyte wollten nicht, diesmal ohne weitere Erklärung. Auch ein anderer GoogleMail-Account wollte nicht.

Okay, also über das Webinterface (Nervstufe 1). Im Safari wählte ich die Datei und schrieb den kleinen Satz und drückte “Senden” — und da fiel mir auf, das die Mail gar keinen Anhang hatte? Also, nochmal “Neue Mail”, Datei wählen.. und nix. Kein Anhang.

Okay, also über den Firefox (Nervstufe 2). Die letzten Schritte wiederholt, und er lud auch brav die Datei mit Fortschrittsbalken hoch, nur um mir dann bei gefühlten 99, 999999999999999% (will heißen: die letzten 5 % haben mindestens 10x so lange wie die vorherigen 95% gebraucht) mitzuteilen, dass das Archiv wegen einer ausführbaren Datei nicht akzeptiert wird. Was? Hä? :)

Okay, prüfen wir die verf… Dateien (Nervstufe 3). Nun habe ich jede Datei geprüft, aber leider außer gefährlichen PDFs, sensiblen PNGs und potenziell terroristischen JPGs nur eine wirklich – naja, *hüstel* – nennenswerte Datei in irgendeinem Unterordner finden können: dateiname.chm. Warum auch immer. Umbenannt, wieder das Spielchen von vorne, keine Veränderung, Archiv immer noch illegal. (Nervfaktor 4).

Schlussendlich habe ich danach das Archiv.zip in Archiv.zip.itsonlyafuckingzipfile umbenannt und hochgeladen (via Mail).. und alles war wunderbar.

Google

Google hat also nebst so Allerweltssachen wie Mails, Cloud, Docs und Search also auch

  • ein paar Javascript Tools
  • verlinken als CDN die bekanntesten JS-Frameworks, gleichzeitig Anbieter von entsprechenden APIs für Maps, Analytics & Co.
  • Google Wave, “was vollkommen neues”, was irgendwie noch keiner (nicht viele) richtig einzurordnen / anzuwenden kann
  • ein eigenes Dateisystem (hm, man sieht noch nicht viel davon)
  • ein eigenes Betriebssystem (soll ja kommen, man hört nichts mehr)
  • ein eigenen Browser mitsamt Javascriptengine
  • just eine Internet-Protokollerweiterung/ersetzung namens SPDY von/für HTTP – mitsamt Spezifikationen, also nichts halbgares
  • “nur ein paar” technische Paper, etwa zu Map/Reduce oder BigTable
  • nebst den nicht zählbaren Rechenzentren (geschweige Containern, ganz zu schweigen Rechnern) auch noch eigene Datenleitungen…

Und die Leute haben da noch Angst vor der Datenkrake – da bahnt sich doch ein ganz anderes – liebes? – Monster an.

Und Hinweise, Links? Google! Ha!

Ersatz für Thawte (personal e-mail certificates)

Kleine Randnotiz und Hinweis für diejenigen, die auch eine Alternative für Thawte suchen – zur Erinnerung: Die kostenlosen E-Mail-Zertifikate bzw. der Dienst dafür läuft in wenigen Tagen ab.

Eine Alternative ist TrustCenter mit seinem Angebot TC Internet ID. Auch dies ist ein E-Mail-Adressen basiertes und kostenloses Zertifikat – und dieses PKI-Zertifikat ist auch beim “Rest” installiert und bekannt.