W kontekście powyższego updatea warto wspomnieć o konsolidacji nazw, jakiej ulega ostatnio Flash Platform. Nie wiem jak dla Was, ale dla mnie sam Flash, jako narzędzie z pakietu Creative Suite zatacza krąg (był taki moment, że dynamicznie puchło pod względem „developerskim”, teraz ten temat wydaje się być odpuszczony … i dobrze, bo to środowisko developerskie „zabawka”, wprawiające bardziej frustracje, niż w zachwyt, szczególnie w kontekście innych narzędzi służących temu celowi). Widać, że Adobe nieuchronnie wraca do tego, aby Flash jako składnik pakietu CS służył przede wszystkim do kreacji opartej na rozwiązaniach bazujących na listwie czasu i prostych skryptach. Stosunkowa prostota „programowania” w AS2 pozwalająca przypinać kod gdzie popadnie dla „technicznych designerów” była prostsza w użyciu i bardziej przyswajalna (choć dalece „niebezpieczna”), niż bardziej skomplikowana i restrykcyjna składnia AS3. Doświadczam codziennie jak przykładowo animatorzy mają problem z oskryptowaniem animacji w AS3, bo chcą używać AS3, tak samo jak używali AS2, a tu nie da rady. Nie da się przykładowo zrobić tak prosto gotoAndStop do klatki i zaraz po nim w następnej linii kodu sięgnąć do obiektu z tej klatki, bo nie jest on jeszcze zainicjowany, i trzeba kombinować z listenerami (Event.ADDED itd…), a to już inny poziom i para kaloszy, bo cały AS3 powinien wykluczać operowanie na listwie czasu w kontekście programowania … i bardzo dobrze (z punktu widzenia „pewności kodu” i stabilności opracowywanych rozwiązań jest to jak najbardziej słuszne). W związku z powyższym zmiana konwencji nazw wokół Flash Platform akcentująca Flasha, jako środowisko uruchomieniowe w kontekście ostrego podziału na narzędzia wytwórcze dla developera, designera i pośredniczące ma sens, nie tylko z punktu widzenia marketingowego (patrz środowiska wytwórcze na poniższym rysunku).

Wiadomo już, że Flex Builder w następnej odsłonie („Gumbo”) będzie nazywał się Flash Builder. „Thermo” jako narzędzie „pośredniczące” będzie Flash Catalystem. A co z kolejną odsłoną Flash CS4? Logika i obecne zorientowanie tego narzędzia nakazują, aby nazwać je np. Flash Designerem. W ten sposób pod względem spójności nazewnictwa i działań marketingowych „kolumna” narzędzi wytwórczych Flash Platform by grała … jak z tymi nazwami będzie … zobaczymy.

Z pewnością dla samego Flexa jako opensourceowego frameworka zmiana nazw ma znaczenie poboczne. Flex zaczął dźwigać brzemię technologii bezpłatnej, stąd w tym kontekście Flex Builder jako narzędzie płatne, ze swoją nazwą również nie bardzo pasował …

Interpretację oficjalnych opisów LiveCycle ES (w skrócie LC) pozostawmy specjalistom od marketingu i przejdźmy do konkretów. Najprościej rzecz ujmując LC to zestaw usług zbudowanych na platformie Java Enterprise Edition i towarzyszących im narzędzi, których wspólną cechą jest to, że mają coś wspólnego ze standardem PDF. Definicja jest bardzo ogólna ale wynika to z mnogości zastosowań LiveCycle w związku z czym został on podzielony na 14 różnych komponentów, z których każdy jest osobnym produktem i udostępnia różne zestawy usług. Co ważne, każda z usług jest dostępna przez jeden z trzech interfejsów programistycznych:

• Java API – jak łatwo się domyślić, do wykorzystania w aplikacjach na platformie Java
• WebService – do wszystkich innych platform jak .NET czy PHP
• LiveCycle Remoting – specjalny interfejs dla aplikacji Flex

Dla szybkiego zrozumienia zastosowań LiveCycle przyjrzyjmy się kilku przykładowym sytuacjom:

