Software Developers Journal 2015 01.pdf

Z bloga architekta systemowego Krzysztof „Kris” Olszewski „Verto” to słowo, które od dłuższego już czasu sprawia, że kilkanaście osób z jednego z zespołów w zielonogórskiej firmie Streamsoft budzi się wcześniej niż zazwyczaj. Budzi się, nie tylko za sprawą nadgorliwego budzika czy nieodpartej chęci odbycia porannej „przebieżki”. Responsywny Web Design Chodorek Damian W ostatnich latach rynek urządzeń mobilnych eksplodował. Dostęp do internetu z telefonu czy tabletu jest dziś standardem. Ogromna liczba stron internetowych jest jednak nieprzystosowana do małych ekranów, co znacznie utrudnia życie użytkownikom urządzeń mobilnych.W tym artykule postaram się zaprezentować technologie i sposoby, które umożliwiają tworzenie stron przyjaznych właścicielom małych ekranów. Szybki i łatwy WebGL z silnikiem AexolGL Artur Czemiel Od dłuższego czasu możemy zauważyć coraz większe zainteresowanie technologiąWebGL.Wiele osób twierdzi, że technologia ta zdominuje przyszłość interaktywnej rozrywki. Czy to prawda?Wielkie koncerny walczą o jak najszersze i jak najwydajniejsze wsparcieWebGL dostrzegając jego ogromny potencjał. Program jako utwór, programista jako twórca – prawa do programu Bartłomiej Leszczyński, Piotr Zawadzki Coraz większa obecność szeroko rozumianej informatyki w codziennym życiu rodzi coraz większe zapotrzebowanie na pracowników zajmujących się oprogramowywaniem urządzeń, komputerów i maszyn. Innymi słowy, rośnie zapotrzebowanie na programistów. Wizualizacja struktury intonacyjnej wypowiedzeń dla celów analizy i syntezy mowy cz.2 Wypowiedzenia pytające (na materiale języka rosyjskiego, niemieckiego i polskiego)! Juliusz skorek Niniejsza publikacja jest kontynuacją pracy Wizualizacja struktury intonacyjnej wypowiedzeń dla celów analizy i syntezy mowy stanowi jej integralną i dalsza część.W powszedniej wprowadzono pojęcie akcentu suprematycznego jako element identyfikujący rodzaj wypowiedzenia. 24 28 18 4 SPIS TREŚCI Software Developer’s Journal jest wydawany przez NPRACA Sp. z o.o. Redakcja: sdjpl@sdjournal.pl Adres korespondencyjny: NPRACA Spółka z o.o. ul. 3 Maja 46, 72-200 Nowogard, Polska Oddział w Warszawie: ul. Postępu 17 D, 02-676 Warszawa, Polska www.sdjournal.pl Facebook: https://www.facebook.com/SoftwareDevelopersJournal Redakcja dokłada wszelkich starań, by publikowane w piśmie 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: sdjpl@sdjournal.pl Skład i łamanie / projekt okładki: Digital Concept www.digitalconcept.pl admin@digitalconcept.pl 32

4 1/2015 26 kwietnia 2011 „Verto” to słowo, które od dłuższego już czasu sprawia, że kilkanaście osób z jednego z zespołów w zielonogórskiej fir- mie Streamsoft budzi się wcześniej niż zazwyczaj. Budzi się, nie tylko za sprawą nadgorliwego budzika czy nieodpartej chęci odbycia porannej „przebieżki”. Osoby te, to analitycy, projektanci i programiści, którzy ponad rok temu otrzyma- li zadanie zaprojektowania i zbudowania systemu ERP no- wej generacji. System ten ma z jednej strony kontynuować dobre tradycje firmy w dziedzinie dostarczania rozwiązań o wysokiej jakości i funkcjonalności, a z drugiej wprowa- dzić nową unikalną na polskim rynku (hmmm..., nie tylko na polskim) jakość. Dlaczego Verto ? W dziedzinie systemów ERP firma Streamsoft osiągnęła już wiele, wydawałoby się, że obecne produkty: system Streamsoft Pro i Streamsoft Pre- stiż są rozwiązaniami optymalnymi we własnych segmentach rynku … Verto natomiast ma dawać więcej. Ma wybiegać w przyszłość w każdym wymiarze systemu informatycznego. Większa skalowalność, niezależność od platform systemo- wych, bazodanowych, otwarta architektura zorientowana na komponenty, gotowość do integracji z innymi systemami, nowatorskie podejście do realizacji merytorycznych funk- cjonalności w procesach biznesowych. Ktoś pewnie zauwa- ży, że to wielkie i ambitne wyzwanie, złośliwy powie, że to w polskich realiach porywanie się „z motyką na słońce”. No cóż, to prawda. Zacznijmy więc od „motyki”. Aby podjąć się takiego wyzwania, potrzebny jest potencjał, który ... mamy. Wieloletnie doświadczenia w połączeniu z rozsądnym po- dejściem do najnowszych technologii oraz połączenie w jed- nym zespole doświadczonych „wiarusów” i „młodych wil- ków”... tak właśnie pojmujemy nasz potencjał. 5 maja 2011 Zacznijmy od samego podejścia do technologii. Jak wiado- mo, system ERP rozpina się ponad istniejącą infrastruktu- rą IT, stanowi ostatnią warstwę pomiędzy człowiekiem a sprzętem, bazą danych czy systemem operacyjnym. Do- datkowo, jako całość, nie jest monolitem, a raczej integruje pewne elementy składowe. W związku z tym decyzją strate- giczną jest na czym „postawimy” nasz system i czego użyje- my w roli „klocków” do jego zbudowania. Decyzją kluczową jest także wybranie języka, w którym będziemy się wyrażać jako twórcy, języka, który pozwoli posklejać wszystko to, co jest dostępne i stworzyć to, czego brakuje. Dlaczego to takie ważne ? Hmm... Wybierając język, technologie czy platformę ponosimy znaczne ryzyko. Wszystko w IT (oprócz standar- dów) jest produktem, a jak wiadomo, produkty przychodzą i odchodzą, a nasz system ma trwać. Jak to osiągnąć ? Są trzy podejścia, pierwsze mówi, aby uniezależniać się od do- stawców technologii idąc w abstrakcję, drugie, aby stawiać na pewnych dostawców, trzecie, aby stawiać na brak silne- go związku z dostawcą (np. opensource). Wszystkie podej- ścia są dobre, a to które należy zastosować, zależy zawsze od kontekstu. Nie ma jednej, złotej zasady. My zastosowali- śmy wszystkie w różnych miejscach, dobierając najbardziej, naszym zdaniem, optymalne. Jest także pewne wymaganie narzucone nam poprzez samą klasę problemu, mianowicie systemy ERP muszą być systemami raczej „dużego zaufania” niż „błyskotliwych wodotrysków”, jest więc silne wskazanie na używanie technologii ugruntowanych, sprawdzonych, nie- zależnych, a nie dopiero co „wczoraj” powstałych koncepcji marketingowych. Tyle teorii. Co do konkretnych rozwiązań to chciałbym jeszcze przedstawić zagadnienie wyboru samej Z blogaarchitekta systemowego „Verto” to słowo, które od dłuższego już czasu sprawia, że kilkanaście osób z jednego z zespołów w zielonogórskiej firmie Streamsoft budzi się wcześniej niż zazwyczaj. Budzi się, nie tylko za sprawą nadgorliwego budzika czy nieodpartej chęci odbycia porannej „przebieżki”.

