• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Ria Zh
 

Ria Zh

on

  • 1,904 views

 

Statistics

Views

Total Views
1,904
Views on SlideShare
1,857
Embed Views
47

Actions

Likes
0
Downloads
8
Comments
0

7 Embeds 47

http://michaelmarth.blogspot.com 34
http://www.linkedin.com 7
http://michaelmarth.blogspot.in 2
http://www.blogger.com 1
http://feeds.feedburner.com 1
http://michaelmarth.blogspot.ch 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Ria Zh Ria Zh Presentation Transcript

  • Flex on Rails: the Good, the Bad and the Ugly Michael Marth, viibee.com
  • Der Vortragende
    • Hintergrund in Java, Content Management, Mobile
    • Interessen : Rich UI (Flex, WPF) und Agile Development (Rails, Sling)
    • Co-founder von viibee.com
    • Evangelist bei Day Software
  • Das Projekt: viibee.com
    • Video-basierte Dating Plattform
    • Fokus auf Spass und visueller Interaktion
  • Flex: was und warum Flash f ür Entwickler Deployment, deployment, deployment! L ä uft im Flash Player (compiled zu swf Datei) Hat die “richtigen” Entwicklungsparadigmen UI in XML Programmierung in Actionscript Ähnlich wie WPF, XUL, … Warum nicht JS? Der Flash Player kann ein paar Tricks
  • Rails: was und warum?
    • Ruby-basiertes Framework f ü r Datenbank-gest ü tzte Web Sites
    • MVC Architektur, Convention-over-Configuration
    • Extrem effizient, fokusiert auf Entwicklerproduktivit ä t
    • Sehr agil (wenn man schnell mal nen Server braucht…)
    • viibee ist eigenfinanziert
  • Meine Erfahrungen mit der Integration dieser beiden best-of-breed Technologien? Vorkenntnisse über Flex und/oder Rails erw ünscht
  • The Good
  • Client-Server Kommunikation
    • Flex/Rails ist eher Client-Server als Web
    • Good news: der Rails Server muss nur Daten liefern, nicht das komplette UI
    • Man ben ö tigt einen Mechanismus zum Datenaustausch
    Flex Client Rails Server
  • Client-Server Kommunikation
    • Gute Sache: RESTful’er Ansatz
    • Der Klassiker: xml über http
    • JSON w äre möglich, aber funktionierte bei Projektbeginn nicht wie erwartet
    • N ächstbeste Alternative: AMF
    Flex Client Rails Server xml over http
  • XML/HTTP vs. AMF
    • XML/HTTP
    • Etabliert
    • Cachebar auf Client- und Serverseite (Vorsicht: Browserabh ängigkeiten )
    • Einfach zu debuggen
    • Implizite API
    • Wg Performance: alle Requests sind asynch (nicht wie eine typische Web App)
    • Aber: Um die Modell-Serialisierung und Deserialisierung muss man sich selbst k ümmern
    • AMF
    • Bin är, schneller
    • Weniger Code durch geteiltes Modell
    • Schwieriger zu debuggen/verstehen
    • Ben ötigt Web Orb Komponente
    Eventuell ben ötigt man AMF trotzdem: f ü r Video Aufnahme und Wiedergabe
  • Werkzeuge
    • Eclipse: FlexBuilder und RadRails
    • Dieselben Konzepte: oop, Unit Tests , MVC, ant und svn (und daher auch Trac)
    • Silobildung weniger wahrscheinlich
  • The Bad
  • Rails Entwicklung ist sehr “DRY”
  • Es wird nass
  • Nass? Warum?
    • Client und Server teilen sich das Modell
    • Modell änderungen in der db werden von Rails automatisch propagiert, aber im Client muss man…
      • Den XML Parser anpassen
      • Das Client-seitige Modell anpassen
      • Die Client-seitigen Value Objects anpassen
      • Wahrscheinlich den Delegate anpassen
    • Plus: db und Client m üssen in sync sein
    • Daher ben ö tigt die Kommunikation ein Versionssystem
    Wanna buy a Wet Suit?
  • Nass? Warum?
    • Man ben ö tigt etwas wie Cairngorm – ein Client-seitiges MVC Framework
    • F ür Rails Entwickler schockierend (oh Gott, J2EE ist zur ü ck)
  • Ein Beispiel: das Hinzuf ügen einer Methode im Rails Controller bedeutet in Cairngorm…
    • Erstelle ein neues Command
    • Erstelle einen neuen Cairngorm Event
    • F üge Event und Command zum Cairngorm Controller hinzu
    • Erstelle eventuell ein neues Value Object
    • Erstelle einen neuen Responder
    • F üge eventuell eine neue Methode zum Parsen der Response hinzu
    • F üge eine Methode zum Delegate hinzu
    • F üge einen Eintrag in services.xml hinzu
    MVC ist gut Nicht-DRY-ness ist das Thema Wenn man kein MVC Framework verwendet, wird man es wahrscheinlich im Projekt neu erfinden
  • Und noch ein paar kleinere Punkte
    • Langsamere Entwicklungszyklen (wegen Kompilierens)
    • i18n Konfiguration ist über verschiedene Systeme verteilt
    • Langsameres Deployment (wegen Uploads)
  • The Ugly
  • Model State auf dem Client X=0 X=0 X=1 X=1 User Interaktion Wann? Vor UI Update? Nach UI Update? Was ist mit Constraints?
  • Model State auf dem Client 2 1
    • Beispiel Use Cases:
    • Chat
    • Inbox Update
    Wenn man bei http bleiben will: Comet, Polling oder mit inkonsistenten Daten leben
  • Schlussfolgerung
    • Mehr “good” als “bad”
    • Rails ist eine gute Wahl als Backend f ür Flex Apps
    • XML/HTTP funktioniert gut genug f ür uns
    • State sollte auf die UI Logik beschr änkt werden, wenn dies m öglich ist (nicht das Modell verteilen)
  • Bonus track: Flex, Rails und Social Networks
  • viibee l äuft in den Social Networks… Reality Check: RIAs in Social Networks deployen
  • Die Herausforderung: APIs
    • In der Theorie:
      • Facebook API
      • OpenSocial
      • Und einige propriet äre APIs
    • In der Praxis:
      • Anpassungen pro Network n ötig
  • Facebook
    • Gute Unterst ützung für swf Dateien
    • Grosse Entwickler Community und gute Dokumentation
    • Interaktion mit Facebook Server-seitig
      • Rails Plugin rfacebook
  • Orkut
    • OpenSocial API ist JS-basiert
      • Ben ötige FlexJS Bridge
      • Ben ötige embedCachedFlash
    • Vern ünftige Entwickler Unterstützung
    • SN-seitiges Caching erschwert das Testen der Application
    (bug)
  • MySpace
    • Gute Entwickler Unterstützung
    • Man muss das MySpace CDN verwenden, Caching Strategie und Expiry sind unklar
    • Man muss propriet ä re Flash Lib verwenden, OpenSocial js api wurde “erweitert”
  • Friendster
    • Keine gute Entwickler Unterstützung
    • API ist REST basiert, Integration also Server-seitig, keine Ruby library verf ügbar
    • OpenSocial ist versprochen
    • Benutzt iframe, also problemloses Includen einer swf Datei
    • Funktioniert zumeist “as advertised”
  • Weitere Herausforderungen bei der RIA Entwicklung in SNs: Testing
    • Man muss Test User erstellen (was verboten ist)
    • Caching Probleme (SN-seitig)
    • Man muss uploaden (zeitaufw ändig )
    • Viele APIs sind instabil, was das Debuggen erschwert
  • Weitere Herausforderungen bei der RIA Entwicklung in SNs : Viralit ät
    • Wenig Sinn, in ein SN zu deployen, wenn die App nicht viral ist
    • Viralit ät kann momentan nur SN-spezifisch erreicht werden
    • Emails, Notifications, Feed Eintr ä ge sind alle sehr SN-spezifisch
  • Multi-Plattform Deployments sind Dickmacher
    • Die Code Base der Clients muss getrennt bleiben
    • Der Flex Compiler inkludiert alle referenzierten Klassen, was die Applikation vergr össert
    • Man braucht gute Entwickler Disziplin
    • Frameworks wie Cairngorm helfen hier
  • Gute Aspekte von RIAs bei Multi-Plattform Deployments
    • UI in Flex wirkt wie eine Abstraktionsschicht
    • swf ben ötigt eine Network Session
    • Danach ist die Applikation vom SN gr össtenteils abgeschirmt
  • Vielen Dank f ür Ihre Aufmerksamkeit. Fragen?