Po kolei. Osoby władne podejmować decyzje były już tak wymęczone poprzednim systemem zarządzania treścią, a z drugiej strony zachęcone ceną usługi, że sama produkcja poszła gładko i bez problemów, ku naszemu lekkiemu zaskoczeniu. Klient zastrzeżeń ani poprawek w trakcie wdrażania projektu nie zgłaszał, schody zaczęły się dopiero przy… instalacji na serwerze Klienta. Na marginesie- w efekcie koszty tej instalacji stanowiły zauważalny procent kosztów wykonania strony, a łatwo można było ich uniknąć.

W czym tkwił problem? Zwykle własne oprogramowanie instalujemy Klientowi sami, ale w tym konkretnym przypadku – ze względów “bezpieczeństwa” – było to niemożliwe. Niemożliwe było nawet uzyskanie informacji o konfiguracji serwera, a że koszt napisania instalatora nie był uwzględniony w cenie usługi, Klient nową stronę instalował sobie sam Per aspera ad astra chciało by się rzec. Instalowanie oprogramowania trwało niestety długo, w miarę możliwości (dane specjalnego znaczenia!!) służyliśmy pomocą, co sprowadzało się przede wszystkim do prowadzenia rozbudowanej korespondencji mailowej oraz licznych kontaktów telefonicznych. Nowe technologie są wspaniałą rzeczą, jednakże w przypadku przekazywania specjalistycznych instrukcji postępowania i komunikatów o błędach nie zawsze się sprawdzają.

Zaczęło być niefajnie, Klient się denerwuje (bo strona mu nie działa), my też się denerwujemy (bo Klient się denerwuje… a secundo- bo wedle naszej najlepszej wiedzy wszystko powinno chodzić jak złoto), dostępu do serwera FTP nadal nie mogliśmy uzyskać. W końcu wyjście z sytuacji godne Salomona – przyjedzie do nas pracownik ze służbowym laptopem.

Służbowy laptop połączył się z FTP bez problemu, w 30 sekund znaleźliśmy błąd, w kolejne 30 sekund uruchomiliśmy serwis.

Błąd jak się okazało był z gatunku niespodziewanych, ale łatwych do usunięcia: używany przez osobę instalującą oprogramowanie klient FTP przy przesyłaniu pliku na serwer nie poradził sobie ze znakami nowej linii i zbił jedną z bibliotek do jednej linii tekstu.

Wnioski z powyższego case study:
procedury bezpieczeństwa zakazujące wydania osobom spoza firmy dostępu do serwera (mimo podpisanej umowy i naszej propozycji  podpisania osobnej, drakońskiej, bezpłatnej umowy na instalację oprogramowania) kosztował wydawnictwo lekko licząc dodatkowe kilkaset złotych. Służbowa podróż osoby z laptopem na dystansie 100km, dzień pracy, czas poświęcony przez osobę instalującą oprogramowanie, czas – dobre dwa tygodnie – poświęcony przez pracowników z obu stron na zidentyfikowanie problemu, usunięcie problemu i na koniec na zainstalowanie systemu.

Kosztów tych można było uniknąć. Wystarczyło dać zleceniobiorcom dostęp do FTP na choćby 5 (słownie – pięć) minut, w jakiejkolwiek formie pozwalającej zapisać pliki – byłoby po problemie.  Bez opóźnienia i bez kosztów, o nerwach nie wspominając

Zasady są ważne. Ale… “naucz się dobrze wszystkich zasad, żebyś wiedział, kiedy je łamać”.

Dziś bowiem – po upływie tych kilku miesięcy – coraz więcej klientów prosi, żeby te bajery powyłączać lub przerobić. Dlaczego? Ano dlatego, że chcą poprawić statystyki swoich serwisów- a rezygnacja z lightboxa czy DHTMlowych tabów potrafi wydatnie zwiększyć ilość odsłon. Zlecenia te wykonujemy z nie mniejszą ochotą, ale sytuacja skłoniła mnie do wysondowania sprawy.

