Notatka po spotkaniu (14.12.2010)

Sebastian Kaczanowski

unread,

Dec 14, 2010, 5:54:56 PM12/14/10

to Warszawa Design Patterns Study Group

Propozycja reguł sposobu pracy nad projektem Piotra.

1) Pracujemy nad projektem na spotkaniach i w domu.
2) Poprawiamy rzeczy, które trudno poprawić (nie ma sensu poprawiać
oczywistych knotów, bo to nie jest pouczające)
3) Poprawiamy jedną rzecz na raz z dwóch powodów: po pierwsze, żeby
uniknąć bałaganu i po drugie, żeby skorzystać z doświadczeń jak
największej grupy osób. Innymi słowy nie chodzi nam o wydajność tylko
o to, by rozwiązać problem w zadowalający sposób i nauczyć się przy
tej okazji czegoś od siebie nawzajem.
4) Zestaw rzeczy do zrobienia na początek przygotuje Piotr ale
oczywiście innych też się do tego zachęca. Gdy już będzie gotowa lista
zadań zdecydujemy, poprzez głosowanie na forum, w jakiej kolejności
realizujemy zadania.
5) Wyznaczyliśmy zadanie domowe: postawienie projektu.

pozdrawiam i proszę o komentarze, uwagi, poprawki etc.
Sebastian

Witalij Olejnik

unread,

Dec 15, 2010, 6:34:52 AM12/15/10

to Warszawa Design Patterns Study Group

Uwagi, które zdążyłem zapisać:

1. Ponglish (n.p. sklep3-core)
2. Hardkodowane stringi
3. 2 war vs 1 war
4. 2 war vs 3 war
5. Core doliczany do obu warow
6. Meszana notacja (PEAR case / Camel Case )

On 14 Gru, 23:54, Sebastian Kaczanowski

Piotr Przybylak

unread,

Dec 15, 2010, 11:30:32 AM12/15/10

to warsz...@googlegroups.com

Dzięki wszystkim za przybycie wczoraj

Dodałem uwagi, które Witalij spisał do dokumentu google doc, który udostępniłem na adres grupy - mamy wiec takie mini wiki.

Dopisałem punkt 7 - anemiczny model domeny. Prawdę mówiąc jak to pisaliśmy to nam się wydawało że mamy dynamiczny model bo są metody na encjach i w ogóle ;> Kuba, mógłbyś w wolnej chwili parę słów napisać jakby to trzeba przerobić, żeby był dynamiczny ?

Ja do przyszłego tygodnia jestem totalnie zawalony ale w przyszłym postaram się przygotować listę tematów, które moglibyśmy przedyskutować/poprawić/rozważyć opcję.

Zgodnie z tym co napisał Sebastian postaram się ominąć oczywiste fuck'upy to one są ... oczywiste, więc za dużo się nie nauczymy analizując je. Ale oczywiście zachęcam to wypisywania wszystkich znalezionych fukcupow w dokumencie "netkombajn - uwagi" - warto wiedziec jakie niespodzianki moga na nas czekac podczas developmentu.

Napiszcie też czy udalo Wam się odalić projekt.

Podzilcie sie tez ogolnymi wrazeniami / przemysleniami.

Np. że prezentacja ostatnia była nudna. Do 20 dotrwali najwytrwalsi i nie wiem czy tylko za dlugo bylo, czy zmeczyl was temat czy prowadzacy - feedback mile widziany :D

--
Pozdrawiam
Piotr Przybylak

Piotr Przybylak

unread,

Dec 22, 2010, 4:34:42 AM12/22/10

to warsz...@googlegroups.com

Hej

Poprzeglądałem trochę kod, wybrałem parę rzeczy , które możemy przeanalizować i jedno zadanie chyba szczególnie dobrze nadaje się na początek:

1. Proces importu produktow z plikow XML, do którego test jest tu:

pl.netolution.sklep3.service.imports.IncomImportServiceTest

Jest on już jako tako czytelny bo został gruntownie przerobiony po warsztatach 'coding by example' na Javarsovii 2009. Jedna wielka metoda testująca została podzielona na małe sprawdzające jedną rzecz. Nadal daleko mu do ideału głównym 'zapachem' jest chyba zbyt rozbudowany setUp/fixutre do testu.

Na rozgrzewkę proponuję refactoring klas IncomImportServiceTest i IncomImportService.

2. Kolejny potencjalny temat to:

Zarządzanie obrazkami do produktów.

Gdzie i w jakiej formie trzymać konfigurację formatów, miejsc na dysku?

Kto powinien być odpowiedzialny za zapisywanie / wczytywanie zawartości obrazków?

3. Następnie możemy przyjrzeć się obsłudze systemów płatności online:

pl.netolution.sklep3.domain.payment

- być może będzie można wyekstrahować z tego niezależną od sklepu bibliotekę.

4. Konfiguracja systemu:

- jak trzymać w bazie : kolumna per wartosc, czy rowek per wartosc

- jak keszować, jak udostępniać

5. NetKombajnMailSender - idealny kandydat do zastąpienia aspektowością ?

6. Temat typowo JSF'owy:

Totalnie zrąbane są scope'y w JSF. Wszystko jest na session, bo nie umieliśmy zrobić requestowo.

7. I last but not least - czy warto i jak dokonać transformacji sklepu w kierunku bardziej aktywnej domeny - mnie ten temat najbardziej chyba pociąga, ale może nie jest najlepszy na początek.

Inspiracją pewnie mogą tu być artykuły Allana Holuba, który próbuje przedstawić podejście umożliwiające obiektowe konstruowanie również guia webowego - aczkolwiek na razie znalazłem trochę poczytałem ale jeszcze nie załapałem ;>.