W nocy z 25 na 26 Lutego 2006 będę miał przyjemność wygłościć wykład p.t. “Backup danych w systemach FreeBSD”. Odbędzie się on w Krakowie w ramach projektu “Noc linuksożerców“.
Bo zgrany zespół to podstawa efektywnego tworzenia oprogramowania. Teraz na mojej twarzy pojawia się uśmiech jak przypomne sobie jeden z pierwszych projektów jaki wykonywaliśmy w stosunkowo nowym zespole. Ile to nie porozumień, błędów, czy wręcz kłótni wywiązało się z tak prostej rzeczy jaką była różne postrzeganie aspektów projektu.
Wszystkie następne projekty były dużo lepsze pod tym względem. Nie musieliśmy tracić czasu na uzgadnianie różnych elementów - wystarczylo tylko rzucić hasło “zrób logowanie” a osoba odpowiedziala doskonale wiedziała czego się od niej oczekuje. Może to też zasługa iż członkowie zespołu charakteryzowali się dużą kreatywnością oraz umiejętnością myślenia na stosunkowo wysokim poziomie abstrakcji.
Zgranemu zespołowi jest dużo łatwiej - wszyscy znają swoje mocne i słabe strony. Jeżeli tylko są ukierunkowani na sukces projektu ( a nie osobiste rozgrywki) wykorzystają wady i zalety żeby odnieść sukces. Dużo łatwiej także przychodzi przekazywanie ideii czy rozwiązań. Skoro wszyscy się znają potrafią odczytać intencje osoby zanim do konca zostaną one zwerbalizowane. To naprawde jest ogromna przewaga w stosunku do zespołów które nazywam “lepionymi”.
Osobiście lubie pracować z nowymi osobami. Dzięki temu poznaje inne sposoby rozumowania czy też patrzenia na pewne sprawy. Natomiast jeżeli od tego ma zależeć powodzenie projektu wole wybrać cały zespół, który jest już zgrany.
PS. Oprócz powyższych działaja tu także mechanizmy które opisałem w “Dlaczego większkość praktyk jest nieefektywna ?“
Wielu developerów nie docenia automatycznych testów aplikacji. Automatycznych - czyli takich które nie są wykonywane przez testera a przez program komputerowy.
Zazwyczaj testowanie wygląda w ten sposób że robi się testowe wdrożenie oprogramowania, daje się kilku osobom dokumentację i wydaje polecenie “przeklikania” aplikacji. Jeżeli znajdą jakieś błędy to mają je zgłościć developerom.
O ile to podejście w wielu przypadkach się sprawdza (testerzy potrafią takie rzeczy wpisywać w formatki że programiści nigdy by nie wpadli że coś takiego może mieć miejsce 
) to w pewnym momencie staje się to zbyt kosztowne. Każdorazowa zmiana w aplikacji wymaga przetestowania praktycznie całego projektu.
Tu z pomocą przychodzą automatyczne testy. O ile nie są one w stanie sprawdzać działania interface’u użytkownika (albo przynajmniej mogą to robić w ograniczonym zakresie) to do testów funkcjonalnych nadają się znakomicie. Są w stanie sprawdzić wszelkie funkcje aplikacji (ale tylko pod kątem poprawności ich działania).
Test automatyczny to poprostu kolejny program który wykonuje funkcje podstawowej aplikacji i sprawdza czy wynik ich działania jest zgodny z oczekiwaniami. Sprawdzenie może być dokonane na podstawie prostego porównania wartości, sprawdzenia wyniku w bazie danych (np.: czy funkcja zapisz_zamowienie() wykonala zapis zgodny z założeniami), czy też wykonanie znacznie bardziej skomplikowanych operacji.
Przydatność testów można zauważyć zwłaszcza podczas modyfikacji już działającego, istniejącego ( i najczęsciej przetestowanego przez ludzi) oprogramowania. Zdaża się bowiem tak iż modyfikacja w jednym miejscu implikuje “awarią” w innym. W przypadku dobrze napisanych testów będziemy w stanie błyskawicznie wykryć błąd.
Drugim przypadkiem może być sytuacja w której Klient zgłasza błąd w aplikacji (np.: ceny nie są zaokrąglane do drugiego miejsca po przecinku). Developer oprócz poprawienia błedu powinnien napisać test który to sprawdza. Pozwoli w przyszłości to uniknąć problemów jeżeli z jakiegoś powodu powyższa zmiana została wycofana z projektu.
Generalnie jest bardzo mało przypadków kiedy testy automatyczne są nie przydatne. Wymienię tylko dwa (moim zdaniem bardzo dyskusyjnych) znane mi przypadki kiedy przygotowanie testów może być nieopłacalne:
Testowanie aplikacji uważam za bardzo ważny moment w cyklu życia projektu. Aplikacje nie przetestowane raczej nie mają szans na przetrwanie. Szczególnie cenie sobie testowanie przez osoby a nie automat ponieważ często tester daje sugestie dotyczące niektóych rozwiązań. Testy automatyczne zaś doskonale sprawdzają się w przypadku dostowywania już istniejącego projektu do nowych potrzeb (np.: zupełnie innego Klienta) - dopiero wtedy dopiero widać ich wartość.
Kiedyś uważałem że tak. Obecnie jednak troche zweryfikowałem ten pogląd.
Powszechnie używanym mechanizmem przekazywania identyfikatora sesji jest cookies. Jednak od pewnego czasu część użytkowników zupełnie wyłączyczasem w swoich przeglądarkach obsługę cookies. Okazało się bowiem iż mechanizm cookies jest niedoskonały - jedną z jego wad jest fakt iż działa on bez porozumienia z użytkownikiem. Dzięki temu portale internetowe, sklepy czy też inne firmy (reklamowe) mogą zbierać informację o użytkowniku (jakie strony odwiedzał itp).
Dlatego też przekazywałem identyfikator sesji przez adres URL.
Jednak nadal wiele stron użyta cookies do przekazywania sesji nie stosując żadnych dodatkowych mechanizmów. Zatem jeżeli jakiś użytkownik uporczywie nie chce zaakceptować “dobrych ciasteczek” to raczej jest świadomy iż pewne strony mogą źle działać (zwłaszcze że domyślna konfiguracja przeglądarek pozwala na działanie nieszkodliwych cookies).
Drugim argumentem który mnie przekonał do wyrzucenia identyfikatora sesji z urla jest fakt iż wielu użytkowników przesyła między sobą linki, polecając sobie artykuły czy informacje ze stron. Dla typowego użytkownika (który nie zna takich “skarcaczy” jak http://tinyurl.com lub http://42.pl/url/ ) użycie długiego linka, wklejonego w program pocztowy może stanowić nie lada problem - link może się połamać lub być źle zinterpretowany przez klienta poczty.
Trzecim argumentem jest tzw. “kradzież sesji”. O ile w przypadku cookies jest ona troche utrudniona, to w przypadku przekazywaniu identyfikatora przez adres jest wręcz banalna - zwłaszcza jak nieświadomy użytkownik prześle koledze link do strony. Dzięki temu, kolega będzie mógł użyć takiego linka i zazwyczaj bez żadnej autoryzacji może otrzymać jego uprawnienia.
Z uwagi na powyższe argumenty uważam iż jednak lepiej przekazywać sesje poprzez - tak nie lubiane - cookies. Jeżeli ktoś nie chce ich przyjmować, powinnien pogodzić się że część stron będzie dla niego nie dostępna.
No właśnie. Dlaczego tak dziwny język programowania ma tak duży udział w rynku ? Odpowiedź nie jest jednoznaczna. Wpłyneło na to kilka czynników.
W zamieszchłych czasach, jedynym sposobem integracji bazy danych ze stroną WWW było pisanie skryptów CGI. Pisanie ich w C lub C++ było trudne i żmudne. Dodatkowo niosło ze sobą dość poważne zagrożenia związane z przepełnieniem bufora i włamaniem na serwer.
Drugą możliwością było użycie języka perl. Uruchomienie programu nie wiązało się z potrzebą kompilacji co ułatwiało wprowadzanie zmian. Dodatkowo perl był wyposażony w dużą bibliotekę (CPAN) rozszerzeń. Wśród nich znajdowały się także moduły do komunikacji z bazami danych (np.: DBI).
Perl miał jednak poważną wadę - pozwalał ( a czasami wręcz wymagał ) na tworzenie koszmarnie nieczytelnego kodu. Dzieki tej “zalecie” wielu programistów porzuciło ten język jak najszybciej mogło.
Początkowe wersje PHP były o dziwo oparta na perlu. Jednak PHP które znamy ( od wersji 3) jest zupełnie nie związane ze swoim protoplastą - służyło jedynie jako podstawowy wzór.
Wśród zalet pojawiły się międzyinnymi gotowe moduły do komunikacji z bazami danych, przystosowanie do środowiska internetowego (możliwość działania w trybach CGI, FastCGI oraz jako moduł serwera Apache ), łatwe operowanie na ciągach znakowych i prosty, przejżysty kod oparty na składni języka C. To było wszystko czego potrzebowali programiści chcący uciec jak najszybciej od znienawidzonego perla.
To jest jeden z pierwszych powodów popularności PHP. Poprostu w tamtych czasach nie było innej alternatywy - albo perl albo PHP.
Drugim powodem była jakość dokumentacji. W przypadku PHP była ona spójna, wmiare dokładna i poparta przykładami. Jeżeli zaś chodzi o perla to przydatność dokumentacji w dużej mierze zależała od twórcy danego modułu.
Te dwa powoby były podstawowe jeżeli chodzi o szybkość z jaką PHP zdobywało nowych zwolenników.
Trzecim powodem była prostota. PHP wymagał jedynie podstawowej znajomości zasad programowania. Nie było w nim kontroli typów (można było zmienne traktować jako liczbę lub jako tekst w zależności od aktualnej potrzeby), pozwalał na niechlujne pisanie a zamiast programowania zorientowanego obiektowo oferował programowanie strukturalne. Ja osobiście te właściwości traktuję jako wady, choć dla wielu były niewątpliwie zaletami.
Bardzo szybko firmy hostingowe zaczeły oferować dostęp do baz danych i PHP. Fakt iż programiści zadbali o stoworzenie modułu do najbardziej rozpowszechnionego serwera WWW jeszcze tą sprawę ułatwił.
Od tej pory każdy mógł mieć stronę WWW w PHP.
PHP jest stosunkowo niewymagającym językiem jeżeli chodzi o serwer. Na jednym serwerze można “upchnąć” wiele stron. Jest to niewątpliwe zaleta w porówaniu do Javy która jest bardzo wymagająca. Na serwerze hostingowym z Java zostanie umieszczonych nieporównywalnie mniej stron niż w PHP.
Tu pojawia się kolejna przyczyna popularności PHP - usługodawcy chcąc minimalizować swoje koszty, oferują technolgię dzięki której będą mogli pomieścić wielu Klientów na jednym serwerze (czy małej grupie serwerów). Ofert hostingu Javy czy Pythona jest bardzo mało.
I tu zataczamy koło - PHP jest popularne, ponieważ jest powszechne, a powszechne jest poniważ…