NetBeans 6.8 - wymarzone IDE nie tylko do JAVY

Ostatnimi czasy przyszło mi sporo pisać w xhtml/css/php... Tak dokładnie, do czego to już doszło :D

Dzisiaj jednak ostatecznie przekonałem się o wyższości NetBeans nad takimi środowiskami jak Eclipse PDT czy Aptana Studio. Żeby to jakoś uargumentować no to napiszę co mnie tak urzekło ;-)

Drogi kliencie, czy wiesz za co płacisz?

Idąc za ciosem po publikacji luźnych myśli, postanowiłem naświetlić Wam - moi drodzy klienci - kosztorys dobrej aplikacji. Często wchodzicie na stronę firmy zajmującej się tzw. webmasterką i chcecie im zlecić wykonanie strony firmowej. Co firma to inne ceny i przeróżne hasła zachęcające do skorzystania z ich usług.

Marketing tutaj odgrywa bardzo ważną rolę, ale czym tak na prawdę jest reklama? Czy zawsze mówi prawdę? Reklama jest jak lep na muchy - w tym przypadku na Was drodzy klienci - mający przyciągać masy. A co wiecie o produktach masowych? Znacie idealne rozwiązania dla każdego? A może jakiś półprodukt? I nie mówię tutaj o chlebie czy maśle, ale o generatorach witryn internetowych. Tak dokładnie, tych generatorach które pozwalają za pomocą 2-3 kliknięć "zbudować" stronę. Nie będę wnikał jak ta strona wygląda, co oferuje i czy reprezentuje jakąkolwiek jakość...

Mogę powiedzieć za to czym powinien się charakteryzować produkt naprawdę wysokiej jakości. Produkt który zrealizuje zapotrzebowanie klienta, który będzie zrobiony "na miarę". Chyba tego za każdym razem oczekujecie? Chcecie otrzymać coś dobrego, wydajnego i użytecznego...

Kolega lubi używać porównania "mercedes vs polonez", ale moim zdaniem nie tak należy do tego podejść. To porównanie niestety nie oddaje złożoności problemu i często gęsto daje złudny obraz. Każda strona czy aplikacja webowa to długi i skomplikowany proces produkcji, gdzie macie kontrolę nad każdym jej etapem. To jest jak układanie domino, gdzieś się popełni błąd i klocki lecą...

Przejdźmy może do pytań jakie powinniście sobie zadać zanim zamówicie jakąkolwiek aplikację:

• czego ma dotyczyć?
• ile odwiedzin dziennie/tygodniowo/miesięcznie się spodziewacie?
• czy jest to produkt na lata? A może chwilowy/tymczasowy?
• czy będziecie przetrzymywać tam wartościowe informacje?
• będziecie gromadzić informację o klientach?
• będą prowadzone statystyki?
• czy aplikacja ma być bezpieczna? Odporna na ataki? Jeśli tak to jakie?
  
• jakiego typu treści będą umieszczone?
• jaki charakter prezentowania treści wybierzecie?
• na jakim hostingu będzie działała aplikacja? Jakie są parametry tego hostingu?
  

i wiele, wiele innych...

Odpowiedzi jakich udzielicie na powyższe pytania w bardzo dużym stopniu wpłyną na sposób wykonania aplikacji i technologię w jakiej zostanie ona wykonana. Zadałeś/aś sobie te pytania? Udzieliłeś/aś na nie odpowiedzi? A teraz najważniejsze, czy widzisz złożoność problemu?

Wyprodukowanie dobrego oprogramowania, to nie jest kwestia 5-10min. Czy jeśli idziesz gotować obiad, ogranicza się to do wlania wody do garnka i postawienia na kuchence gazowej? To może przestawię Ci z grubsza jak wygląda proces wytwarzania dobrego oprogramowania:

1. Spis wymagań
• podstawowe założenia aplikacji
• spis funkcjonalności
  
2. Przypadki użycia
• dokładny opis działania
• diagramy przypadków użycia
3. Model klas
4. Przygotowanie środowiska testowego
   