Otóż okazało się, że większość osób proszących o tego rodzaju zmiany zaczęło poważnie traktować możliwość zarabiania na reklamie, a pozostała część – porównała swoje statystyki z szacunkami o statystykach konkurencji.

Z kolei na pytanie o przyczynę zainteresowania reklamą ogólna odpowiedź brzmi – “a bo się dowiedziałem/dowiedziałam, że ja też mogę”. Co ciekawe, głównym źródłem informacji jest próba zorientowania się w zasadach działania i korzyściach korzystania z AdWords.

Pozostaje mieć zatem nadzieję, że długi ogon reklamy online będzie rósł i rósł

P.S. Do tej pory, najbardziej przemyślany pod względem nabijania odsłon serwis wskazany przez klienta, to mobile.de

Otóż od bardzo dawna wyznaję zasadę, że lepsze jest wrogiem dobrego, a pochodząca z tematu sentencja jest jednym z istotniejszych elementów spośród tych, które kładę do głowy nowym pracownikom. Zaraz po “rób backupy!”

W luźnej rozmowie na spotkaniu zdarzyło mi się wyrazić rzeczony pogląd, co doradca biznesowy skwitował prostym “Może i tak, ale wtedy nie miałbym pracy ani ja, ani pana firma nie dostałaby tego zlecenia”. Pomyślałem najpierw – ma chłop rację. Ale zaraz potem – no zaraz, przecież gdyby wszystko działało wystarczająco dobrze, nikt by nie myślał o tym, żeby coś zmieniać – w dużym biznesie po prostu nie ma pieniędzy na sztukę dla sztuki.

I tak, po zastanowieniu, uznawszy argumenty drugiej strony, pozostaję przy swoim poglądzie. Z tym jednak, że nie oznacza on awersji do wszelkiego rodzaju zmian. Oznacza tyle, że należy wystrzegać się jak ognia zmian wprowadzanych bez potrzeby i zastanownienia – tylko dlatego, że “pojawiła się nowa wersja”, albo “bo teraz jest taka nowa technologia”. Jeśli nowa wersja lub nowa technologia ma zalety, które po analizie sprawdzą się w konkretnym zastosowaniu, należy ocenić jej plusy i minusy. I dopiero wtedy podjąć decyzję o zmianach.

Inaczej może skończyć się tak jak w przypadku kilku Klientów, którzy jakiś czas temu prosili o uruchomienie na ich stronach DHTML-owo – AJAXowych bajerów, a dziś, kiedy okazało się że wyraźnie spadła ilość odsłon – proszą o to, by je usunąć. Ale to temat na osobny wpis

W sytuacji wspomnianej na początku wpisu- gdyby firma działała jak należy (w skrócie – po prostu “działała”), nie byłoby potrzeby zatrudniania doradcy i usprawniania procesów biznesowych. I wprowadzania zmian w działającym od kilku lat oprogramowaniu.

Tak jak do tej pory nie było potrzeby wymieniać sprawdzającej się, poczciwej Odry w Ośrodku Informatyki PKP w Lublinie.

W końcu cała historia społeczeństwa informatycznego to historia produktów “wystarczająco dobrych”, a nie “perfekcyjnie dobrych”. Być może sprawy zaszły odrobinę za daleko  (vide błędy w Facebooku) ale… całość działa.

Podsumowując – innowacje dobrą rzeczą są, w końcu chodzi o to aby się rozwijać. Ale nie bez planu i strategii. Pierwsze pytanie jakie należy sobie zadać przy zmianach powinno brzmieć “dlaczego chcę zmienić to i tamto”, a kolejne – “w jaki sposób owe zmiany usprawnią mój biznes”. Potem jest jeszcze pytanie o koszty zmian. I dopiero można podjąć wyważoną decyzję, która będzie miała długotrwałe i pozytywne skutki.