1. Firma A chce udostępnić na swojej stronie elektroniczny formularz, który użytkownik będzie mógł wypełnić na komputerze i przesłać drogą elektroniczną lub wydrukować i dostarczyć wersję papierową.

2. Firma B przygotowuje się do organizacji przetargu i chce śledzić zmiany w specyfikacji zamówienia, a później udostępnić dokumenty oferentom tak, by nie mogli ich odczytać po zakończeniu przetargu.

3. Firma C chce regularnie wysyłać do swoich klientów elektroniczne faktury opatrzone podpisem cyfrowym.

4. Firma D potrzebuje rozwiązania, które usprawni proces składania i rozpatrywania wniosków o urlop lub wewnętrzny zakup sprzętu.

W każdej z tych sytuacji pomocne mogą się okazać poszczególne komponenty LiveCycle:

1. Firmie A desktopowe narzędzie pod nazwą LiveCycle Designer ES umożliwia projektowanie rozbudowanych formularzy elektronicznych przy pomocy bogatej biblioteki komponentów takich jak pola tekstowe, przyciski, listy rozwijane itd. Do budowy bardziej zaawansowanych formularzy dostępne są języki Form Calci JavaScript. Formularze można zapisać w gotowym do dystrybucji formacie PDF (statycznym lub dynamicznym) lub w opartym na XML formacie XDP, które za pomocą komponentu serwerowego LiveCycle Forms ES łatwo mogą być renderowane w innych formatach takich jak PDF, HTML i SWF. Oprócz tego LC Forms umożliwia zbieranie danych wysłanych z formularza, walidacjętychdanychiwieleinnychfunkcjonalności.Ponadtoformularzetworzone w Designerze mogą zawierać dwuwymiarowe kody polowe, których zadaniem jest przechowywanie wybranych danych z formularza tak, by po wydrukowaniu go możliwe było bezbłędne odczytanie ich z powrotem do postaci elektronicznej. Po stronie serwera dba o to komponent LiveCycle Barcoded Forms. Z kolei LiveCycle Reader Extensions pozwoli na odblokowanie zaawansowanych funkcjonalności formularzy PDF (jak umieszczanie komentarzy, dodawanie załączników, składanie podpisów cyfrowych) dla użytkowników darmowego Adobe Readera.

2. Dla firmy B idealnym rozwiązaniem może się okazać LiveCycle Rights Management ES. Dzięki temu komponentowi będzie mogła nałożyć na dokumenty PDF (a także DOC, XLS i PPT dzięki pluginowi do Office’a) tzw. polityki bezpieczeństwa, które określają jacy użytkownicy mogą otworzyć dokument, w jakim czasie można to zrobić i jakie operacje na dokumencie są dozwolone. W celu zapewnienia poufności dokumentu jest on zabezpieczany szyfrem symetrycznym (AES 128 lub 256) dzięki czemu nawet niekontrolowana dystrybucja (np. zgubienie pendrive’a) nie powoduje wycieku danych. Do odczytu dokumentu wystarczy zwykły Adobe Reader, który po uwierzytelnieniu użytkownika ściąga klucz i jednorazowo odszyfrowuje dokument. Dodatkowo, autor dokumentu może wybrać opcję śledzenia akcji wykonywanych przez użytkowników w czasie przeglądania dokumentu. Tak zwane zdarzenia audytowe (otwarcie dokumentu, modyfikacja, drukowanie i wiele innych) są wysyłane do serwera LiveCycle Rights Management do późniejszego wglądu.

3. Firmę C prawdopodobnie zainteresuje LiveCycle Digital Signatures ES, który pozwala na automatyczne składanie podpisu cyfrowego na dużych ilościach dokumentów. W połączeniu z LiveCycle PDFGenerator ES i usługą wysyłania maili obecną w LiveCycle Foundation ES, firma łatwo zaimplementuje mechanizm automatycznego generowania, podpisywania i wysyłania faktur.