5 Z bloga architekta systemowego www.sdjournal.pl każdą zmianę w bazie, pozwala na tworzenie nowych sche- matów baz oraz na aktualizację/reorganizację już istnieją- cych, dodatkowo stanowiąc źródło informacji dla wyższych warstw systemu. Dodając do tego narzędzie do sprawnej edycji meta-modelu oraz zestaw strategii pozwalający reali- zować go w różnych silnikach baz SQL, otrzymujemy potęż- ne narzędzie, które pozwala sprawnie zrealizować założone wymagania. 11 lipca 2011 Baza danych w systemach dwuwarstwowych była central- nym punktem systemu, często przepełniona kodem bizne- sowym, który osiągając z  czasem masę krytyczną, bloko- wał możliwości dalszego rozwoju. W  naszym przypadku sercem systemu jest logika biznesowa umieszczona w wy- dzielonej warstwie zwanej warstwą przetwarzania. W war- stwie tej stosujemy połączenie kilku technologii, u podstaw jej konstrukcji leży standard JavaEE, a więc w konsekwen- cji serwer aplikacyjny zgodny z tą specyfikacją, dalej mamy lekki kontener komponentów (SPRING), dostęp do ba- zy danych poprzez ORM’a  (HIBERNATE), do tego jesz- cze kilka technologii wspierających (obsługa kolejek, zega- rów), oraz specjalizowane podejście architektoniczne, czyli zdobywającą coraz większą popularność architekturę CQS (Command-Query Separation) oraz pewne elementy zapo- życzone z DDD (Domain-Driven Design). Wygląda to na bardzo rozbudowany „park maszynowy” i tak jest w rze- czy samej. Można się przestraszyć poziomu skomplikowania. Niepotrzebnie. Cała ta „maszyneria” jest ukryta pod „ma- ską” platformy, która pozwala o tym wszystkim zapomnieć i skupić się na sednie, czyli na kodzie biznesowym. Patrząc dalej poza horyzont samego kodu i usług platformy, podą- żając za myśleniem o tej warstwie jako „klu” systemu, nie można pominąć kwestii zapewnienia wysokiej jakości. Kod biznesowy musi podlegać ciągłej weryfikacji, testowaniu na zgodność z  wymaganiami, można zaryzykować twierdze- nie, że jest to najważniejsza usługa, którą powinna dostar- czać platforma. Nie jest więc zaskoczeniem, że w warstwie biznesowej platformy Next testy jednostkowe i integracyjne odgrywają pierwszoplanową rolę. Pozwala to na stosowanie technik wytwarzania bliskich podejściu TDD (Test-Driven Development). 18 sierpnia 2011 Zwieńczeniem stosu warstw jest warstwa prezentacji. Bogactwo i różnorodność dostępnych technologii i roz- wiązań w  tej warstwie jest ogromna. Z  drugiej strony nie można nie dostrzec znacznego zróżnicowania potrzeb klientów w zakresie metod dostępu do systemu. Poczyna- jąc od klasycznej pracy na stanowisku roboczym związa- nej z szybkim wystawianiem i drukowaniem dokumentów, poprzez pracę przedstawicieli handlowych używających małych urządzeń mobilnych, aż po szeroką rzeszę klien- tów składających zamówienia poprzez witrynę interne- tową, a  na analizie danych klasy „business intelligence” w  postaci panela decyzyjnego przez kadrę zarządzającą architektury systemowej. Od samego początku jasne było dla (prawie) wszystkich osób w zespole, że tworzenie syste- mu „od początku” czy „na pieszo” będzie nieproduktywne. Kierunek był jasny, nie robimy systemu ERP (sic!), robimy platformę do tworzenia systemów tej klasy, a dopiero po- tem zrobimy system. To jedno proste zdanie odkrywa bar- dzo istotny aspekt systemu Streamsoft Verto, czyli platfor- mę Streamsoft Next. 11 maja 2011 Rola platformy Streamsoft Next ? Platforma będzie jakością samą w sobie, wypełni ona lukę semantyczną pomiędzy języ- kiem programowania, technologią, a biznesowymi aspektami systemu. Pozwoli wynieść analityków, projektantów i pro- gramistów biznesowych ponad abstrakcję aspektów tech- nicznych. Czy odkrywamy tu „Amerykę” … hmm ... nie, w tym przypadku korzystamy ze sprawdzonych wzorców. Na rynku z powodzeniem działa wiele platform, wspomnę tylko platformę Eclipse, która dzięki swojej otwartości staje się typowym narzędziem developera IT. Chcielibyśmy, aby nasza platforma pozwoliła nam w szybki i elegancki sposób dostarczyć gotowy system, i co równie ważne, aby nasi partnerzy w biznesie mogli korzystając z platformy - zarazem rozbudowując to roz- wiązanie o specyficzne funkcjonalności, które swoim za- kresem obejmą ten obszar potrzeb użytkowników sys- temów ERP, którego nie jesteśmy w stanie przewidzieć. Faktem jest, że obecne systemy nie pokrywają 100% potrzeb każdego klienta, te brakujące procenty to czę- sto obszar funkcjonalności nominalnie nie znaczny, ale biznesowo, kluczowy. Platforma ma umożliwić pokry- cie także tego obszaru podczas wdrożenia systemu u klienta, a powstałe rozwiązania mają zachować spój- ność z resztą systemu, stanowiąc jego składową część. Decyzja o tworzeniu platformy była kluczowa z punktu widzenia samej strategii produktu, ustawiła nasze myśle- nie na odpowiednie tory, zdeterminowała skład zespołu i dalsze plany działania. 21 czerwca 2011 Baza danych to fundament systemów ERP. W systemie Ver- to z zasady dostawcy silnika bazy danych mogą być różni. Trzeba to rozumieć jako gotowość migracji na prawie do- wolny silnik relacyjnej bazy danych z interfejsem SQL, przy zaangażowaniu akceptowalnych zasobów. Dlaczego stało się to możliwe? Staramy się traktować bazę danych wyłącznie jako kontener danych, z zasady nie umieszczamy logiki biz- nesowej w bazie. Co z różnicami dialektów SQL? Używa- my technologii dostępowych pozwalających abstrahować od wspomnianych różnic, a konkretnie bibliotek mapujących ta- bele do obiektów (ORM). Co warto nadmienić udało nam się zrealizować autorski pomysł na wprowadzenie do bazy danych jej meta-modelu. Cała struktura bazy danych projek- towana jest i utrwalana w specjalnym zestawie tabel stano- wiącym centrum informacji o obiektach w bazie. Meta-mo- del jest abstrakcyjny, niezależny od dialektów SQL, rejestruje