Otóż, na rzeczonym wideo widać, jak użytkownik wybiera opcję “Zobacz, jak wygląda Twój profil widziany przez innych” i faktycznie, widzi profil “oczami” wybranego użytkownika, a dodatkowo… widzi zminimalizowany chat tegoż użytkownika i – jak się zdaje – jego zaproszenia do znajomych (w 0:28 nie ma na górnej belce powiadomień, a w 0:45, po zmianie użytkownika – są).

Cóż, widziałem podobnego rodzaju objawy wiele razy, na szczęście nie zdarzyło nam się wypuścić ich do klienta a co dopiero puścić live. Najczęściej przyczyną był błąd tyleż durnowaty, co, jak widać, brzemienny w skutki.

Otóż, wystarczy że programista w warunku sprawdzania czy ID profilu jest zgodne z jakąś wartością, pomyli się i zastosuje instrukcję przypisania. Czyli (w wielu językach programowania) zamiast a==b napisze a=b.

Albo, trzymając się zasad DRY, użyje tego samego kawałka kodu do pokazywania “podglądu” jak i “prawdziwego widoku” profilu (co jest w zasadzie ze wszech miar słuszne), a nie wprowadzi warunków odróżniających, który widok właśnie oglądamy – “podgląd”, czy “prawdziwy”.

I w opisanym przypadku widać wyraźnie, jaką czkawką może odbić się albo chwila nieuwagi, albo nieumiejętne i zbyt sztywne trzymanie się “dobrych praktyk”.

A na koniec jeszcze jeden trywialny błąd ze stajni FB – w “Happy Aquarium”  na dole wyświetlani są znajomi, którzy też posiadają swoje akwaria. I jeśli pierwszy znajomy licząc od lewej ma swoje zdjęcie, a następni nie, to zdjęcie to będzie się powtarzać u wszystkich kolejnych znajomych. Czym to pachnie? Ano, prostym niewyczyszczeniem zmiennej w pętli, czyli błędem tak samo durnowatym jak napisanie “=” zamiast “==”

• dotychczas jako parametr funkcji .attr() można było podać funkcję- teraz można to zrobić także z większością setterów (.html(),  .css(), .val(), .append() itd.). Co więcej, jako drugi parametr wywołania tej funkcji, jQuery przekazuje teraz dotychczasową wartość elementu (jeśli można ją określić)
• funkcja .param() poprawnie serializuje tablice
• możliwość określenia kontekstu wywołania callbacków przez funkcję .ajax() i przekazanie obiektu XMLHttpRequest jako trzeciego parametru callbacka success
• wszystkie zdarzenia mogą być przypisywane przez .live() – przy czym focus i blur zastępuje focusin oraz focusout
• nowa metoda .unwrap() – jak sama nazwa wskazuje
• .nextUntil(), .prevUntil(), .parentsUntil() – pozwalają przetwarzać listę obiektów do napotkania obiektu o podanym selektorze
• możliwość tworzenia obiektów z parametrami i zdarzeniami za jednym zamachem. Czyż

  jQuery("<div/>", {
      id: "foo",
      css: {
          height: "50px",
          width: "50px",
          color: "blue",
          backgroundColor: "#ccc"
      },
      click: function() {
         $(this).css("backgroundColor", "red");
      }
  }).appendTo("body");
  

  nie wygląda pięknie?

• a na koniec przydatny drobiazg – funkcja .delay(), która wstrzymuje wykonywanie łańcucha na określony czas.

Żeby nie było tak słodko, pojawiają się powoli coraz większe problemy z kompatybilnością w dół. Bodaj najbardziej upierdliwym wydaje się ten, że skrót jQuery() przestał być równoznaczny z jQuery(document) – a był on niezwykle popularny. Na szczęście autorzy udostępniają plugin, który zapewnia całkowitą zgodność w dół.

