bardzo ładne podsumowanie.
Z jednej strony jestem nieco zawiedziony, że trafiłem tu już w momencie kiedy ów wybór mam za sobą, z drugiej szalenie miłym zaskoczeniem był fakt, że zupełnie niezależnie, w rezultacie podobnej analizy dokonałem tego samego wyboru.

To czego mi we wpisie zabrakło, to nieco większe rozwinięcie tematu frameworków. Wybór odpowiedniego bynajmniej nie jest to banalną sprawą, a tymczasem mam wrażenie, że autor po tak długim wpisie potraktował sprawę nieco po macoszemu.
Może jest to potencjalny materiał na kolejny wpis?
Jedno z podstawowe pytanie, przy frameworkach powinno IMHO dotyczyć ilości i przede wszystkim jakości wdrożeń o nie opartych. Nie na darmo mówi się, że lepiej uczyć się na cudzych błędach, a co za tym idzie raczej nie warto opierać projektu o rozwiązanie, które nie sprawdziło się jeszcze w produkcyjnych warunkach na dużą skalę.

BTW Pod kryteriami dla których odpadł Perl podpisuję się z całym przekonaniem

Czekam na kolejne informacje z frontu

Wszystko w swoim czasie…

Póki co mogę jedynie sparafrazować, to co jest na naszej stronie głównej, tj. http://www.profitto.pl. Sami szukaliśmy serwisów/narzędzi pozwalających zarządzać naszymi szeroko rozumianymi finansami. Niby ostatnio coś drgnęło w temacie tego typu serwisów, jednak żaden z nich nie podchodzi do tematu w sposób, który by nam odpowiadał – postanowiliśmy więc sami stworzyć coś takiego, po części dla nas samych, po części dla innych, którzy mają podobne podejście i wymagania jak my (sądzę, że nie jesteśmy osamotnieni w takich potrzebach).

Co do bliższych szczegółów, to ten blog na pewno jest dobrym miejscem, aby śledzić postęp naszych prac – w miarę ich postępu będziemy opowiadać o kolejnych pomysłach, które zamierzamy zrealizować.

Za jakiś czas pewnie dodamy inne formy komunikacji z nami, jak mail, formularze kontaktowe, może jakieś ankiety – więc jeśli temat zarządzania swoimi finansami jest Ci bliski a co więcej jakaś jego dziedzina wybitnie potrzebuje wsparcia, zapraszamy do kontaktu – może wyjdzie z tego coś ciekawego, co uda się dodać do naszej road-mapy

A czy mozesz uchylic rąbka tajemnicy i powiedziec co to własciwie będzie?

@Michał
Dzięki za pragmatyczne spojrzenie na temat – choć może z tego postu tego nie widać, staramy się robić dokładnie to samo, tj. podchodzić pragmatycznie i nie obciążać się niczym, co nie wnosi dla nas realnej wartości (także jestem gorącym zwolennikiem podejść typu Agile/SCRUM). Choć jak widać powyżej, czasem moja dociekliwość bierze nad tym górę…

Gdybyśmy pracowali w tym samym pomieszczeniu, pewnie byłoby tak jak piszesz – duża biała tablica i namalowany pisakiem diagram, rodem z Agile. Jednak pracujemy osobno i tylko cyklicznie się spotykamy – a taki tryb wymaga trochę odmiennego podejścia.
I nie było tak źle z opanowaniem narzędzia (w tym wypadku jest to StarUML) – zajęło to kilka minut. Dodatkowo modelujemy w ten sposób tylko część która mocno nas wszystkich dotyczy, czyli model domenowy – co doskonale upraszcza nam późniejsze dyskusje.

Może za jakiś czas, gdy nasz „proces” okrzepnie na tyle, że będzie go można nazwać „procesem” trochę go opiszemy, wraz z używanymi przez nas narzędziami.

Literatura uzupełniająca:
* Agile Tools. When is Whiteboard a Better choice than Software?
* Using an Agile Software Process with Offshore Development – na szczęście większość kwestii opisanych tutaj nas nie dotyczy…

Skłaniam się ku konkluzji Mikołaja, że stosowanie tych pojęć wymaga bardzo elastycznego, a jednocześnie świadomego podejścia. Pamiętajmy jednak o tym, że modelowanie samo w sobie niekoniecznie zawsze przekłada się na implementację – jeśli agregacja daje nam możliwość uchwycenia czegoś ‘między wierszami’, jestem za jej stosowaniem.

Co do szukania programistów Python-owych, to mam nadzieję, że jak już do tego punktu dotrzemy, to współpraca z MFI pomoże nam zaadresować ten punkt

Zgadzam się także, że w temacie tego rodzaju aplikacji web-owych królują „PHP-owcy” (w temacie hostingu zresztą też), ale część z nich zaczyna dostrzegać ograniczenia tego języka i rozglądając się za czymś dojrzalszym migrują w stronę Ruby lub właśnie Python-a.

Tego typu ciekawych punktów do dyskusji jest mnóstwo – może za jakiś czas, jak uzbieramy bardziej pokaźny bagaż doświadczeń, porównać i przemyśleń pokusimy się o jakąś prezentację na SPIN-ie (bo na JUG-a to temat chyba nie specjalnie by się nadawał).

A co do języków do tego rodzaju aplikacji, to wydaje się że duo: Groovy+Grails też byłoby warte bliższej analizy.

Chyba właśnie tak jest – nie ma jednoznacznej definicji. Moim zdaniem poza wyraźnymi relacjami całość-część lepiej nie stosować agregacji. Dokładnie tak jak piszesz w konkluzji