Flex Automation - testy funkcjonalne i integracyjne

Trafiła mi się bardzo interesująca prezentacja Jima Chenga o tym dlaczego warto zainteresować się Flex Automation API, która obecnie znajduje się w Adobe LiveCycle Data Services ES. Jest na stronach internetowych Adobe przykład wykorzystania tej technologii, a także wprowadzenie to tego.
Otóż celem jest zbieranie informacji o interakcji aplikacji Flex i mierzenie zdarzeń jakie występują w tej aplikacji. Z tej prezentacji można było wywnioskować o tym ze warto tym zainteresować się ze względu innowacyjność podejścia. To co jest potrzebne po stronie serwera to aplikacja do zbierania tych informacji. Dowiedziałem się z tej prezentacji ze są to HP QTP, RIATest, FunFX, Rational Functional Tester czy Selenium-Flex API
Ostatnio zainteresował mnie projekt FlexMonkey, który jest połączeniem taki projektów jak FlexUnit, FlexSpy, czy wykorzystanie Flex Automation API. Polecam zobaczyć demo Robi wrażenie na mnie jako analityku internetowym i programiście Flex/AIR.

Google Analytics Tracking For Adobe Flash

Od pewnego czasu więcej czasu spędzam nad analityką internetową. W tej sytuacji bardzo ucieszyło mnie to, że Google dało możliwość mierzenia tego jak użytkownicy wykorzystują aplikacje RIA tworzone w Flash Platform za pomocą Google Analytics. Do tej pory oficjalna dokumentacja do Google Analytics wspominało o tym że można wykorzystać kod w Action Script do zbierania informacji. Natomiast trudno było znaleźć informacji o tym jak zbierać informacje do Google Analytics. z aplikacji tworzonych w technologii Adobe Flex. Od pewnego czasu istnieje kod ActionScript 3 Data Collection API for Google Analytics. Kod tej biblioteki pozwala na zbieranie informacji na zasadzie przekazywania danych do skryptu odpowiedniego skryptu JS Google Analytics, który wywołuje funkcje z pliku ga.js. Jest on dostępny dla programistów Flash CS3, a także jako komponent SWC dla programistów Adobe Flex. Twórca tej biblioteki stworzył jedną z najciekawszych aplikacji AIR Analytics Reporting Suite. Na konferencji Adobe MAX w San Francisco 17 listopada firma Sprout przedstawiła możliwości jakie daje wykorzystanie Google Analytics do mierzenia interakcji użytkowników. O tym też napisało Google na swoim blogu Google Analytics. Oczywiście że można pobrać kod źródłowy i jak skompilowane biblioteki ze strony Google Analytics Tracking For Adobe Flash. Warto tez zapoznać sie z artykułem wprowadzającym do używania tej biblioteki.

Google Chrome - demon szybkosci

Google Chrome jest przykładem jak bardzo intensywnie pracuje się nad nowymi silnikami JavaScript. Google na bazie tego co zaimplementowano ostatnio w silnikach skryptowych SqurrielFish i TraceMonkey (ten ostatni już tłumaczy kod JS na polecenia procesora i jest szybszy od poprzednika) stworzył nowy silnik V8 Możecie sobie przetestować wydajność w tym teście Warto też przetestować to na Dromadeo, czy SunSpider (moje wyniki). Warto zobaczyć porównanie pomiędzy SqurrielFish a TraceMonkey. Albo dema pod roboczą wersja Firefoxa 3.1 bądź kolejne nightbuildy WebKit, które jeszcze nie chodzą w Google Chrome. Podobnie nie wszystko w Processing.js działa dla Chrome. Ciekawe, która wersja WebKit jest w Google Chrome? I mamy
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13
Google Chrome pozytywnie przeszedł Acid2, a Acid3 zakończył na poziomie 78/100
A programiści Safari dalej pracują i usprawniają Safari 4 kompilacja 40A12 i silnik WebKit:
Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL) AppleWebKit/528.1 (KHTML, like Gecko) Version/4.0 Safari/528.1.1
Widać ile do nadrobienia mają programiści Google Chrome,żeby to wszystko chodziło? Ale wobec programistów od Apple mają przewagę, że Google Chrome współpracuje z Google Gears (i już jest zintegrowany wystarczy zobaczyć C:\Documents and Settings\Michal\Ustawienia lokalne\Dane aplikacji\Google\Chrome\Application\Plugins) Apple natomiast celuje w dodanie profilera JavaScriptu. Zastanawiałem się gdzie Google Chrome sie instaluje się? Okazało się że tam gdzie jest to najbezpieczniej czyli w:
C:\Documents and Settings\Michal\Ustawienia lokalne\Dane aplikacji\Google\Chrome\
daje to w pewnym sensie możliwości uruchamiania Google Chrome na USB i łatwego przenoszenia danych z ustawień pomiędzy komputerami.
Warto też skorzystać z takich wpisów w pasku adresowym takich jak about:network about:histograms, about:cache, about:plugins, about:dns, about:version, about:stats, about:memory, about:crash, chrome-resource://inspector/inspector.html,
view-source:chrome-resource://about/stats
about:internets