6 1/2015 kończąc. Wszystkie te aktywności wymagają dostępu do systemu w  odmienny, specjalizowany sposób. Potrzeby to jedno, z drugiej strony mamy możliwości, w tym zakre- sie nie da się nie zauważyć dynamicznie zmieniającej się sytuację na rynku, rozwój klasycznych technologii web’o- wych opartych o HTML, CSS i JavaScript, ekspansja tech- nologii klasy RIA (Flex, JavaScript, JavaFX) oraz dobrze ugruntowane i  sprawdzone technologie okienkowe czy natywne interfejsy na urządzeniach mobilnych. Sytuację można by określić jako „dynamicznie zmieniającą się róż- norodność potrzeb i możliwości”, a tam gdzie spotykamy zmiany i różnorodność dobrym rozwiązaniem jest abs- trakcja. Platforma Next nie narzuca technologii klienckiej, sam fakt, że posiadamy warstwę przetwarzania, do której dostęp może odbywać się w różny sposób, oznacza, że klientów może być wielu, mogą być stworzeni przy uży- ciu różnych technologii. System Verto posiada oczywiście podstawową aplikację kliencką, poprzez którą wykony- wane są typowe czynności związane z obsługą systemu. Aplikacja ta jednak nie jest tworzona w żadnej konkretnej technologii. Tworząc domyślną warstwę klienta, używa- my abstrakcyjnych pojęć: widok, akcja, filtr, moduł edy- cji, układ kontrolek, deklarując je, określając ich atrybuty i powiązania. Z takiej definicji stworzonej głównie w języ- ku JAVA i XML platforma Next tworzy aplikację klienc- ką w jednej z wybranych technologii. Aktualnie aplikacja kliencka generowana jest w technologii SWING w posta- ci aplikacji okienkowej, oczywiście aplikacja kliencka nie wymaga instalacji i konfiguracji, uruchamiana jest przy po- mocy technologii Java Web Start. 14 września 2011 Kiedyś, (niestety) dawno temu, kiedy kupiłem kolejny ze- staw Lego, mój starszy syn nie patrząc na obrazki na pudeł- ku (które to ja bacznie oglądałem) rozerwał je i powiedział „dobra, dobra, zobaczmy, jakie w tym są klocki”. My do tej pory postępowaliśmy inaczej. Inaczej gdyż prawie wszyst- kie poprzednie wpisy były jak oglądanie pudełka, przyglą- daliśmy się platformie z wysokiej perspektywy, omawiając założenia, koncepcje, idee. Nadszedł czas zajrzeć do środ- ka ... „dobra, dobra, jakie tam są klocki”. Po kolei: akcje (ac- tion), widoki (view), opcje (option), moduł (modul), okna opcji (optionFrame), dostawcy danych (databaseContent- Provider), moduły danych (dataModule), słowniki (dictio- nary), filtry (filter), modyfikatory (modyficator), formate- ry (formatter), renderery (renderer) to te najważniejsze. Przyswoimy sobie ich funkcje w platformie. Akcje już znamy. Akcja inicjuje pewną czynność, wizualnie jest ikoną lub pozycją w menu. Widok z założenia to pewien obszar, na którym coś jest wyświetlone, poza ogólnym poję- ciem są bardziej specjalizowane widoki np. widok tabelarycz- ny, widok drzewiasty. Opcja to symbol i zgrupowanie innych komponentów wokół pewnego pojęcia merytorycznego, ta- kim pojęciem mogą być „Dokumenty sprzedaży”, „Jednostki miary”. Moduł to pojęcie jeszcze szersze, ponieważ moduł lo- gicznie i merytorycznie grupuje opcje, np. moduł „Sprzedaż”, „Rozrachunki”, „Administracja”. Okno opcji to okno, w któ- rym można wykonać wszystkie czynności związane z daną opcją takie jak przeglądanie, wyszukiwanie, edycja, drukowa- nie, słowem jest to kontener na widoki, akcje, miejsce gdzie łączą się one w celu dostarczenia założonej funkcjonalności. Moduł danych zajmuje się wszystkim, co jest związane edycją danych, domyślnie obsługuje cztery podstawowe czynności z  zakresu CRUD, dodanie nowego „Create”, odczytanie istniejącego „Read”, poprawa „Update” oraz usunięcie „Delete”. Słownik to specjalna konstrukcja po- zwalająca w łatwy sposób wybrać coś ze spisu np. wybór kontrahenta na dokumencie, wybór kartoteki na pozycji dokumentu, wybór jednostki miary na kartotece. Filtr ma za zadanie zawężać zakres danych w widokach, do których jest podłączony, np. widok dokumentów sprzedaży jest fil- trowany wg miejsc sprzedaży, w należnościach i zobowią- zaniach możemy filtrować przeterminowane dokumenty. Modyfikator a w zasadzie różne jego odmiany pozwa- lają zmieniać kształt zdefiniowanych już wcześniej obiek- tów, np. można modyfikatorem okna opcji dodać ikonkę lub widok do okna kontrahentów. Formatery i renderery pozwalają na zdefiniowanie sposobu prezentacji wartości w kolumnach widoków. To podstawowy zestaw komponentów w warstwie pre- zentacji, jak widać są to pojęcia wyższego rzędu, proste i łatwe do przyswojenia, nie trzeba być programistą, aby zrozumieć ich rolę. 2 listopada 2011 Platforma daje, ale platforma także wymaga. Co trzeba zrobić, aby uzyskać na przykład komponent widoku tabela- rycznego? Podstawowa zasada to „przedstawić się platfor- mie” w formie wizytówki (Listing 1). Dostarczyć pewnych informacji opisowych, tak jak w Li- stingu 2. Widok jest gotowy, z tym że brakuje mu informacji, jakie dane miałby wyświetlać, z jakich widoków i w jakim ukła- dzie. Widok, będąc komponentem czysto prezentacyjnym, nie zajmuje się w/w zadaniami, zadania te są delegowane do „zaprzyjaźnionego” z widokiem komponentu o dosyć oczywistej nazwie: dostawca danych. Dostawcę danych także należy przedstawić platformie w formie wizytówki (Listing 3) oraz zdefiniować jego zawartość w formie klasy samego dostawcy (Listing 4). Przyjrzyjmy się dokładnie, co zawiera ta klasa. W  linii 23 i 24 deklarujemy chęć skorzystania z serwisu platfor- my udostępniającego dostawcę kontekstów połączeń z ba- zą danych. Jak widać dzieje się to w deklaratywny sposób poprzez zadeklarowanie odpowiedniego prywatnego po- la klasy (24) oraz dodania adnotacji PlatformService (23). W  dalszej kolejności naszym zadaniem jest uzupełnienie treści metody createQueryDefinition(), której jedynym za- daniem jest zwrócenie obiektowej definicji zapytania w po- staci instancji klasy QueryDefinition. W treści tej metody pobieramy od dostawcy kontekst połączenia (29), tworzy- my pustą instancję definicji zapytania (32), do której doda-

7 Z bloga architekta systemowego www.sdjournal.pl jemy trzy widoki: Customer (35), CustomerHist (44) oraz Address (51). Do każdego widoku dodajemy możliwe do wybrania kolumny oraz dwa podrzędne widoki łączymy z widokiem głównym za pomocą wskazania odpowiedniej relacji (48) i (56). Na koniec zwracamy wypełnioną defini- cję zapytania (58). Na potrzeby tego przykładu zawartość widoku została znacznie ograniczona, ale nie ma to wpływu na samą za- sadę działania: komponent przedstawia się, wymaga i de- klaruje, a platforma „ochoczo” przystępując do pracy, wy- konuje całą resztę. Gdyby ktoś powiedział, że to i tak jest dużo pisania ... śpieszę donieść, że znaczna część prezen- towanego kodu została wygenerowana przy pomocy na- rzędzi platformy. 10 kwietnia 2012 Obsługa systemów informatycznych w zwykły klasycz- ny sposób polega na wykonywaniu pewnych czynno- ści w pewnym kontekście. Kontekstem może być miej- sce w programie, aktywna strona, aktywne okno opcji, okno dialogowe itp. Wykonując czynność, zakładam, że wykonuję ją właśnie na tym czymś, na czym stoję, na tym, gdzie jestem. Dla przykładu wykonanie czynności „Usuń” w  kontekście spisu kontrahentów rozumiemy w oczywisty sposób jako „Usunięcie danych kontrahen- ta”, a w kontekście spisu dokumentów sprzedaży jako „Usunięcie danych dokumentu”. Sam proces pracy z ta- kim systemem polega na tym, że najpierw musimy się znajdować w odpowiednim kontekście, robimy to po- Listing 1. Wizytówka widoku kontrahenta Listing 2. Lokalizowane właściwości widoku kontrahenta Listing 3. Wizytówka dostawcy danych widoku kontrahenta

