Kategorie
Uncategorized

Książka „Debugowanie jak wyszukiwać i naprawiać błędy w kodzie oraz im zapobiegać”

Link do archiwalnej kopii recenzji:

http://web.archive.org/web/20170701042134/http://www.yarpo.pl/2010/11/28/ksiazka-debugowanie-jak-wyszukiwac-i-naprawiac-bledy-w-kodzie-oraz-im-zapobiegac/

Link do recenzji na oficjalnej stronie helionu:

https://helion.pl/ksiazki/debugowanie-jak-wyszukiwac-i-naprawiac-bledy-w-kodzie-oraz-im-zapobiegac-paul-butcher,debugo.htm#format/d

Kategorie
Uncategorized

Pseudo przestrzenie nazw w PHP

Archiwalna kopia do artykułu:

http://web.archive.org/web/20200108063942/http://yarpo.pl/2010/11/27/pseudo-przestrzenie-nazw-w-php/

Kategorie
Uncategorized

Wyjątki w PHP 5

Archiwalna kopia artykułu:

http://web.archive.org/web/20170724153915/http://www.yarpo.pl/2010/11/27/wyjatki-w-php-5/

Kategorie
Uncategorized

Autoloader w PHP 5

Chyba nie muszę nikogo przekonywać do tego, że warto jest podzielić kod na logiczne moduły, zamiast umieszczać wszystkiego w jednym pliku. Później można za pomocą funkcji require_once / include_once załączyć jedynie potrzebne skrypty i z tych cegiełek budować nasz system. Niestety takie rozwiązanie, prócz niezaprzeczalnych plusów, ma też minusy. W tym artykule postaram się pokazać jak owe minusy zniwelować.

Nim zaczniesz warto

  • wiedzieć cokolwiek o obiektowym PHP 5
  • posiadać serwer www (może być lokalny, np. Wamp)
  • mieć jakieś 5-10 minut

Przykład “brzydkiego” kodu

require_once 'pliki/klasa1.php'
require_once 'pliki/klasa2.php'
require_once 'pliki/klasa3.php'
require_once 'pliki/klasa4.php'
require_once 'pliki/klasa5.php'

Wady powyższego kodu

  1. Nie jest powiedziane, że wszystkie klasy będą w ogóle wykorzystane (jednak lepiej jest wszystkie require trzymać razem, niż rozsiać je po kodzie). A więc część niepotrzebnie zwalnia pracę bezcelowo się ładując.
  2. Na początku skryptu mamy wiele linii kodu, które tak naprawdę niewiele robią.
  3. Dodając następne klasy musimy pamiętać o odpowiednim zaincludowaniu ich [także o kolejności includowania w przypadku dziedziczenia itp.].

Rozwiązanie

Starczy jedynie użyć ciekawej funkcji PHP – autoload. Spójrz na prosty przykład:

function __autoload($className) {
    echo $className;
}

$obj  = new MyClass1(); // wyświetli "MyClass1"
$obj2 = new MyClass2(); // wyświetli "MyClass2"

Skoro możemy wyświetlić nazwę klasy, to czemu nie wykorzystać tego do załączenia plików z klasami! Starczy jedynie używać odpowiednich nazw.

function __autoload($className) {
    echo $className;
}

Tym sposobem możemy załączyć wszystkie potrzebne pliki. Oczywiście w folderze ‘pliki’ powinny się znajdować pliki ‘klasa1.php’, ‘klasa2.php’, …, ‘klasa5.php’. I w tych plikach powinny znajdować się deklaracje odpowiednich klas.

Poprawki

Każdy kod na początku nie jest idealny, choć często działa. Warto jednak tu zabezpieczyć sie przed jednym bardzo niebezpiecznym zjawiskiem – możliwością wywołania klasy, która nie istnieje. Warto zastosować bardzo prostą w użyciu funkcję file_exists.

function __autoload($className) {
    $path = 'pliki/'.$className. '.php';

    require_once $path;
}

$obj1  = new klasa1();

Załóżmy teraz, że nie będzie pliku ‘pliki/klasa1.php’. Co wtedy? Oczywiście powstanie błąd. Warto się przed tym zabezpieczyć:

function __autoload($className) {
    $path = 'pliki/'.$className. '.php';

    if (file_exists($path)) {
        require_once $path;
    } else {
       // rzuć wyjątek
       // zaloguj błąd
       // wyślij mejla - cokolwiek uważasz za słuszne
    }
}

$obj1  = new klasa1();

Takie wydawałoby się oczywiste i banalne zabezpieczenie pozwala nam uniknąć sytuacji, które mogą narazić nas na spore straty (od kwestii finansowych, przez zawieszenie systemu, po bezpieczeństwo i prestiż).

Co dalej

Skoro już potrafimy ładować automatycznie pliki, to warto teraz nauczyć się jak odpowiednio je przetrzymywać, aby jeszcze przyjemniej móc zarządzać naszym kodem. Ale to już jest temat na inny artykuł nt. pseudo – przestrzeni nazw w PHP < 5.3.3. W Najnowszych wersjach PHP istnieją już mechanizmy wspierające zwykłe przestrzenie nazw.

Kategorie
Uncategorized

Darmowe warsztaty programistyczne dla uczniów z Trójmiasta

Mam przyjemność zaprosić wszystkich chętnych na darmowe warsztaty programistyczne o nazwie Akademia Szybkiego Startu, organizowane przez redaktorów youthcoders.net w ramach Inicjatywy CrEuro.

Więc informacji o warsztatach na oficjalnej stronie: youthcoders.net/blog/wpisy/824-akademia-szybkiego-startu.html

Kategorie
Uncategorized

Książka „Mocne strony JavaScript”

Mocne strony JavaScript

To, że Javascript jest w tej chwili jednym z najpopularniejszych języków programistycznych świata – rzecz oczywista. To, że każdy kto chce tworzyć nowoczesne strony www wcześniej czy później JS nauczyć się musi – rzecz pewna. To, że JavaScript jest najbardziej niezrozumianym (SIC!) językiem świata – rzecz, którą warto zrozumieć.

Kategorie
Uncategorized

Książka „Head First Servlets & JSP. Edycja polska. Wydanie II”

Kopia recenzji dostępna na stronie:

http://web.archive.org/web/20170701101959/http://www.yarpo.pl/2010/11/27/ksiazka-head-first-servlets-jsp-edycja-polska-wydanie-ii/

A także na oficjalnej stronie Helion.pl:

https://helion.pl/ksiazki/head-first-servlets-jsp-edycja-polska-wydanie-ii-rusz-glowa-bryan-basham-kathy-sierra-bert-bates,hfsjp2.htm

Kategorie
Uncategorized

Unit testy

Czym są testy jednostkowe [ang. unit tests]? Jest to test działania małego wycinka systemu – jednostki. Np. metody.Testujemy jedną klasę sprawdzając, czy dla danych wejściowych zwróci oczekiwany rezultat. Z pewnością nie raz robiłeś w kodzie coś takiego (pseudokod):

function dodawanie(a, b) {
    return a + b;
}

c = dodawanie(2, 5); 

if (7 != c) {
    print "Ej, coś jest nie tak z dodawaniem dla 5 i 2.";
}

Właśnie na tym polegają unit testy. Są jednak specjalne biblioteki, które sprawiają, że:

  • Nie musisz ingerować w swój kod (powyższy przykład to robił).
  • Mogą zostać utrwalone i odpalane po każdej zmianie kodu.
  • Niektóre frameworki do unit testów potrafią w bardzo ładny graficzny sposób prezentować wyniki testów.

