Climbus Blog

Ostatnio trochę bawię się railsem i zdenerwowała mnie jedna śmieszna kwestia.

A było to tak:

Robiłem model zamówienia i pomyślałem sobie, że przydało by sie pole “hash” w bazie. A tu bach wyjątek. Konflikt z funkcją “hash” podstawowego obiektu rubiego. Ok, będzie brzydko nazwałem pole po polskiemu “hasz” :(

Idziemy dalej: model do wymiany danych za pomocą xml’a. Wymyśliłem sobie metodę “send”, która wyśle przygotowany wcześniej xml. A tu bach, metoda “send” obiektu rubiego. Ok, bedzie “send_xml”.

Cholera, każdy obiekt ma ponad 40 publicznych metod na starcie. Teraz boję się dodawać nowe atrybuty do klasy bo nie znam dnia i godziny kiedy znowu natrafię na magiczną wbudowaną metodę :)

Ciężkie jest życie człowieka, który chce poznać nowe, fajne technologie ale przyzwyczaił się do minimalizmu pythona.

Zawsze uważałem, że nazywanie Railsa Java killerem to gruba przesada. I dalej tak myślę, lecz po bliższym poznaniu RoR’a muszę mu zwrócić trochę honoru. To co mocno uderza to kompleksowość frameworka. Widać jak twórca RoR wyciąga wnioski z procesu tworzenia web-aplikacji. Wszystko z czym spotyka się przeciętny autor serwisów internetowych ma podane na tacy. Od projektowania struktury bazy, wersjonowania jej i łatwego przenoszenia (migracje), przez wprowadzanie testowych danych (scaffold) a kończąc na łatwym deployingu (capistrano). Prawie każde pytanie znajduje odpowiedź w funkcjonalności.

RoR jest przygotowany profesjonalnie. Nie widać zbyt dużo niedoróbek czy luk w myśleniu. To co można spotkać nieraz w innych frameworkach, gdy autorzy skupiają sie na jakiejś funkcjonalności pomijając lub zapominając o innych (np. czyszczenie sesji w Pylonsie).

Konwencja nad konfiguracją wprowadza też dużo porządku w kodzie. Uczy programistów jak ważny jest ład w nazewnictwie.

Do tego jeszcze takie szczegóły jak pokazywanie w trybie developerskim czasu wykonania wszystkich sql’i oraz stron.

Naprawdę warto się zainteresować Raislem nawet tylko po to aby zobaczyć dobrze przygotowany soft. Soft, który napędza coraz większa społeczność, która zdaje się dobrze przy tym bawić.

Tylko wielka szkoda, że to jest Ruby, a nie Python …

Warto wspomnieć, że ludzie od Pylonsa jakiś czas temu uruchomili projekt zbierający dokumentację na temat różnych frameworków webowych napisanych w Pythonie. Jest to kolejny dowód na to, że Pylons wyróżnia się chęcią integracji różnych rozwiązań. Nie skupia się na samym sobie lecz stara się pomóc we wspólnym rozwoju tzw “web pythona”.

Na razie większość artykułów odnosi się do Pylonsa ale można liczyć, że w niedalekiej przyszłości pojawią się teksty o TurboGears, Paste itp.

Zachęcam do odwiedzania: http://docs.pythonweb.org/.

Programowanie to prosta sprawa :-) Gorzej jest z komunikacją z użytkownikami. Pomijam tu kwestię tłumaczenia wymagań i oczekiwań na postać bardziej precyzyjną, technicznie możliwą do wykonania. Obecnie skupiam się bardziej na kwestii przyjmowania zleceń i poprawek. Bardzo mnie zastanawia jakie są granice godzenia się na pomysły i terminy wykonania proponowane przez użytkowników. Kiedy można się zgodzić na daną poprawkę a kiedy należy odmówić.

Jedna zasada jest prosta. Jeżeli coś obiecasz użytkownikowi musisz to wykonać w terminie. Żeby się nawet waliło musisz to zrobić bo dałeś słowo. Dlatego obiecywać trzeba z umiarem. Tylko jak znaleźć ten umiar. Jeżeli będziesz odmawiał zbyt często użytkownicy będą równie źli jak wtedy gdy coś obiecasz i nie zrobisz. A może nawet bardziej.

W swojej praktyce spotkałem różnych programistów. Często stosują prostą kolejkę FIFO. Pierwsze przyszło robię to i jak skończę to biorę następne. Śmieszniej jest jak programista stosuje kolejkę LIFO. Robi coś a gdy zadzwoni ktoś z jakimś problemem zostawia to co robił i zajmuje się kolejną sprawą. Potem kolejny telefon i sytuacja się powtarza. O problemy przy takim rozwiązaniu nie trudno. Tacy programiści powinni mieć nad sobą dyspozytora, który przydzieli im zadania i sprawdzi ich wykonanie. Czasami odłoży jedno zadanie i wpuści na chwilę inne.

Dyspozytor (np. team leader) lub samodzielny programista ma trudne zadanie. Musi mocno się namęczyć aby znaleźć złoty środek. Kiedy coś przyjąć, kiedy coś odłożyć a kiedy odmówić. Zależy to nie tylko od rodzaju projektu ale też od rodzaju użytkownika (wewnętrzny, zewnętrzny) a nawet od charakteru człowieka z którym ma do czynienia.

Pracowałem z użytkownikami wewnętrznymi oraz z zewnętrznymi i są to różne relacje. ciężko stwierdzić co jest lepsze, ciekawsze. Na pewno jest to inna współpraca i zachowania muszą być różne.

Tak więc poszukuję teraz odpowiedniego podejścia do użytkowników. Kawał pracy przede mną.

Przecież chodzi o to aby wszyscy byli zadowoleni… :-)