8 1/2015 przez wejście w  odpowiednie miejsce w  systemie np. w opcję „Kontrahenci” i tam konkretyzując kontekst za pomocą wyszukiwania, szukamy tego kontrahenta, któ- ry ma stać się podmiotem operacji. W przygotowanym w ten sposób kontekście możemy wykonać czynność, wybieramy ze zbioru dostępnych tą, która nas interesu- je, w omawianym przypadku będzie to „Usuń”, przecho- dzimy poprzez wszystkie jej etapy i koniec, wykonaliśmy założone zadanie. Nasza codzienna praca polega na wie- lokrotnym wykonywaniu podobnych sekwencji czynno- ści. To proste i łatwe do opanowania, spróbujmy jednak coś usprawnić. Przebłysk pierwszy. Konteksty są bogatsze, niż nam się wydaje. W kontekście dokumentów sprzedaży jest dostępnych więcej informacji niż tylko jaki dokument sprzedaży jest aktualnie wybrany na liście, czy jaki zakres dat obejmuje spis, mamy też informację np. o kontra- hencie, który jest przypisany do tego dokumentu. Co to implikuje? Rozważmy akcję „Pokaż historię kontrahen- ta” jest to akcja dostępna w kontekście „Kontrahenci” pokazująca dla aktualnego kontrahenta analizę transakcji przeprowadzonych z nim w ostatnim okresie. Czy ta ak- cja musi ograniczać się do tego własnego macierzyste- go kontekstu? Nie. Pozwólmy jej skorzystać z bogactwa kontekstu „Dokumenty sprzedaży”, pozwólmy jej dzia- łać w tym kontekście, ponieważ zawiera on to, co jest niezbędne do jej działania, wskazanie na kontrahenta. Wniosek: Czynności mogą być wykonywane w dowol- nym kontekście zawierającym wystarczające informacje do ich działania. Przebłysk drugi. Kontekst można wzbogacić. Wyobraź- my sobie, że w pewnym miejscu systemu (kontekście) nie Listing 4. Implementacja dostawca danych widoku kontrahenta

9 Z bloga architekta systemowego www.sdjournal.pl mamy informacji o kontrahencie, np. w kartotekach ob- rotowych, ale podczas wdrożenia systemu zdefiniowano atrybuty dodatkowe dla kartoteki obrotowej: „Dostaw- ca z najniższą ceną” oraz „Dostawca z najkrótszym ter- minem dostawy”. Atrybuty te są typu „słownik” z pod- łączonym słownikiem kontrahentów, co daje systemowi świadomość o ich tożsamości. Umieszczając je w wido- ku kartotek obrotowych, wzbogacamy kontekst na tyle, że możemy już wykonać dowolną czynność wymagającą właśnie informacji o aktualnym kontrahencie. Wniosek. Dostępność czynności jest związana ze stanem kontek- stu, a ten może ulegać zmianie, nawet na etapie wdraża- nia systemu. Przebłysk trzeci. Kontekst można stworzyć. Dlaczego by nie, taki nasz, szyty na miarę, skoro wykonujemy pew- ne określone czynności związane z pewnymi procesami zachodzącymi w  naszej organizacji, zgromadźmy dane o nich właśnie w takie mające początek i koniec kontek- sty, przebiegi pracy, będzie łatwiej, nie trzeba będzie bie- gać po systemie w poszukiwaniu odpowiedniego kontek- stu pracy i czynności do wykonania. Przebłysk czwarty. Kontekst można przekazać. Stwo- rzyliśmy kontekst pracy pewnego operatora, on wy- konał pracę, ale praca musi zostać dokończona przez kogoś innego, więc przekażmy gotowy już wypełniony kontekst dalej, a kolejna osoba przejmie zadanie wyko- nania dalszej pracy. Mamy pomysł jak usprawnić zarzą- dzanie kontekstem a co z czynnościami? Czy napraw- dę każda z nich jest autonomiczna? Często właśnie nie. Mamy przecież głowy pełne zasad obowiązujących u nas w firmie: „... jak nie płaci, to mu nie sprzedajemy, chyba że te wina co już się ledwo nadają ... ale jak ma ponad 10tyś po terminie to nie sprzedajemy nawet tego wina …”, „... nie wysyłaj do kompletacji niezaakceptowanych zamówień powyżej 10 tys., musi to akceptować Marcin ... chyba że jest chory wtedy ...”, każdy to zna. W kon- sekwencji tych rozważań uderza nas ...przebłysk piąty. Tak naprawdę bardzo często wykonujemy czynności wg pewnych zasad i reguł. Skoro działamy wg reguł, to mo- że działamy wg schematów, a schematy to coś co da się oprogramować i monitorować, to w takim razie, po co nam system z ogromnym menu, po którym trzeba prze- łączać się, szukać kontekstu, skupmy się na jednym wi- doku prezentującym to, co możemy i powinniśmy robić w systemie. Wystarczy nam taki jeden panel roboczy, z którego da się wykonać całą pracę. Dodajmy do tego pracę grupową, przekazujmy pracę pomiędzy sobą z za- chowaniem kontekstu, kolejna osoba w  łańcuszku nie musi ponownie szukać kontrahenta, zamówienia. Podsumujmy. Chcemy opisać pracę w systemie za pomo- cą definiowanych schematów działania, schematy te będą wytwarzać dla operatorów przyjazny kontekst pracy, co pozwoli wykonywać w takim środowisku czynności i akcje w odpowiedni, uporządkowany sposób, przekazując pracę po wykonaniu własnej części dalej do kolejnych osób aż do zakończenia procesu. Na koniec trochę pokory. To, co odkryliśmy, w zasadzie jest już dawno odkryte i nazywa się „workflow”. A naszą przewagę na tym polu zbudowaliśmy na tym, że kompo- nentowa struktura oraz abstrakcja komunikacji pomiędzy komponentami w postaci gniazd obecna na platformie Stre- amsoft Next jest jakby „szyta” pod różne sposoby obsługi systemu, a także pod zmiany kontekstów i ich wzbogacanie i w konsekwencji idealnie wpasowuje się w ideę „workflow”. 28 czerwca 2012 Piękno leży w prostocie, a reguły KISS (Keep It Simple, Stu- pid) czy nasze polskie BUZI (Bez Udziwnień Zapisu, Idioto) w żartobliwy, acz niepozbawiony sensu sposób, podkreśla- ją praktyczną stronę rozwiązań prostych. Komunikacja między komponentami, to jak się wydaje zagadnienie szerokie i pozwalające się „wykazać” pomysło- wością i inwencją, jednak na platformie Next zostało ono sprowadzone do bardzo prostego mechanizmu opartego o gniazda komunikacyjne. Idea gniazd w służbie komunika- cji znana jest od wielu lat w różnych architekturach, od po- wszechnie używanych sieciowych (Network Sockets) do desktop’owych systemów graficznych (np. Qt’s signals and slots). Zobaczmy więc, jak wygląda to koncepcyjnie na Ry- sunku 1. Prawda, że proste? Mamy tylko trzy reguły! • Każdy komponent może mieć dowolną liczbę gniazd wyjściowych i wejściowych. • Gniazdo ma określony typ przesyłanych danych. • Gniazda o zgodnym typie danych można łączyć. Jest to takie proste, że nie za bardzo jest o  czym da- lej pisać. Więc może, zobaczmy rzeczywistą realizację idei komunikacji w systemie Verto w opcji „Kontrahen- ci” (Rysunek 2), co w efekcie daje gotową opcję pokaza- ną na Rysunku 3. Korzyści, jakie daje standaryzacja komunikacji za pomocą gniazd, są niebanalnie duże. Zacznijmy od tego, że gniazda można łączyć statycznie w kodzie programu ... to raczej oczywiste, ale nie tylko, możemy dodawać nowe połącze- nia, za pomocą „pluginów”, co też specjalnie nie zaskakuje. Ciekawe i  nie oczywiste jest to, że możemy gniazda łą- czyć dynamicznie już w  trakcie działania programu (jeśli ktoś przypomina sobie w tym miejscu wpisy o „workflow”, to dobrze). Zauważmy, że gniazda są jawnie deklarowane, możemy dostać na poziomie działającej już aplikacji infor- macje o komponentach i ich gniazdach ... konsekwencje są łatwe do przewidzenia. Wiemy jakie mamy komponen- ty, znamy możliwości ich łączenia, łączenie może odbywać się dynamicznie, stąd już tylko krok do interaktywnego, za pomocą „myszki” układania programu z gotowych „kloc- ków”. 7 listopada 2012 Kompozycja jest dalece bardziej efektywna niż dziedzi- czenie. Jakiś czas temu, wcale nie tak dawno patrząc na

10 1/2015 Rysunek 1. Koncepcja komunikacji za pomocą gniazd Rysunek 2. Komunikacja w opcji „Kontrahenci