4. Natomiast firmie D LiveCycle Process Management ES pozwoli na przeniesienie “papierowych” procedur do postaci elektronicznej. Poprzez interfejs LiveCycle Workspace użytkownicy będą mogli składać, rozpatrywać, eskalować, przekazywać wszelkiego rodzaju wnioski, pisma i tym podobne formalności bez zużywania ton papieru, a także uczestniczyć w dowolnych procesach biznesowych firmy przygotowanych w opartym na Eclipse narzędziu LiveCycle Workbench ES:

Jak wspomniałem, niektóre z komponentów dostarczają standardowego interfejsu użytkownika (np. LiveCycle Workspace) jednak wszystkie usługi dostępne są z Flexa, więc nic nie powstrzymuje nas przed zbudowaniem własnego interfejsu czy wykorzystania niektórych usług we własnych aplikacjach Flexowych.

Każda usługa czy proces automatycznie udostępnia punkt docelowy (destination) do wykorzystania z Flexowym mechanizmem Remote Object. Na przykład deklaracja zdalnego obiektu dla usługi EncryptDocument wygląda następująco:

<mx:RemoteObject id="encryptDocument"
destination="EncryptDocument"
result="resultHandler(event);">
<mx:method name="invoke"
result="handleExecuteInvoke(event)"/>

</mx:RemoteObject>

Natomiast właściwe wywołanie usługi jest równie proste jak każde inne:


encryptDocument.setCredentials("administrator", "password");
varparams:Object = new Object();
params["inDoc"] = pdfDocument;
encryptDocument.invoke(params);


gdzie pdfDocument to referencja do dokumentu wcześniej uploadowanego na serwer. W obsłudze zdarzenia result z powrotem dostajemy zaszyfrowany dokument:


varres:Object = event.result;
vardocRef:DocumentReference = res["outDoc"] as DocumentReference;


