Archive for November, 2009
Znów co nieco o warstwie modelu w architekturze MVC
Wiem, że ciągle nawijam o tym samym, że modele są ważne. Ale to ma sens i znalazłem jego potwierdzenie w książce, którą teraz czytam: Agile. Programowanie w Rails.

Znalazłem tam ciekawy fragment na temat warstwy modelu, który zacytuję (mi w rączki wpadła angielska wersja, więc tłumaczenie będzie moje):
Model to coś więcej niż tylko dane; wspiera wszystkie reguły biznesowe które odnoszą się do danych.
Na przykład, jesli zniżka nie powinna być stosowana dla zamówień na kwotę mniejszą niż 20 dolarów, model wspiera to ograniczenie.
To jest sensowne; poprzez umieszczenie implementacji tej reguły biznesowej w modelu mamy pewność, że nic innego w naszej aplikacji nie może sprawić, że nasze dane będą nieprawidłowe.
Model spełnia dwie role: pilnowanie bramy i przechowywania danych.
Świetna książka o wytwarzaniu oprogramowania (i o SCRUM)
Jeśli masz w jakikolwiek sposób do czynienia z wytwarzaniem oprogramowania to mam dla Ciebie naprawdę dobrą książkę.
Sprawne zarządzanie projektami metodą Scrum
Jeśli metodyka używana aktualnie u Ciebie w firmie Cię męczy, jest to typowy waterfall i czujesz, że nie do końca pasuje- w tej książce znajdziesz ciekawe przypadki opisujące podobne problemy.
Jeśli jesteś managerem, albo właścicielem firmy i wydaje Ci się, że nie ma nic lepszego niż model wodospadowy – na prawdę ta książka może Cię zainteresować. Być może po jej lekturze inaczej spojrzysz na swoją firmę.
Nawet jeśli jesteś grafikiem, które kwestie techniczne zleca “zewnętrznej firmie” – książka ta pozwoli Ci inaczej spojrzeć na tą współpracę. Bardzo możliwe też, że zaczniesz dostrzegać problemy, których istnienia nie do końca zdawałeś sobie sprawę. A to pierwszy krok do ich usunięcia.
Sam czytałem tą pozycję i stwierdzam, że wbrew pozorom nie jest przeznaczona tylko dla programistów:
W momencie, kiedy aplikacje stały się bardziej skomplikowane, a ilość udziałowców projektu wzrosła, w celu koordynacji komunikacji między zwiększającą się liczbą uczestników zaczęto stosować pewne zasady. Na przykład, ze względu na dużą ilość zaangażowanych udziałowców, zaczęliśmy zbierać wymagania przed rozpoczęciem tworzenia oprogramowania.
To jest pierwszy krok do modelu waterfall. Dodając do tego szczyptę problemu z ustalaniem kontraktów, które mogą wyglądać tak:
Jeśli zgadzacie się, że to co wam pokazałem jest pełnym opisem waszych wymagań, będziemy kontynuować. Jeśli się nie zgodzicie, będziemy kontynuować dopracowywanie wymagań do momentu, aż się poddacie.
… i jako efekt K. Schwaber celnie trafia w sedno:
Każdy kolejny krok tworzył coraz to większą przepaść między udziałowcami i programistami. Przeszliśmy od komunikacji twarzą w twarz do tworzenia dokumentacji. (…) Z perspektywy czasu, im bardziej ulepszaliśmy praktyki inżynierii oprogramowania, tym bardziej poszerzaliśmy przepaść między udziałowcami a programistami. Ostatnim etapem separacji było wprowadzenie metodologii kaskadowej, która wciela w życie wszystkie wady programowania sekwencyjnego.
Wave dodaje więcej zaproszeń!
Dostałem więcej możliwych zaproszeń do Wave’a. Chętnie dam je osobom, które naprawdę chcą ze mną tą usługę testować.
Dotychczasowi obdarowani przeze mnie jakoś zapominają używać tego narzędzia, a mnie interesuje jak ono spisuje się w faktycznych warunkach.
Dlatego dam 5 zaproszeń osobom, które w komentarzu opiszą dlaczego chcą używać Wave. Pierwsze trzy wpisy dostaną na pewno zaproszenie. Dwa wybiorę wśród najciekawszych odpowiedzi
.
Poza tym jedno ekstra wymienię na zaproszenie do sandboxa – proszę również o info w komentarzu.