11 Z bloga architekta systemowego www.sdjournal.pl Rysunek 3. Opcja „Kontrahenci” Rysunek 3. Skrypt obsługi zdarzenia technicznego

12 1/2015 ilość czasu, jaką zajmuje się programowaniem, dotarło do mnie właśnie to zdanie w postaci bardzo impera- tywnej „Favor ‘object composition’ over ‘class inheri- tance’” i w niezmiernie krótkim czasie znacząco zmie- niło moje poglądy. Grupa ludzi nazywana GoF (Gang of Four) we wciąż za mało sławnej w naszych kręgach książce „Design Patterns” już ponad 7 lat temu zaanon- sowała w/w nie jako wzorzec projektowy, co sugero- wałby tytuł książki, ale jako generalną regułę, która objawia swoje istnienie podczas odkrywania tychże ty- tułowych wzorców. Nie ukrywam także że omawiana reguła za sprawą nie- wątpliwie świadomych decyzji przerodziła się w ogólne podejście, które było i jest obecne w trakcie całego pro- cesu projektowania i  tworzenia platformy Next i  sys- temu Verto. Nie będę omawiał wyższości kompozycji nad dziedziczeniem, ufam, że wielu czytelników jest już w naszym „klubie”, tym spoza polecam w/w książkę jako pozycję pozwalającą w miarę bezboleśnie się nawrócić. Pominę milczeniem też fakt, skąd wzięło się moje i nie tylko moje jak mniemam wcześniejsze przywiązanie do mechanizmów dziedziczenia doprawionego polimorfi- zmem jako głównych technik obiektowych, ale nie mogę nie wyrazić żalu, że tak wiele osób tkwi jeszcze w tym „średniowieczu” zaserwowanym nam w procesie insty- tucjonalnej edukacji. 23 kwietnia 2013 Zdolność zarządzania determinowana jest zdolnością identyfikacji. Zasada ta dotyczy wszystkich aspektów ży- cia, wszystko, co ma podlegać zarządzaniu musi być iden- tyfikowalne. Przykłady można mnożyć, zarządzanie społe- czeństwami wymaga identyfikacji obywateli, zarządzanie reklamacjami wymaga identyfikacji zgłoszeń, zgłaszających i przedmiotów reklamacji, zarządzanie ryzykiem wymaga identyfikacji potencjalnych źródeł ryzyka, zarządzanie ze- społem wymaga identyfikacji osób ich zdolności, zadań, terminów itd. Zarządzanie czymś, co jest bezkształtną masą, „blob’em”, zbiorem nieoznaczoności, jest nieefek- tywne, niemożliwe, w konsekwencji pierwszą czynnością, która jest podejmowana w procesie zarządzania w kon- takcie z nieoznaczonością, jest zidentyfikowanie dziedziny tak, aby mogły nastąpić dalsze klasyczne procesy zarząd- cze. Dlaczego to piszę? Często spotykam się z  pytania- mi dotyczącymi platformy Next, dlaczego w  zasadzie wszystko ma identyfikator czy wizytówkę z identyfika- torem, dosłownie każda „ikonka”, a nawet jej parametr ma identyfikator. Dlaczego tak bardzo dbamy o to, aby żadne elementy składowe systemu nie pozostawały poza świadomością platformy? Można by rzec, że platforma ogranicza „radosną twórczość” na rzecz działania efektywnymi schema- tami, i  jest to jak najbardziej zamierzone i  celowe. Odpowiedzią na te pytania i wątpliwości jest właśnie konieczność utrzymania „zarządzalności” na jak naj- wyższym poziomie, a to na początku kosztuje, wymaga, czasem ogranicza, ale potem procentuje, zwraca się, daje przewagę. 3 października 2013 W obszarze dynamizmu i szybkiej reakcji na zmianę na platformie Streamsoft Next rządzi DISEN (DynamIc Script ENgine). Sam akronim wiele tłumaczy i wystarczy dodać, że mechanizm oparty jest o działający na maszy- nie wirtualnej Javy język skryptowy „Groovy”, który to wpięty w wiele wyselekcjonowanych miejsc systemu po- zwala na dostarczanie dynamicznych funkcji i zachowań. Skrypty w zależności od przeznaczenia dzielimy na ser- werowe i klienckie. W  obszarze serwerowym wyróżniamy skrypty re- agujące na zdarzenia techniczne, biznesowe i  okre- sowe. W obszarze serwera, jak i klienta, dostępne są skrypty wywoływane na życzenie operatora, stanowią- ce element typu „Akcja” z  definiowanym przebiegiem wykonania. Kolejnym obszarem dynamizmu jest mecha- nizm „Workflow”, gdzie skrypty mogą stanowić źródło wiedzy w  postaci warunków sterujących przebiegiem, warunków walidacji, przekazywania danych pomiędzy stanami procesów oraz mogą opisywać zachowanie au- tomatycznych i dynamicznych elementów w procesach. Aby zobrazować możliwości tkwiące w DISENie za- cznijmy od przykładów. Na jednym z wdrożeń zaistniała potrzeba dodatkowej weryfikacji danych kontrahentów, Rysunek 5. Prezentacja błędu walidacji

13 Z bloga architekta systemowego www.sdjournal.pl mianowicie wszyscy kontrahenci spoza województwa mazowieckiego muszą mieć przypisanego operatora prowadzącego, który zazwyczaj należy do pewnej grupy operatorów. Skrypt, który zapewnił tą funkcjonalność to skrypt techniczny, czyli taki który zapina się na zda- rzenie powstałe w  pewnym standardowym momencie cyklu działania serwisu, w naszym przypadku serwisu od obsługi kontrahentów. Jest to zdarzenie wywołania me- tody walidacji zbioru danych przed zapisem. Skrypt taki może zgłosić swoje zastrzeżenia co do po- prawności danych, które to zastrzeżenia zostają zinter- pretowane przez platformę i przedstawione operatorowi. Przyjrzyjmy się samemu skryptowi przedstowionemu na Rysunku 4. Linia od 1 do 7 to odczytanie danych wejściowych skryp- tu i ustalenie stanu aktualnego. W liniach od 9 do 13 sprawdzamy, czy kontrahent jest spoza województwa mazowieckiego i czy brak jest operatora prowadzącego, jeżeli tak jest, to do listy in- formacji walidacyjnych w linii 10 dodawana jest infor- macja o błędzie, jego treści i nazwie pola w zbiorze da- nych, którego ten błąd dotyczy. W liniach od 15 do 23 sprawdzamy, czy kontrahent jest spoza województwa mazowieckiego, czy podany jest operator prowadzący, oraz czy podany operator prowadzący znajduje się na liście operatorów zaleca- nych, jeżeli się nie znajduje, dodajemy w linii 19 do listy uwag walidacyjnych ostrzeżenie z treścią, i informacją, jakiego pola w zbiorze danych ten błąd dotyczy. Od razu po zapisaniu skryptu możemy sprawdzić jego działanie. Próba naruszenia warunku kończy się błędem prszedstawionym na Rysunku 5, a podanie operatora spo- za zalecanej listy, kończy się ostrzeżeniem (Rysunek 6 i Ry- sunek 7). 26 listopada 2014 Całkiem nie aż tak dawno, Andreas Bechtolsheim (nie trze- ba czytać tego nazwiska), mądry, młody człowiek o otwar- tych horyzontach w  początkach swojej informatycznej kariery wymyślił ideę komputera sieciowego. Z podobny- mi mu pasjonatami założył „słoneczną” firmę produkują- cą właśnie komputery i jak wielu innych w tamtym czasie, osiągnął ogromny sukces. Na fali dobrych wyników, kon- sekwentnie dążył do spopularyzowania swojego marzenia, manifestując je znanym hasłem „Dopiero sieć to kompu- ter”. Choć w tamtym okresie niewielu z branży się z nim zgadzało, a firma SUN została w końcu po latach wchłonię- ta ze smakiem przez jedną z wielkich korporacji, to trudno Rysunek 6. Prezentacja ostrzeżenia walidacji Rysunek 7. Pytanie o potwierdzenie ostrzeżenia walidacji