Ale najciekawsze pozostaje to że mam bibliotekę Rlz.dll (oraz kod żródlowy)
Częsciowo mnie zastanawia dlaczego w adresie URL wyników zwracanych z wyszukiwarki Google mam coś takiego
http://www.google.pl/search?rlz=1C1GGLS_plPL291&aq=f&sourceid=chrome&ie=UTF-8&q=Flex%202
może ktoś mi wyjaśni co to za rlz z parametrem 1C1GGLS_plPL291

A Adobe i tak pracuje nad rozwojem Adobe AIR 2.0, doda tam Flash Playera 10 i prawdopodobnie którąś z aktualnych wersji WebKit (zakładam że tą samą co obecnie Google Chrome), może przejdą na wersję zaproponowaną przez Google Chrome? Pożyjemy zobaczymy.

Spodziewam się silnej rywalizacji pomiędzy programistami ActionScript 3 / Flex a programistami JavaScriptu o to co ma decydować o trendach UI w internecie. Czego mi brak? Wsparcia OpenGL ES w przeglądarkach? Biblioteki ActionScript nie rozwiążą problemu wydajności gier 3D w przeglądarce, skoro teraz prawie każdy nowy komputer może obsługiwać PixelShader 2.0 i VertexShader 3.0. Wystarczy zrobić wtyczkę typu Canvas 3D ? Ale może jednak poczekać z tym? Może jednak przyjrzeć się bliżej silnikom 3D w ActionScript? Tak szczerze uważam ze sprzęt dorósł do programowania 3D w internecie, technologie też... ale użytkownicy jeszcze nie.

A tak na marginesie Google nazwą "Chrome" w pewnym sensie wymierzyło policzek Microsoftowi - przywłaszczając nazwę której Microsoft nadał silnikowi 3D do przeglądarek 10 lat temu czyli Chromeffects

Kontakt

Aplikacje RIA offline

Czasami padają pytania o uruchamianie aplikacji RIA w trybie offline. Można zrozumieć to jako uruchamianie aplikacji RIA na krążkach CD/DVD czy kluczach USB.

Jest kilka podejść:

• Aplikacja Flash / Flex to nic innego jak plik SWF. Ale polityka bezpieczeństwa Flash Playera nie pozwala bez zgody użytkownika na działanie lokalnie czyli w sytuacji gdy użytkownik otworzy z CD/DVD stronę WWW z plikiem SWF to Flash Player potraktuje to jako działanie zagrażające użytkownikowi i nie pozwoli na ładowanie zawartości (tekstów czy grafiki) z krążka CD/DVD. W tej sytuacji użytkownik musi wejść do ustawień Flash Playera i ustawić to że dany plik SWF ma uprawnienia do pobierania zawartości lokalnej. Jedynym rozwiązaniem z wyjścia z danej sytuacji jest "upakowanie" całej zawartości do pliku SWF i zrobienie z tego projektora. Ale w większości sytuacji kontent jest trzymany w plikach zewnętrznych w tej sytuacji przeniesienie aplikacji RIA na CD/DVD wymaga innego podejścia
  