A wszystkie szczegóły nowego wydania można przeczytać na stronie jquery14.com.

Otóż cel jest jak najbardziej zrozumiały, jednak wizja przeglądarki jako maszyny do wszystkiego wywołuje u mnie gęsią skórkę. Toć współczesne przeglądarki mają niemały problem z wydajnym i poprawnym wyświetleniem co bardziej skomplikowanych dokumentów HTML (próbowaliście stworzyć w IE tabelkę z ponad 7000 komórek?), że  o wydajnym przejęciu funkcjonalności zapewnianej dotychczas przez Flasha nie wspomnę (kto próbował zrobić przy pomocy jQuery kilka cross-fade’ów zdjęć jednocześnie wie o czym mówię). A tu jeszcze przeglądarki mają wziąć na siebie to, czym do tej pory zajmował się serwer. Ja wyraźnie czuję powiew grozy.

Wiem, że od roboczego szkicu do pełnej specyfikacji droga daleka, ale zawsze warto zastanowić się czy podąża ona w dobrym kierunku. Jeśli bowiem przeglądarka ma zapewnić wszystko co potrzebne do działania bogatej aplikacji internetowej (a te z reguły operują na dość pokaźnych bazach danych – w końcu RIA znajduje zastosowanie głównie w sprawach nietrywialnych) – gdzie jest miejsce na netbooki, będące tanią końcówką sieci? Gdzie miejsce na system w chmurze? Jak ma się idea “wszystkomającej” przeglądarki do bezpieczeństwa przechowywania i przesyłu danych? Wirtualne maszyny, które zapewniają działanie aplikacji na różnych platformach (a tym przecież byłaby taka przeglądarka) już mamy i wiadomo, że nie jest to specjalnie wydajne rozwiązanie…

Moim zdaniem, idea szczytna, acz nieco nadmuchana. W końcu do tej pory wszystko szło raczej w kierunku tego, by aplikacje działały w sieci, do której dostęp ma być łatwy i powszechny. Dlaczego więc z mozołem opracowywać platformę, pozwalającą dostęp do tejże ograniczyć?

Pomysł pewnie wyewoluuje i znajdzie zastosowania pośrednie, w których będzie bardzo przydatny- ja jednak mam przeczucie, że jest to krok w złym kierunku. Złym, to znaczy takim, w którym po raz kolejny wrócimy do wykrywania przeglądarek i pisania oddzielnego kodu dla każdej z nich… czego ani sobie, ani developerom, ani użytkownikom sieci nie życzę

Stosowanie po kolei każdej z nich (od downgradu sterowników aż do wyłączania wszystkich usług) poprawiało tymczasowo sytuację, jednak koniec końców okazywało się, że “to nie to”.  Zwołane konsylium   orzekło – pacjenta uratuje jedynie reinstalacja.

Ale reinstalacja nie pomogła. Świeży system natychmiast obciążał procesor w 100%. Szczęściem pracowniczych HP-ków nx7300 jest kilka, co ułatwiło dochodzenie – przekładanie po kolei wszystkich części dowiodło, że problem jest związany z konkretnym zestawem płyta główna/karty sieciowe/ karta graficzna.  Ale…. otwarty laptop działał sprawnie przez kilka minut, potem dopiero obciążenie skakało do 100%.  A stąd (to elementarne, drogi Watsonie;) ) prosta droga do wniosku, że problemem jest… chłodzenie. I faktycznie – pomogło… przedmuchanie wszystkich dostępnych kanałów wentylacyjnych. Bowiem rosnąca temperatura chipsetu powodowała obniżenie prędkości działania, kompletne “zatkanie” systemu, w konsekwencji wzmożoną pracę komputera, wzrost temperatury…. itd. itp. etc. Dodam, że kratki wentylacyjne wcale nie były zapchane tak, by wyglądały na wymagające przedmuchania.