Zalety testów

  • Pisząc testy dokładnie wiesz jakie dane mają zostać zwrócone przez funkcję / metodę dla jakich danych wejściowych. Tak więc zanim zdążysz napisać linię kodu właściwego już dokładnie wiesz, co on ma robić. Często ta wiedza odpowiada także na pytanie: „jak ma to robić?”.
  • Programując „pod testy” nie możesz sobie pozwolić na metody robiące wszystko! Automatycznie starasz się, aby kod był podzielony na logiczne części, łatwe do testowania.
  • Możesz sobie na więcej pozwolić! Mając zestaw testów pozwalający sprawdzić zachowanie programu w każdej sytuacji możesz sobie czasem pozwolić na dziwne konstrukcje czy uproszczenia – po ponownym uruchomieniu testów (jeśli nadal wszystkie zostaną zaliczone) wiesz, że nic nie popsułeś. Bardzo przydatne podczas refaktoryzacji.
  • Testy są jednocześnie dokumentacją projektu i twojej pracy. Nikt nie zarzuci Ci, że coś nie działa z powodu twojej klasy. Starczy, że dodasz (jeśli jeszcze nie masz) test, pokrywający sytuację o której ktoś mówi i sprawdzasz, czy kod zwróci to czego oczekujesz.
  • Pozwalają lepiej zrozumieć istniejący kod. Czasem w wyniku działania testów zauważasz, że twój system działa inaczej niż wydawało ci się, że powinien. Co wcale nie musi znaczyć, że działa błędnie – ty po prostu źle rozumiałeś to jakby on miał się zachować w danej sytuacji.

Wady testów

  • Wymagają oderwania od „normalnej pracy”. Choć w definicji „normalnej pracy” testowanie i tak występuje. Tyle tylko, że jest bardziej chaotyczne i najczęściej wyklikane. Ile razy już zapomniałeś o jakiejś jednej możliwości? Pisząc testy zawsze możesz dodać kolejny jeśli coś ci przyjdzie do głowy.
  • Uważa się, że jest to praca „destrukcyjna” – w przeciwieństwie do kodowania – pracy „kreatywnej”. Niesłusznie. Testy pozwalają wykryć błędy, co pozwala je naprawić, co pozwala tworzyć lepsze programy! A więc to praca jak najbardziej kreatywna.
  • Same w sobie nie zapewniają poprawności działania programu. To, że twój program przeszedł poprawnie 120 testów, jakie stworzyłeś nie znaczy, że nie wyłoży się na 121-szym teście, który przyjdzie ci do głowy za późno i już klient wykryje ten błąd. Jednak po naprawieniu tego buga możesz uruchomić 121 testów i być pewnym, że załatanie nowo odkrytej dziury nie zepsuło niczego, co działało wcześniej! A to już jest wiele.

Tak naprawdę czy się do tego przyznajesz czy nie robisz testy. Tyle tylko, że często sam sobie robisz pod górkę zmieniając kod testowanej klasy, aby można było wyświetlić wartości poszczególnych zmiennych, czy też za każdym razem wpisując  w formularz 40 różnych rodzajów danych. Czy nie czas to zmienić? Zautomatyzować? Ulepszyć?

Jeśli podoba ci się ta idea, czytaj dalej

W najbliższym czasie mam zamiar napisać kilka artykułów o testowaniu kodu (niedawno zacząłem się tym bawić, więc najpierw sam się muszę podszkolić :P). Oto lista tematów jakie mam zamiar poruszyć z linkami do źródeł. Jeśli chcesz, możesz nie czekać na mnie:)

Kategorie
Uncategorized

Simpletest

Stary artykuł. Jego kopię można znaleźć tu:

http://web.archive.org/web/20170613172209/http://www.yarpo.pl/2010/10/31/simpletest/

Kategorie
Uncategorized

Zmiana strefy czasowej

Czasem przydatna jest możliwość zmiany strefy czasowej.  Czas – w przypadku PHP – brany jest z serwera, na którym skrypt jest odpalony.

Zdarza się jednak, że potrzebujemy czasu np. dla Nowego Jorku czy Pekinu, a nie Warszawy.

Oto przykład rozwiązania:

function dateFromTimezone($timezone, $format = "m/d/Y h:i:s A") {
    $original_time_zone = date_default_timezone_get();
    date_default_timezone_set($timezone);
    $zone_date = date($format);
    date_default_timezone_set($original_time_zone);

    return $zone_date;
}
echo dateFromTimezone("Europe/Warsaw"); // wyświetli date dla Warszawy

Jako, że drugi parametr jest opcjonalny, można także podać format daty jaki ma nam być zwrócony. O formatowaniu daty przeczytasz więcej w manualu. Jeśli nie podamy żadnego parametru uzyskamy np. „12/23/2009 12:43:13 PM”.

Więcej o ustawieniach stref czasowej w manualu PHP.