14 1/2015 nie zgodzić się z Andreasem. Miał „chłop” rację. Jego hasło działa dziś w wymiarze tak powszechnym i wszechogarnia- jącym, że chyba bardziej się już nie da. I trudno nie zauwa- żyć procesów migracji do sieci z kolejnymi aspektami życia i w ogóle wszystkiego. Pozostając pod wrażeniem wizjonerstwa Andreasa, moglibyśmy zacząć zastanawiać się, jakie jest kolejne „ha- sło”, jaka jest reguła na kolejny niewątpliwie nadchodzący czas. Polecam każdemu podjęcie takiego intelektualnego wysiłku. Sam chciałbym zwrócić uwagę raczej na to, co dzieje się aktualnie. Coś, co jest tak bardzo namacalne i widoczne, coś co używa sieci jako warstwy fizycznej, by móc sprawnie działać. Co łączy IRC, OpenSource, Face- book, GaduGadu, StarCraft, grupy dyskusyjne, YouTube, SoundCloud, Wikipedię, ruch DIY i setki innych, których nie sposób wymienić… Wiadomo, sieć, ale to nie jest „ta” odpowiedź. Wszystko to są przejawy życia społecz- nego, które rozkwita w  sieci jak miliony słoneczników na ogromnej światowej łące, dla której sieć jest z jednej strony „glebą” pozwalającą kiełkować i rosnąć dotychczas już znanym formom. Z drugiej strony stymulantem mu- tacji eDNA, powodując powstawanie form całkiem no- wych, wcześniej niespotykanych. Parafrazując Andreasa, można ryzykownie powiedzieć, że… „Dopiero społeczność to człowiek”. Lubimy być ra- zem, należeć do grupy, być częścią całości, organizujemy się w gangi, towarzystwa, zakładamy kluby, budujemy społecz- ności lokalne i globalne, chcemy i lubimy działać wspólnie. Robimy to nieprzypadkowo. Tysiące lat ewolucji udowod- niły, że skoordynowane, zespołowe działanie, przynosi lep- sze efekty i ta ewolucyjna zdobycz jest główną przyczyną nowoczesnej rewolucji typu „social”, czy „social network”. Wstęp miał mieć kilka zdań. Jest trochę dłuższy, zrobię więc krótkie podsumowanie. Odnosząc w końcu powyż- sze rozważania do własnego podwórka, nie mogę nie za- uważyć coraz większej grupy osób rosnącej wokół Stream- soft Verto i Streamsoft Next. Czas biegnie, mamy kolejne kontrakty, wdrożenia, powstają kolejne zespoły develope- rów tworzących różnorodne rozwiązania przy pomocy na- szych narzędzi. Szkolimy się, komunikujemy, wymieniamy wiedzą, dzielimy pomysłami, mamy wspólne cele, pojawiają się pierwsze „zyski” z takiego właśnie podejścia, w efekcie, zaczynamy tworzyć społeczność ... płyniemy w głównym nurcie. Co mnie i nie tylko mnie bardzo cieszy. Krzysztof „Kris” Olszewski Programista, projektant, analityk, architekt, zagorzały zwolennik po- dejścia zwinnego. W firmie Stream- soft, odpowiedzialny za platformę programistyczną Streamsoft Next REKLAMA Jeżeli jesteś zainteresowany/a reklamą swoich produktów w naszym magazynie Jeżeli jesteś zainteresowany/a wypromowaniem swojej marki wśród specjalistów IT Jeżeli szukasz klientów lub pracowników Zareklamuj się u nas! Posiadamy bazę 90 tysięcy specjalistów z różnych działów IT! W celu uzyskania oferty reklamowej skontaktuj się z nami: sdjpl@sdjournal.pl tel. 799 46 34 76

O firmie Streamsoft Jesteśmy znanym i cenionym producentem oprogramowania dla biznesu. Od 25 lat dostarczamy kompletne systemy do zarzadzania wszystkimi obszarami przedsiębiorstwa takimi jak m.in.: logistyka, produkcja, sprzedaż, zakupy, finanse i księgowości, itp. Centrala firmy Streamsoft znajduje się w Zielonej Górze, a oddziały w prężnych aglomeracjach miejskich w Polsce: w Warszawie, Wrocławiu i Krakowie. Ponad 75 tysięcy firm produkcyjnych, handlowych i usługowych codziennie korzysta z naszych rozwiązań. Oferta Streamsoft W naszej ofercie dla firm znajdują się następujące produkty: • dwa systemy ERP dla średnich i dużych firm: pierwszy o nazwie Streamsoft Prestiż (bogaty funkcjonalnie) i drugi: Streamsoft Verto („szyty na miarę”) • oprogramowanie pudełkowe dla małych firm i biur rachunkowych: Streamsoft PCBiznes (Ala, Ewa, Aga, Iza) • oprogramowanie w chmurze dla mikro firm: Firmino.pl

Nasi specjaliści Zatrudniamy 145 specjalistów we wszystkich naszych lokalizacjach na terenie Polski. Grupę specjalistów tworzą: pro- jektanci, programiści, analitycy, konsultanci. Nasze produkty dostępne są również dzięki Partnerom – niezależnym firmom informatycznym, które zajmują się dystrybucją i wdrażaniem ich u klientów. Współpracujemy z ponad 100 firmami informatycznymi. Poszukujemy programistów i konsultantów ERP Jeśli szukasz dynamicznie rozwijającej się firmy, to wyślij dokumenty aplikacyjne na adres praca@streamsoft.pl.  Kontakt do Centrali Streamsoft ul. Kossaka 10, 65-140 Zielona Góra tel. 68 45 66 902 email: handelpro@streamsoft.pl www.streamsoft.pl Programista aplikacji biznesowych JAVA Lokalizacje: • Centrala firmy Streamsoft w  Zielonej Górze oraz oddział we Wrocławiu Wymagania: • znajomość języka JAVA • znajomość relacyjnych baz danych i języka SQL • znajomość narzędzi developerskich Eclipse, Svn • znajomość wybranych technologii wchodzących w skład standardu Java EE • wykształcenie wyższe informatyczne lub pokrewne • zaangażowanie, kreatywność, logiczne myślenie • umiejętność pracy w zespole i pod presją czasu Co nas mile zaskoczy? • znajomość technologii: Hibernate, Spring, EJB, Webservices • wiedza z zakresu: wzorce projektowe, TDD Oferujemy: • stabilne zatrudnienie w formie umowy o pracę • pracę w młodym i dynamicznym zespole wynagrodzenie adekwatne do posiadanego doświad- czenia • możliwość rozwoju i doskonalenia zawodowego • pracę przy wykorzystaniu najnowszych narzędzi deweloperskich • pakiet socjalny Konsultant systemów ERP Lokalizacje: • Centrala firmy Streamsoft w  Zielonej Górze oraz oddział w Warszawie Wymagania: • wykształcenie wyższe techniczne lub ekonomiczne • determinacja w realizacji wyznaczonych celów • kreatywność, samodzielność • wysokie umiejętności interpersonalne Obowiązki: • administracja systemów operacyjnych Linux, Win- dows i baz danych Firebird, Oracle • wdrażanie systemów finansowo-księgowych, ka- drowo-płacowych, zarządzania produkcją • przygotowywanie i prowadzenie szkoleń z obsługi systemu ERP Streamsoft Prestiż. Oferujemy: • stabilne zatrudnienie w formie umowy o pracę • pracę w młodym i dynamicznym zespole • wynagrodzenie adekwatne do posiadanego do- świadczenia • możliwość rozwoju i doskonalenia zawodowego • pracę przy wykorzystaniu najnowszych narzędzi deweloperskich • pakiet socjalny

