Oczekiwania:

- umiejętność  projektowania interfejsu użytkownika
- podstawowych umiejętności pisania oprogramowania w języku ActionScript 3
- znajomość języka Java będzie dodatkowym atutem.

Oferta:

- atrakcyjne wynagrodzenie
- elastyczne godziny pracy pozwalającej pogodzić naukę i zdobywanie doświadczenia zawodowego
- zaświadczenie o odbyciu praktyk studenckich
- możliwość zdobycia doświadczenia z fascynującymi technologiami
- możliwość szkoleń w Polsce i za granicą

Zgłoszenia (zawierające CV) należy przesyłać na adres e-mail:
warsaw@adobe.com.

Adobe Polska zastrzega sobie prawo do kontaktu tylko z wybranymi kandydatami.

Jeżeli jesteś studentem/studentką z pewnością warto wziąć udział w rekrutacji i zdobyć cenne szlify i kwalifikacje przy współpracy z doświadczonymi osobami. Ze swojej strony gorąco polecam i zachęcam do wysyłania zgłoszeń.

Serdecznie gratuluję też zwyciężcom! A tym, którym w tym roku się nie udało, napiszę, że na parwdę poziom prac był wysoki i z pewnością się jeszcze spotkamy ;) Miło było oceniać i widzieć, że w przypadku niektórych osób stwierdzenie “jednoosobowa firma wdrożeniowa” jest realizowalna, tak trzymajcie ;)

Za niedługo na AkademiaPanaFlexa.pl oraz jak sądzę na blogu naszego niezmordowanego Flex Evangelisty Piotra Walczyszyna ;) pojawi się informacja o uroczystej gali wręczenia nagród!

Tym razem będzie ona dedykowana polskim studentom, stąd też pełna i oficjalna nazwa zawodów to Flex Challenge Academic Tour. W nazwie pojawia się nieprzypadkowo słowo “Tour”, ponieważ zawody będą poparte warsztatami na uczelniach wyższych w wybranych miastach Polski ;) Oczywiście po zakończeniu zawodów odbędzie się gala wręczenia nagród.

Niebawem pojawią bardziej szczegółowe informacje na temat zawodów na stronie http://www.flexchallenge.pl oraz z czasem na powiązanej z wydarzeniem Akademii Pana Flexa ;) Zachęcam też do przeczytania wpisu na blogu Piotra Walczyszyna, lista miast nie jest jeszcze zamknięta!

Organizatorem tegorocznych zawodów jest polski oddział Adobe wraz wybranymi partnerami i grupami Adobe w danych lokalizacjach, natomiast sponsorami wydarzenia jest polski oddział Adobe oraz Janmedia.

Oczywiście zapraszamy wszystkich do współtworzenia tegorocznych zawodów razem z nami, będzie nam miło ;)

Kontakt w sprawie współpracy: wspolpraca@flexchallenge.pl

Zeszłoroczna strona zawodów znajduje się pod adresem 2008.flexchallenge.pl

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ł …

Janmedia – Raiffeisen MBO – wzorzec MVP w praktyce
RIA Day 2008 – 27.11.2008 Wrocław

Jarek też dodał swoje trzy grosze ;)

Media Ambassador – Efektywne tworzenie aplikacji RIA w technologii ColdFusion
RIA Day 2008 – 27.11.2008 Wrocław

Ars Thanea – Mydeco Room Planner – zaprojektuj pokój online
RIA Day 2008 – 27.11.2008 Wrocław

Chodziło o to, aby na podstawie badań empirycznych sprawdzić, czy prototypowanie z zastosowaniem UML (z profilem RT) + metod formalnych (do formalnego wsparcia semantyki UML) w RIA (swoiste MDE, z ukierunkowaniem na RAD) może przynieść wymierne korzyści. Do tego celu posłużyłem się modelem COCOMO II.2000 (Constructive Cost Model) + Nelsen dla estymacji przewidywanych kosztów, oraz rozkładem Rayleigh’a (plus „wagi” Pressman’a) dla oszacowania gęstości występowania defektów w poszczególnych fazach projektu, a w konsekwencji kosztu usunięcia defektów w danej fazie produkcyjnej. Nie będę tu prezentował lekko rozbudowanych wzorów, które były podstawą do przeprowadzenia badań, a następnie odniesienia rezultatów do świata rzeczywistego (zresztą niedługo pojawi się pewna publikacja w tym względzie, to może pochwale się linkiem ;)).

Jakby nie było biorąc pod uwagę osiągnięte rezultaty mogę stwierdzić, że stosowanie formalnych metod prototypowania RIA średniej wielkości może zmniejszyć o około 43% koszt usunięcia błędów – jest to niebagatelna wartość, biorąc pod uwagę, że szacuje się, że koszt usunięcia błędów w fazie implementacji, jest średnio około 10 razy większy niż usunięcie danego błędu w fazie projektowania (w tym w procesie modelowania). Biorąc pod uwagę fakt, że stosowanie takich metod wydłuża fazy projektowania, skompensowany zysk to około 23% mniej kosztów, co też nie jest małą wartością. Zatem zainteresowanie się prototypowaniem RIA oraz stosowaniem metod formalnych w ich procesie wytwórczym wydaje się niegłupie … polecam.

Inna sprawa jak widać COCOMO może mieć wiele postaci, niesamowita zbieżność nazw z Adobe Cocomo ;)