Wniosek pierwszy- wyniesione z czasów świetności “pieców” i windowsa 95, 98 i XP odruchy (reinstalacja dobra na wszystko) przestały się sprawdzać.

Wniosek drugi – a właściwie informacja dla szczęściarzy, którzy jeszcze nie reinstalowali Visty – pobranie i zainstalowanie wszystkich uaktualnień do systemu dostarczanego w 2007 roku trwa ponad 20 godzin na czteromegabitowym łączu.

Osobiście wydaje mi się, że w Polsce, zwłaszcza w sektorze MSP, wpływ na to ma jeszcze jedna rzecz, kto wie czy nie istotniejsza od kwestii kosztów (choć “małemu przedsiębiorcy” łatwiej wyciągnąć z kieszeni kilkadziesiąt złotych na miesiąc niż kilka tysięcy jednorazowo).  Do niedawna, jeśli ktoś myślał o usprawnieniu działania przedsiębiorstwa za pomocą komputera, najczęściej był związany w taki czy inny sposób z branżą IT – co znaczy, że rozumiał jak działa komputer (często gęsto potrafił go złożyć z części), rozumiał jakie może przynieść korzyści. Osoba taka najczęściej miała wiedzę pozwalającą na zorganizowanie sobie “wystarczająco dobrego” oprogramowania z zasobów Open Source, zmodyfikowaniu go bądź wręcz napisanie takowego softu od zera.

Dziś te czasy się skończyły. Oprogramowania potrzebują albo wkrótce będą potrzebować wszyscy, także – a może zwłaszcza – ci, którzy komputer traktują jak większość przedmiotów codziennego użytku. Dla takich osób wyzwaniem bywa instalacja najprostszego programu, a aplikacją której obsługę mają opanowaną perfekcyjnie, jest właśnie przeglądarka internetowa.

Fakt ten dotarł do mnie bardzo wyraźnie, gdy zaprzyjaźniony pan ze sklepu spożywczo-monopolowo-warzywnego tuż obok biura, często dopytujący się “co się mogło stać z moim komputerem”, zaczął dopytywać się o program do wystawiania faktur. Po kilku dniach zaś oznajmił nagle, że korzysta z (uwaga kryptoreklama ) ifirma.pl i jest bardzo zadowolony. I to, że jest z tej usługi zadowolony, powtarza dość często.

Wydaje mi się że właśnie ten mechanizm będzie miał kluczowy wpływ na rozwój rynku aplikacji SaaS. Firm MSP jest dużo więcej, niż  tych które mogłyby zastaniawiać się czy kupić SharePointa, czy korzystać z jego modułów w modelu SaaS. Firmy MSP są bardziej elastyczne, a proces decyzyjny jest w nich sprawniejszy i nie obciążony korporacyjnymi manierami.

Jest jeszcze jeden aspekt sprawy. Dość delikatny Ludzie z branży IT często bardzo dużą wagę przykładają do prywatności i bezpieczeństwa swoich danych. I często strach przed utratą kontroli nad fizyczną reprezentacją danych jest argumentem przeciw używaniu aplikacji w modelu SaaS. Pominąwszy sporną kwestię czy SaaS jest czy nie jest bardziej niebezpieczny (laptopa łatwiej ukraść niż serwer, ale to temat na osobny wpis ) , istotnym wydaje się co innego – człowiek traktujący komputer jak sprzęt codziennego użytku, lodówkę czy golarkę, będzie się zastanawiał czy ktoś może wykraść dane tylko, jeśli będzie miał coś do ukrycia. Jeśli natomiast sprzedaje drożdżówki pracownikom biurowym i nalewki okolicznym pijaczkom, nie będzie się zastanawiał czy ktoś mu nie ukradnie faktur bo zwyczajnie jest to dla niego bez znaczenia – tak samo zresztą, jak dla potencjalnego złodzieja.