5. Wytwarzanie aplikacji
6. Refaktoryzacja -> wersja release
7. Oddanie aplikacji

Nakreśliłem ten plan w mocno przewrotnej formie, ponieważ rozpisałem kroki w których Ty drogi kliencie, bierzesz udział. Jak by zebrać tak procentowo to pierwsze 2 punkty stanowią jakieś 3-5% całości projektu. Więc dlaczego nie wyolbrzymiłem jakże żmudnej pracy zleceniobiorcy? Dlatego, że nic by Ci to nie powiedziało drogi kliencie, a szukanie wyjaśnień wszystkich etapów i tak by nie oddało nakładu pracy jaki zostanie w to włożony.

Jak widzisz wybieram to co dla Ciebie jest ważne, bo to Ty decydujesz czego potrzebujesz. A teraz wyobraź sobie, że zmiana decyzji w trakcie wytwarzania aplikacji, czyli pisania kodu źródłowego potrafi nieść za sobą olbrzymie zmiany w całej architekturze. Możesz podejść do tego jak do zmiany szerokości tylnej kanapy w samochodzie - na szerszą ;-) Nie dość, że trzeba zmienić karoserię to i po zmianie karoserii całe podwozie...

Chcesz czy nie, to na Twoich barkach w znacznej mierze leży jakość wytworzonej aplikacji i czas jej realizacji. A "my" tak jak i Ty nie wiemy wszystkiego. Bardzo często dochodzi do potrzeby rozwiązania problemów powstających w trakcie pisania kodu.

Wszystkie powyższe czynniki składają się na jakość aplikacji. Ktoś może wykona to 10x taniej i będzie tak samo wyglądać, ale czy spełni te wszystkie wymogi jakie postawiłeś? Zapewni bezpieczeństwo Twoim danym i danym klientom? Będzie odporna na większość ataków? Czy będzie się nadawać do umieszczenia na Twoim hostingu? Czy nie będziesz musiał co miesiąc dopłacać do hostingu, ponieważ zacznie generować zbyt duży ruch? A może będzie generować tak duże obciążenie serwera, że nie przyjmie odpowiedniej ilości jednoczesnych wizyt? No ale przecież będzie wyglądać tak samo! I będzie tanio!

Więc tak na prawdę zastanów się mój drogi kliencie, na czym tak na prawdę Ci zależy. I miej świadomość, że dobrze wykonana aplikacja, nie będzie kosztować 200zł a wielokrotność tej sumy. A ktoś kto będzie wykonywać Twoje zlecenie, musi mieć już dobrze opanowany kunszt oraz olbrzymią wiedzę, żeby wiedzieć, jak spełnić Twoje oczekiwania.

Jedyne czego mogę Ci życzyć, to dobrych decyzji i udanych "zakupów".

Moralność a cena...

Witam wszystkich czytelników. Dzisiaj nieco odbiegnę od standardowej tematyki swoich wypowiedzi. Gałąź webmasterska rozwija się bardzo dynamicznie. Zewsząd zalewają nas frameworki aplikacyjne pozwalające niewielkim nakładem pracy stworzyć "coś"... Naturalnie przyciąga to coraz więcej ludzi, ponieważ staje się prostsze i przystępniejsze. Powstaje bardzo dużo (video)tutoriali związanych z tworzeniem prostych aplikacji i witryn internetowych. Naturalnie poruszają one podstawy, niewielki zakres jakim powinna cechować się dopracowana strona. I właśnie tutaj zaczyna się problem...

Z życia codziennego, kiedy zgłasza się do Was klient z prośbą o wycenę konkretnego projektu, co bierzecie pod uwagę? Bezpieczeństwo, optymalizację, interaktywność, wodotryski, grafikę...? Kolejność wymienianych elementów nie jest bez znaczenia, całkiem celowo podałem właśnie taką konfigurację.


Uwzględniając taką konfigurację i rzetelnie wyceniając czas jaki to zajmie, nakład pracy jakiego wymaga projekt, jaką odpowiedź odnośnie ceny dostajecie? Czy słowa "Ile?! Przecież inni to zrobią za 10x mniej!", brzmią znajomo? Czy jeśli uwzględnicie wszystkie aspekty stać Was na podjęcie się takiego zlecenia za 200zł?