Tyle tytułem wstępu. Polecam własnoręczne sprawdzenie, co można zrobić przy pomocy LiveCycle ES. Trial jest dostępny do ściągnięcia z Adobe Developer Connection (http://www.adobe.com/devnet/livecycle/trial), również w prostej do użycia wersji turnkey, która automatycznie instaluje serwer JBoss i bazę MySQL. LiveCycle Designer jest dostępny także jako osobny produkt, który można wykorzystać do budowy formularzy z inną technologią serwerową lub zupełnie offline (http://www.adobe.com/products/livecycle/designer).

Bartek Soin Specjalista w zakresie technologii Flex i LiveCycle w polskim oddziale Adobe. Wolny czas spędza aktywnym wypoczynku (kolarstwo górskie, wspinaczka, snowboard), zgłebianiu tajników fotografii i rozpoznawianiu najnowszych technologii internetowych.

Każdy proces jest uporządkowanym zbiorem faz oraz artefaktów. Fazy mogą być realizowane w sposób kaskadowy (ang. waterfall model), bądź równoległy. W jednym z poprzednich postów wspominałem o metodykach lekkich jak XP (eXtreame Programming). Bardzo dobrą metodyką lekką, która sprawdza się w kontekście adaptowalnego prowadzenia przedsięwzięć RIA, jest SCRUM, jako, że jej stosowanie wymusza m.in. spotkania zespołu pomiędzy kolejnymi fazami/iteracjami procesu, które pozwalają na kontrolowane rozbudowywanie/korygowanie zakresu projektu od strony funkcjonalnej razem z klientem. Porównując chociażby Flex’a z Flash’em, należy stwierdzić, że Flex to takie małe błogosławieństwo dla stosowania procesu adaptowalnego w kontekście wytwarzania RIA (czy nawet w kontekście stosowania programowania parami (ang. pair programming) w RIA). Flex, jako technologia oraz środowisko wytwórcze, pozwala chociażby na zrównoleglenie poszczególnych faz, na dostarczanie szybkich prototypów oraz artefaktów funkcjonalnych do klienta, nie zaburzając przy tym architektury aplikacji oraz płynności samego procesu produkcyjnego. Jego zorientowanie na warstwę prezentacji wymaga chociażby zainteresowania się tematyką UCD (ang. User-Centered Design, usabilty, itd…) oraz włączenia ideii UCD choćby w szczątkowej postaci do procesu produkcyjnego.

Jak stosowanie procesu adaptowalnego, UCD oraz SCRUM, jako „jedność” wygląda w praktyce? No, na pewno wszystkiego tutaj nie opiszę (po szczegóły ad. procesów adaptowalnych zapraszam m.in. do sięgnięcia do publikacji m.in. mojego autorstwa – link tu, i tu ), jako że temat jest dosyć obszerny. Niemniej jednak chcąc wszystko przedstawić w sposób bardzo zwięzły na potrzeby tego wpisu w skrócie wygląda to tak. Zamiast WBS stosuje się FBS (ang.  Functional (czasami mówi się Features) Breakdown Structure), który jest drzewiastą reprezentacją modułów, obszarów funkcjonalnych oraz funkcjonalności projektów wraz z wagami realizacyjnymi (priorytety) określonymi przez klienta (czasami, choć rzadko przed stworzeniem FBS’a stosuje się badania fokusowe, aby „wybadać”, czego przyszli użytkownicy (z grupy docelowej) mogą pożądać w aplikacji, od strony funkcjonalności). Na bazie FBS’a tworzone są scenariusze odpowiadające realizacji danych funkcjonalności (np. w postaci diagramów aktywności UML’a) – opisy stanów oraz tranzycji (przejść) między nimi, które następnie są upraszczane (redukowane) w kontekście możliwości Flex’a. Następnym krokiem jest szukanie możliwych kolaboracji danych stanów pochodzących ze scenariuszy odrębnych funkcjonalności, tak, aby zbudować model interakcji pomiędzy odpowiednimi obszarami funkcjonalnymi projektu. Na bazie wszystkiego co powyżej, tworzy się makiety oraz prototypy, które są poddawane testom z użytkownikami (ang. user-tests). Ważne jest to, że przed kreacją makiet jasno określa się interfejsy pomiędzy warstwą prezentacji, a logiką biznesową, tak, aby faza implementacji (logiki biznesowej) mogła zacząć się równolegle z wytwarzaniem GUI. Faza wdrożenia, to iteracyjna i równoległa realizacja połączonych faz projektowania oraz implementacji, – czyli po prostu stosowanie podejścia adaptowalnego w kontekście SCRUM, które skutkuje dostarczaniem kolejnych funkcjonalności systemu przy współpracy z klientem oraz w kolejności, które określają wcześniej zdefiniowane priorytety realizacyjne. Tak to w DUŻYM skrócie wygląda.

Jakby nie było metodologie ad. projektów adaptowalnych to jak dla mnie przyszłość w realizacji złożonych projektów RIA, dodatkowo bardzo dobrze „radzą sobie” z pracą zdalną (ang. telecommuting), dlatego jestem dosyć mocno zaangażowany w ich promocję oraz precyzowanie (Adam pracujący w SAP’ie testował je od strony wdrażania aplikacji programowych, natomiast ja od strony aplikacji multimedialnych (systemów czasu rzeczywistego) – i razem stwierdzamy, że proces adaptowalny daje radę oraz przynosi wymierne rezultaty w stosunku do podejścia konwencjonalnego). Jako, że temat jest z pogranicza zarządzania projektami i technologii Flex, nie chcę już Was więcej zanudzać ;)

Jared wyróżnia w strukturze aplikacji webowych dwa główne elementy – hub oraz wywiad (interview). Hub jest centralnym miejscem w którym znajdują się informacje na których dokonuje się działań (przykład huba to lista todo lub lista maili). Po wykonaniu operacji wraca się do huba. Wywiad jest natomiast procesem gdzie użytkownik odpowiada na kolejne pytania i przechodzi kolejne kroki procesu. Większość aplikacji łączy oba elementy. Niżej (za publikacją UIE) propozycja wizualizacji huba i wywiadu.

