Spis treści. Miesięcznik Software Developer s Journal (13 numerów w roku) jest wydawany przez SoftPress Sp. z o.o.

Transkrypt

1

2

3 Spis treści Praca z Legacy Code część 2 Przekleństwo czy intelektualne wyzwanie?... 3 Grzegorz Gubiński Wielu programistów nie chce pracować w projektach, w których głównym zajęciem jest utrzymanie produktu a nie jego rozwój. W przypadku takich projektów metafora produkcji oprogramowania wymyślona przez Alistaira Cockburna gra bagienna ma zdwojoną siłę przekazu. Programiści pracujący w takim środowisku starają się przetrwać. Ponieważ nie znają moczar, boją się w nie wchodzić. Jednak ich zadaniem jest opieka nad cennymi roślinami-funkcjonalnościami za to są przecież wynagradzani. Aby wybrnąć z sytuacji większość z nich decyduje się na najbezpieczniejszą z pozoru strategię minimalne ingerencje. Jednak takie podejście powoduje dalszą degenerację środowiska ich pracy bagno zarasta coraz bardziej. Rozwój technologii to wyzwanie dla programistów Dariusz Dudek Producenci sprzętu komputerowego prześcigają się w tworzeniu urządzeń o coraz lepszych parametrach mniejszych, lżejszych, z coraz większą mocą obliczeniową. Podobnie dzieje się w obszarze technologii IT. Z jednej strony oznacza to zwiększenie możliwości twórców oprogramowania, jednak z drugiej, stawia przed informatykami sporo wyzwań. Obecnie głównym wyzwaniem dla programistów jest bycie na bieżąco ze zmianami na rynku technologii, który jest bardzo dynamiczny. Nowości, które początkowo wydają się jedynie ciekawostkami, często stają się poważnymi konkurentami wobec sprawdzonych i znanych produktów. Okazuje się, że nowe rozwiązanie mogą być lepsze i znacznie tańsze. Dzięki dobrej znajomości rynku zespoły projektowe wraz z programistami mogą zaprojektować i stworzyć systemy najlepiej dopasowane do potrzeb biznesu, ale też najbardziej korzystne finansowo. Centrum danych - budowa czy kolokacja? Edyta Marchaluk Rosnące potrzeby IT, digitalizacja kolejnych dziedzin życia, wymagające sprzętowo aplikacje, czy wreszcie ekspansja i nowe obszary działalności firm, stawiają managerom IT wyzwanie zapewnienia przestrzeni dla rozrastających się środowisk IT. Decyzje w tym obszarze poparte są najczęściej szeregiem analiz biznesowych, ale mogą mieć także podłoże w przyzwyczajeniach. Jedno z nich podpowiada nam, że wykonanie czegoś samodzielnie będzie tańsze. Drugie, że jeśli coś jest naszą własnością, to mamy nad tym większą kontrolę, a więc mamy większe poczucie bezpieczeństwa. Czy rzeczywiście tak jest? Co powinniśmy rozważyć podejmując decyzję dotyczącą budowy własnego centrum danych? Zarządzanie infrastrukturą centrum danych wypełnia lukę pomiędzy IT a obiektami Piotr Kowalski W dobie oszczędności i kryzysu gospodarczego menedżerowie centrów danych znajdują się pod ogromną presją podnoszenia efektywności działalności i zwiększenia wykorzystania dostępnych zasobów. Są zmuszeni do podwyższania wydajności i redukcji kosztów przy jedno- czesnym zachowaniu dostępności. W odpowiedzi na to zapotrzebowanie departamenty IT wdrażają technologię wirtualizacji, środowiska cloud computingu i ujednoliconego przetwarzania dla systemów logicznych. Takie działania są efektywne dla IT, ale jednocześnie tworzą nowe zależności w systemach fizycznych zarządzanych przez departamenty obiektów i skutkują zmianami w zarządzaniu zasilaniem, chłodzeniem i przestrzenią fizyczną. Czynniki te w połączeniu z rosnącymi kosztami energii elektrycznej, wymaganiami dotyczącymi zgodności z przepisami i umowami SLA powodują, że menedżerowie centrum danych są zmuszeni zajmować się nie tylko działaniem sprzętu IT, ale także kompleksową obsługą całości infrastruktury centrum danych jako elementów ekosystemu. Grywalizacja życie to nie bajka Adrian Adio Zając Wirtualna zabawa w farmera stała się ogólnoświatowym fenomenem, bijąc rekordy popularności. Zasiadając przed swoją ukochaną konsolą po ciężkim i wyczerpującym dniu nauki, czy pracy liczymy na chwilę relaksu po trudach dnia codziennego. Efekt takiego odstresowywania się jest o tyle lepszy, o ile dany tytuł spełnia swój główny cel, którym jest dostarczenie szeroko pojętej rozrywki, czy to za sprawą hipnotyzującej zmysły grafiki, urzekającej ścieżki dźwiękowej, zapierającej dech w piersiach fabuły, czy pompującej do krwi adrenalinę akcji. Metodyka Agile i projekty SharePoint mezalians, ślub czy pogrzeb? Janusz Falkiewicz Analityk i Konsultant Biznesowy, JADE. Metodyk zwinnych jako takich sądzę, iż nie ma potrzeby przedstawiać - oficjalnie zostały ogłoszone jako manifest już w 2001 roku. Po szczegóły, bądź dla odświeżenia pamięci, polecam sięgnąć do tego źródła: Idea jest prosta i chwytliwa: w realizacji wdrożeń informatycznych ważni są ludzie, współpraca z Klientem, interakcja wewnętrzna, reagowanie na zmiany, cykliczne iteracje (trwają od 2 do 4 tygodni, są to tzw. sprinty) no i oczywiście działające oprogramowanie. A działające oznacza wspomagające pracę i realizację celów biznesowych Klienta, takie, które on wykorzystuje, a nie obsługuje. No software just tools. Programowanie w świecie nowych technologii Bogdan Bereza Trzy podstawowe pytania Programiści czy tworzą działające, zgodne z potrzebami klienta aplikacje, czy tylko produkują i kompilują kod źródłowy? Rozwój technologii czy to tylko bardziej wypasiona elektronika oraz systemy operacyjne i języki programowania o coraz dziwaczniejszych nazwach, czy również zmiany metod, procesów, organizacji? Nowość dla jednej osoby, dla danej firmy, czy autentyczna nowość? Co to właściwie jest programowanie? Czy oznacza to tworzenie oprogramowania, a więc złożony proces, obejmujący całą drogę od analizy wymagań, poprzez projektowanie, pisanie kodu, integrację, testowanie, wdrożenie i utrzymanie? Czy też programowanie, to samo kodowanie: pisanie kodu źródłowego, kompilowanie, ewentualnie anali za statyczna i testy jednostkowe Miesięcznik Software Developer s Journal (13 numerów w roku) jest wydawany przez SoftPress Sp. z o.o. Prezes: Natalia Sieniutowicz Redaktor Naczelny: Natalia Sieniutowicz Redaktor Prowadzący: Patrycja Popławska Skład i łamanie: Marcin Ziółkowski, Graphics & Design Studio, Kierownik Produkcji: Andrzej Kuca andrzej.kuca@software.com.pl 2 Adres korespondencyjny: SoftPress Sp. z o.o. ul. Bokserska 1, Warszawa, Polska tel , fax cooperation@software.com.pl Dział reklamy: adv@software.com.pl Redakcja dokłada wszelkich starań, by publikowane w piśmie i na towarzyszących mu nośnikach informacje i programy były poprawne, jednakże nie bierze odpowiedzialności za efekty wykorzystania ich; nie gwarantuje także poprawnego działania programów shareware, freeware i public domain. Wszystkie znaki firmowe zawarte w piśmie są własności odpowiednich firm. Zostały użyte wyłącznie w celach informacyjnych. Osoby zainteresowane wspópracą prosimy o kontakt: cooperation@software.com.pl

4 Praca z Legacy Code część 2 Przekleństwo czy intelektualne wyzwanie? Wielu programistów nie chce pracować w projektach, w których głównym zajęciem jest utrzymanie produktu a nie jego rozwój. W przypadku takich projektów metafora produkcji oprogramowania wymyślona przez Alistaira Cockburna gra bagienna ma zdwojoną siłę przekazu. Programiści pracujący w takim środowisku starają się przetrwać. Ponieważ nie znają moczar, boją się w nie wchodzić. Jednak ich zadaniem jest opieka nad cennymi roślinamifunkcjonalnościami za to są przecież wynagradzani. Aby wybrnąć z sytuacji większość z nich decyduje się na najbezpieczniejszą z pozoru strategię minimalne ingerencje. Jednak takie podejście powoduje dalszą degenerację środowiska ich pracy bagno zarasta coraz bardziej. Widząc pogarszającą się powoli, lecz niezmiennie sytuację stają się coraz bardziej sfrustrowani i zniechęceni. Niniejszy artykuł ma za zadanie przedstawić strategię osuszania mokradeł wraz z kilkoma użytecznymi technikami. Dowiesz się: w jaki sposób radzić sobie z niepożądanymi zależnościami w kodzie. Powinieneś znać: podstawy języka C++ podstawy Test Driven Development podstawowe pojęcia programowania obiektowego Dosłowne znaczenie terminu kod spadkowy, to kod, który otrzymaliśmy od innej osoby. Jednak w środowisku zwinnych metodyk wytwarzania oprogramowania powszechnie przyjęła się definicja kod bez lub z małą ilością testów automatycznych. Bez względu na definicję kod spadkowy (czy też odziedziczony) wzbudza w programistach niemiłe skojarzenia. Wśród najczęściej wymienianych są trudność ze zrozumieniem kodu, oraz związany z nim strach przed wprowadzeniem niepożądanych efektów podczas pielęgnacji. Z takim problemem mierzy sie codziennie wielu programistów. Aby móc skutecznie radzić sobie innym z takimi zadaniami M. Featchers zaproponował heurystykę wprowadzania zmian w kodzie spadkowym. Algorytm ten składa się z pięciu etapów: Znalezienie punktów, w których dokonywać będziemy zmiany, Znalezienie miejsc, w których będziemy testować, Usunięcie niepożądanych zależności pomiędzy elementami, które będziemy testować a ich otoczeniem, Napisanie testów, Wprowadzenie pożądanych zmian. W poprzednim artykule zajmowaliśmy się dwoma pierwszymi krokami powyższej heurystyki i w związku z tym, możemy założyć, że mamy już wiedzę na temat tego: gdzie i w jaki sposób będziemy dokonywać zmiany, oraz 4