Patrzę na to co się dzieje z niedowierzaniem i zastanawiam się gdzie leży tego przyczyna? Dochodzę do wniosku, że to przez "programistów" co zajmują się odpalaniem darmowych projektów na hostingach, oraz osoby które mają znikomą wiedzę na temat wytwarzania oprogramowania. Nie zdają sobie sprawy z olbrzymich niedociągnięć wytwarzanego przez siebie oprogramowania. Ich niewiedza przyczynia się również, do niesamowitego mniemania o sobie... Zdecydowany brak pokory wobec siebie i innych.

Z drugiej strony niczego nieświadomi klienci... Nie zdają sobie sprawy z niebezpieczeństw na jakie są narażeni, na lichą jakość produktu który otrzymują. Dla nich, jeśli ładnie wygląda i coś tam się rusza to jest super! Tego właśnie chcieli... Co z tego, że mogę spam rozsyłać przez ich formularz kontaktowy... Nieważne, że wstrzyknę kod SQL i skasuje im wszystkie informacje w bazie danych... Dlaczego? Bo ktoś zrobił im to tanio!

Robicie tak samo? A może uświadamiacie klientów jakie zagrożenia niesie ze sobą tania aplikacja?

Niesamowity jest fakt, że ludzi nie obchodzi ile transferu zużyje ich aplikacja, jakie obciążenie będzie generować i ile luk bezpieczeństwa posiada... Płacą za pozycjonowanie, wykupują dobre hostingi, dopłacają do transferu a jeden "niewinny" atak umieszcza ich serwer na czarnej liście.

A teraz odpowiedź sobie na pytanie, jakim jesteś developerem/klientem? Czy moralne jest nieuświadamianie klienta o tym co dostaje? A jeśli go uświadomimy, czy moralne jest podjęcie się produkcji bubla?

Ukradli sesję!

Już jakiś czas rozmawiam ze znajomymi o zabezpieczeniach. Większość zgodnie używa do zabezpieczenia po stronie PHP sesji, ale czy używa ich prawidłowo? Do tego dojdziemy, ale zacznijmy od spraw oczywistych.

Czym jest sesja i do czego służy? Sesja to odmiana ciasteczka charakteryzująca się tym, że wszystkie dane sesji trzymane są po stronie serwera. Wydaje się być to najbezpieczniejszym rozwiązaniem ponieważ użytkownik posiada jedynie ID sesji i nie ma bezpośredniej możliwości manipulowania danymi zawartymi w sesji. Super mamy coś czego nikt nam nie zmieni!

Z w.w. powodu sesja to bardzo dobry sposób na trzymanie stanu zalogowania użytkownika oraz podstawowych danych sesji. Jednak jest tego zasadniczy minus. Co jak ktoś przechwyci sesję?

HTTP jest protokołem bezstanowym, dlatego każdy kto posłuży się ID sesji ma do niej dostęp. Załóżmy, że Janek zalogował się do serwisu i otrzymał identyfikator sesji ab12c. Następnie sytuację gdzie Krzysiek logując się do serwera lub też niekoniecznie po przez logowanie - celowo/niecelowo - otrzymuje ID sesji taki sam jak Janek. W tym momencie jeśli Krzysiek celowo przejął ID sesji Janka, dla serwisu jest Jankiem.

Przykry scenariusz, jednak jesteśmy na niego narażeni, jeśli nikt nie zabezpieczył się przez przechwyceniem sesji. Ale jak się zabezpieczyć? - zapytacie. Otóż istnieje bardzo prosta technika:

1. przy tworzeniu sesji zapisujemy w sesji IP usera który powołał sesję do życia
2. przy następnych zapytaniach porównujemy IP zapytania z IP w sesji
3. jeśli IP się nie zgodzi niszczymy sesję