• Ponieważ FlashPlayer jest "pobłażliwy" jak jest uruchomiony z serwera HTTP, to w tej sytuacji pozostaje zrobienie na nośniku serwera Apache i uruchamianie go w celu otwarcia aplikacji RIA. Takie działanie ma sens jak chcemy uruchamiać lokalnie całą aplikację RIA emulując działanie internetu. Można zainteresować się takimi pakietami jak Lighty2Go czy Server2Go, bądź PortablePython. To rozwiązanie ma słabość, z powodu obsługi bazy danych, która jest problematyczna (bo działania na bazie danych zapisują się w pamięci, a nie na CD czy na dysku użytkownika).
• Inna koncepcja to uruchamianie debugera adl.exe z AIR SDK (osobiście raczej nie polecałbym takiego rozwiazania w aplikacjach RIA uruchamianych z CD/DVD), a lepiej już przegotować plik .air jako instalację i poprosić użytkowników, aby zainstalowali aplikację AIR u siebie lokalnie.
• Inny pomysł to opakowanie kontrolki ActiveX FlashPlayera w program komputerowy. Inne rozwiązanie to osadzenie silnika Flash Playera w program komputerowy, tak jak to widać w Google Lively (za pomocą biblioteki F-IN-BOX). Czasami zastanawiam się, czy podobnie można opakować kontrolkę ActiveX Viewpoint Media Player w celu uruchaminiania aplikacji RIA ( jako pliku SWF Flex). Obecnie jednak preferowałbym tworzenie aplikacji RIA we Adobe Flex i uruchamianych z poziomu aplikacji w Adobe Director na nośnikach.

Google Lively

Bez większego entuzjazmu zainstalowałem sobie Google Lively. Bo obawiałem się że mi to nie pójdzie. Po drugie dość już naoglądałem się czatów 3D. W tej sytuacji postanowiłem śledzić jak mi to wszystko pójdzie. Plik instalacyjny wylądował mi w C:\Program Files\Google\Update\Download\{635EAF17-43BA-4D5A-A1C9-87C580F6AA02}
a instalacja przebiegała tak cicho, że dopiero potem zreflektowałem się że mam już to zainstalowane w
C:\Program Files\Google\Lively Zajrzałem do tego folderu
Był tam katalog flex z plikami *.swf odpowiedzialnymi za interfejs użytkownika. Folder datafiles zawierał tajemnicze pliki *.nif (są to pliki z silnika Gamebryo).
Zauważyłem, że Google Lively wymaga obsługi DirectX na co wskazywała obecność pliku d3dx9_27.dll Za GUI we Lively odpowiadała biblioteka f_in_box.dll firmy Softanic. Ta biblioteka ma własną stronę. W tej sytuacji zajrzałem do API tej biblioteki. Zrozumiałem że komunikacja ze stroną WWW może odbywać się tak kod JS -> API Plugina -> API F-in-Box.
Najciekawsze jest to, że do Lively dodano silnik pozwalający na obsługę gadgetów Google GadgetEngineRedist.dll

Gdy wybrałem pierwszy lepszy pokój, pomyślałem że sprawdzę logi i pojawiło się coś takiego
User-Agent: Fiji Client (gzip)
A natomiast serwery Google przedstawiały sie jako "GFE/1.3" lub po zalogowaniu "3dweb storage server". I zauważyłem, że większość operacji na Lively dokonuje sie z poziomu REST (a pliki SWF ładowane są ukrywane przed użytkownikiem, to taka cecha biblioteki f-in-box.dll)

Po zalogowaniu zauważyłem, że sporo danych leci ode mnie nawet podanie hasła na loginie nie jest bezpieczne, bo nie jest wysyłane przez HTTPS. Ilość danych jakie leciała do mnie przekroczyła ponad 2000 żądań i przesłała mi same skompresowane pliki, aż zablokowało mi przeglądarkę.