Na stronach firmy Jareda – UIE, kupić można dwie publikacje omawiające metody projektowania aplikacji webowych: The Designer’s Guide to Web Applications, Part II
Web Apps Tour 2007: Learning from Successful Designs, The Designer’s Guide to Web Applications, Part I
Structure and Flows. Warto wspomnieć, że UIE udostępnia za darmo po jednym rozdziale z każdej publikacji.

Aplikacjami Webowymi zajął się też Jakob Nielsen. Nazywany niekiedy „Wałęsą usability” ze względu na dość siermiężne i ortodoksyjne przekonania :). W każdym razie, gdy Nielsen o czymś pisze światek usability zawsze poddaje to dyskusji i jest to cenne samo w sobie. Jakob Nielsen w tym roku pierwszy raz opublikował swoje Top-10 Design Mistakes w odniesieniu do aplikacji (wcześniej zestawienia tego typu dotyczyły serwisów www).

Przyjrzyjmy się bliżej kilku z głównych błędów jakie zostały zdefiniowane w publikacji Nielsena.

• Niestandardowe kontrolki – użytkownicy przyzwyczaili się do tego jak zachowują się checkboxy, listy rozwijane, przyciski – każda zmiana takiej standardowej kontrolki może wprowadzić wiele niepotrzebnego stresu w używanie aplikacji. Nielsen argumentuje za używaniem wzorców projektowych – „Najlepsi projektanci interakcji zdefinowali wygląd i zachowanie kontrolek GUI w wyniki 30 lat pracy popartej tysiącami godzin testów. Mało prawdopodobne abyś przez weekend wymyślił coś lepszego.”, dalej Nielsen pisze „Użytkownicy spędzają większość swojego czasu na innych niż twoja stronach (…) Użytkownicy mają kilka tysięcy razy więcej doświadczenia w interakcji ze standardowymi kontrolkami niż z indywidualnie projektowanymi”.
  Jako szczególny przypadek niestandardowych kontrolek, Nielsen wymienia elementy designu, które wyglądają jak kontrolki ale nimi nie są – najprostszy przykład to elementy, które wyglądają na klikalne ale nie pozwalają na interakcję.
• Brak konsekwencji – konsekwencja w projektowaniu GUI zakłada używanie tych samych nazw na te same rzeczy. Funkcja, która wykonuje czynność powinna z każdego miejsca aplikacji być wywoływana w ten sam sposób. Najbardziej oczywisty przykład niekonsekwencji zauważyłem w oprogramowaniu mojego routera. Pokazuje on adresy MAC podłączonych urządzeń w formacie XX-XX-XX-XX-XX-XX ale gdy chcę dodać nowe urządzenie do listy dostępu to wymaga ode mnie formatu XX:XX:XX:XX:XX:XX. W obrębie jednej aplikacji nie mogę skopiować danych i wkleić ich.
• Brak sugestii – Nielsen używa sformułowania „Perceived affordances” na określenie akcji, które użytkownik wie, że może wykonać gdy patrzy na obiekt. Dobrym przykładem jest tutaj wyraźne oznaczenie elementów ekranu, które można złapać i przeciągnąć w inne miejsce. Aplikacje pozwalając użytkownikom na personalizację powinny jasno komunikować co można na ekranie poprzestawiać.
• Brak odpowiedzi – należy prezentowac użytkownikowi aktualny stan systemu. Przykładowo – badania, które prowadzono niezależnie zawsze pokazują, że użytkownik, który widzi stan systemu jest skłonny dłużej oczekiwać na wykonanie się czasochłonnych zadań. Interesujące, że subiektywny odbiór czasu u użytkowników, którzy widzieli stan systemu był niezgodny z obiektywnym czasem oczekiwania. Użytkownicy (mylnie) uważali, że czekali krócej na zadania o których przebiegu byli informowani.
• Brak komunikatów błędów – komunikaty błędów od zawsze były najbardziej zaniedbanym elementem projektowania. To zupełnie zrozumiałe ale warto zastanowić się jak dobrymi komunikatami o błędach możemy zjednać sobie użytkowników i nauczyć ich przy okazji jak błędów tych unikać.
• Pytanie dwa razy o to samo – użytkownicy zawsze irytują się gdy muszą powtórnie podać informacje o które już ich pytano. Gdy projektuje się pojedyńcze strony aplikacji można pominąć takie pozyskane już dane – warto zatem wyjść od projektowania procesów i dopiero na ich bazie projektować makiety. Pomocny może być tutaj choćby program Axure (www.axure.com), który łączy procesy i strony w jeden prototyp.
• Brak wartości domyślnych – wartości domyślne zawsze polepszają płynność procesów. Rozmyślnie usunąłbym tylko te wartości domyślne, których wybór dla użytkownika jest kluczowy i jeśli nastąpi pomyłkowy wybór wartości domyślnej (np. przez nieuwagę) użytkownik będzie bardzo niezadowolony. Przykładem może to być kolor ubrania (użytkownicy zazwyczaj zakładają, że kolor jest taki jak na zdjęciu gdy często można wybrać różne kolory a kolor defaulowy może być inny niż na fotce).