5 Praca z Legacy Code część 2 w jaki sposób i w jakich miejscach najwygodniej będzie nam testować. Aby tego dokonać posługiwaliśmy się dwoma pomocnymi na tych etapach technikami. Były to tak zwanym scratch-refaktoring i szkice efektów. W niniejszym artykule zajmiemy się krokiem 3 usuwaniem niepożądanych zależności. Co sprawia, że zmiana kodu odziedziczonego jest taka trudna? Oczywiście zmiana, jako taka jakiegokolwiek kodu nie jest trudna. Trudność polega na tym, że jako profesjonaliści chcemy naszą zmianę zweryfikować za pomocą testów automatycznych. W przypadku pisania nowego kodu z zastosowaniem TDD podjęcie decyzji jak testować jest wystarczającym warunkiem do tego, aby zacząć pisać test. Niestety, mając do czynienia z kodem spadkowym programiści często wpadają w błędne koło problemu jajka i kury. Z definicji kod taki nie ma testów, lub ma ich mało. To powoduje, że trudno poprawić jego strukturę (refaktoryzować) bez obawy o skutki takich zmian. Taka obawa często prowadzi do wybierania takich rozwiązań, które wprowadzą minimum zmiany w kodzie. Takie dodawanie kolejnego przysłowiowego jednego if-a skutkuje nieuchronnie wzrostem skomplikowania kodu. Natomiast skomplikowana Listing 1. Klasa z metodą odwołującą się do czasu (przed zmianami) class ClassUnderTest { public: // metoda wywołująca funkcję systemową int functionundertest() { std::time_t t = std::time(null); std::tm tm = std::localtime(&t); if (tm.tm_wday == 0 /*Sunday*/ tm.tm_wday == 6 /* Saturday*/) { performfullprocedure(); else { performsimplifiedprocedure(); return 0; private: int performsimplifiedprocedure() { // some complicated code here return 0; ; int performfullprocedure() { // some even more complicated stuff... return 0; struktura wewnętrzna utrudnia lub nawet uniemożliwia napisanie testów. Sposobów, w jaki obniżamy testowalność aplikacji jest wiele. Jednym z najczęstszych problemów przy próbie pisanie testów jednostkowych w kodzie spadkowym są skomplikowane zależności. Zależności mogą uniemożliwić nam stworzenie w środowisku testowym obiektu klasy, w której wprowadzamy zmiany. Przykładem może tu być parametr konstruktora, którego do poprawnej inicjalizacji wymaga podania wielu kolejnych równie skomplikowanych obiektów. Te z kolei wymagają kolejnych itd. Wywołana w ten sposób lawina może oznaczać skompilowanie i ręczne skonstruowanie znacznej części systemu. Tak skonstruowany test będzie zazwyczaj nadmiarowy, bardzo pracochłonny, podatny na błędy i trudny w pielęgnacji. Inną kłodą rzucaną przez zależności pod nasze nogi może być fakt, że czasem nie będziemy chcieli w teście współpracować z obiektami oryginalnych (produkcyjnych) klas. Najczęstszym przypadkiem są tutaj obiekty współpracujące z bazami danych. Współpraca naszego testowego obiektu z obiektem wykonującym połączenie do bazy danych lub komunikującym sie poprzez sieć na pewno wielokrotnie spowolni wykonanie przypadku testowego,a dodatkowo może wprowadzić utrudniającą testowanie losowość zachowania. Dla uproszczenia rozważań przyjąć możemy, że miejsce zmiany i miejsce testowania są takie same, (choć nie zawsze jest to prawdą patrz pierwsza część artykułu szkice efektów) oraz że będę tych pojęć używał zamiennie. Zależności publiczne i prywatne Wszystkie wymienione zależności pomiędzy elementami (klasami, modułami itd.) można podzielić na dwie kategorie: publiczne i prywatne. Pierwszą z nich są powiązania wynikające z interfejsu klasy lub modułu, drugą stanowią powiązania zdefiniowane w funkcjach i metodach. Ta pierwsza grupa - jawne powiązania jest z punktu widzenia testowalności przypadkiem łatwiejszym. Większość publicznych powiązań obiektu, który zamierzamy testować z obiektami klas, które są trudne w tworzeniu lub współpracy można, po niewielkich zmianach zastąpić zależnościami do interfejsów lub klas abstrakcyjnych. Po takiej zmianie umożliwiamy sobie oddzielenie testowalnego obiektu od reszty środowiska przez zastosowanie dublerów testowych. Wystąpienie kłopotliwych zależności prywatnych jest większym wyzwaniem: wymaga dodatkowych kroków umożliwiających ich wyeliminowanie. Powyższe uwagi w przypadku programowania zorientowanego obiektowo oznaczają powiązania pomiędzy obiektami. Zależności od wartości losowych Występowanie w kodzie losowych lub związanych z czasem wartości także może poważnie utrudniać testowanie. Do tych pierwszych należą wszelkie wywołania generatorów liczb pseudolosowych, do drugich wszystkie odmiany znaczników czasowych (ang. time-stamp) i dat. Problem najłatwiej zobrazować wyobrażając sobie przykładową komputerową wersję dowolnej gry planszowej z kostkami do gry. W grach tego typu ruch gracza uzależniony jest od ilości wyrzuconych oczek na kostce do gry. W wersji komputerowej rzut kostką symulowany jest poprzez wywołanie jakiejś odmiany funkcji random. Gdy przystępujemy do testowania elementów związanych z ruchem graczy po planszy, bez odseparowania zależności od generatora - za każdym razem algorytm przesuwający pionek będzie przesuwał go w inne miejsce. Krok 3 Usuwanie niepożądanych zależności Na szczęście istnieją skuteczne sposoby pozbywania się niepożądanych zależności. Techniki refaktoryzacji, o których mowa są wystarczająco bezpieczne, aby stosować je również do kodu bez testów. Przypadek 1: Testowana funkcja zależna jest od funkcji systemowej (daty systemowej, czasu systemowego, generatora liczb pseudolosowych itd.). 5

6 Listing 2. Klasa po zmianach class ClassUnderTest { public: // metoda wywołująca funkcję systemową // po wydzieleniu fragmentu do osobnej metody int functionundertest() { std::tm tm = getlocaltime(); if (tm.tm_wday == 0 tm.tm_wday == 6) { performfullprocedure(); else { performsimplifiedprocedure(); return 0; private: // wydzielona część odwołująca się do systemu virtual std::tm getlocaltime() { std::time_t t = std::time(null); std::tm tm = std::localtime(&t); return tm; ; int performsimplifiedprocedure() { return 0; int performfullprocedure() { return 0; Listing 3. Podklasa testowa class TestingVersionUnderTest: ClassUnderTest { private: // wersja testowa metody zwraca dogodny dla testu wynik virtual std::tm getlocaltime() { std::tm tm; tm.tm_wday = 0; return tm; ; Listing 4. class ClassWithLongMathods { public: int somelongmathod(int id, std::string name, Person &dsc); // metoda wywołująca metodę somelongmathod void clientmathod(); // metoda wywoływana przez somelongmathod void anothermethod(); private: // pole do którego odwołuje się somelongmathod std::string somedata; ; void ClassWithLongMathods::clientMathod() { int ret = somelongmathod( id, na, person ); int ClassWithLongMathods::someLongMathod(int id, std::string name, Person &dsc){ if( somedata == name ){ anothermethod(); Wyobraźmy sobie metodę, która inaczej zachowuje się w dni robocze, inaczej w dni wolne (listing 1). W dni robocze uruchamiany jest szybki, ale mało dokładny algorytm obliczania pewnej wartości. W dni wolne natomiast wykonywana jest pełna wersja. Rozwiązaniem jest refaktoryzacja nadpisanie metod(y) w podklasie Algorytm zmiany: Zidentyfikuj elementy, które stanowią problem Jeśli elementem tym jest bezpośrednie wywołanie funkcji systemowej użyj refaktoryzacji Wyodrębnienie metody, (jeśli używasz języka Java i środowiska Eclipse możesz zaznaczyć to wywołanie i użyć skrótu alt+shif+m). Jeśli kłopotliwe zachowania stanowią metodę upewnij się, że można tę metodę nadpisać. Przykładowo w języku Java może to między innymi oznaczać zmianę zakresu metody jeśli dotychczas była prywatna (listing 2). Stwórz w testach podklasę i nadpisz kłopotliwe metody w taki sposób, aby zachowywały się w pożądany sposób (listing 3). Powyższą technikę stosować można także w wielu innych wypadkach. Wśród innych częstych przykładów można wymienić: tworzenie obiektu dowolnej klasy. Wydzieleniu metody dla instrukcji tworzącej obiekt jest de-facto zastosowaniem wzorca metoda tworząca. Unieważnienie dowolnego niepożądanego zachowania. Jeśli mamy dowolny fragment kodu, o którym wiemy, że nie wpływa na modyfikowaną funkcjonalność, ale spowalnia testy (przykład: weryfikacja uprawnień użytkownika) Przypadek 2: Testowanie zmiany w długiej metodzie. Jednymi z najczęściej występujących problemów w kodzie są zapachy długa metoda i wielka klasa. Problematyczne w nich jest między innymi to, że długa metoda z definicji robi wiele różnych rzeczy i czasem weryfikacja zmian poza tą metodą jest niemożliwa. W takich sytuacjach warto rozważyć przeniesienie metody do nowej klasy. Przykładowy pseudo-kod z oczywistych względów zawiera długą metodę tylko z nazwy (listing 4), lecz powinno to wystarczyć do zobrazowania problemu i jego rozwiązania. Poniższy algorytm zaczerpnięty został z książki Working Effectively with Legacy Code. Podobny algorytm zaproponowany został przez M. Fowlera w książce Refactoring: Improving the Design of Existing Code. 6

7 Praca z Legacy Code część 2 Listing 5. Po krokach 1-4 class SomeLongMathod { int _id; std::string _name; Person &_dsc; public: SomeLongMathod(int newid, std::string newname, Person &newdsc) : dsc(newdsc) { Id = newid; name = newname; ; int run(); Listing 6. Po kroku 5 int SomeLongMathod::run() { if( somedata == name ){ foo3(); anothermethod(); Listing 7. Po kroku 6 i 7 z dodaną referencją do klasy macierzystej class SomeLongMathod { private: int id; std::string name; Person dsc; ClassWithLongMathods source; public: SomeLongMathod(ClassWithLongMathods &newsource, int newid, std::string newname, Person &newdsc) : source(newsource), dsc(newdsc) { Id = newid; name = newname; ; ; int run(); // przeniesiona metoda z referencją do obiektu klasy macierzystej int SomeLongMathod::run() { foo1(); if( source.somedata == name ){ foo3(); source.anothermethod(); foo4(); return id + 100; void ClassWithLongMathods::clientMathod() { SomeLongMathod methodobject(id, na, person ); methodobject.run(); Stwórz klasę, która zostanie gospodarzem dla przenoszonego kodu (proponuję nadać jej nazwę nawiązującą do nazwy metody, którą przenosimy) Stwórz konstruktor, skopiuj do niego sygnaturę przenoszonej metody W nowej klasie dodaj pola, które przechowają wartości przekazane przez parametry wywołania konstruktora. Stwórz w nowej klasie bezparametrową metodę, która będzie wykonywała przenoszony kod (proponuję nazwy run lub execute ), Jeśli oryginalna metoda zwraca wartość nowa metoda powinna zwracać taki sam typ. Dodatkowo, w niektórych językach np. w języku Java - jeśli metoda wyrzuca wyjątek nowa metoda powinna zadeklarować taki sam typ wyjątku (listing 5). Przenieś ciało metody do stworzonej metody wykonawczej (listing 6). Skompiluj. Jeśli nowa metoda używa metod lub pól ze starej klasy podaj, jako pierwszy parametr do konstruktora referencję do obiektu klasy macierzystej. Odwołania do pól i metod starej zastąp wywołaniami do pól i metod dodanej referencji. Czasem wymagać to będzie zmiany poziomu dostępu. Jeśli nowa klasa kompiluje się wróć do oryginalnej klasy i usuń metodę. Wywołanie metody zastąp stworzeniem egzemplarza nowej klasy i wywołaniem na nim metody uruchamiającej przeniesiony kod (listing 7). Jeśli trzeba, zastąp wywołania metod ze starej klasy, odwołaniami do interfejsu (zobacz refaktoryzację wyodrębnienie interfejsu ) Wielką zaletą opisanego powyżej algorytmu jest jego skuteczność. Można go zastosować dosłownie do każdej długiej metody. Bezpośrednią potencjalną wadą użycia jest obniżenie hermetyzacji klasy. Oczywiście dzięki temu podnosimy (czy raczej tworzymy) testowalność. Obie te cechy testowalność i hermetyzacja są narzędziami służącymi temu samemu celowi: podniesieniu niezawodności kodu. Dlatego mając do wyboru rezygnację z jednej na korzyść drugiej zawsze wybiorę wyższą testowalność. W tym miejscu warto przypomnieć, że sprzymierzeńcem w pracy z kodem jest dobra znajomość języka programowania. Kilka lat temu, gdy pracowałem w projekcie, w którym używany był język Delphi odkryłem w aplikacji wycieki pamięci. Problem związany był z tym, że: w kodzie wywoływanym przez wydzialaną metodę następowała leniwa 7

8 inicjalizacja jednego z parametrów przekazanych, oraz dodatkowo, że zainicjalizowany obiekt zwracany był poprzez parametr wywołania. Po zastosowaniu tego algorytmu leniwa inicjalizacja zachodziła oczywiście dalej, ale aktualizowana była jedynie składowa nowo powstałego obiektu. Parametr przekazywany do nowopowstałego obiektu pozostawał niezainicjowany poza wywoływaną funkcją, co z kolei skutkowało ponowną próbą stworzenia obiektu w innym fragmencie kodu. Ponieważ, dodatkowo, wszystko to działo się w języku programowania, który wymagał jawnego zwalniania pamięci (Delphi) to oprócz utraty danych wprowadzonych do kłopotliwego obiektu następował wyciek pamięci. Był to jedyny problem spowodowany zastosowaniem powyższego algorytmu, jaki kiedykolwiek odkryłem. Przypadek 3: Testowanie zmiany w obiekcie z kłopotliwymi powiązaniami z innymi obiektami. Inna często występującą sytuacją są zależności do obiektów-składowych tworzonych w konstruktorze. Niejednokroć zdarza się, że klasa mając jedynie bezparametrowy konstruktor w swoim ciele powołuje do życia kilkanaście innych obiektów. Często jeden lub wiele z nich wpływa na zachowanie obiektu w sposób uniemożliwiający skuteczne napisanie testów. Przykładem może być sytuacja, w której klasa reprezentująca osobę powołuje w konstruktorze obiekt służący zapisywaniu/odczytywaniu obiektów z bazy danych DAO (wzorzec Obiektu Dostępu do Danych ang. Data Access Object - listing 8). Testując taki obiekt interesować nas będzie czy spełnia swoje zadania w systemie (np. czy zwraca metoda string getfulladdress() zwróci poprawnie sformatowany adres wraz z imieniem i nazwiskiem) i czy ewentualnie podejmie próbę zapisania się w bazie danych a nie to czy rekord w bazie danych powstanie to jest już rola wspomnianego wcześniej obiektu DAO. Algorytm: Parametryzacja Konstruktora Skopiuj konstruktor, który sprawia kłopoty Określ, które obiekty tworzone w konstruktorze stanowią problem Po kolei usuwaj te parametry przenosząc je do listy parametrów konstruktora (listing 9) Ze starego konstruktora usuń cały kod (poza inicjacją kłopotliwych zmiennych) i zastąp go wywołaniem nowego konstruktora (listing 10) Po takiej refaktoryzacji mamy do dyspozycji dwa konstruktory. Pierwszy z mniejszą ilościa parametrów nadal tworzy potrzebne sobie Listing 8. class Person { string _firstname, _familyname; time_t _birthdate; PersonDAO *_persondao; public: Person(string firstname, string familyname, time_t birthdate); ; Person::Person(string firstname, string familyname, time_t birthdate) { _persondao = new PersonDAO(); // problematyczny obiekt _familyname = firstname; _familyname = familyname; _birthdate = birthdate; _persondao->save( *this ); Listing 9. Po kroku 3 // oryginalny konstruktor Person::Person(string firstname, string familyname, time_t birthdate) { _persondao = new PersonDAO(); // problematyczny obiekt _familyname = firstname; _familyname = familyname; _birthdate = birthdate; _persondao->save( *this ); // dodany, testowy konstruktor Person::Person(string firstname, string familyname, time_t birthdate, PersonDAO *persondao) { _persondao = persondao; _familyname = firstname; _familyname = familyname; _birthdate = birthdate; persondao->save( *this ); Listing 10. Wersja finalna // oryginalny konstruktor po usunięcu duplikacji Person::Person(string firstname, string familyname, time_t birthdate) { this(familyname, familyname, birthdate, new PersonDAO()); Person::Person(string firstname, string familyname, time_t birthdate, PersonDAO *persondao) { _persondao = persondao; _familyname = firstname; _familyname = familyname; _birthdate = birthdate; _persondao->save( *this ); 8

9 Praca z Legacy Code część 2 Listing 11. Klasy reprezentujące osobę oraz singleton umożliwiający jej zapis do bazy danych (wersja wyjściowa) // klasa singleton, który sprawia kłopoty class PersonDAO { private: PersonDAO( string url, string usr, string pass); static PersonDAO *_instance; string connectingstr, usr, pass; public: static PersonDAO* PersonDAO::instance(){ if( _instance == NULL ) { string url = geturl(); _instance = new PersonDAO(url, admin, * ); return _instance; ; void save(person &person) const; void remove(person &person) const; void update(person &person) const; Person* find(int Id); // klasa, którą chcemy testować class Person { string _firstname, _familyname; time_t _birthdate; PersonDAO *_persondao; public: Person(string firstname, string familyname, time_t birthdate); ; Person::Person(string firstname, string familyname, time_t birthdate) { _familyname = firstname; _familyname = familyname; _birthdate = birthdate; _persondao = PersonDAO::instance(); _persondao->save( *this ); Listing 12. Zmiana po stronie singletonu (kroki 1-3) class PersonDAO { private: PersonDAO( string url, string usr, string pass); static PersonDAO *_instance; static string _connectingstr, _usr, _pass; static PersonDAO* instance(); public: PersonDAO(); ; void save(person &person) const; void remove(person &person) const; void update(person &person) const; Person* find(int Id); obiekty samodzielnie i używany jest w kodzie produkcyjnym. Drugi konstruktor, do którego poza oryginalnymi parametrami dodaliśmy nowe służyć nam będzie do dostarczenia w kodzie testowym dublerów testowych zamiast egzemplarzy, które sprawiały nam problem. Przypadek 4: Zależność od Singletonu Występowanie w kodzie wzorca singleton jest szczególnym przypadkiem zależności od elementów statycznych. W większości popularnych implementacji wzorca klasa singletonu jest odpowiedzialna za stworzenie egzemplarza. Klasa tworzonego obiektu jest podana wprost. To powoduje, że w takich implementacjach nie ma możliwości zwrócenia obiektu klasy pochodnej bez istotnych zmian w implementacji wzorca. Jedną z możliwości jest zmiany jest użycie rejestrów singletonów, kolejną stworzenie osobnych konfiguracji dla kodu produkcyjnego i testowego oraz korzystających z nich fabryk abstrakcyjnych. Jeśli taka zmiana jest niemożliwa lub nieopłacalna można posłużyć się innymi, mniej pracochłonnymi sposobami. Sposób 1 - Wprowadzenie wzorca Monostate. Zmień wszystkie pola klasy singletona na statyczne Zmień zakres metody zwracającej egzemplarz na prywatny Sprawdź kod inicjalizujący egzemplarz obiektu singletonu (zazwyczaj w metodzie instance) Jeśli stworzenie polega jedynie na wywołaniu prywatnego konstruktora: zmień jego zakres konstruktora na publiczny Jeśli nie ma bezparametrowego konstruktora, stwórz go i przenieś kod inicjalizujący (listing 12). Skompiluj; Wszędzie tam gdzie kompilator zgłosi błędy związane z niedostępnością metody zwracającej egzemplarz (instancje()): zmień wywołanie na stworzenie egzemplarza. Usuń metodę zapewniającą dostęp do egzemplarza (instancje()) i zmienną przechowującą egzemplarz (listing 13). Jeśli w kodzie testowym trzeba będzie nadpisać którąkolwiek upewnij się czy to będzie możliwe (np. przez uczynienie metody wirtualną w C++, czy też usunięcie modyfikatora final w Java) Teraz możemy zastosować wydzielenie metody i nadpisanie metod w podklasie. Po tych krokach w miejscu gdzie używaliśmy single tonu mamy metodę kreującą egzemplarz pochodny od mona state, w którym to przedefiniowaliśmy kłopotliwe dla nas zachowania. 9

10 Listing 13. Ostateczny wygląd kodu // klasa która sprawiałą kłopoty obecnie monostate class PersonDAO { private: PersonDAO( string url, string usr, string pass); static string _connectingstr, _usr, _pass; public: PersonDAO() { // przeniesiony kod inicjalizujący this (geturl(), admin, **** ); void save(person &person) const; void remove(person &person) const; void update(person &person) const; Person* find(int Id); ; // zmiana w kodzie klienta Person::Person(string firstname, string familyname, time_t birthdate) { _familyname = firstname; _familyname = familyname; _birthdate = birthdate; _persondao = new PersonDAO(); _persondao->save( *this ); Listing 14. Po dodaniu metody umożliwiającej ustawienie innego egzemplarza. class PersonDAO { private: PersonDAO( string url, string usr, string pass); static PersonDAO *_instance; static string _connectingstr, _usr, _pass; static PersonDAO* instance(); public: // dodana metoda umożliwiająca ustawienie // zwracanego egzemplarza void setinstance(persondao *newinstance){ ; _instance = newinstance; ; void save(person &person) const; void remove(person &person) const; void update(person &person) const; Person* find(int Id); Sposób 2 Dodanie statycznego settera. Metoda ta polega na dodaniu do singletonu metody pozwalającej ustawić zwracaną instancję w ten sposób możemy wpływać na to co zostanie zwrócone przez metodę instancje (Listing 14). Oczywiście ma to (poza zmniejszeniem hermetyzacji) wadę: trzeba pamiętać, aby po teście przywrócić oryginalną instancję. Usunięcie zależności nie jest oczywiście celem samym w sobie. Uniemożliwia nam jedynie napisanie testów, które upewnią nas w przekonaniu, że modyfikując kod wprowadziliśmy tylko takie efekty, o których myśleliśmy i że żadna z pozostałych funkcjonalności systemu nie została zepsuta. Mając to za sobą będziemy mogli przystąpić do napisania testów i wprowadzenia nowych funkcjonalności lub zmodyfikowania (poprawienia) starych. To jednak będzie tematem ostatniej, trzeciej odsłony tematu. Refaktoryzacja Seria małych przekształceń kodu nie zmieniających jego funkcjonalności mających na celu poprawę STRUKTURY kodu. Kod Spadkowy (ang. Legacy Code) 1. Kod napisany przez kogoś innego. 2. Kod z małą ilością lub pozbawiony zupełnie testów automatycznych.. Wzorzec Monostate Wzorzec zapewniający, że wszystkie dane przechowywane przez egzemplarz są współdzielone przez wszystkie egzemplarze danej klasy. Wzorzec Singleton Wzorzec zapewniający, że istnieje tylko jeden egzemplarz obiektu oraz dostarczający globalny punkt dostępu do tego egzemplarza. Zapachy Kodu (ang. Code Smells) Ogólne pojęcie zaproponowane przez Kenta Becka wyjaśniające kiedy kod powinien zostać poddany refaktoryzacji. Dublerzy Testowi (ang. Test Doubles) Zaproponowana przez Gerard Meszaros ogólna nazwa na wszystkie obiekty, na które podmieniamy oryginały w celu ułatwienia testowania W Sieci articles/workingeffectivelywithlegacy Code.pdf book/software-engineering-anddevelopment/ software-engineering-and-development/ refactoring/ Grzegorz Gubiński Trener Agile z Nokia Siemens Networks, z pond trzynastoletnim doświadczeniem w programowaniu w takich językach jak C++, Java, Pascal/Delphi czy też Flex. Obecnie zajmuje się między innymi wdrażaniem metodyki Scrum oraz praktyk inżynierskich programowania ekstremalnego. 10

11 Rozwój technologii to wyzwanie dla programistów Rozwój technologii to wyzwanie dla programistów Producenci sprzętu komputerowego prześcigają się w tworzeniu urządzeń o coraz lepszych parametrach mniejszych, lżejszych, z coraz większą mocą obliczeniową. Podobnie dzieje się w obszarze technologii IT. Z jednej strony oznacza to zwiększenie możliwości twórców oprogramowania, jednak z drugiej, stawia przed informatykami sporo wyzwań. Obecnie głównym wyzwaniem dla programistów jest bycie na bieżąco ze zmianami na rynku technologii, który jest bardzo dynamiczny. Nowości, które początkowo wydają się jedynie ciekawostkami, często stają się poważnymi konkurentami wobec sprawdzonych i znanych produktów. Okazuje się, że nowe rozwiązanie mogą być lepsze i znacznie tańsze. Dzięki dobrej znajomości rynku zespoły projektowe wraz z programistami mogą zaprojektować i stworzyć systemy najlepiej dopasowane do potrzeb biznesu, ale też najbardziej korzystne finansowo. Nowinki technologiczne wiążą się z koniecznością stałego dokształcania i podnoszenia kwalifikacji, zdobywania nowych umiejętności i certyfikatów. Praca programisty wymaga znajomości gotowych produktów, takich jak serwery baz danych, serwery aplikacyjne, portale, silniki procesów, system obiegu dokumentów. W tym obszarze programiści certyfikują się w zakresie produktów oferowanych przez największych na świecie dostawców technologii (np. Microsoft, Oracle, IBM czy JBoss). Rozwój technologiczny bezpośrednio dotyczy takich czynników jak bezpieczeństwo informacji, ergonomia systemów czy ich skalowalność. W tym kontekście każda implementacja nowych rozwiązań zwiększa ryzyko wystąpienia problemów. Stąd wiele firm i dostawców decyduje się na technologie, które gwarantują jak największe bezpieczeństwo danych. Nie zmienia to jednak faktu, że dostawca powinien pomóc dokonać wyboru prezentując także korzyści w obszarach ergonomii, wydajności i skalowalności przy użyciu najnowszych rozwiązań. Klienci chcą mieć pewność, że otrzymają od dostawcy stabilne rozwiązanie, stworzone w technologii, która nie zostanie wycofana czy wyparta z rynku w ciągu najbliższych kilku lat. W wielu przypadkach w ten aspekt bezpieczeństwa wpisuje się możliwość rozwoju systemu, dostępność nowych wersji, otwartość czy łatwość dokonania migracji. Jeżeli programiści nie są na bieżąco z najnowszymi technologiami, to po pierwsze ich klienci będą potencjalnie tracić korzyści wynikającej z wdrażania tańszych i lepszych rozwiązań, po dru- gie zaś, w dłuższej perspektywie dla programistów może to oznaczać utratę klientów i zleceń. Języki programowania Jednym z zagadnień, które muszą śledzić programiści, są języki programowania. Języki podstawowe wykorzystywane w tworzeniu rozwiązań stale się rozwijają. Opanowanie ich wszystkich jest praktycznie niemożliwe, dlatego programiści specjalizują się w jednym bądź kilku językach. Stąd w przypadku tworzenia produktu lepiej bazować na jednym języku. Dla klientów ważne są możliwości, jakie dają nowe technologie. Z punktu widzenia zespołu projektowego przed przystąpieniem do pracy najważniejszy będzie wybór odpowiedniej technologii. Twórcy rozwiązania muszą mieć stuprocentową pewność, że wybrany język, technologia czy platforma pozwolą stworzyć i wdrożyć wymagane przez klienta funkcjonalności. Jednocześnie wybór ten należy wpisać w trendy rozwoju rynku i branży, w jakiej działa klient. W praktyce producenci wykorzystują nowe i tym samym nie dość dobrze sprawdzone języki i platformy tylko w prototypach i małych rozwiązaniach. Zmiany technologiczne Dla programistów bardzo istotne są zmiany związane z wzorcami architektonicznymi i projektowymi, co może rzucać nowe światło na sposoby tworzenia oprogramowania. Tego rodzaju zmiany pozwalają lub wręcz zmuszają do przemodelowania myślenia o tym, w jaki sposób można spełnić oczekiwania klienta. Do takich zmian technologicznych należały m.in. MOM (Message-oriented middleware), SOA (Service-oriented architecture), rozwój narzędzi workflow/bpm, dbpm (dynamic BPM), REST (Representational state transfer), a w ostatnim czasie rozwój modelu chmury (Cloud computing) wraz z coraz powszechniejszym udostępnianiem w sieci usług w modelu SaaS (a także IaaS i PaaS). Warto zwrócić uwagę, że tego rodzaju zmiany są trudne do przyjęcia, ponieważ wymagają znacznego zaangażowania po stronie klienta i jego współpracy z dostawcą oprogramowania. Chmura Jednym z obecnie największych wyzwań jest cloud computing. To typowa innowacja, która zmienia dotychczasową filozofię dostarczania oprogramowania klientom. Jej konsekwencją jest przekierowanie na inne tory myślenia o rozwiązaniach IT zarówno po stronie dostawców, jaki i użytkowników. Wsparcie społeczności W przypadku wielu wdrożeń i projektów tworzenia rozwiązań dedykowanych ważnym czynnikiem sukcesu jest możliwość współpracy twórców oprogramowania z jego użytkownikami. Rola klienta nie powinna sprowadza się wyłącznie do złożenia zamówienia. Ważne jest środowisko tworzenia i budowania aplikacji, dobre IDE, wsparcie do debugowania, wsparcie do wykonywania testów jednostkowych, narzędzia SCM (Software configuration management). Ważna jest też społeczność otoczenie zgromadzona wokół danej technologii. Na nie składają się firmy i ludzie, którzy dostarczają bibliotek, dzielą się doświadczeniami, a nawet aplikacjami wykorzystującymi technologię. Umiejętność korzystania z tego rodzaju społeczności ułatwia tworzenie nowych rozwiązań. Nieświadomi sobie szkodzą Postęp technologii jest wyzwaniem także dla samych firm. Nieświadomość postępu doprowadza czasem do sytuacji, w których organizacja zostaje ze starą technologią, co w konsekwencji powoduje problemy przy dalszym rozwoju systemu czy aktualizacji. (np. poprzez uniemożliwienie migracji do nowej wersji systemu operacyjnego). Tacy maruderzy technologiczni narażają się na duże trudności w funkcjonowaniu przedsiębiorstwa, co niemal zawsze skutkuje wysokimi i nieprzewidzianymi kosztami. Dariusz Dudek Główny Specjalista IT, Pentacomp Systemy Informatyczne S.A., 11

12 Centrum danych budowa czy kolokacja? Rosnące potrzeby IT, digitalizacja kolejnych dziedzin życia, wymagające sprzętowo aplikacje, czy wreszcie ekspansja i nowe obszary działalności firm, stawiają managerom IT wyzwanie zapewnienia przestrzeni dla rozrastających się środowisk IT. Decyzje w tym obszarze poparte są najczęściej szeregiem analiz biznesowych, ale mogą mieć także podłoże w przyzwyczajeniach. Jedno z nich podpowiada nam, że wykonanie czegoś samodzielnie będzie tańsze. Drugie, że jeśli coś jest naszą własnością, to mamy nad tym większą kontrolę, a więc mamy większe poczucie bezpieczeństwa. Czy rzeczywiście tak jest? Co powinniśmy rozważyć podejmując decyzję dotyczącą budowy własnego centrum danych? Kwestia skali, czyli jakiego centrum danych potrzebuję? Budowa własnego centrum danych to jedna z najważniejszych, podejmowanych na lata decyzji dotyczących infrastruktury przedsiębiorstwa. Aby inwestycja nie odpowiadała tylko na bieżące potrzeby konieczne jest oszacowanie niezbędnej powierzchni w określonym czasie. Nie może to być jednak inwentaryzacja obecnego stanu serwerów i prosta ekstrapolacja, ale bardziej złożone prognozowanie przyrostu zasobów serwerowych. To także okazja do przeprowadzenia konsolidacji istniejących, często rozproszonych zasobów, określenia poziomu wirtualizacji czy migracji do nowych rozwiązań np. w modelu as a Service. Dopiero taka prognoza, a wręcz strategia rozwoju, pozwoli określić potrzeby firmy w dłuższej perspektywie oraz konieczną nadmiarowość powierzchni centrum danych, która będzie zajmowana w miarę pojawiających się w przyszłości potrzeb (warto pamiętać, że utrzymanie niewykorzystanej powierzchni centrum danych to także bardzo istotny koszt). Własne centrum danych to inwestycja na lata, ale obecnie nie mówimy już o perspektywie kilkunastoletniej. Wystarczy odwiedzić serwerownię wybudowaną np. w 2000 roku by zobaczyć jak szybko następuje funkcjonalne starzenie się takich obiektów. Nowe, efektywniejsze technologie, zużywanie się istniejącej infrastruktury, niesatysfakcjonująca efektywność energetyczna czy niezależny od inwestora brak możliwości zwiększania mocy centrum danych dla coraz bardziej energochłonnych urządzeń, znacznie skraca cykl życia centrum danych. Dlatego już na tym etapie warto rozważyć istniejące alternatywy dla budowy własnej infrastruktury. Gdzie mogę umieścić sprzęt? Budowa własnego centrum danych angażuje zwykle kilka działów przedsiębiorstwa - oprócz IT, także administrację czy finanse. Najczęściej wymaga stworzenia interdyscyplinarnego zespołu projektowego, nawet jeżeli inwestycja realizowana jest przez wyspecjalizowanego dostawcę tego typu rozwiązań. Decydując się na budowę własnego centrum danych należy pozytywnie odpowiedzieć na następujące pytania: Czy obecna siedziba pozwala na budowę data center? Czy dysponujemy powierzchnią nadającą się do zaadoptowania na potrzeby tego typu obiektu? Czy kwestie własnościowe i prawne pozwalają na adaptację części budynku na ten cel? Czy jest to docelowa (nietymczasowa) siedziba firmy? Konstrukcja i lokalizacja budynku ważna jest nośność stropów, możliwość przeprowadzenia prac budowlanych, a także czy budynek znajduje się w miejscu nienarażonym na zdarzenia losowe (np. powodzie). Czy można zapewnić wystarczające i redundantne zasilanie z 2 niezależnych źródeł? Czy można umieścić w siedzibie generator prądotwórczy? 12

13 Centrum danych - budowa czy kolokacja? Czy można zapewnić odpowiednie chłodzenie? Czy budynek pozwala na instalację systemu chłodzenia (np. montaż chillerów, przewodów itp.) Jaki jest system wykrywania, sygnalizacji i gaszenia pożaru w budynku? Czy jest możliwość montażu systemu gaszenia gazem obojętnym? Jakie jest bezpieczeństwo fizyczne budynku? Czy budynek chroniony jest w trybie 24/7/365, ma system monitoringu, powiadomienia o nieuprawnionym dostępie? Czy jest możliwy dostęp do budynku przez 24 godziny na dobę i w dni wolne od pracy w razie planowanych i nieplanowanych prac? Decydując się na usługę kolokacji na tego typu pytania nie musimy odpowiadać, bowiem spełnienie wszystkich powyższych wymagań spada na dostawcę. Dynamiczny rozwój outsourcingu tego obszaru i rosnąca konkurencja na rynku powoduje, że coraz łatwiej o usługi kolokacji optymalnie dopasowane do specyfiki danego środowiska IT, oferowane w dogodnym miejscu, o poziomie bezpieczeństwa i dostępności zwykle trudno osiągalnych we własnej lokalizacji. Komercyjne centra danych oferują wszelkie możliwe warianty powierzchni kolokacyjnej - od pojedynczych U, szaf rack, poprzez odseparowane, specjalnie chronione boxy, po indywidualne pomieszczenia z dedykowana infrastrukturą, siecią, systemem bezpieczeństwa w modelu DCaaS (Data Center as a Service) czy też powierzchnię o wysokiej gęstości mocy. Jak szybko można uruchomić centrum danych? Czas uruchomienia nowej serwerowni szacowany jest na 8-24 miesiące, z czego znaczną część pochłaniają kwestie formalne, w tym pozwolenia, ekspertyzy, projekty architektoniczne, wybór i umowy z dostawcami. Również w tym przypadku wariant kolokacyjny ma zdecydowaną przewagę powierzchnia kolokacyjna jest bowiem dostępna niemalże z dnia na dzień, po podpisaniu umowy. Wraz z rozwojem firmy można też dowolnie zwiększyć zajmowaną powierzchnię, przepływności ł ączy czy utylizowaną moc elektryczną. Ile to kosztuje? Na kluczowe koszty w wariancie budowy własnego centrum danych składają się: dostosowanie pomieszczeń, infrastruktura, przyłącza sieciowe, energetyczne, czy też nieprzewidziane we wstępnych analizach wydatki, jak np. budowa przyłącza światłowodowego czy rozbudowa stacji transformatorowej, która odbywa się na koszt odbiorcy. Koszt budowy 1m 2 centrum danych o standardzie Tier3 i powierzchni kilkuset metrów kwadratowych w istniejącym już pomieszczeniu oscyluje w granicach kilkunastu tysięcy złotych. Im mniejsza powierzchnia, tym średni koszt metra staje się wyższy. Koszty Capex to oczywiście nie wszystko. Niebagatelne znaczenie mają koszty związane z zarządzaniem i utrzymaniem centrum danych. Najistotniejsze są opłaty za utylizowaną moc, łącza (connectivity), koszty związane z personelem technicznym dedykowanym do utrzymania DC, umowy serwisowe, czy wymiana baterii UPS co kilka lat. W przypadku korzystania z komercyjnego data center koszty ograniczają się do stałych i przewidywalnych pozycji: jednorazowa opłata aktywacyjna oraz miesięczne opłaty za powierzchnię kolokacyjną, łącza, zużycie energii i ewentualne usługi dodatkowe np. zdalnej pomocy. Obecnie dostawcy oferują elastyczne formy opłat, np. ryczałtowe bądź licznikowe rozliczanie energii, za rzeczywistą utylizację pasma, czy szereg usług dodatkowych zawartych w cenie powierzchni. Innym argumentem przemawiającym na korzyść wariantu kolokacyjnego jest także obserwowany na rynku spadek cen. Edyta Marchaluk Product Manager, GTS Poland Decyzja budować czy kolokować wymaga przeanalizowania wielu czynników, w tym rozważenia, czy budowa i utrzymywanie własnego centrum danych przyniesie strategiczne korzyści firmie, jakie są najważniejsze cele biznesowe i najlepsze sposoby wykorzystania wewnętrznych zasobów firmy. Zatem czy warto podejmować wysiłek budowania własnego centrum danych? Korzyści kolokacji vs budowa własnego centrum danych Własne centrum danych Kolokacja w komercyjnym data center Całkowita kontrola nad data center: dostępem, warunkami środowiskowymi, sposobem wykorzystania Bliska odległość od data center, stały, nieograniczony dostęp Redundancja i niezawodność trudno osiągalna w serwerowniach budowanych in house Przewidywalne, stałe opłaty za rzeczywiste wykorzystanie zasobów Przesunięcie kosztów z CapEx do OpEx Brak kosztów utrzymania, serwisu, personelu Łatwy i szybki dostęp do powierzchni o wysokich parametrach środowiskowych i zasilania Skalowalność - elastyczne powiększenie zajmowanej powierzchni wraz z rozwojem środowiska IT Wiedza doświadczonych, wyspecjalizowanych w data center specjalistów Wsparcie techniczne Odpowiedzialność za utrzymanie infrastruktury i optymalnych warunków spoczywa na dostawcy 13

14 Zarządzanie infrastrukturą centrum danych wypełnia lukę pomiędzy IT a obiektami W dobie oszczędności i kryzysu gospodarczego menedżerowie centrów danych znajdują się pod ogromną presją podnoszenia efektywności działalności i zwiększenia wykorzystania dostępnych zasobów. Są zmuszeni do podwyższania wydajności i redukcji kosztów przy jednoczesnym zachowaniu dostępności. Wodpowiedzi na to zapotrzebowanie departamenty IT wdrażają technologię wirtualizacji, środowiska cloud computingu i ujednoliconego przetwarzania dla systemów logicznych. Takie działania są efektywne dla IT, ale jednocześnie tworzą nowe zależności w systemach fizycznych zarządzanych przez departamenty obiektów i skutkują zmianami w zarządzaniu zasilaniem, chłodzeniem i przestrzenią fizyczną. Czynniki te w połączeniu z rosnącymi kosztami energii elektrycznej, wymaganiami dotyczącymi zgodności z przepisami i umowami SLA powodują, że menedżerowie centrum danych są zmuszeni zajmować się nie tylko działaniem sprzętu IT, ale także kompleksową obsługą całości infrastruktury centrum danych jako elementów ekosystemu. Infrastruktura centrum danych to coś więcej niż tradycyjny sprzęt i sieci IT: obejmuje również systemy zasilania, klimatyzacji, zasilacze UPS i generatory oraz powiązane urządzenia przełączające. Komponenty te składają się na precyzyjnie dostrojony ekosystem, a jakakolwiek zmiana jednego składnika może mieć szkodliwy lub nieprzewidywalny wpływ na pozostałe elementy. Infrastruktura centrum danych (zasilanie, chłodzenie i przestrzeń fizyczna) oraz infrastruktura teleinformatyczna są zazwyczaj zarządzane niezależnie przez oddzielne zespoły. Każda warstwa jest zarządzana w sposób konserwatywny. Systemy zasilania i chłodzenia są zwymiarowane w sposób umożliwiający zapewnienie odpowiedniej wydajności sprzętu IT, a systemy IT wdrażane w sposób gwarantujący ich działanie w ramach limitów zasilania i chłodzenia, co w rzeczywistości powoduje konieczność zwiększenia bufora operacyjnego zaprojektowanego wcześniej dla systemu. Takie podejście sprawia, że zespoły obiektów zarządzają dostępnością centrum danych w sposób skuteczny, ale mało efektywny. W dobie technologii wirtualizacji, cloud computingu i ujednoliconego przetwarzania takie podejście staje się mało praktyczne. Menedżerowie centrum danych muszą przyjąć bardziej kompleksową zintegrowaną koncepcję nie tylko dla sprawnego zarządzania efektywnością i kosztami, ale także dla zagwarantowania wysokiej elastyczności, realizacji umów o poziomie usług i możliwości świadczenia usług IT. Operatorzy centrum danych potrzebują rozwiązania zarządzania infrastrukturą spójnego dla systemów IT i obiektów. Powinno ono być skalowalne, bezpieczne, działające w czasie rzeczywistym, modułowe, łatwe we wdrożeniu oraz kompatybilne z funkcjonującymi systemami zarządzania IT i obiektami, a także oferować możliwość zdalnego zarządzania. Poszukując rozwiązań automatyzacji operacji muszą oni wybrać wszechstronną platformę, która umożliwi zbudowanie podstaw i sprawne rozwiązanie pilnych problemów przy jednoczesnym zapewnieniu skalowalności pozwalającej reagować na przyszłe potrzeby. A dla zapewnienia sprawnego wdrożenia muszą także dokumentować procesy i dostosować strukturę organizacyjną. Podstawą trafnych, świadomych decyzji jest kompleksowy wgląd w procesy przebiegające w centrum danych z perspektywy infrastruktury centrum danych i infrastruktury IT. Konieczne jest uwzględnienie statycznego charakteru dotychczasowego zarządzania centrum danych całkowicie odmiennego od dynamiki nowych technologii. Brak danych w czasie rzeczywistym, to jest informacji o IT i obiektach, gromadzonych niemal natychmiastowo za pośrednictwem natywnego systemu komunikacji pomiędzy urządzeniami, nie jest możliwe przyjęcie wiarygodnych założeń i podejmowanie trafnych decyzji dotyczących kondycji centrum danych. Brak funkcji w czasie rzeczywistym wpływa negatywnie na możliwości zarządzania problemem stwarzając ryzyko przeoczenia krytycznych zdarzeń i pojawienia się istotnych zagrożeń dla infrastruktury. Ponadto obsługa w czasie rzeczywistym staje się niezbędna dla bardziej precyzyjnego dostosowania zasobów fizycznych do obciążeń IT i uzyskania wyższej wydajności. IT a obiekty: luka uniemożliwiająca optymalizację Na przestrzeni ostatnich kilkunastu lat działy IT i administracji obiektów zostały zmuszone do przedefiniowania dotychczasowego statycznego podejścia do zasobów, by sprostać środowisku szybko zmieniających się potrzeb biznesowych. Podobnie jak departamenty IT podjęły wyzwanie wdrożenia dostosowanych usług biznesowych: standaryzowanych, mierzalnych, elastycznych i adaptowalnych - tak samo zespoły zarządzania obiektem muszą zapewnić działom IT zasoby na żądanie (przestrzeń fizyczną, zasilanie, ogrzewanie, wentylację i klimatyzację), które umożliwią świadczenie takich dynamicznych usług biznesowych. Przy rosnącej zależności pomiędzy sferą IT i obiektem, kwestią najważniejszą staje się wymiana informacji o zdarzeniach historycznych 14

15 Zarządzanie infrastrukturą i w czasie rzeczywistym, która umożliwi dynamiczne dostosowywanie sposobu wykorzystywania zasobów. Zarządca obiektu polegając na podstawowej prognozie mocy może w pewnej mierze przewidzieć zapotrzebowanie IT na zasoby. Jednak wyłącznie w czasie rzeczywistym można dostrzec dynamiczny charakter reakcji centrum danych na potrzeby. Trudność polega na tym, że menedżerowie IT nie są informowani na bieżąco przez menedżerów budynków o wzajemnie powiązanych obciążeniach, czyli o codziennych zmianach kosztów zasobów i mediów, a menedżerowie obiektu o umowach o poziomie świadczenia usług (SLA), do których przestrzegania podczas zaspokajania potrzeb firmy są zobowiązani menedżerowie IT. Nawiązanie ściślejszej współpracy pozwala zarządcom obiektu zrozumieć drobne niuanse planowania wydajności oraz uczestniczyć w identyfikacji zalet i wad wykorzystywania zasobów w obrębie centrum danych. Ponadto, lepsze relacje zapewnią menedżerom centrum danych informacje o kosztach zasobów centrum danych i ułatwią podejmowanie decyzji dotyczących doboru aktywów, planowania priorytetów i czynności off-line. W następstwie lepszego zrozumienia tych wzajemnych oddziaływań oraz misji biznesowej oczywista staje się kwestia potrzeby wdrożenia rozwiązania do Zarządzania Infrastrukturą Centrum Danych (Data Center Infrastructure Management DCIM). Personel działu IT i obiektu musi przyjąć bardziej dynamiczne podejście do zarządzania wydajnością, które wymaga dostępu przez obie strony do bieżących danych operacyjnych dotyczących mocy obliczeniowej, zasilania, chłodzenia i przestrzeni fizycznej. Obecnie brakuje zintegrowanych danych niezbędnych do zarządzania wydajnością. Z tego powodu większość departamentów IT wybiera konserwatywny, minimalizujący ryzyko sposób zarządzania. Jest to konieczna strategia i chociaż zarządzanie efektywnością ma dziś wyższy priorytet niż w przeszłości to jednak zajmuje ono drugie miejsce po dostępności. Koszt pojedynczego przestoju może przewyższać oszczędności uzyskane dzięki wyższej efektywności. Sytuacja, w której efektywność jest realizowana kosztem niezawodności stwarza zagrożenie dla zdolności centrum danych do obsługi firmy i może zmusić osoby zarządzające nim do szukania pracy gdzie indziej. Połączenie: Zarządzanie Infrastrukturą Centrum Danych Jeżeli rozwój centrum danych ma zmierzać w kierunku zapewniania wyższej efektywności, wydajności i dostępności, to konieczne jest zmniejszenie przepaści pomiędzy warstwą IT i warstwą infrastruktury fizycznej centrum danych i stworzenie możliwości zarządzania nimi jako jednym systemem. Najlepszym sposobem osiągnięcia owocnej integracji infrastruktury IT i obiektu jest wdrożenie efektywnego Zarządzania Infrastrukturą Centrum Danych (DCIM). Krytycznym elementem staje się szczegółowy monitoring i pomiar w czasie rzeczywistym osiągów centrum danych, wykorzystania i zużycia energii elektrycznej. Pozwala on menedżerom centrum danych podejmować trafne decyzje, odpowiednio planować, a przez to optymalizować operacje. DCIM oznacza możliwość wszechstronnego zarządzania infrastrukturą centrum danych poprzez optymalizację zasobów, efektywności i dostępności. DCIM obejmuje zarządzanie warstwą fizyczną infrastruktury centrum danych, warstwą infrastruktury IT oraz luką pomiędzy nimi. Infrastruktura IT w pewnym sensie obejmuje platformę wirtualizacji, ponieważ dynamicznie przełączające się serwery wirtualne oddziałują na serwery fizyczne, na których są one zainstalowane. Dopiero niedawno pojawiły się na rynku w pełni zintegrowane kompleksowe rozwiązania DCIM. Uniwersalna koncepcja DCIM daje nowe spojrzenie na relacje pomiędzy obiektami a komponentami infrastruktury IT i umożliwia menedżerom centrum danych wyższą optymalizację wykorzystania zasobów centrum danych. Prawidłowe wdrożenie strategii DCIM wymaga doboru optymalnego pakietu sprzętu, oprogramowania i usług, który umożliwi menedżerom centrum danych zapełnić lukę w krytycznej infrastrukturze. Przed wdrożeniem rozwiązania DCIM menedżerowie centrum danych muszą odpowiedzieć sobie na wiele pytań: Które aktywa mają krytyczne znaczenie dla infrastruktury mojego centrum danych i jakie są zależności pomiędzy nimi? Repozytorium zasobów umożliwia menedżerom centrum danych realny wgląd w naj- 15

16 cenniejsze zasoby, a także kontekstowe spojrzenie na nie w perspektywie przyszłego rozwoju centrum danych. Taka wybiegająca w przyszłość analiza daje biznesowy wgląd w krytyczne aktywa i gwarantuje osiągnięcie wyższego współczynnika zwrotu inwestycji (ROI) na aktywach. Pozwala także uwolnić i przeznaczyć środki na inne istotne priorytety kluczowe dla menedżerów centrum danych. Czy poproszony przez przełożonych będę w stanie szybko sporządzić obszerny raport monitorowania i analizy wszystkich aktywów centrum danych? Czy raport ten zidentyfikuje wąskie gardła centrum danych? Efektywne rozwiązanie DCIM to produkt, który w czasie rzeczywistym będzie monitorować wszystkie parametry przestrzeni fizycznej, zasilania i chłodzenia środowiska centrum danych. Korzystanie z modelowych i chwilowych danych realnych zbieranych w dużych odstępach czasu może prowadzić do przeoczeń i uniemożliwiać szybkie rozwiązywanie problemów oraz przewidywanie nieuchronnych zdarzeń. Rozwiązanie DCIM powinno oferować pulpity nawigacyjne oraz raportowanie w czasie rzeczywistym umożliwiające menedżerom centrum danych podejmowanie proaktywnych działań w celu zapobiegania awarii operacyjnej mającej swoje źródło w infrastrukturze. Raporty na temat infrastruktury centrum danych powinny być dostępne na żądanie i sporządzane w czasie rzeczywistym, co pozwoli utrzymać dostępność i obniżać koszty. Czy moje centrum danych jest w stanie elastycznie obsługiwać codzienne obciążenia i jednocześnie reagować na bieżące wymagania stawiane mojej firmie? Rozwiązanie DCIM powinno obejmować przepływ prac w procesie i zapewniać: Scenariusze rozwoju - możliwość modelowania zmian przed ich wdrożeniem; Wbudowane procesy zawierające kroki, których ukończenie jest konieczne przed zatwierdzeniem działania; Wskaźniki dla umów o poziom świadczenia usług (SLA), będące standardowymi lub indywidualnymi miarami sukcesu; Raportowanie informacji o niedostatecznie wykorzystywanej przestrzeni fizycznej, mocy zasilania i chłodzenia. Funkcja ta powinna rekomendować optymalne rozmieszczenie urządzeń na podstawie ich unikatowych wymagań oraz informować o bieżącym obciążeniu i wydajności infrastruktury. Czy oprogramowanie DCIM oferuje analizę tendencji i wiedzę niezbędną mojemu zespołowi do opracowania całościowego planu zarządzania wydajnością? Rozwiązania DCIM, dla zapewnienia kontroli bieżącego i przyszłego wykorzystania zasobów centrum danych, powinny zapewniać menedżerom wgląd w: Potoki rzutowania - statusy projektów na różnym etapie zatwierdzania oraz informacje o ich wpływie na infrastrukturę; Tendencje bieżącego i planowanego wykorzystania zasobów (na podstawie danych historycznych). Menedżerowie centrum danych powinni na przykład być w stanie, na podstawie tendencji wykorzystania, określić moment, kiedy moc i chłodzenie staną się niewystarczające. Jakie narzędzia internetowe raportowania dla kierownictwa i planistyczne zawiera rozwiązanie? Oprogramowanie DCIM powinno standardowo zawierać konfigurowalne internetowe pulpity nawigacyjne i narzędzia analityczne. Automatyzacja gromadzenia informacji o operacjach i raportowania za pomocą uniwersalnego internetowego pulpitu nawigacyjnego umożliwia opracowywanie informacji zarządczych, które stają się następnie jedynym źródłem wiedzy dla DCIM i planowania. Czy rozwiązanie DCIM dostosowuje się do usług IT i biznesowych? Dostosowanie usług IT w sposób gwarantujący realizację celów i potrzeb biznesowych ma nadrzędne znaczenie. Każde rozwiązanie DCIM musi umożliwiać kierownictwu centrum danych dostosowanie wykorzystania zasobów do strategii Systemów Zarządzania IT (ITSM), metodyki ITIL oraz strategii Zarządzania Usługą Biznesową (BSM). Przyszłość DCIM Obecnie menedżerowie centrum danych znajdują się pod presją redukcji kosztów i podnoszenia poziomu usług. Na rynku dostępnych jest wiele technologii wspomagających osiągnięcie tego celu: wirtualizacja, wysokoefektywne źródła zasilania serwerów oraz nowe technologie zasilania i chłodzenia. Technologie te, wraz z opracowanymi w ostatnich latach dobrymi praktykami, mogą przyczynić się do redukcji poboru energii, ale nie umożliwiają wdrożenia prawdziwej optymalizacji. Optymalizacja centrum danych w kategoriach efektywności, wydajności i dostępności wymaga znalezienia punktu pełnego wykorzystania zasobów bez zwiększania ryzyka awarii. W ostatnich kilku latach wiele czynników złożyło się na zwrot rynku w kierunku rozwiązań DCIM. Kluczowymi elementami prawidłowego funkcjonowania IT stało się zużycie energii i wykorzystanie przestrzeni. Narzędzia DCIM rozwijają się szybko i w najbliższych latach staną się kluczowym elementem arsenału operatorów centrum danych. Dostarczać będą cennych danych niezbędnych dla raportowania i uzyskiwania wyższych oszczędności energetycznych, identyfikowania problematycznych punktów infrastruktury i podnoszenia efektywności planowania wydajności. Według instytutu Gartner ponad 50% operatorów centrum danych wdroży narzędzia DCIM w 2013 roku 1. Obecnie nadszedł czas, aby firmy przyjęły całościową koncepcję zarządzania infrastrukturą centrum danych w czasie rzeczywistym i połączyły w sposób kompleksowy zarządzanie IT i obiektami. 1 Raport Gartner, Net IT Out: DCIM New Tools to Monitor, Manage and Control Your Data Center, IT Jay Pultz, Infrastructure, Operations & Management Summit, 5-7 czerwca, 2012 Orlando, Floryda Piotr Kowalski, Dyrektor Działu Inżynierskiego w Emerson Network Power 16

17 Gdy gra przekracza granice ekranu Zasiadając przed swoją ukochaną konsolą po ciężkim i wyczerpującym dniu nauki, czy pracy liczymy na chwilę relaksu po trudach dnia codziennego.efekt takiego odstresowywania się jest o tyle lepszy, o ile dany tytuł spełnia swój główny cel, którym jest dostarczenie szeroko pojętej rozrywki, czy to za sprawą hipnotyzującej zmysły grafiki, urzekającej ścieżki dźwiękowej, zapierającej dech w piersiach fabuły, czy pompującej do krwi adrenalinę akcji. Nie możemy jednak zapominać o równie istotnej, co wręcz podstawowej roli elektronicznej rozrywki, a więc udostępnieniu nam sposobu, do chociaż chwilowej ucieczki od rzeczywistości i zapomnieniu o jej problemach. To główny powód, dla którego (oprócz aspektów technicznych) w pierwszych grach królowały wszelakiej maści światy science-fiction i fantasy. Wraz z upływem lat można zauważyć diametralną zmianę tej tendencji, do tego stopnia, iż ogromna część gier osadza gracza w faktycznie istniejących lokalizacjach, czy miastach, a samo ich przedstawianie w coraz większym stopniu nabiera cechy fotorealizmu. Podobnie sprawa ma się z wydarzeniami przedstawianymi na ekranach naszych monitorów, dzięki czemu każdy z nas może stać się członkiem oddziału desantowego na Normandię, zatańczyć na scenie Thriller a z samym Michaelem, przytrzeć lakier Hamiltonowi na torze w Monaco, czy nawet rzucić mokasynem w prezydenta USA. Jak dotąd, pomimo ciągłych prób samych deweloperów, aby wpłynąć na nasz realny byt za pośrednictwem gier, jak chociażby standardowy już proceder umieszczania reklam firm w świecie gry, granica pomiędzy prawdziwym życiem, a jego wirtualnym odpowiednikiem zawsze zawierała się w brzegach ekranu i przycisku włączania konsoli. Na samą przyjemność szarpania w ulubione tytuły składa się pewien wachlarz przyzwyczajeń i zachowań, który poniekąd wynika z umowności wykreowanego świata. Każdy gracz doskonale zna i wręcz ubóstwia zbieranie punktów doświadczeń, żyłowanie i poprawienie wyników swoich oraz znajomych, nabijanie kolejnych leveli, wypełnianie questów, czy zdobywanie osiągnięć i trofeów. To właśnie te czynniki tak bardzo nas nakręcają i nie pozwalają odejść od konsoli, niejednokrotnie sprawiając, że dzięki syndromowi jeszcze jednej godziny doświadczymy tak zapierającego dech w piersiach widoku, jakim jest wschód słońca za oknem naszego pokoju i totalny zgon dwie godziny później w szkole, lub pracy. Skoro te, tak doskonale nam znane i wyuczone growe czynności potrafią dawać nam tyle frajdy, jednocześnie zmuszając nas do takich poświęceń, to dlaczego nie można wykorzystać tego zjawiska w normalnym, zupełnie niewirtualnym życiu? Tak się składa, że można. Gamifikacyjny biznes Nie od dziś wiadomo, że pieniądz rządzi światem. Jeżeli ktoś się z tym nie zgadza, to znaczy, że nigdy nie wziął pożyczki z banku, lub jeszcze nie zaczął jej spłacać. Menadżerowie oraz spece od marketingu wielkich, zamożnych i niestety, generalnie chciwych korporacji tego świata, prężą się jak pawian na stronie, aby znaleźć nowe 17

18 Gdy gra przekracza granice ekranu sposoby wypchania swoich i tak już rozdętych do granic możliwości portfeli. Tak więc, ktoś zauważył wyżej wspomniany fenomen, dokonał skrupulatnych kalkulacji i wywnioskował, że na grze w życie można naprawdę nieźle zarobić. Czym więc jest grywalizacja, lub gramifikacja, jeżeli ktoś lubi synonimy? Tak naprawdę jest to stosunkowo nowe słowo i odkrycie, które trafiło do biznesowego słownika dopiero w 2010 roku. Generalnie oznacza ono przenoszenie do realnego świata wszystkich tych mechanizmów i zachowań, którymi rządzą się gry wideo, a które my, gracze tak dobrze znamy i kochamy. To zupełna odwrotność tego, co do tej pory znaliśmy to nie gra naśladuje życie, to życie naśladuje grę. Samo zjawisko dość szczodrze czerpie ze znanych już programów lojalnościowych, jednakże to tylko preludium do rozwiązań i pomysłów, jakie stworzy ludzka kreatywność, napędzana chęcią zysku. Samo nabijanie punktów za korzystanie z usług konkretnego producenta i idące za tym różnorakie wynagrodzenie, to relatywnie stare i tak naprawdę tylko podświadomie wykorzystujące schemat grywalizacji rozwiązanie. Zjawisko zacierania granicy między życiem a grą ma miejsce już od jakiegoś czasu, subtelnie, acz konsekwentnie rozwijając swoją ideę. Przypomnijmy sobie popularną matę do ćwiczeń Wii Fit od Nintendo, za sprawą, której tylko gra stawała się profesjonalnym programem treningowym, analogicznym do jego prawdziwego odpowiednika. Nie sposób nie wspomnieć o święcącej swego czasu tryumfy serii Guitar Hero od giganta gier muzycznych Harmonix. Dzięki kontrolerom imitującym wyglądem i funkcjonalnością prawdziwe instrumenty, mogliśmy, chociaż przez chwilę poczuć się jak prawdziwe gwiazdy rocka. Immersja i zlewanie się codzienności ze światem wirtualnym to jedno, ale każdy gracz doskonale wie, że nic tak nie potrafi zwiększyć zaangażowania w wykonywaniu danej czynności, jak gwarancja otrzymania za nią nagrody, a głównym atutem opisywanego fenomenu jest właśnie możliwość uzyskania gratyfikacji w czysto realnej formie. O potencjale, jaki kryje w sobie grywalizacja świadczyć może fakt, iż w tym roku odbyła się pierwsza, w całości poświęcona jej konferencja Gamification Summit Jak nawozić, żeby się nie nawozić Kolejnym krokiem na drodze do ingerencji w nasze życie, zaraz po wyżej wspomnianych tytułach jest pielenie grządek tych wirtualnych, jak na razie. Niepodważalny hit ostatnich miesięcy, czerpiący garściami z konsolowego Harvest Moon a, przeglądarkowy Farmville bije rekordy popularności, przynosząc jej producentowi, firmie Zynga ogromne dochody. Można mieć swoje zdanie na temat ambitności podobnych produkcji, w których rdzeń rozgrywki Dzięki Chromaroma, nawet zwykła podróż londyńskim metrem może zamienić się w questa rodem z prawdziwqego RPG a. Jeżdżąc ekonomicznie sprawisz, że twoje wirtualne drzewko po prawej zacznie powoli rosnąć. 18

19 Możemy snuć własne teorie spiskowe na temat wołowiny w BigMac ach, wale chyba każdy chciałby spróbować zagrać na takim ekranie. ogranicza się do dojenia łaciatych i nawożenia plantacji kopru, co nie zmienia faktu, że gra stała się światowym fenomenem. Szacuje się, że około 100 milionów osób dziennie (sic!) zasiada przed komputerem, by sprawdzić ilość zniesionych przez jego kury jajek. Gra do tego stopnia ingeruje w nasz plan dnia, że za coś zupełnie normalnego uważa się wstawanie wcześniej rano do pracy, aby tylko zdążyć zasiać kolejne plansze zakupionymi nasionami. Wszędzie tam gdzie jest kosmiczna popularność produktu, pojawiają się coraz to nowsze sposoby zarobienia na nich przez osoby trzecie. Nie inaczej jest w tym przypadku, gdyż już teraz każdy z nas może zakupić specjalny, dedykowany poradnik, jak zostać najlepszym we wsi wirtualnym farmerem. Kolejnym przykładem, który jeszcze lepiej zobrazuje istotę grywalizacji, jest aplikacja Chromaroma, w którą od jakiegoś czasu zagrywają się mieszkańcy Londynu. Korzystając często i gęsto z londyńskiej komunikacji miejskiej i posiadając kartę z nabitym biletem, za każdym razem, gdy zbliżymy ją do kasownika, program rejestruje nasze położenie. W ten sposób możemy wykonywać zlecone nam zadania, poprzez dotarcie w wyznaczone miejsce, za co dostajemy punkty, zdobywając ze znajomymi wyznaczone tereny. Program zachęca do przejścia niektórych odcinków pieszo, oferując powiększenie naszego wyniku o odpowiednią wartość. Podobną, lecz znacznie bardziej rozwiniętą strukturę działania posiada Foursquare, do którego potrzebujemy wyłącznie telefonu komórkowego. Za pomocą wbudowanego w aparat modułu GPS możemy informować znajomych gdzie jesteśmy, sprawdzając jednocześnie najczęściej odwiedzane przez nich lokale. Jeżeli dana miejscówka nie znajduje się na liście aplikacji, można ją tam bardzo łatwo dodać. Często odwiedzając dane kina, knajpy czy bary dostajemy specjalne punkty, możemy też zostać nagrodzeni medalami za wykonywanie zleconych zadań, a nawet uzyskać z tego tytułu profity i zniżki w danych lokalach, co w tym miejscu odsłania marketingowy charakter aplikacji. Jeżeli lubicie pstrykanie fotek, to powinien was zainteresować Appysnap. Zabawa polega na robieniu zdjęć na swoim telefonie, wypełniając podane w zadaniu warunki. Tak, więc na początku musimy uwiecznić naszą prywatną i osobistą facjatę, na co mamy godzinę czasu. Później poziom trudności rośnie, wymagając od nas na przykład odpowiedniej liczby osób w kadrze, czy konkretnej imprezy w tle (znów marketing gdyby ktoś nie zauważył). Najlepsi domorośli paparazzi mają szansę na nagrody rzeczowe. Lubicie porządki domowe? Też pytanie każdy je wręcz kocha i aż płacze z radości, gdy łapie w dłoń ścierę. Jeżeli jednak należycie do tego minimalnego odsetka populacji, która nie może poradzić sobie z psychiczną barierą, blokująca gwałtowny wzrost endorfiny w organizmie w czasie mopowania posadzki, to Chore Wars jest stworzone wprost dla was. Zabawa polega na wykonywaniu tak prozaicznych czynności jak mycie zlewu, szorowanie wanny, czy zaprzyjaźnienie się z WC kaczką, za co rzecz jasna dostajemy punkty, ścigamy się ze znajomymi w rankingach i pretendujemy do tytułu najzacniejszego technika higieny domowej. Punkty wystawiają oczywiście bezstronni sędziowie, w postaci zadowolonych z pracowitości swoich pociech rodziców. Grywalizacyjny trend nie omija także i tych ostatnich, nabierając delikatnego, ekologicznego posmaku. W trosce o nasze środowisko, hybrydowe modele Forda, załączyły do swoich bajeranckich komputerów pokładowych specjalny segment, imitujący rosnące, wirtualne drzewko. Jeżeli będziemy jeździć w sposób oszczędny, walcząc z przemożną chęcią wciskania pedału gazu do samej podłogi, to nasza roślinka zacznie rozkwitać, wizualnie dając nam do zrozumienia, że przyczyniamy się do ochrony środowiska. Wyniki możemy porównywać dla przykładu na 100 km odcinku, co słusznie może przywodzić na myśl słynne masterowanie wyników. W tej pięknej idei jest też i ciemna strona mocy, żerująca na ludzkiej zachłanności, która niweczy pierwotne założenia twórców tego rozwiązania. Zanotowano przypadki, gdy kierowcy przejeżdżali na czerwonym świetle, nie chcąc się zatrzymywać, gdyż ponowne ruszenie z miejsca sprawia, że licznik spalania szybuje pod sufit, psując rekordowy wynik. Na takich fanatycznych ekologów znaleźli sposób Szwedzi. Gdy widzimy znajdujący się w pobliżu fotoradar (załóżmy, że wyjątkowo nie jest to atrapa), to mimowolnie odczuwamy chęć schowania twarzy za kierownicą, a jeszcze lepiej zasłonięcia nią tablicy rejestracyjnej. Projekt Speed Camera Lottery działa na zupełnie odmiennej zasadzie niż znany nam system mandatowy. Radary robią zdjęcia losowym samochodom, które przestrzegały przepisów ruchu drogowego, automatycznie włączając ich do loterii, w której wygrana czerpana jest z puli mandatów zapłaconych przez piratów drogowych. Eksperyment przyniósł efekt, zmniejszając średnią prędkość o ok. 10 kilometrów. Jak już o przemierzaniu odległości mowa, to warto wspomnieć o kolejnym pomyśle promującym tym razem zdrowie, którego autorem jest firma Nike. Jej aplikacja Nike + Tag zachęca nas do biegania, a wszystko, czego potrzebujemy to telefon z GPS i specjalny sensor, który zlicza dokładną odległość, jaką przebiegliśmy, spalone przez nas kalorie, czas, czy średnią prędkość. Swoje wyniki możemy wrzucić do sieci, porównując je z osiągnięciami znajomych. Najsłabszy wynik w grupie zostaje otagowany, co poniekąd zmuszą delikwenta do poprawienia swojego rezultatu. Kolejny gi- Wystarczy smartfon, specjalny sensor i (opcjonalnie, dla chętnych) buty, aby zwykłe, poranne bieganie przerodziło się w rywalizacje z przyjaciółmi o jak najlepsze wyniki. 19

20 Gdy gra przekracza granice ekranu gant naszego świata, tym razem ten mniej dbający o nasze zdrowie, czyli McDonald s wymyślił genialną akcję promocyjną, w której zwycięzca może odebrać nagrodę dosłownie od razu. Zawiesił on w centrum Sztokholmu (Szwedzi prekursorem gamifikacji?) ogromny billboard, na którym każdy może zagrać w partyjkę sędziwego Ponga. Wystarczy, że na swoim smartfonie wejdziesz na odpowiednią stronę internetową, wybierzesz proponowaną nagrodę z menu, a następnie sterując za pomocą telefonu nie zaliczysz zbicia w ciągu pół minuty. Wtedy na naszej komórce ląduje wirtualny kupon, który możemy zrealizować tuż za rogiem. Super 5 Beer Combo, please! Jak doskonale widać na załączonych przykładach potencjał tkwiący w zjawisku grywalizacji jest ogromny, a jego wykorzystanie nieraz wykracza poza granice bezlitosnego marketingu. Wszystko opiera się na sposobie przeszczepienia naszych growych przyzwyczajeń na grunt codziennej egzystencji i wdrożenia ich w zwyczajne obowiązki. Sprzątanie domu, jako sposób do nabijania kolejnych poziomów, już był, a więc osiągnięcie levelu 30, odblokowujące możliwość zmierzenia się z klozetowym bossem za pomocą buławy przepychu nikogo nie powinien już dziwić. A co gdybyśmy dostawali dodatkowe punkty doświadczenia z punktualne pojawianie się w pracy? A może warto powalczyć o specjalny mnożnik punktów, poprzez szybsze wykonanie zadania, lub zrobienie tego w grupie? Bardzo ciekawym pomysłem byłoby wykorzystanie znanego nam z gier określenia combo, oznaczające wykonywanie po sobie pod rząd określonych czynności. Zamiast zaserwować oponentowi Super Combo Finish, moglibyśmy wypić kilka puszek napoju, czy piwa za jednym zamachem. Taki atak umożliwiłby nam dostanie specjalnego bonusu, w postaci +1 do obrażeń. Bonusu z pianką rzecz jasna. Rentowność inwestowania w strategie grywalizacyjne została potwierdzona w badaniach naukowych. Jak donosi Nielsen Online, granie to druga, zaraz po buszowaniu po portalach społecznościowych czynność, jakiej oddają się w Internecie Amerykanie, poświęcając jej miesięcznie kolosalną liczbę 407 mln godzin. Według innych badań obecna, szacunkowa wartość rynku grywalizacji wynosi 100 mln dolarów, a w przeciągu najbliższych 4 lat, wartość ta ma wzrosnąć do 1,6 mld zielonych, zaś sama liczba tego typu aplikacji, oferowana przez koncerny ma podskoczyć o ok. 70%. Ponadto według firmy M2 Research, ponad 45% firm przyglądających się metodom gamifikacyjnym za cel stawia sobie zwiększenie zaangażowania użytkowników produktu, 1/3 pragnie umocnić lojalność klienta wobec marki, a co piąta chce podnieść jej świadomość na rynku. Wbrew pozorom zalety opisywanego trendu niekoniecznie muszą się ograniczać wyłącznie do celów komercyjnych, Przyszłość, w której życie stanie się jedną wielką grą, jest na szczęście naprawdę odległa, chociaż jesteśmy na najlepszej ku temu drodze. mając ogromne pole do popisu chociażby w samym systemie edukacji. Niejaki Lee Sheldon, wykładowca na Uniwersytecie Indiana wpadł na pomysł podzielenia swoich studentów na gildie, podobne do tych z World of Warcraft. Uczniowie zamiast standardowych ocen otrzymywali punkty XP, których odpowiednia ilość wymagana była do zaliczenia semestru. No cóż, nasze punkty ECTS od dawna wykorzystują ten patent, ale jakoś mniej przyjemnie się kojarzą. Swoje 3 grosze do tematu dorzuciła również Annath Pai, kolejna nauczycielka w amerykańskiej szkole. Eksperyment polegał na stosowaniu list najlepszych wyników oraz przydzielaniu uczniom odpowiednich wyzwań, co przyczyniło się do podniesienia średniej ocen w klasie. Mało tego, system oceniania tak zaangażował małych podopiecznych, że zaczęli się oni uczyć nawet zagadnień z kolejnych lat. Jeżeli dodalibyśmy do tego perki zwalniające z pisania kartkówek, czy dające niezniszczalność w czasie odpowiedzi przy tablicy, to mamy sposób na zwiększenie wyników maturalnych o jakieś 50%. Gracz w klatce Skinnera Rozwodząc się nad zaletami grywalizacji, nie możemy zapomnieć o niebezpieczeństwie, jakie niesie ona ze sobą, co niestety najczęściej wynika z ludzkiej chciwości i niepohamowanej chęci zysku. Jak dla mnie, już teraz lekkim przegięciem jest brazylijska aplikacja na Facebooka o wdzięcznej nazwie Get Closer, nagradzająca nas punktami za jak najdłuższe przebywanie w związku z daną osobą. Pomimo wyraźnej kontrowersyjności tegoż programu, już teraz bawi się nim ok. 22 tys. osób, a liczba ta raczej będzie się powiększać. Pomimo wyraźnych, pozytywnych możliwości, jakie ma szansę przynieść ze sobą grywalizacja, czy to w postaci pomocy ochrony środowiska, zwiększenia efektywności pracy, czy chociażby na gruncie edukacji, zjawisko to posiada także grupę zagorzałych przeciwników, wywodzących się głównie ze świata nauki. Najlepszym przykładem skrajnie odmiennej opinii jest profesor Ian Bogost, zajmujący się mediami interaktywnymi na uniwersytecie technicznym w stanie Georgia. Uważa on, że grywalizacja jest świetnym sposobem łatwego zwiększenia zysków kosztem samych gier, co już nie podoba się ich twórcom. Nadmierne wykorzystywanie pozytywnie kojarzących się mechanizmów z tychże produkcji, może doprowadzić do zmęczenia materiału, pewnego przesycenia danych czynników, co przyczyni się w końcu do negatywnego postrzegania samej elektronicznej rozrywki. Bogost zaznacza, że tak naprawdę głównym celem grywalizacji, jest eksploatacja popularnych haseł do momentu, aż nasze kieszenie zostaną opróżnione, a ona sama zostanie zepchana na boczny tor przez nowy, popularny trend. Z tego powodu proponuje, aby zjawisko to nazwać raczej eksploatyzacją, co uwydatni jego prawdziwe zamiary. W międzyczasie samo, zbyt intensywne wykorzystanie gamifikacji może stworzyć wokół nas tzw. klatkę Skinnera. Jest to urządzenie w formie skrzynki, w którym B. Skinner badał procesy warunkowania. Umieszczone w niej zwierzę, wciskając przycisk otrzymywało nagrodę, najczęściej w formie pożywienia. Obawy, że podobne skłonności mogą przejawiać się w zachowaniu ludzi są jak najbardziej słuszne. Już teraz posiadając kartę lojalnościową danej myjni, jesteśmy w stanie jechać na drugi koniec miasta, omijając te bliższe i tańsze, tylko po to by zyskać kolejne punkty. Mechanizm ten faktycznie może uczynić z nas jeszcze wydajniejsze maszynki do wydawania pieniędzy i zmusić do bezmyślnego wciskania przycisku, tylko po to by z otworu wyskoczył nam kolejny do kolekcji reklamowy długopis. Oczywiście ta czarna i pesymistyczna wizja świata, wydaje się być mało prawdopodobna, a jeżeli już to dość odległa. Sam temat grywalizacji to istna góra lodowa, której czubek został jedynie nieznacznie ukazany w powyższym artykule. Można by snuć nieskończoną ilość pomysłów i planów, nad jego wykorzystaniem w niedalekiej przyszłości, jednakże już nie mam na to czasu. Muszę lecieć piąty raz tego dnia wyszorować zęby, gdyż brakuje mi jedynie 200 pkt. do rangi nieustraszonego obrońcy szkliwa. Adrian Adio ZAJąc Jest studentem Informatyki na Wydziale Fizyki, Astronomii i Informatyki Stosowanej Uniwersytetu Jagiellońskiego. Oprócz gier komputerowych, pasjonuje się również podróżami i dziennikarstwem. Jest redaktorem SAGE, organizacji Gamedev Students Association. Kontakt z autorem: adrian.zajac@uj.edu.pl 20