18 1/2015 C zym jest responsywny Web Design? To tworzenie stron internetowych, które zaspakajają potrzeby właścicieli urządzeń o różnych rozmiarach ekra- nów. Oczywiście termin ten dotyczy przede wszystkim użytkowników urządzeń mobilnych. Jaka jest różnica pomiędzy stroną mobilną a responsyw- ną? Responsywny oznacza zdolny do reagowania na zmia- ny. Mam tu na myśli głównie zmiany dotyczące rozmiaru ekranu. Jeżeli mówimy o stronach mobilnych, to przeważ- nie chodzi o całkowicie oddzielną stronę WWW, przezna- czoną wyłącznie dla urządzeń mobilnych. Najpopularniejszym podejściem jest jednak responsywny Web Design, który polega na tworzeniu stron dynamicz- nie zmieniających swój wygląd i zawartość, na ekranach o różnych rozmiarach. Responsywny Web Design Tworzenie stron responsywnych można sprowadzić do trzech elementów: • elastycznych układów, • zapytań mediów, • elastycznych mediów. Połączenie trzech powyższych czynników pozwoli na stworzenie doskonałej strony WWW, która wygląda do- brze i jest czytelna zarówno na komputerze, jak i małym smartfonie. Flexible layouts Czyli elastyczne układy. Sztuka tworzenia stron przy ich użyciu polega na korzystaniu z relatywnych wymiarów. Responsywny Web Design W ostatnich latach rynek urządzeń mobilnych eksplodował. Dostęp do internetu z telefonu czy tabletu jest dziś standardem. Ogromna liczba stron internetowych jest jednak nieprzystosowana do małych ekranów, co znacznie utrudnia życie użytkownikom urządzeń mobilnych. W tym artykule postaram się zaprezentować technologie i sposoby, które umożliwiają tworzenie stron przyjaznych właścicielom małych ekranów. Dowiesz się... • Na czym polega tworzenie responsywnych stron WWW oraz jakie technologie są do tego celu wykorzystywane. Powinieneś wiedzieć... • Znać podstawy CSS oraz HTML. Listing 1. CSS’y wykorzystujące jednostkę px. Język: CSS .parent{ width: 900px; display: table; } .child-1, .child-2{ margin: 10px; } .child-1{ float: left; width: 580px; } .child-2{ float: right; width: 280px; } Rysunek 1. Ilustracja listingu 1

19 Responsywny Web Design www.sdjournal.pl Teraz dzieci zajmują szerokość proporcjonalną do rodzi- ca. Zmianie ulegają także marginesy. Dla szerokich ekra- nów będą one większe, dla wąskich mniejsze. Metoda flexible layout jest relatywnie prosta w imple- mentacji. Ma jednak bardzo poważną wadę – dla zbyt wą- skich ekranów, szerokość kolumn stanie się bardzo mała. Zwłaszcza jeżeli jest ich wiele. Najprostszym rozwiąza- niem byłoby uczynić wszystkie elementy kolumnowe mak- symalnie szerokie i umieszczone jeden pod drugim. Dla różnych ekranów, elementom powinny być więc przypi- sane różne CSS’y. Tę właśnie funkcjonalność udostępniają Media Queries, które w połączeniu z flexible layouts pozwa- lają na tworzenie responsywnych, świetnie wyglądających na wszystkich ekranach, stron. Media Queries To zapytania, które jak już wspomniałem, umożliwiają przypisywanie elementom różnych stylów, w zależności od przeróżnych parametrów ekranu, takich jak jego rozmiar, orientacja, rozdzielczość itd. Media Queries można dołączyć na 3 sposoby: • wykorzystując regułę @media wewnątrz stylów, • importując style przy pomocy @import, • dołączając oddzielny plik wewnątrz sekcji HEAD doku- mentu HTML. Media Queries składają się z różnych parametrów medium (rozmiar, orientacja, rozdzielczość) oraz operatorów lo- gicznych, które je łączą. Jeżeli postawione warunki są spełnione, to arkusz stylów jest dołączany. W przeciw- nym razie zostanie zignorowany. Jednym z podstawowych parametrów jest typ medium, na którym zostanie uruchomiona strona. Są to m.in.: • all – obejmuje wszystkie rodzaje mediów, • speech – syntezatory mowy, • print – urządzenia drukujące, podgląd wydruku, • screen – ekrany komputerowe. Istnieje możliwość połączenia kilku zapytań mediów przy pomocy operatorów logicznych. Ich zadaniem jest wy- produkowanie finalnej wartości logicznej, która zadecy- duje czy dane style będą zignorowane czy też nie. Oto li- sta dostępnych operatorów: • and – operator koniunkcji, • przecinek – operator alternatywy, • not – operator negacji, może być użyty do zanegowa- nia całego wyrażenia, ale nie wyrażeń cząstkowych, • only – sprawia, że starsze przeglądarki internetowe nie zastosują danych stylów (Listing 5). Kolejne parametry dotyczą wymiarów ekranu. Są one najcześciej wykorzystywane. Wyróżniamy: Szerokość, wysokość, odstępy oraz marginesy różnych elementów ustawiamy więc przy użyciu %, em lub rem, a nie px. W CSS3 wprowadzono nowe jednostki, które są związa- ne z rozmiarem przeglądarki i urządzenia. Są to: • vw (viewport width) – 1vw odpowiada 1% szerokości ob- szaru, na którym wyświetlona jest strona, • vh (viewport height) – 1vh odpowiada 1% wysokości ob- szaru, na którym wyświetlona jest strona, • vmin (viewport minimum) – 1vmin to mniejsza z warto- ści 1vw lub 1vh, • vmax (viewport maximum) – 1vmax to większa z warto- ści 1vw lub 1vh. Powyższe jednostki są wspierane przez większość najpo- pularniejszych i nowoczesnych przeglądarek. Jeżeli chodzi o tworzenie stron WWW jest to jednak za mało. Powyższy przykład prezentuje użycie jednostek sztyw- nych, niezależnych od rozmiaru przeglądarki. Oczywistym problemem jest to, że strona zbudowana w ten sposób będzie niewygodna w użyciu na urządzeniach mobilnych. Użytkownicy będą musieli dużo przewijać, powiększać i pomniejszać, aby dostać się do interesujących części stro- ny i móc je przeglądać. Flexible layout oznacza, że zamienimy wszystkie px na jednostki relatywne. Kontener ma szerokość 900px. Dzie- ci mają marginesy 10px oraz szerokości 580px i 280px. Liczby te należy podzielić, aby uzyskać wartości relatywne, przykładowo 580px to około 64.4444% z 900px. Po zasto- sowaniu tych zmian uzyskujemy elastyczny układ. Listing 2. Przykład elastycznego układu. Język: CSS .parent{ width: 100%; display: table; } .child-1, .child-2{ margin: 1.1111%; } .child-1{ float: left; width: 64.4444%; } .child-2{ float: right; width: 31.1111%; }