O pozostałych błędach projektantów przeczytacie u Nielsena: Top-10 Design Mistakes.

Na zdrowy rozsądek, narzędzie mające zautomatyzować i nadzorować powyższe kwestie powinno dysponować jakimś standardem opisu zależności pomiędzy poszczególnymi modułami, który krótko mówiąc opisywałby budowę aplikacji, a także szereg innych informacji dotyczących m.in. konfiguracji środowisk wytwórczych, generowania raportów, czy opisu zespołu projektowego wraz z referencją do zdefiniowanych wcześniej artefaktów, za które odpowiedzialni są poszczególni członkowie zespołu.

Narzędziem, które pozwala to zrobić jest Apache Maven, natomiast standardem dokumentu zawierającym definicje między innymi wymienionych wyżej aspektów jest POM – Project Object Model (który jasna sprawa bazuje na języku XML). Niestety ciężko by było w tym poście opisać poszczególne tagi niezbędne do tego, aby stworzyć POM – dlatego odsyłam do tego linku po specyfikację wraz z przykładami.

Jednak przed tym jak zaczniemy definiować POM’y musimy zainstalować plugin Maven’a do Flex SDK 2.0 (przyznam się, ze plugina z SDK 3 jeszcze nie używałem, nie wiem, czy da radę). Jakby nie było, plugin ten, nie jest może zbyt rozbudowany, niemniej jednak oferuje cztery bardzo przydatne dyrektywy (czynności) [ flex2:asdoc, flex2:compile-swc, flex2:copy-flex-applications, flex2:compile-swf], których nazwy mówią same za siebie i o których można sobie więcej poczytać tu. Przykłady użycia są tu. Jeżeli natomiast w swoich projektach używasz webserviceów WSDL’a polecam wsdl2as plugin, jest tam też plugin pod Maven’a – niezmiernie ułatwiająca życie sprawa.

Maven rządzi i jak dla mnie to teraźniejszość i przyszłość, z pewnością więc warto zapoznać się z nim w kontekście tworzenia rozbudowanych aplikacji Flex’owych.