Ten prosty sposób już sporo nam daje, lecz kiedy zawiedzie? Chociaż by, w sytuacji gdy Jan i Krzysiek są użytkownikami tej samej sieci lokalnej, która do komunikacji z internetem używa tej samej bramy. Możliwe, że Janek łączy się przez proxy, jeśli Krzysiek użyje tego samego proxy nasze zabezpieczenie również zawiedzie.

Jak się ustrzec przed tymi, jaki i kolejnymi potencjalnymi atakami napiszę w części 2 (w bliżej nie określonym terminie).

Kodowanie znaków amfphp & mysql

Przechodząc od razu do rzeczy, kodowanie bazy i tabel należy ustawić na utf_polish_ci - jeśli aplikacja będzie używała jedynie języka polskiego, jeżeli nie utf_general_ci - natomiast w serwisach phpowych łączyć się z bazą danych w następujący sposób:

mysql_connect( $host, $user , $pass );
mysql_select_db( $dbase ); 

@mysql_query("SET NAMES 'utf8';");
@mysql_query('SET CHARACTER SET utf8;');

 Dzięki mooska za refresh :D

W bramce komentujemy zmianę kodowania w locie. Tutaj nam się to nie przyda ;-)

Zapis logów do pliku w PHP

Ostatnio napisałem sobie Loggera w PHP. Prosta aczkolwiek bardzo przydatna klasa. Poniżej zamieszczam pełny kod.

<?php
define( 'LOGGER_NEW_LINE' , "\r\n" ) ;

class Logger
{
/**
* Jedyna instancja klasy
* @var Logger
*/
private static $_instance = null ; 

/**
* Zwraca jedyną instancję klasy
* 
* @return Logger
*/
public static function getInstance()
{
if( is_null( self::$_instance ) )
{
self::$_instance = new Logger() ;
}

return self::$_instance ;
}

private $absolute_path ;
private $logs_path ;
private $date ;
private $log_file ;

/**
* W konstruktorze następuje połaczenie z bazą danych.
* 
* @return Logger
*/
private function __construct()
{
$this->absolute_path = dirname( __FILE__ ) . '/' ;
$this->logs_path = $this->absolute_path . 'logs/' ;
$this->date = date( 'Y_m_d' ) ;
$this->log_file = $this->logs_path . 'logs_' . $this->date . '.log' ;

$this->clearOldLogs( 5 ) ;
}

/**
* Usuwa stare pliki logów
* @return unknown_type
*/
private function clearOldLogs( $maxHistory )
{
$files = glob( $this->logs_path.'*.log' ) ;

$this->log( $files , __FUNCTION__ , __CLASS__ , __FILE__ , __LINE__ ) ;

// przerwanie usunięcia jeśli plików jest zbyt mało
if( sizeof( $files ) <= $maxHistory )
return ;

for ($i = 0; $i < sizeof( $files ) - $maxHistory; $i++ )
{
unlink( $files[ $i ] ) ;
}
}

/**
* Zapis danych do pliku
* @param $data        Dane do zapisania w logu
* @param $function    Zawsze jako parametr podawać __FUNCTION__
* @param $class    Zawsze jako parametr podawać __CLASS__
* @param $file        Zawsze jako parametr podawać __FILE__
* @param $line        Zawsze jako parametr podawać __LINE__
*/
public function log( $data , $function , $class = null , $file = null , $line = null )
{
ob_start( $log_str ) ;
echo date( 'H:i:s' ) , '    ' , $class , '::' , $function , '    in    ' , $file , '    on line    ' , $line , LOGGER_NEW_LINE ;
var_dump( $data ) ;
echo LOGGER_NEW_LINE , LOGGER_NEW_LINE ;
$log_str = ob_get_contents() ;
ob_end_clean() ;

$log_str = str_replace( array( "\r\n" , "\n" ) , LOGGER_NEW_LINE , $log_str );
file_put_contents( $this->log_file , $log_str , FILE_APPEND ) ;
}
}

?>

A o to przykład użycia:

Logger::getInstance()->log( $someData , __FUNCTION__ , __CLASS__ , __FILE__ , __LINE__ ) ;

Logger zapisuje dane w formie wyświetlanej przez funkcję var_dump.