Wszedłem do swojego pustego pokoju. Zobaczyłem w logach: http://clients3.google.com/lively/s/gp?id=-8618462218026787199&obj_ed=0 i zrozumiałem że pobrałem plik binarny mojego pustego pokoju. Jeden z kolejnych logów był taki:
http://clients3.google.com/lively/s/gpmd?id=-9193953186449112932&obj_ed=0 co prawdopodobnie były pliki binarne przedmiotów w pokoju.
Ale to co mnie zaskoczyło to fakt że gdzieś informacja o moim awatarze jest zapisana lokalnie o czym świadczył mały plik http://clients3.google.com/lively/s/ga. Następnie zacząłem przeglądać swoje ustawienia. A rzeczy do ustawień ładują się spod takiego adresu:
http://clients3.google.com/lively/s/gpss?id=9214425981265137557&obj_ed=0.

Na koniec kliknąłem prawym przyciskiem na awatara i wybrałem sobie animację, którą ma awatar zrobić, Warto protestować sobie animacje takie jak rofl czy tada. Jak wyczułem w tym produkcie to że "duchem" bardziej przemawia to na rynek azjatycki. Nie ma co się dziwić jak za tym projektem stoi uzdolniona programistka Niniane Wang Byłem już pod wrażeniem tej Chinki, że nie miałem ochoty już sprawdzać co jest w tych plikach SWF.

Indeksowanie SWF w wyszukiwarkach

Interesujący temat ostatnio, czyli sezon ogórkowy. Adobe ogłosiło że razem z Google i Yahoo pozwoli na indeksowanie zawartości tekstowej plików SWF9 (wcześniejsze formaty były indeksowane). Myślę, że tworzenie plików SWF podlegających indeksowaniu to temat rzadko poruszany. Mam własne przemyślenia na ten temat:

• Od umieszczania zawartości tekstowej były metatagi w formacie SWF, a takze zawartość testowa osadzana w polu tekstowym. Jest to jedyny sposób na trafienie w wynikach Google
• Obecne zawartość tekstowa w plikach SWF to śmieci. - wystarczy dopisać filetype:swf
  

Jak sprawić żeby zawartość plików SWF nie była "koszmarem"? Należy zrobić pliki SWF z pełna zawartością tekstową bez formatowania. A formatowanie zawartości pozostawić skryptom Action Script i plikom CSS. W ten sposób unikniemy indeksowania takiej zawartości typu: font face="Tahoma" size="12" color="#ffffff" letterSpacing="-0.100000" kerning="0"

W przypadku gdy mamy na stronie zawartość pliku SWF tworzonego przy pomocy Flex/Haxe to trzeba dodać bardzo dokładnie opisujące. A nawet jest to jest opisane w dokumentacji

Kolejna sprawa to pewien paradoks tkwiący w tym że, Adobe powinno było stworzyć rozwiązanie dzięki któremu wyszukiwarki "odsiewały" plewy od ziarna. Ta technologia już była: nazywa się FlashPaper. Nawet można już ładnie wyszukać pliki z dokumentami FlashPaper

Pozostaje teraz dość interesująca sytuacja dzięki temu że powstają konwertery online na format SWF w takich usługach jak Media Convert, ale to nie ułatwia sprawy, jeżeli chodzi o indeksowanie plików SWF , bo aplikacje RIA coraz bardziej przypominają aplikacje Ajax. A te wymagają stworzenia właściwej interakcji pomiędzy treścią na stronie WWW, a nawigacją w aplikacji AJAX/RIA.

Idealna sytuacja to taka w której serwis został tak zaprojektowany że na każdy "widok" aplikacji odpowiada odpowiedni dokument FlashPaper, który zresztą może zostać załadowany "wewnątrz" aplikacji RIA. W ten sposób załatwiamy prawie wszystkie bolączki aplikacji RIA:

• Google ładnie indeksuje pliki SWF z FlashPapera
• Użytkownik otrzymuje dokument SWF przystosowany do druku
• Prawie wszędzie można odczytać dokumenty FlashPapera (nawet w FlashLite)
• Pliki z FlashPaper są przyjazne screenreaderom
• po "shackowaniu" API FlashPaper jest możliwa komunikacja z innymi aplikacjami RIA/Ajax