Pomysł na TDD, pojawił się niedługo po ukłuciu i rozpowszechnieniu się terminu XP (ang. eXtreme Programing), jednej z bardziej popularnych metodyk lekkich (inaczej zwanych zwinnymi ang. agile) wytwarzania oprogramowania, które kładą nacisk na dostarczanie klientowi artefaktów programowych, zamiast papierowych tj. dokumentacji – która w XP ma formę szczątkową w porównaniu m.in. do RUP (ang. Rational Unified Process), który czerpie korzenie z USDP (ang. Unified Software Development Process)) i jest reprezentantem metodyk ciężkich. XP jako uznana metodyka zwinna, zaczeła permanentnie dążyc do skracania faz produkcyjnych i tak m.in. powstał pomysł na to, aby zautomatyzowac testowanie poprzez wprowadzenie testów jednostkowych (nazwa bierze się z testowania danej jednostki, jaka jest metoda (funkcja) lub klasa) oraz przeniesienie fazy testowania na poczatek fazy implementacji, a docelowo zmusić programistę, aby pisał przypadki testowe przed napisaniem właściwego kodu aplikacji programowej, pisać na początku, co kod ma zrobić, a nie jak coś ma być zrobione. W porównaniu do tradycyjnego procesu wytwarzania oprogramowania, w którym testy (czy to weryfikacyjne, walidacyjne, wydajnościowe, czy to ilościowe) sa przeprowadzane za zwyczaj w koncowych fazach procesu wytwarzania oprogramowania, była to koncepcja nadzwyczaj rewolucyjna (nawet jak na poczatki XXI wieku ). Z ”marketingowego” punktu widzenia, wydawalo sie od razu, ze programisci będą mieć wiekszy zapał aby pisać testy na początku fazy wdrożenia, niż w kolejnych fazach (przecież na zdrowy rozsądek każdy z nas jak podchodzi do projektu ma najwięcej zaangażowania na początku prac, najmniej na żmudnym końcu, kiedy należy poprawiac i poprawiac, i nie zawsze wiadomo, gdzie się popełniło błąd ), a kod tworzony wedle ścisłych reguł umożliwiajacych automatyzację testowania oraz przypadków testowych będzie łatwiejszy w pielęgnacji i rozbudowie.

Nie ma co się oszukiwać, TDD sprawdza się dobrze przede wszystkim w duzych projektach, dotyczy to takze Flex’a, w małych m.in. programiści nie rozumieją po co mają pisać “nadmiarowy kod” testujący coś, co po prostu “musi działać”  - jednym slowem stosowanie TDD w malych projektach bardziej prowadzi do frustracji niż jest pomocne. Ale przecież to m.in. za sprawa Flex’a – technologia Flash wchodzi pod strzechy rozwiazań korporacyjnych, gdzie takowe metodyki się sprawdzają. Kod testuje siebie, o to własnie chodzi, i dlatego też powstał FlexUnit , czy ASUnit. Obecna wersja np. FlexUnit, czyli 0.85 jeżeli chodzi o stosowanie metodyki TDD sprawdza się bardzo dobrze, tym bardziej jezlei ktos stosowal JUnita (Java) w Eclipsie, nie bedzie mial za duzo problemow z przesiadka ;)

Chcąc zabrać się za TDD we Flex, musisz wpierw zrozumiec co to jest test jednostkowy, asercja i przypadek testowy i troche zmienic swoj tradycyjny punkt wytwarzania oprogramowania ;) – sam wiem, po sobie, ze potrzebowalem troche czasu, aby przywyknąć. Polecam artykuł Neil’a - Unit testing and Test Driven Development (TDD) for Flex and ActionScript 3.0 - zrobil na prawde dobra robote przedstawiajać to zagadnienie w dosyc zwiezly sposob, czego ja bym nie potrafił ;) Warto też zapisać się na listę dyskusyjną FlexUnit - http://groups.google.com/group/as3flexunitlib.

Przepraszam, za ten przydługi wpis, ale jedno jest pewne, mówie to z własnego doswiadczenia, jeżeli macie duży projekt RIA, spróbujcie stosować TDD, a zobaczycie, że jego siła tkwi przede wszystkim w tym, że stosujac go, o wiele łatwiej jest zlokalizować “gdzie jest problem w kodzie”.

P.S. Miałem poruszyc w tym poscie BDD (ang. Behaviour Driven Development), czyli wytwarzanie oprogramowania zorientowane na behavioryzm, które jest niejako ewolucją TDD, i osobiście uważam, że jest przyszłością. W trakcie pisania tego postu zdecydowalem, ze bym Was juz całkiem zanudził z tym BDD, stad napisze o nim w innym poscie ;) – kiedys indziej, być może pokusze się o jakis tutorial, jako, że o stosowniu BDD we Flexie na razie w sieci dosyc mało informacji.