Przenosząc odrobinę przewrotnie ten aspekt sprawy na rynek IT – po co zamykać w sejfie dokumentację do swoich projektów, skoro 80% z nich to po prostu “stronka firmowa z sekcjami o nas, oferta, kontakt, i jeszcze jakimś katalogiem produktów”, a pozostałe 20% to i tak projekty jakich prowadzi się wiele ?

Podsumowując – rynek usług SaaS rusza. I bardzo dobrze, pozwoli to bowiem na zinformatyzowanie wielu procesów w wielu firmach, które bez tego rodzaju dystrybucji oprogramowania miałyby dostęp do dużo mniejszej ilości dużo mniej zaawansowanego oprogramowania.

Ta ciekawa informacja skłoniła mnie do refleksji nad tym, co takiego specjalnego jest w naszym “dogadywaniu się”. A czego, jak można wnioskować z reakcji szacownego Grona, często przy tworzeniu oprogramowania brakuje. Wnioski w skrócie można przedstawić za pomocą jednej z głównych zasad SCRUM-u : “it’s all about common sense”.

Zaangażowanie. Potrzebne jest z obu stron- do tego, aby każda z nich mogła dostarczyć drugiej informacje, o jakie prosi. Czy będą to dokładne wzory na obliczanie podatków, czy informacja co można, a czego nie można zrobić, czy cokolwiek innego. Sprawa niby oczywista, ale w przypadku projektu, który trwa miesiącami łatwa do pominięcia, zwłaszcza ze strony Klienta, który ma przecież swoje zajęcia i nie zawsze musi przejmować się programem który “się pisze”.

Zrozumienie dla niezrozumienia. Niektórych  informacji trzeba udzielać wielokrotnie, tłumaczyć, wyłuszczać i wyjaśniać. Informacji, które leżą u podstaw zawodu jednej ze stron projektu, ale drugiej – niekoniecznie. Choćby wydawały się nie wiem jak proste – na przykładzie projektu dla biura księgowego widać to idealnie. Dla przykładu: członkowie naszego zespołu potrzebowali niekiedy dokładnego rozpisania i wielokrotnego wyjaśniania obliczeń podatkowych,  które Klient początkowo opisywał jednym krótkim zdaniem.  Z drugiej strony, niejeden raz musieliśmy wyjaśniać że aplikacja obsługiwana przez przeglądarkę to nie to samo co aplikacja desktopowa.

Przyjęcie niezrozumiałych potrzeb. Tak jak Klient nie musi rozumieć, dlaczego właściwie niektórych druków nie można drukować bezpośrednio z przeglądarkowego “drukuj”, tylko muszą przejść przez PDFa, skoro “ten inny druk można tak wydrukować”, tak samo projektant UI nie musi rozumieć dlaczego dwa pola formularza muszą być koniecznie obok siebie, a nie jedno pod drugim. Od strony zespołu tworzącego system oczywiście “wszystko jest kwestią czasu i pieniędzy”, ale działając w określonych realiach – trzeba niektóre rzeczy trzeba po prostu przyjąć. Bo “tak musi być”.

Unikanie hermetycznego języka. W zasadzie jest to pochodna “zrozumienia dla niezrozumienia”, ale zdaniem naszego Klienta, jest to tak ważne, że musi być wymienione oddzielnie Księgowy naprawdę nie musi wiedzieć, ani do sprawnego przeprowadzenia projektu nie jest potrzebne by się nauczył, czym różni się HTTP od WWW. A członkowie zespołu tworzącego soft do końca prac nie muszą wiedzieć czym są “konta grupy 7″.

Dodatkowo, przy tworzeniu tak rozbudowanego systemu, wydaje się że najbardziej naturalnym sposobem prowadzenia projektu jest zastosowanie zasad SCRUM – obu stronom najłatwiej zaakceptować prace prowadzone właśnie w tym modelu.

I to wszytko. Bo do tego, żeby udał się jakikolwiek projekt, potrzeba przede wszystkim zdrowego rozsądku.