20 1/2015 • height – wysokość przeglądarki, • width – szerokość przeglądarki, • device-height – wysokość ekranu urządzenia, • device-width – szerokość ekranu urządzenia. Każda z powyższych cech może być poprzedzona kwalifi- katorem max lub min. Pierwszy, oznacza mniejszy lub rów- ny. Drugi, większy lub równy. Używamy ich zamiast zna- ków mniejszości i większości, które wprowadziłyby spo- ro zamieszania do kodu (Listing 5). Przykładowo, zapyta- nie @media all and (min-width: 320px) and (max-width: 780px) oznacza, że dane style będą dołączone, jeżeli szero- kość przeglądarki jest wartością pomiędzy 320px a 780px. Kolejną cechą, szczególnie użyteczną jeżeli chodzi o urządzenia mobilne, jest orientacja. Determinuje czy dane urządzenie jest w orientacji pionowej czy poziomej. Orien- tacja pionowa (portrait) oznacza, że szerokość przeglądarki jest mniejsza niż wysokość, pozioma (landscape) oznacza sytuację odwrotną (Listing 5). Reguła aspect-ratio dotyczy proporcji szerokości do wysokości przeglądarki. Proporcja jest zdefiniowana przez dwie liczby całkowite w postaci: szerokość/wysokość. Przykładowo, 4/3 pasuje do takich rozmiarów jak 640x480 i 1024x786. Analogiczną regułą jest device-aspect-ratio, która odnosi się do proporcji ekranu urządzenia (Listing 5). Przy pomocy własności resolution możemy zdefiniować CSS’y, które zostaną użyte w przypadku określonej gęsto- ści pikseli. Można ją zdefiniować korzystając z jednostek takich jak: dpi, dppx, dpcm. Kwalifikatory max i min mogą być tu również wykorzystane (Listing 5). Listing 3. Media Queries w sekcji HEAD pliku HTML. Język: HTML.Listing 4. Reguła @media oraz @import w arkuszu stylów. Język: CSS /* reguła @media */ @media all and (max-width: 800px){ /*style CSS*/ } /* reguła @import */ @import url(styles.css) all and (max-width: 800px); Listing 5. Przykładowe Media Queries. Język: CSS. /* przykładowe użycie operatorów logicznych */ @media all and (min-width: 800px) and (max-width: 1366px) { /*style CSS*/ } @media not screen and (color) { /*style CSS*/ } @media only screen and (orientation: portrait) { /*style CSS*/ } /* przykładowe zastosowanie cech min-width oraz max-width */ @media all and (min-width: 320px) and (max-width: 780px) { /*style CSS*/ } /* przykładowe zastosowanie cechy orientation */ @media all and (orientation: portrait) { /*style CSS, które będą dołączone jeżeli przeglądarka jest wyższa niż szersza*/ } /* przykładowe wykorzystanie proporcji */ @media all and (aspect-ratio: 4/3) { /*style CSS*/ } @media all and (min-device-aspect-ratio: 4/3) { /*style CSS*/ } /* przykładowe wykorzystanie gęstości pikseli */ @media print and (min-resolution: 300dpi) { /*style CSS*/ } Listing 6. Technika mobile first. Język: CSS /* tutaj powinny znaleźć się domyślne style, przeznaczone dla małych ekranów */ /* poniżej dołączamy style dla coraz to większych rozmiarów */ @media screen and (min-width: 600px) { /*...*/ } @media screen and (min-width: 1000px) { /*...*/ } @media screen and (min-width: 1400px) { /*...*/ }

21 Responsywny Web Design www.sdjournal.pl To tylko wybrane możliwości, które oferują Media Qu- eries. Właściwości mediów i reguł, które je określają, ist- nieje dużo więcej. Wsparcie Co w przypadku, gdy zależy nam na starszych przeglądar- kach, w których Media Queries nie są obsługiwane? Z po- mocą przychodzą biblioteki JavaScript. • Respond.js – niewielka biblioteka, która obsługuje typ medium oraz reguły max/min width. • css3-mediaqueries.js – znacznie większa biblioteka, wspierająca bardziej skomplikowane zapytania me- diów. Ze względu na jej rozmiar należy mieć na uwa- dze potencjalny spadek wydajności. Technika mobile first Wyobraźmy sobie, że tworzymy stronę. Piszemy więc kod CSS, który dotyczy przede wszystkim komputerów. Po- tem, przy pomocy Media Queries, zastępujemy część reguł nowymi, z myślą o małych ekranach. Jaki jest tego efekt? Urządzenia mobilne wczytują i aplikują dużą część stylów tylko po to, aby je potem zastąpić innymi. To duża strata na wydajności. Technika mobile first, to podejście polegające na dołączeniu arkuszy stylów przede wszystkim dla małych urządzeń, w sposób domyślny, a następnie przy pomocy Media Queries, dodawania stylów dla coraz to większych ekranów. Przykła- dowe style CSS mogą więc wyglądać jak na listingu 6. Dosyć ważnym aspektem projektowania stron respon- sywnych jest świadomość wpływu różnych grafik oraz za- awansowanych efektów na urządzenia o małych ekranach i niewielkiej wydajności. Ich użycie może w znaczący sposób spowolnić ładowanie strony, a nawet sprawić, że urządze- nie nie będzie w stanie płynnie generować obrazu podczas przewijania. Jeżeli zastosujemy technikę mobile first do przykładu z po- czątku artykułu, to pozbędziemy się problemu zbyt wąskiej kolumny na małych ekranach. Obydwie kolumny, na małych ekranach, zostaną prze- transformowane na wiersze, co znacznie poprawi ich czy- telność. Meta-tag viewport Jest to znacznik, który określa sposób wyświetlania stro- ny na urządzeniach mobilnych. Pozwala ustawić wielkość strony oraz jej powiększenie (Listing 8). Zawartością atrybutu content jest para w postaci: dyrektywa=wartość. Istnieje możliwość wpisania po prze- cinku wielu dyrektyw. Podstawowymi są width oraz height, Listing 7. Przykład wykorzystujący technikę mobile first. Język: CSS .child-1, .child-2{ margin: 2.2222%; } @media all and (min-width: 500px) { .child-1, .child-2{ margin: 1.1111%; } .parent{ width: 100%; display: table; } .child-1{ float: left; width: 64.4444%; } .child-2{ float: right; width: 31.1111%; } } Listing 8. Przykłady użycia meta-tagu viewport. Język: HTML

REKLAMA OnLine Jeżeli jesteś zainteresowany/a reklamą swoich produktów na naszej stronie internetowej! Jeżeli jesteś zainteresowany/a wypromowaniem swojej marki wśród specjalistów IT Jeżeli szukasz klientów lub pracowników Zareklamuj się na naszej stronie! Możesz również wykupić kampanię mailingową! Posiadamy bazę 90 tysięcy specjalistów z różnych działów IT! W celu uzyskania oferty reklamowej skontaktuj się z nami: sdjpl@sdjournal.pl tel. 799 46 34 76

24 1/2015 C o takiego oferuje WebGL? Przede wszystkim do- starcza naprawdę niesamowitych możliwości two- rzenia interaktywnych stron WWW, prezentacji, aplikacji, gier 3D, które uruchomimy bezpośrednio w prze- glądarce, niemal na każdym urządzeniu. W erze powszech- nego dostępu do internetu projekty webowe mają ogrom- ny potencjał komercjalizacji. Na pierwszy rzut oka widać wiele zalet technologii WebGL, czy ma ona jakieś wady? Po pierwsze kodowanie w WebGL nie jest takie proste. Niskopoziomowość Mówiąc krótko praca w WebGL do najprzyjemniejszych nie należy. Na szczęscie istnieje API dla języka Java- script, które ,wraz ze wzrostem popularności techno- logii WebGL, przyczyniło się do wysypu bibliotek Java- script bardzo ułatwiające tworzenie scen 3D. Powstało ich naprawdę dużo, każda inna, skupiająca się na innych zagadnieniach: komercyjne projekty, githubowe kola- boracje, duże projekty dostarczjące kompleksowe roz- wiązania, mniejsze skupiające się na określonych opera- cjach, a nawet silniki graficzne , w tym jeden rozwijany w Polsce - AexolGL. AexolGL Czym dokładnie jest AexolGL? W skrócie to narzędzie do tworzenia wizualizacji, aplikacji i gier Szybki i łatwy WebGL z silnikiem AexolGL Od dłuższego czasu możemy zauważyć coraz większe zainteresowanie technologią WebGL. Wiele osób twierdzi, że technologia ta zdominuje przyszłość interaktywnej rozrywki. Czy to prawda? Wielkie koncerny walczą o jak najszersze i jak najwydajniejsze wsparcie WebGL dostrzegając jego ogromny potencjał. Dowiesz się... • Jak szybciej tworzyć multiplatformowe aplikacje. • Czym jest AexolGL. Powinieneś wiedzieć... • Panuje boom na WebGL. • Trwa wyścig gigantów z Doliny Krzemowej o jak najszersze jego wsparcie. Rysunek 1. Przygotowany do instancjonowania obiekt animowanego spirte’a z pliku JSON (C++)

25 WebGL z silnikiem AexolGL www.sdjournal.pl