Monthly Archives: December 2009

Plany są po to, żeby je zmieniać!

Posted on by
Reply

Dziś lekki, łatwy i przyjemny temat. Gdy zaczynasz jakiś projekt – ważne abyś miał/a plan. Bez tego trudno zrobić ten (najtrudniejszy podobno) pierwszy krok. Jednak o planie przedsięwzięcia myśl jak o planie podróży samochodem.

Gdy wybierasz się w samochodową wycieczkę wiesz gdzie startujesz, jaki jest cel i jakie po drodze punkty należy odwiedzić. Oczywiście masz też plan co do tego jakimi drogami pojedziesz. Jednak w pewnym momencie trafiasz w remont drogi. Oczywiście modyfikujesz nieco wykonanie w stosunku do planu – nie jedziesz po placu wykopu, bo taki był plan ale używasz objazdu.
Jak złapiesz defekt zatrzymujesz się i zmieniasz koło – nie kontynuujesz jazdy po to, aby się trzymać harmonogramu. To jest przecież oczywiste, kiedy jedziesz samochodem.

Niestety w trwającym projekcie (oczywiście chodzi mi głównie o te informatyczne) nie jest to już takie oczywiste. Trzymanie się planu jest często kluczowe i tak jak jazda bez powietrza w kole, lub po placu budowy grozi uszkodzeniem pojazdu, tak kurczowe trzymanie się planów w projektach informatycznych zwiastuje kłopoty. Nie będę zagłębiał się w szczegóły, ale możecie wierzyć mi na słowo, że widziałem to w działaniu przynajmniej raz :)

Co jednak można zrobić, gdy Twój szef lub klient na razie tego nie może zrozumieć? Możesz mu wysłać link do tego wpisu ;) lub podać mu przykład z samochodem. Ważne jest, aby zrozumiał (i Ty również!), że różnica pomiędzy planem i jego wykonaniem nie musi być wyznacznikiem tego, że plan był zły. Oczywiście im gorszy plan (zakładający, że uda się przejechać 300km w godzinę), tym częściej trzeba go modyfikować.
Często modyfikacja planu oznacza, że zmieniają się warunki.
Konkretniej – zmienia się Twój zasób informacji o otoczeniu, które wpływa na projekt. Tylko głupiec nie będzie reagował na takie zmiany. Osoba rozgarnięta uzna je za zło konieczne, geniusz być może dojrzy w nich szansę na sukces.

Tym optymistycznym akcentem życzę wszystkim planów na nowy rok sięgających nieba, których nie będziemy bać się zmieniać, kiedy zajdzie taka potrzeba.

Testowanie AppModel

Posted on by
Reply

Mam kilka metod w AppModel, potrzebowałem pokryć je testami. Różni się to nieco od testowania zwykłych modeli.

Najpierw analogicznie do innych testów stworzyłem app_model.test.php:

App::import("model", "AppModel");

class AppModelTest extends CakeTestCase {
   var $name = "AppModel";

   function start() {
      parent::start();
      $this->AppModel = ClassRegistry::init("AppModel");
   }

Problem w tym, że dostaniesz wtedy Missing Database (“app_models”).

Nie możesz w AppModel ustawić atrybutu useTable na false, bo wszystkie modele go dziedziczą. Tzn. jest to możliwe, ale w takim wypadku we wszystkich modelach, które jednak są połączone z tabelami w bazie należałoby explicite podać $useTable = ‘nazwa_tabeli’

Odeszlibyśmy wtedy od Convention over Configuration, poza tym za dużo roboty. Ale można zastosować trick. Stworzyć klasę, która “zasłoni” naszą AppModel, ale będzie działać tak samo (nazywa się to Mock Classes, albo Mock Objects, albo i tak, i tak na pewno ;)):

App::import("model", "AppModel");

class DummyAppModel extends AppModel {
  var $useTable = false;
}

class AppModelTest extends CakeTestCase {
   var $name = "AppModel";

   function start() {
      parent::start();
      $this->AppModel = ClassRegistry::init("DummyAppModel");
   }

I będzie działać :)

Seban i Flaker

Posted on by
Reply

Kto by pomyślał, że będę się bawił w mikroblogowanie? No i okazało się, że w ten sposób wpadł do mnie Seban i był tak uprzejmy iż zostawił komentarz z ciekawą pozycją do przeczytania.

Z ciekawości poczytałem też jego blog i muszę powiedzieć, że jest interesujący, dlatego zdecydowanie mogę go polecić.

Oby więcej takich rozgarniętych blogowiczów w okolicach Agile, WebDevelopment i pokrewnych.