O Agile i XP, czyli poemat dla debili
=?iso-8859-2?q?Przemek_Wi=B6niewski?= - 01-07-2007 00:01
O Agile i XP, czyli poemat dla debili
Aktualnie mam do czynienia z programem okienkowym napisanym przez
jakichś amatorów agile, extreme programming i pewnie jeszcze kilku
innych zbawiennych "metodologii". Poprawiam różne rzeczy, dodaje nowe.
Niestety nie jest to w żadnym przypadku zajęcie przyjemne chociaż na
pierwszy rzut moja oka lista zadań jest prosta jak drut. Mam zajebiste
problemy z nawigacją po kodzie źródłowym, z szukaniem w kodzie tych
fragmentów, które mam zmienić, a jak je już znajdę i zobaczę coza syf
tam jest naprodukowany to mam ochotę wyjebać cały kod do kosza i
napisać to wszystko od nowa. Tak właśnie proste rzeczy okazują się
niemożliwe do wykonania. Kilka przykładów poniżej.
1. Hibernate
Do hibernate mam umiarkowany stosunek, w sumie sam w sobie jest ok,
ale weźmy dwa przypadki:
1.a) Programista siada i klepie chociaż nikt tak naprawdę nie
powiedział mu co robić, bo nawet klient nie spieszy się z
doprecyzowaniem wymagań. Wtedy hibernate jest git, bo jak klient
zmieni zdanie to dosyć prosto poprawić coś w mapowaniach, wyczyścić
bazę i utworzyć tabelki na nowo przy pomocy wygenerowanych plików sql.
1.b) Jak już programista sie naprogramuje i korzystając z
dobrodziejstw dystansu (dystans 2-3 tygodni) spojrzy na to co
naprogramował to być może stwierdzi, że ten hibernate jest mu zupełnie
zbędny i powoduje konieczność załączenia 20-30 jarów.
Istnieje też spore prawdopodobieństwo, że programista w czasie pracy
natknie się na sytuacje, które spowodują wypadanie włosów na głowie -
niezrozumiałe wyjątki, które ciężko rozpracować, syf i niepoprawność
danych spowodowana jakimiś drobnymi błędami, wreszcie niemożliwość
obsłużenia specyficznych dla bazy danych błędów.
Wniosek: żeby móc używać hibernate trzeba go znać na wylot, całego
dokładnie, w pełnej okazałości, nie wystarczy sobie powiedzieć "chce
tylko prostych struktur, bez skomplikowanych relacji, hibernate
napewno da rade". Jeśli tak sobie ktoś powie to czemu nie użyje JDBC?
2. Spring, z którym się właśnie zetknąłem
Do springa mam negatywny stosunek. Powtarzam tutaj, że program, który
poprawiam działa na desktopie i ma okienka. Po co używać springa jako
kontenera obiektów? Po co wogóle korzystać z tej całej konfiguracjiw
xml? Nie jest prościej zrobić sobie klaske, ze statycznymi finalnymi
publicznymi polami?
3. Spring rich client, z którym też się właśnie zetknąłem
To taki dodatek do springa, niestety od miesięcy pozostaje w wersji
0.2.1 albo coś koło tego. Pozwala toto budować okienka w jakiś
naprawdę pojebany sposób, bo jak nazwać to, że trzeba korzystać z
jakiegoś buildera i wywoływać metody, które budują gui "w tle", do
tego wszystkiego trzeba jeszcze tworzyć setki interfejsów i klas
modeli. Rany, mnie się wydawało, że prościej uruchomić sobie netbeansy
i wyklikać gui, czy nawet napisać to gui ręcznie (doszedłem ostatnio
do takiej wprawy w Swingu, że potrafię ręcznie zrobić gui z
GridBagLayoutem). Autorzy programu, który poprawiam przeszli samych
siebie i użyli spring rich clienta w wersji 0.3.0-SNAPSHOT :) Czyli
takiej wersji, której nie ma nawet na oficjalnych stronach tej
biblioteki i ponadto, przez kilka godzin nie mogłem znaleźć żadnych
źródeł. Czemu ludzie są tak głupi, jeśli wersja czegoś tam zaczyna się
od 0. to się tego nie dotyka.
4. AndroMDA
W poprzednim zleceniu, które dotyczyło innego programu użyta była też
AndroMDA - takie coś co z MagicDraw-a potrafi wygenerować kod dla
hibernate-a, setki interfejsów, tysiące klas i.. za przeproszeniem
chuj mnie strzelił jak zobaczyłem wynik. Klasy wygenerowane były
zorganizowane tak - jeden interfejs, jedna klasa abstrakcyjna, jedna
klasa z finalna implementacją, nawigacja po kodzie zerowa.
Po co więc powstało to całe agile i xp? Na wikipedii piszą o
iteracyjnym procesie produkcji programu. Rozumiem to tak, że ma być
łatwo zmieniać istniejący kod programu kiedy trzeba wydać nową wersję.
No i wszystko ładnie tylko, że ja mam na bieżąco do czynienia z tym
całym agile i jakoś nie mogę tego potwierdzić. Na wikipedii pisząteż
coś o konieczności posiadania dużego doświadczenia przy pracy w agile,
ale jeśli ktoś takowe posiada to raczej zastosuje obchodzenie szerokim
łukiem niż da się w to wciągnąć.
Zastanawiam się teraz po co sobie ludzie tworzą wszystkie te śmieszne
metodologie, biblioteki, które nie wychodzą poza wersję beta,
programy, w których nie da się poprawić wszystkich błędów. Chodzi o
to, żeby się wyszaleć, żeby coś było ładne i zgodne z jakąś ideologią?
Jakie macie wrażenia z używania agile i xp?
0x28and0x4 - 01-07-2007 00:01
Przemek Wiśniewski napisał(a):
> 1. Hibernate
[..]
> Wniosek: żeby móc używać hibernate trzeba go znać na wylot, całego
> dokładnie, w pełnej okazałości, nie wystarczy sobie powiedzieć "chce
> tylko prostych struktur, bez skomplikowanych relacji, hibernate
> napewno da rade". Jeśli tak sobie ktoś powie to czemu nie użyje JDBC?
[Ostatnio korzystam na co dzień z Hibernate]
Sprawa z Hibernate (i pewnie od razu można to uogólnić do wszystkich
zaawansowanych ORM) jest chyba bardziej złożona. Aby napisać przy
wykorzystaniu Hibernate aplikację Hello World lub nawet coś większego,
gdzie wydajność operacji bazodanowych nie jest kluczowa, raczej nie
trzeba być ekspertem od Hibernate. Tutaj można sobie pozwolić na "N+1
selects problem" i inne przymykania oka.
Lecz jeśli chcę się (lub potrzeba) zrobić system wysoce wydajny
(bazodanowo), trzeba się jednak w Hibernate wgryźć na poważnie.
Za przeroszeniem, śmieszne wydają mi się opinie takie jak:
"Length of learning curve to fully understand: five work days"
na stronie: http://www.hibernate.org/290.html
Come on! Get real!
Dokumentacja do Hibernate ma 230 stron (nie licząc annotation, itd.).
Uważam, że co bardziej zaawansowane rzeczy w Hibernate nie należą do
trywialnych i trochę czasu trzeba poświęcić, aby się z tym zapoznać.
Ktoś może zapytać: więc po co "tracić" tyle czasu, na technologię, którą
w końcu można zastąpić dobrze znanym JDBC?
Uważam, że tym projekt jest większy, tym Hibernate pokazuję swój coraz
to większy pazur. Pracowałem już nad kilkoma projektami, gdzie nie
używano ORMów. Na początku projektów po prostu strzelano SELECTami do
bazy danych. Następnie (wraz z rozwojem projektu) postanawiano pewne
powtarzające się operacje JDBC chować za jakimiś klasami to
realizującymi. I tak dla tabeli CUSTOMER tworzyło się klasę Customer,
itd. Następnie takie klasy obrastały w inne kolejne opcje
odzwierciedlające pewne zapytania SQL. I w którymś momencie projekty
takie dochodzą do etapu, gdzie widać, że programiści de facto ...
zaczynają pisać własny ORM. Czy ma to sens? Według mnie nie, skoro od
dawna są już dostępne silne ORM.
btw Ruby:
Nie wiem, jak jest obecnie z ORMami w Ruby, ale czytałem (kiedyś), że
brakuje im jeszcze wiele do np. Hibernate. Brak silnego ORM w Ruby
skutecznie (i absolutnie) mnie zmraża, powodując, że o Ruby nie myślę w
kontekście zastosowań "dużych". Czy coś się w temacie ORM dla Ruby
zmieniło ostatnio?
Pozdrowienia,
Adam
x - 01-07-2007 00:01
Przemek Wiśniewski napisał(a):
> 2. Spring, z którym się właśnie zetknąłem
>
> Do springa mam negatywny stosunek. Powtarzam tutaj, że program, który
> poprawiam działa na desktopie i ma okienka. Po co używać springa jako
> kontenera obiektów? Po co wogóle korzystać z tej całej konfiguracji w
> xml? Nie jest prościej zrobić sobie klaske, ze statycznymi finalnymi
> publicznymi polami?
Mam do pewnego stopnia podobne wrażenia.
To jest jakieś takie ideolo: zróbmy tak, żeby nigdy nie trzeba było nic
zmieniać w kodzie źródłowym. Tylko, że to zwykle się i tak nie udaje, a
zamiast programu w (przykładowo) Javie mamy program Java + framework +
XMLe konfiguracyjne + konfiguracja w bazie danych + ... Wcale nie
uważam, żeby grzebanie w Springowych XMLach (i podobnych
konfiguracyjnych wspaniałościach) było łatwiejsze niż grzebanie w Javie,
choćby dlatego że do Javy istnieją potężne IDE.
No i rozwala mnie osłabienie statycznej kontroli kodu.
Np. wczoraj doszedłem do wniosku, że pole x w klasie y jest zbędne. No
to usunąłem... pięknie, a teraz prosimy na wycieczkę po fafnastu xmlach
konfiguracyjnych, żeby usunąć wywołania setterów. Mała aplikacja, więc
dałem radę. W przypadku większej aplikacji po prostu zostawiłbym ten
śmietnik.
(btw: są może jakieś porządne narzędzia, które sprawdzą takie rzeczy ?)
>
> Zastanawiam się teraz po co sobie ludzie tworzą wszystkie te śmieszne
> metodologie, biblioteki, które nie wychodzą poza wersję beta,
> programy, w których nie da się poprawić wszystkich błędów. Chodzi o
> to, żeby się wyszaleć, żeby coś było ładne i zgodne z jakąś ideologią?
Ja myślę, że m. in. po to, żeby się wyszaleć. Większość oprogramowania
przemysłowego (przynajmniej tego, z którym ja się zetknąłem) nie jest
specjalnie fascynująca. No to chociaż zróbmy sobie np
MegaWyjebistyGeneralEnterpriseDoWszystkiegoAutomat ycznySQLGenerator ;-)
Zamiast pisać "select x from y where z = 6 " będziemy mieli kupę zabawy
;-). Widziałem już kilka takich potworków. :-)
--
Pozdrawiam,
Marcin
Twelve Hungry Mammoths - 02-07-2007 00:00
On Sat, 30 Jun 2007 14:35:25 +0200, Przemek Wiśniewski
<przemekwu@gmail.com> wrote:
> Aktualnie mam do czynienia z programem okienkowym napisanym przez
> jakichś amatorów agile, extreme programming i pewnie jeszcze kilku
> innych zbawiennych "metodologii". Poprawiam różne rzeczy, dodaje nowe.
> [ciach]
> Po co więc powstało to całe agile i xp? Na wikipedii piszą o
rozumiem, ze jest sfrustrowany, ale przeczytalem Twoj post dosc uwaznie i
jakos nie zauwazam zwiazku miedzy Twoimi problemami a metodologia agile.
moze zle Cie zrozumialem, ale wydaje mi sie, ze uwazasz zastosowanie
technologii Hibernate i Spring z rownowazne z metodologia agile. IMHO jest
w zasadzie wprost przeciwnie -- stosowanie takich ciezkich technlogii jest
raczej "enterprisey" niz "agile".
moze po prostu autorzy aplikacji twierdza, ze stosuja agile? moze robia
tzw. agile po polsku, czyli jedynym elementem agile, jaki stosuja, jest
brak dokumentacji? (-:
pzdr
szeryf
Twelve Hungry Mammoths - 02-07-2007 00:00
On Sat, 30 Jun 2007 15:46:58 +0200, 0x28and0x4
<0x28and0x4@nowhere.company> wrote:
>
> btw Ruby:
> Nie wiem, jak jest obecnie z ORMami w Ruby, ale czytałem (kiedyś), że
> brakuje im jeszcze wiele do np. Hibernate.
czego konkretnie? trudno dyskutowac z opinia "X-owi wiele brakuje do Y"
bez konkretnych argumentow, tym bardziej, ze w tym przypadku X i Y
rozwijaja sie w roznych kierunkach.
> Brak silnego ORM w Ruby skutecznie (i absolutnie) mnie zmraża,
> powodując, że o Ruby nie myślę w kontekście zastosowań "dużych". Czy coś
> się w temacie ORM dla Ruby zmieniło ostatnio?
caly czas sie zmienia, i caly czas na lepsze (-:
pzdr
szeryf
0x28and0x4 - 02-07-2007 00:00
Twelve Hungry Mammoths napisał(a):
> On Sat, 30 Jun 2007 15:46:58 +0200, 0x28and0x4
> <0x28and0x4@nowhere.company> wrote:
>>
>> btw Ruby:
>> Nie wiem, jak jest obecnie z ORMami w Ruby, ale czytałem (kiedyś), że
>> brakuje im jeszcze wiele do np. Hibernate.
>
> czego konkretnie? trudno dyskutowac z opinia "X-owi wiele brakuje do Y"
> bez konkretnych argumentow, tym bardziej, ze w tym przypadku X i Y
> rozwijaja sie w roznych kierunkach.
Nie szukając długo: chodzi mi np. o "fetch strategies". Np. tu o tym
piszą w docu do Hibernate:
http://www.hibernate.org/hib_docs/v3...ynamicfetching
ORM bez mechanizmu "fetch strategies" jest dla mnie bezwartościowy.
Kolejna rzecz, która jest w Hibernate jest "Criteria Queries":
http://www.hibernate.org/hib_docs/v3...#querycriteria
Też nie wyobrażam sobie ORMa bez "Criteria Queries". Np. w ORMach bez
"Criteria Queries" trzeba ręcznie dolepiać do Stringa (przechowującego
zapytanie SQL) warunki w klauzuli WHERE, co jest dla mnie obrzydliwe :>
A ten artykuł na który się wcześniej powoływałem, porównujący ORM w Ruby
i Hibernate to jest tu:
http://www.theserverside.com/tt/arti...RailsHibernate
Dość ciekawy to artykuł.
I jeszcze jedno:
Nie jestem w stanie uwierzyć, że w technologiach ORM (w szczególności w
Hibernate) można coś jeszcze istotnie uprościć. Czytałem strony, gdzie
było pokazane, jak łatwo pracuje się z danymi w bazie danych w Ruby. Ale
pewnie jeśli by się w ORMie Ruby chciało osiągnąć bardziej wyrafinowane
zachowanie, to okazałoby się, że albo tych rzeczy w ORM Ruby nie ma, ale
są, tyle, że ich złożoność okazałaby się tak samo duża, jak jest obecnie
w Hibernate.
Dodam też, że według mnie, nie ma co wypatrywać ORMa, który będzie
prostszy od Hibernate. Dokumentacja do Hibernate ma 230 stron i
twierdzę, że dokumentacja do innego zaawansowanego ORMa nie może tych
stron mieć mniej :) Łatwo tę moją tezę udowodnić. Wystarczy adwersarza
poprosić, aby wskazał mi w dokumentacji Hibernate, funkcjonalność, która
w tym ORMie jest zbędna :)
pozdro!
Adam
Twelve Hungry Mammoths - 02-07-2007 00:00
On Sun, 01 Jul 2007 21:30:05 +0200, 0x28and0x4
<0x28and0x4@nowhere.company> wrote:
>>>
>>> btw Ruby:
>>> Nie wiem, jak jest obecnie z ORMami w Ruby, ale czytałem (kiedyś), że
>>> brakuje im jeszcze wiele do np. Hibernate.
>> czego konkretnie? trudno dyskutowac z opinia "X-owi wiele brakuje do
>> Y" bez konkretnych argumentow, tym bardziej, ze w tym przypadku X i Y
>> rozwijaja sie w roznych kierunkach.
>
> Nie szukając długo: chodzi mi np. o "fetch strategies". Np. tu o tym
> piszą w docu do Hibernate:
> http://www.hibernate.org/hib_docs/v3...ynamicfetching
>
> ORM bez mechanizmu "fetch strategies" jest dla mnie bezwartościowy.
ActiveRecord ma ladowanie lazy i eager, czyli podstawowe wymagania
spelnia. Hibernate rozroznia 4 x 6 = 24 rozne strategie. jak dla mnie
przerost formy nad trescia.
> Kolejna rzecz, która jest w Hibernate jest "Criteria Queries":
> http://www.hibernate.org/hib_docs/v3...#querycriteria
>
> Też nie wyobrażam sobie ORMa bez "Criteria Queries". Np. w ORMach bez
> "Criteria Queries" trzeba ręcznie dolepiać do Stringa (przechowującego
> zapytanie SQL) warunki w klauzuli WHERE, co jest dla mnie obrzydliwe :>
oczywiscie, ze mozna elegancko i czytelnie (duzo ladniej niz w Hibernate)
zapisywac kryteria zapytan. w aplikacjach RoR zapytania w SQL klei sie
naprawde sporadycznie.
> A ten artykuł na który się wcześniej powoływałem, porównujący ORM w Ruby
> i Hibernate to jest tu:
> http://www.theserverside.com/tt/arti...RailsHibernate
> Dość ciekawy to artykuł.
byl ciekawy dwa lata temu. od tego czasu troche sie AR rozwinal, choc
oczywiscie podstawowa filozofia pozostala bez zmian. poza tym jak sie
spojrzy na tytul strony ("Enterprise Java Community"), to mozna sie
spodziewac, jaki bedzie wydzwiek artykulu. i nawet nie chodzi mi o slowo
kluczowe Java, ale o slowo kluczowe Enterprise (-: mozna by tez dodac, ze
autor artykulu jest tez autorem ksiazki o Hibernate.
nie mam czasu i sily wdawac sie w polemike z kazdym stwierdzeniem w tym
artykule, ktore mi sie nie podoba, bo jest tego troche. moim zdaniem autor
jest skrzywiony w strone rozwiazan enterprise i to widac w tresci.
> I jeszcze jedno:
> Nie jestem w stanie uwierzyć, że w technologiach ORM (w szczególności w
> Hibernate) można coś jeszcze istotnie uprościć.
konstrukcji dziala przeciwpancernego tez nie da sie prawdopodobnie
istotnie uproscic, a jednak na wrobla uzywa sie czegos innego.
zastosowania enterprise to nie wszystko, wyobraz sobie, ze na swiecie
pisze sie tez innego rodzaju aplikacje.
> Dodam też, że według mnie, nie ma co wypatrywać ORMa, który będzie
> prostszy od Hibernate. Dokumentacja do Hibernate ma 230 stron i
> twierdzę, że dokumentacja do innego zaawansowanego ORMa nie może tych
> stron mieć mniej :) Łatwo tę moją tezę udowodnić. Wystarczy adwersarza
> poprosić, aby wskazał mi w dokumentacji Hibernate, funkcjonalność, która
> w tym ORMie jest zbędna :)
caly Hibernate jest zbedny, da sie to samo osiagnac bez niego (-:
pzdr
szeryf
prozz - 03-07-2007 00:05
0x28and0x4 napisał(a):
> btw Ruby:
> Nie wiem, jak jest obecnie z ORMami w Ruby, ale czytałem (kiedyś), że
> brakuje im jeszcze wiele do np. Hibernate. Brak silnego ORM w Ruby
> skutecznie (i absolutnie) mnie zmraża, powodując, że o Ruby nie myślę w
> kontekście zastosowań "dużych". Czy coś się w temacie ORM dla Ruby
> zmieniło ostatnio?
A jak oceniasz ActiveRecord (ten ktory jest czescia Railsow)?
--
PR
ciukes - 03-07-2007 00:05
Przemek Wiśniewski wrote:
> Aktualnie mam do czynienia z programem okienkowym napisanym przez
> jakichś amatorów agile, extreme programming i pewnie jeszcze kilku
> innych zbawiennych "metodologii". Poprawiam różne rzeczy, dodaje nowe.
> Niestety nie jest to w żadnym przypadku zajęcie przyjemne chociaż na
> pierwszy rzut moja oka lista zadań jest prosta jak drut. Mam zajebiste
> problemy z nawigacją po kodzie źródłowym, z szukaniem w kodzie tych
> fragmentów, które mam zmienić, a jak je już znajdę i zobaczę co za syf
> tam jest naprodukowany to mam ochotę wyjebać cały kod do kosza i
> napisać to wszystko od nowa. Tak właśnie proste rzeczy okazują się
> niemożliwe do wykonania.
>
> 1. Hibernate
> ...
> 2. Spring, z którym się właśnie zetknąłem
> ...
> 3. Spring rich client, z którym też się właśnie zetknąłem
> ...
> 4. AndroMDA
> ...
>
> Jakie macie wrażenia z używania agile i xp?
>
Do generatorow kodu podchodze z rezerwa. Sa to narzedzia, ktore rownie
dobrze moga pomoc co i zaszkodzic. To co opisales wyglada jak dzialanie
malpy z brzytwa w reku.
"Inversion Of Control" to pattern opisujacy sposob tworzenia kodu, tak
zeby uniknac mocnego wiazania z innymi czesciami aplikacji. Spring jest
jedna z implementacji. Jedna - nie jedyna. Mnie rowniez denerwuje
konfiguracja w XML'u - dlatego uzywam Pico
(http://www.picocontainer.org/). Konfigurowany w kodzie, pozwala mi
tworzyc aplikacje desktop z zachowaniem IoC, bez przerostu formy nad
trescia. Innym moim faworytem jest HiveMind (http://hivemind.apache.org)
Przytoczona twoja uwaga n.t. rownowaznosci pomiedzy Spring i fabryka
objektow, jest bledna. Jesli zrobisz to co napisales, to w trakcie
testowania kodu bedziesz musial sie zajmowac nie tylko testowanym
kodem, ale takze elementami po ktore testowana klasa siega. Przyklad:
UslugaA sama siega po instancje i uzywa loggera. Chcac przetestowac
usluge A musisz martwic sie takze o logger. W przypadku IoC, UslugaA
bedzie oczekiwac ze logger bedzie "wtrysniety" (przez konstruktor, albo
setter). W zwiazku z tym, w trakcie testow mozesz wtrysnac udawany
logger. W rzeczywistym dzialaniu, wtrysniesz rzeczywisty logger. To jest
esencja IoC. Rowniez aplikacja typu desktop jest wygodniej testowac.
Jesli masz wydzielony kod obslugujacy (np: dane o klientach) i zwiazany
jest z nim oddzielnmy panel graficzny, to dzieki IoC mozesz "wtrysnac"
udawane zrodlo danych o klientach i przetestowac tylko ten jeden panel.
Wierze ze powyzsze przyklady przedstawily Ci sens IoC. Nie porzucaj tego
rozwiazania, tylko dlatego ze jestes zfrustrowany.
Sprawa Hibernate nie jest jednoznaczna. Rozumiem twoja sytuacje. Masz
dzialajaca aplikacje i pliki z mapowaniem, a ty dopiero uczysz sie jak
to wszystko dziala. Nie mozesz jednak negowac rozwiazania, tylko dlatego
ze go nie znasz. Tak, trzeba znac Hibernate na wylot zeby "robic w nim"
niecodzienne mapowania itd. Tak samo trzeba znac na wylot Jave zeby
pisac w niej aplikacje bardziej zlozone niz "Hello World!". Zaleta
uzycia Hibernate jest przezroczyste polaczenie swiata obiektowego ze
swiatem relacyjnym (Object-Relational Mapping). Uzywajac JDBC schodzisz
do poziomu assemblera, jesli chodzi o wspolprace z baza danych. Dodam ze
Hibernate nie jest jedynym frameworkim ORM. Daleko nie szukajac:
* http://cayenne.apache.org/
* http://ibatis.apache.org/
Jesli istniejace rozwiazanie jest bledne, a dalsze uzycie Hibernate mija
sie z celem, rozwaz zmiane kodu obslygujacego dane.
Nie winilbym Agile za cale zlo projektu. Dla mnie powyzszy opis wyglada
na projekt ktory powstal w celu ... uzycia topowych technologii o
ktorych glosno. Stad Hibernate, Spring i Spring RC. Fakt ze autorzy
uzyli wersji SNAPSHOT jeszcze zle o nich nie swiadczy. Jednak sytuacja w
ktorej zostawili Ciebie bez informacji o dacie buildu i bez zrodel
biblioteki jest karygodna.
Glowa do gory! Porzadny przeglad kodu i meskie decyzje pomoga Ci
wyprowadzic projekt na prosta :)
Pozdrawiam,
ciukes.
ciukes - 03-07-2007 00:05
> No i rozwala mnie osłabienie statycznej kontroli kodu.
> Np. wczoraj doszedłem do wniosku, że pole x w klasie y jest zbędne. No
> to usunąłem... pięknie, a teraz prosimy na wycieczkę po fafnastu xmlach
> konfiguracyjnych, żeby usunąć wywołania setterów. Mała aplikacja, więc
> dałem radę. W przypadku większej aplikacji po prostu zostawiłbym ten
> śmietnik.
> (btw: są może jakieś porządne narzędzia, które sprawdzą takie rzeczy ?)
Sprawdz Hibernate Tools
http://www.hibernate.org/255.html
Pozdrawiam,
ciukes.
=?iso-8859-2?q?Przemek_Wi=B6niewski?= - 03-07-2007 00:05
On 2 Lip, 12:15, ciukes <ciuk...@gmail.com> wrote:
> Przemek Wiśniewski wrote:
> > Aktualnie mam do czynienia z programem okienkowym napisanym przez
> > jakichś amatorów agile, extreme programming i pewnie jeszcze kilku
> > innych zbawiennych "metodologii". Poprawiam różne rzeczy, dodaje nowe.
> > Niestety nie jest to w żadnym przypadku zajęcie przyjemne chociażna
> > pierwszy rzut moja oka lista zadań jest prosta jak drut. Mam zajebiste
> > problemy z nawigacją po kodzie źródłowym, z szukaniem w kodzie tych
> > fragmentów, które mam zmienić, a jak je już znajdę i zobaczę co za syf
> > tam jest naprodukowany to mam ochotę wyjebać cały kod do kosza i
> > napisać to wszystko od nowa. Tak właśnie proste rzeczy okazują się
> > niemożliwe do wykonania.
>
> > 1. Hibernate
> > ...
> > 2. Spring, z którym się właśnie zetknąłem
> > ...
> > 3. Spring rich client, z którym też się właśnie zetknąłem
> > ...
> > 4. AndroMDA
> > ...
>
> > Jakie macie wrażenia z używania agile i xp?
>
> Do generatorow kodu podchodze z rezerwa. Sa to narzedzia, ktore rownie
> dobrze moga pomoc co i zaszkodzic. To co opisales wyglada jak dzialanie
> malpy z brzytwa w reku.
>
> "Inversion Of Control" to pattern opisujacy sposob tworzenia kodu, tak
> zeby uniknac mocnego wiazania z innymi czesciami aplikacji. Spring jest
> jedna z implementacji. Jedna - nie jedyna. Mnie rowniez denerwuje
> konfiguracja w XML'u - dlatego uzywam Pico
> (http://www.picocontainer.org/). Konfigurowany w kodzie, pozwala mi
> tworzyc aplikacje desktop z zachowaniem IoC, bez przerostu formy nad
> trescia. Innym moim faworytem jest HiveMind (http://hivemind.apache.org)
A nie prosciej zrobic sobie glowna klaske z polami statycznymi co je
metoda main w posredni lub bezposredni sposob zainicjalizuje? Na co
komu skomplikowane zarzadzanie komponentami aplikacji. Potem
debuggerem sie przeleci jak gdzies wystapi blad i wszystko bedzie
jasne jak slonce.
> Przytoczona twoja uwaga n.t. rownowaznosci pomiedzy Spring i fabryka
> objektow, jest bledna. Jesli zrobisz to co napisales, to w trakcie
> testowania kodu bedziesz musial sie zajmowac nie tylko testowanym
> kodem, ale takze elementami po ktore testowana klasa siega. Przyklad:
> UslugaA sama siega po instancje i uzywa loggera. Chcac przetestowac
> usluge A musisz martwic sie takze o logger. W przypadku IoC, UslugaA
> bedzie oczekiwac ze logger bedzie "wtrysniety" (przez konstruktor, albo
> setter). W zwiazku z tym, w trakcie testow mozesz wtrysnac udawany
> logger. W rzeczywistym dzialaniu, wtrysniesz rzeczywisty logger. To jest
> esencja IoC. Rowniez aplikacja typu desktop jest wygodniej testowac.
> Jesli masz wydzielony kod obslugujacy (np: dane o klientach) i zwiazany
> jest z nim oddzielnmy panel graficzny, to dzieki IoC mozesz "wtrysnac"
> udawane zrodlo danych o klientach i przetestowac tylko ten jeden panel.
> Wierze ze powyzsze przyklady przedstawily Ci sens IoC. Nie porzucaj tego
> rozwiazania, tylko dlatego ze jestes zfrustrowany.
...ze za przeproszeniem co?? To juz recznie sie nieda spreparowac i
jakimis setterami podstawic testowe dane? Trzeba to robic przez jakis
kontener IOC? Jaki to wogole ma zwiazek z dzieleniem gui i logiki?
> Sprawa Hibernate nie jest jednoznaczna. Rozumiem twoja sytuacje. Masz
> dzialajaca aplikacje i pliki z mapowaniem, a ty dopiero uczysz sie jak
> to wszystko dziala. Nie mozesz jednak negowac rozwiazania, tylko dlatego
Nie, ja hibernate znam juz calkiem niezle, pierwszy raz uzywalem go ze
2 lata temu.
> ze go nie znasz. Tak, trzeba znac Hibernate na wylot zeby "robic w nim"
> niecodzienne mapowania itd. Tak samo trzeba znac na wylot Jave zeby
> pisac w niej aplikacje bardziej zlozone niz "Hello World!". Zaleta
> uzycia Hibernate jest przezroczyste polaczenie swiata obiektowego ze
> swiatem relacyjnym (Object-Relational Mapping). Uzywajac JDBC schodzisz
> do poziomu assemblera, jesli chodzi o wspolprace z baza danych. Dodam ze
Tatarata.. jakiego asemblera? Nie za dalekie to porownanie?
> Hibernate nie jest jedynym frameworkim ORM. Daleko nie szukajac:
> *http://cayenne.apache.org/
> *http://ibatis.apache.org/
> Jesli istniejace rozwiazanie jest bledne, a dalsze uzycie Hibernate mija
> sie z celem, rozwaz zmiane kodu obslygujacego dane.
Kiedy ja wlasnie nie chce sobie szukac mojego wymarzonego frameworku
(nabieram ogromnej niecheci do slowa framework przez to wszystko), mam
to w glebokim powazaniu, nastepna rzecz jaka zrobie bedzie w prawie
czystym JDBC, nie narobie sie za wiele, konfiguracja nie bedzie
straszna, jak ktos to po mnie dostanie to nie zalamie rak.
> Nie winilbym Agile za cale zlo projektu. Dla mnie powyzszy opis wyglada
> na projekt ktory powstal w celu ... uzycia topowych technologii o
> ktorych glosno. Stad Hibernate, Spring i Spring RC. Fakt ze autorzy
> uzyli wersji SNAPSHOT jeszcze zle o nich nie swiadczy. Jednak sytuacja w
.... a jak swiadczy?
> ktorej zostawili Ciebie bez informacji o dacie buildu i bez zrodel
> biblioteki jest karygodna.
Ja nie mialem kontaktu z tamtymi goscmi, ja ich poprostyu znalazlem po
komentarzach w kodzie. W rzeczywistosci klient przyszedl, dal zrodla i
powiedzial "robcie".
> Glowa do gory! Porzadny przeglad kodu i meskie decyzje pomoga Ci
> wyprowadzic projekt na prosta :)
Dzieki za slowa pocieszenia :)
Pozdrawiam,
Przemek Wiśniewski
=?iso-8859-2?q?Przemek_Wi=B6niewski?= - 03-07-2007 00:05
On 2 Lip, 12:16, ciukes <ciuk...@gmail.com> wrote:
> > No i rozwala mnie osłabienie statycznej kontroli kodu.
> > Np. wczoraj doszedłem do wniosku, że pole x w klasie y jest zbędne. No
> > to usunąłem... pięknie, a teraz prosimy na wycieczkę po fafnastu xmlach
> > konfiguracyjnych, żeby usunąć wywołania setterów. Mała aplikacja, więc
> > dałem radę. W przypadku większej aplikacji po prostu zostawiłbym ten
> > śmietnik.
> > (btw: są może jakieś porządne narzędzia, które sprawdzą takie rzeczy ?)
>
> Sprawdz Hibernate Toolshttp://www.hibernate.org/255.html
O nie.. ni mam czasu, ni mam checi, ni chce mi sie :) Przez taki ped
do nowosci mam teraz taka sraczke.
Pozdrawiam,
Przemek Wiśniewski
Bartek Jablonski - 03-07-2007 00:05
Przemek Wiśniewski wrote:
> Kiedy ja wlasnie nie chce sobie szukac mojego wymarzonego frameworku
> (nabieram ogromnej niecheci do slowa framework przez to wszystko), mam
> to w glebokim powazaniu, nastepna rzecz jaka zrobie bedzie w prawie
> czystym JDBC, nie narobie sie za wiele, konfiguracja nie bedzie
> straszna, jak ktos to po mnie dostanie to nie zalamie rak.
Widze, ze cala sprawa rozbija sie o to, czy robisz aplikacje "jednorazowe"
bez perspektyw dalszego ich rozwijania, czy tez moze aplikacje, ktore caly
czas sie zmieniaja.
W pierwszym przypadku rzeczywiscie mozna sobie pozwolic na luz i olanie
pewnych spraw, w drugim przypadku olanie pewnych spraw na poczatku powoduje
klopoty w pozniejszym czasie.
Bartek
=?iso-8859-2?q?Przemek_Wi=B6niewski?= - 03-07-2007 00:05
On 2 Lip, 12:58, Bartek Jablonski <jabo...@nie.chce.spamu.go2.pl>
wrote:
> Przemek Wiśniewski wrote:
> > Kiedy ja wlasnie nie chce sobie szukac mojego wymarzonego frameworku
> > (nabieram ogromnej niecheci do slowa framework przez to wszystko), mam
> > to w glebokim powazaniu, nastepna rzecz jaka zrobie bedzie w prawie
> > czystym JDBC, nie narobie sie za wiele, konfiguracja nie bedzie
> > straszna, jak ktos to po mnie dostanie to nie zalamie rak.
>
> Widze, ze cala sprawa rozbija sie o to, czy robisz aplikacje "jednorazowe"
> bez perspektyw dalszego ich rozwijania, czy tez moze aplikacje, ktore caly
> czas sie zmieniaja.
> W pierwszym przypadku rzeczywiscie mozna sobie pozwolic na luz i olanie
> pewnych spraw, w drugim przypadku olanie pewnych spraw na poczatku powoduje
> klopoty w pozniejszym czasie.
>
> Bartek
Dodawanie zaleznosci zawsze komplikuje sprawe. Kazda taki "nowoczesny
framework" zalezy od stuparu innych rzeczy, ktore maja swoja
konfiguracje i kazda moze sie wylozyc. I jescze wszystko zalezy od
jakarta commons :) Poza tym latwiej sie w pewnym momencie pozbierac i
powiedziec sobie "ok robimy to teraz tak, bo stary sposob juz nie
wystarcza", a nie "o kurwa, po cosmy to tak robili, wogole nie trzeba
bylo tego wszystkiego".
Realny przyklad - Delphi, ktore przez dlugie lata stanowilo wzor
niedoscigniony w RADach. Tam nie ma zadnych zaleznosci, komponenty
zadko miedzy soba zaleza. Z punktu widzenia javowca to delphi to musi
byc jakies barbarzynstwo - do robienia okienek jest jakis tam
dziadowski designer, komponenty niewizualne tez trzeba wstawiac do
formularza, ten pascal jest prosty jak drut i nawet nie ma w nim
porzadnych kolekcji. Mimo to delphi jest latwe i przyjemne. W czasach
swojej swietnosci mialo potezna comunity i duzo komponentow.
=?iso-8859-2?q?Przemek_Wi=B6niewski?= - 03-07-2007 00:05
On 2 Lip, 13:20, Przemek Wiśniewski <przeme...@gmail.com> wrote:
> On 2 Lip, 12:58, Bartek Jablonski <jabo...@nie.chce.spamu.go2.pl>
[...]
Kurde mam wrazenie, ze cie nie zrozumialem i naplodzilem bzdur :)
Pozdrawiam,
Przemek Wiśniewski
ciukes - 03-07-2007 00:05
Przemek Wiśniewski wrote:
> On 2 Lip, 12:16, ciukes <ciuk...@gmail.com> wrote:
>>> No i rozwala mnie osłabienie statycznej kontroli kodu.
>>> Np. wczoraj doszedłem do wniosku, że pole x w klasie y jest zbędne. No
>>> to usunąłem... pięknie, a teraz prosimy na wycieczkę po fafnastu xmlach
>>> konfiguracyjnych, żeby usunąć wywołania setterów. Mała aplikacja, więc
>>> dałem radę. W przypadku większej aplikacji po prostu zostawiłbym ten
>>> śmietnik.
>>> (btw: są może jakieś porządne narzędzia, które sprawdzą takie rzeczy ?)
>> Sprawdz Hibernate Toolshttp://www.hibernate.org/255.html
>
> O nie.. ni mam czasu, ni mam checi, ni chce mi sie :) Przez taki ped
> do nowosci mam teraz taka sraczke.
To tylko narzedzie. Nie boj sie, nie gryzie. W kazdym razie nie powinno.
Czy rozwazyles zmiane mapowania w plikach XML na rzecz adnotacji? To
pozwoli Ci trzymac mapowanie blizej kodu. Taka zmiana moze Ci pomoc w
efektywnym zmienianiu kodu, bez koniecznosci modyfikowania plikow z
mapowaniami
Pozdrawiam,
ciukes.
ciukes - 03-07-2007 00:05
>> Przytoczona twoja uwaga n.t. rownowaznosci pomiedzy Spring i fabryka
>> objektow, jest bledna. Jesli zrobisz to co napisales, to w trakcie
>> testowania kodu bedziesz musial sie zajmowac nie tylko testowanym
>> kodem, ale takze elementami po ktore testowana klasa siega. Przyklad:
>> UslugaA sama siega po instancje i uzywa loggera. Chcac przetestowac
>> usluge A musisz martwic sie takze o logger. W przypadku IoC, UslugaA
>> bedzie oczekiwac ze logger bedzie "wtrysniety" (przez konstruktor, albo
>> setter). W zwiazku z tym, w trakcie testow mozesz wtrysnac udawany
>> logger. W rzeczywistym dzialaniu, wtrysniesz rzeczywisty logger. To jest
>> esencja IoC. Rowniez aplikacja typu desktop jest wygodniej testowac.
>> Jesli masz wydzielony kod obslugujacy (np: dane o klientach) i zwiazany
>> jest z nim oddzielnmy panel graficzny, to dzieki IoC mozesz "wtrysnac"
>> udawane zrodlo danych o klientach i przetestowac tylko ten jeden panel.
>> Wierze ze powyzsze przyklady przedstawily Ci sens IoC. Nie porzucaj tego
>> rozwiazania, tylko dlatego ze jestes zfrustrowany.
>
> ..ze za przeproszeniem co?? To juz recznie sie nieda spreparowac i
> jakimis setterami podstawic testowe dane? Trzeba to robic przez jakis
> kontener IOC? Jaki to wogole ma zwiazek z dzieleniem gui i logiki?
Nie wspomnialem ani slowem o dzieleniu gui i logiki. Od tego masz MVC.
Mowilem o dzieleniu komponentow aplikacji i ich testowaniu.
Wspomniales ze chcesz uzyc publicznych pol statycznych, to silne
przywiazanie do konkretnych implementacji, ktore nie pomaga w testowaniu
komponentow. IoC traktuje o zapobieganiu takim pomyslom.
Jesli to wszystko wydaje Ci sie pomyslem szalonego naukowca, to nie mam
zamiaru Cie przekonywac.
>
>> ze go nie znasz. Tak, trzeba znac Hibernate na wylot zeby "robic w nim"
>> niecodzienne mapowania itd. Tak samo trzeba znac na wylot Jave zeby
>> pisac w niej aplikacje bardziej zlozone niz "Hello World!". Zaleta
>> uzycia Hibernate jest przezroczyste polaczenie swiata obiektowego ze
>> swiatem relacyjnym (Object-Relational Mapping). Uzywajac JDBC schodzisz
>> do poziomu assemblera, jesli chodzi o wspolprace z baza danych. Dodam ze
>
> Tatarata.. jakiego asemblera? Nie za dalekie to porownanie?
Nie. Patrz ponizej.
>
>> Hibernate nie jest jedynym frameworkim ORM. Daleko nie szukajac:
>> *http://cayenne.apache.org/
>> *http://ibatis.apache.org/
>> Jesli istniejace rozwiazanie jest bledne, a dalsze uzycie Hibernate mija
>> sie z celem, rozwaz zmiane kodu obslygujacego dane.
>
> Kiedy ja wlasnie nie chce sobie szukac mojego wymarzonego frameworku
> (nabieram ogromnej niecheci do slowa framework przez to wszystko), mam
> to w glebokim powazaniu, nastepna rzecz jaka zrobie bedzie w prawie
> czystym JDBC, nie narobie sie za wiele, konfiguracja nie bedzie
> straszna, jak ktos to po mnie dostanie to nie zalamie rak.
<dowcip>
Styczen 2008, grupa pl.comp.lang.java:
Subject: Zrob to sam. Czyli jak byc madrzejszym od Papieza.
Cze!
Wlasnie otrzymalem od klienta projekt do poprawienia. Aplikacja typu
desktop. Chyba wyzywal sie na niej jakis matol skonczony.
Dacie wiare, ze w XXI wieku ktos jeszcze pisze kwerendy przy uzyciu
samego JDBC i SQL?? Mialem zrobic niewielkie poprawki w zwiazku ze
zmiana schematu bazy, jednak dzieki temu geniuszowi siedze teraz i
poprawiam setki miejsc w kodzie, gdzie przepisuje dane z ResultSet'a...
o recznym poprawianiu kwerend nie wspomne.
</dowcip>
Uwazam ze punkt widzenia zalezy od punktu patrzenia, a kola nie trzeba
wynajdywac. Juz ktos to zrobil za Ciebie.
>
>> Nie winilbym Agile za cale zlo projektu. Dla mnie powyzszy opis wyglada
>> na projekt ktory powstal w celu ... uzycia topowych technologii o
>> ktorych glosno. Stad Hibernate, Spring i Spring RC. Fakt ze autorzy
>> uzyli wersji SNAPSHOT jeszcze zle o nich nie swiadczy. Jednak sytuacja w
>
> ... a jak swiadczy?
napisalem w nastepnym zdaniu.
>
>> ktorej zostawili Ciebie bez informacji o dacie buildu i bez zrodel
>> biblioteki jest karygodna.
>
> Ja nie mialem kontaktu z tamtymi goscmi, ja ich poprostyu znalazlem po
> komentarzach w kodzie. W rzeczywistosci klient przyszedl, dal zrodla i
> powiedzial "robcie".
<ironia>
W tym momencie przestalem Ci wspolczuc;) Developerow postawionych w
takiej sytuacji nie sposob zliczyc. To nie wyjatek, to chleb pospolity.
Dzieki tym co psuja i lepia slabe aplikacje, powazni ludzie moga zarobic
porzadne pieniadze. Powinienes odzukac tych gosci i postawic im dobre piwo.
</ironia>
Pozdrawiam,
ciukes
=?iso-8859-2?q?Przemek_Wi=B6niewski?= - 03-07-2007 00:05
On 2 Lip, 14:55, ciukes <ciuk...@gmail.com> wrote:
> Przemek Wiśniewski wrote:
> > On 2 Lip, 12:16, ciukes <ciuk...@gmail.com> wrote:
> >>> No i rozwala mnie osłabienie statycznej kontroli kodu.
> >>> Np. wczoraj doszedłem do wniosku, że pole x w klasie y jest zbędne. No
> >>> to usunąłem... pięknie, a teraz prosimy na wycieczkę po fafnastu xmlach
> >>> konfiguracyjnych, żeby usunąć wywołania setterów. Mała aplikacja, więc
> >>> dałem radę. W przypadku większej aplikacji po prostu zostawiłbym ten
> >>> śmietnik.
> >>> (btw: są może jakieś porządne narzędzia, które sprawdzątakie rzeczy ?)
> >> Sprawdz Hibernate Toolshttp://www.hibernate.org/255.html
>
> > O nie.. ni mam czasu, ni mam checi, ni chce mi sie :) Przez taki ped
> > do nowosci mam teraz taka sraczke.
>
> To tylko narzedzie. Nie boj sie, nie gryzie. W kazdym razie nie powinno.
>
> Czy rozwazyles zmiane mapowania w plikach XML na rzecz adnotacji? To
> pozwoli Ci trzymac mapowanie blizej kodu. Taka zmiana moze Ci pomoc w
> efektywnym zmienianiu kodu, bez koniecznosci modyfikowania plikow z
> mapowaniami
Nie narzekam na wygode czy monotonie. Jak zaczne gryzc te adnotacje to
zajmie mi to z miesiac, pozytku z tego nie bedzie zadnego. Kazda
osoba, ktora dostanie projekt po mnie tez bedzie musiala ten miesiac
poswiecic. O to mi chodzi. Moze to dziwne, ale chce byc lemingiem.
Pozdrawiam,
Przemek Wiśniewski
=?iso-8859-2?q?Przemek_Wi=B6niewski?= - 03-07-2007 00:05
On 2 Lip, 14:55, ciukes <ciuk...@gmail.com> wrote:
> <dowcip>
> Styczen 2008, grupa pl.comp.lang.java:
> Subject: Zrob to sam. Czyli jak byc madrzejszym od Papieza.
> Cze!
> Wlasnie otrzymalem od klienta projekt do poprawienia. Aplikacja typu
> desktop. Chyba wyzywal sie na niej jakis matol skonczony.
> Dacie wiare, ze w XXI wieku ktos jeszcze pisze kwerendy przy uzyciu
> samego JDBC i SQL?? Mialem zrobic niewielkie poprawki w zwiazku ze
> zmiana schematu bazy, jednak dzieki temu geniuszowi siedze teraz i
> poprawiam setki miejsc w kodzie, gdzie przepisuje dane z ResultSet'a...
> o recznym poprawianiu kwerend nie wspomne.
> </dowcip>
> Uwazam ze punkt widzenia zalezy od punktu patrzenia, a kola nie trzeba
> wynajdywac. Juz ktos to zrobil za Ciebie.
Naprawde wole takie problemy niz to co mam teraz. Poza tym w pierwszym
poscie napisalem co mysle o hibernate - nie jest taki zly, mam
stosunek umiarkowany.
Pozdrawiam,
Przemek Wiśniewski
x - 03-07-2007 00:05
ciukes napisał(a):
>> No i rozwala mnie osłabienie statycznej kontroli kodu.
>> Np. wczoraj doszedłem do wniosku, że pole x w klasie y jest zbędne. No
>> to usunąłem... pięknie, a teraz prosimy na wycieczkę po fafnastu
>> xmlach konfiguracyjnych, żeby usunąć wywołania setterów. Mała
>> aplikacja, więc dałem radę. W przypadku większej aplikacji po prostu
>> zostawiłbym ten śmietnik.
>> (btw: są może jakieś porządne narzędzia, które sprawdzą takie rzeczy ?)
> Sprawdz Hibernate Tools
> http://www.hibernate.org/255.html
Właściwie to miałem na myśli Springa.
--
Pozdrawiam,
Marcin
Marcin Jancewicz - 03-07-2007 00:30
> Właściwie to miałem na myśli Springa.
Spring IDE ?
http://springide.org/blog/
Pawel Stawicki - 04-07-2007 00:02
> Jakie macie wrażenia z używania agile i xp?
No ja mam różne, raczej pozytywne. Z tego piszesz wnioskuję że Twoje
problemy wynikają raczej z przerostu formy nad treścią (jakiś rich
client do budowania okienek itp). Ja też nie znoszę jak mi się wsadza
wszędzie jakieś kontenery, obudowuje kod pięcioma warstwami abstrakcji
itp, kiedy trzeba zrobić tylko prostą aplikację. Przebijanie się później
przez te warstwy żeby dociec o co w tym chodzi... brrrr.
Pozdrawiam
Paweł Stawicki
=?iso-8859-2?q?Przemek_Wi=B6niewski?= - 04-07-2007 00:02
On 3 Lip, 10:13, Pawel Stawicki
<pawelstawicki@[cut_this_out]poczta.onet.pl> wrote:
> > Jakie macie wrażenia z używania agile i xp?
>
> No ja mam różne, raczej pozytywne. Z tego piszesz wnioskuję że Twoje
> problemy wynikają raczej z przerostu formy nad treścią (jakiś rich
> client do budowania okienek itp). Ja też nie znoszę jak mi się wsadza
> wszędzie jakieś kontenery, obudowuje kod pięcioma warstwami abstrakcji
> itp, kiedy trzeba zrobić tylko prostą aplikację. Przebijanie się później
> przez te warstwy żeby dociec o co w tym chodzi... brrrr.
>
> Pozdrawiam
> Paweł Stawicki
Zgadzam sie. Moze zle zdiagnozowalem problem, jednak nadal mam
wrazenie, ze te cale "nowoczesne" metodologie od urodzenia sa mocno
przesycone forma.
Pozdrawiam,
Przemek Wiśniewski
prozz - 04-07-2007 00:02
> Zgadzam sie. Moze zle zdiagnozowalem problem, jednak nadal mam
> wrazenie, ze te cale "nowoczesne" metodologie od urodzenia sa mocno
> przesycone forma.
A twoje podejscie mocno przesycone sceptycyzmem?
--
PR
=?iso-8859-2?q?Przemek_Wi=B6niewski?= - 04-07-2007 00:02
On 3 Lip, 13:35, prozz <pro...@gmail.com> wrote:
> > Zgadzam sie. Moze zle zdiagnozowalem problem, jednak nadal mam
> > wrazenie, ze te cale "nowoczesne" metodologie od urodzenia sa mocno
> > przesycone forma.
>
> A twoje podejscie mocno przesycone sceptycyzmem?
Rowniez sie zgadza. Nie widze w tym nic zlego, a Ty?
Pozdrawiam,
Przemek Wiśniewski
prozz - 04-07-2007 00:02
Przemek Wiśniewski napisał(a):
> Rowniez sie zgadza. Nie widze w tym nic zlego, a Ty?
Rowniez. Nie chcesz - nie uzywaj. I tyle... Spojrz na to z innej strony:
jesli ten caly agile bylby nic niewart, nie byloby takiego szumu
wokol. Po prostu trzeba go dobrze uzywac. A to ze ktos popsul, no coz,
zdarza sie...
--
PR
Tomek - 05-07-2007 00:01
Przemek Wiśniewski napisał(a):
> Zgadzam sie. Moze zle zdiagnozowalem problem, jednak nadal mam
> wrazenie, ze te cale "nowoczesne" metodologie od urodzenia sa mocno
> przesycone forma.
Jeśli ma powstać prosta aplikacja i taka ma pozostać po wsze czasy, i
nikt nie będzie jej tykał - to zdecydowanie był przerost formy nad treścią.
Czasem się zdarzy, że przewidujemy kiedyś rozbudowę - być może
do dużych rozmiarów i do technologii J2EE - wtedy warto się zawczasu
przygotować, np. stosując czyste JPA (albo chociaż zbudować sobie prostą
warstwę abstrakcji ) zamiast JDBC - oszczędzimy sobie później
przerabiania. Ale mimo wszystko, zgadzam się, że nie wolno przeginać ;-)
--
Tomek malpa japko kropka info.
ris - 10-07-2007 00:01
Przemek Wiśniewski pisze:
> Aktualnie mam do czynienia z programem okienkowym napisanym przez
> jakichś amatorów agile, extreme programming i pewnie jeszcze kilku
> innych zbawiennych "metodologii". Poprawiam różne rzeczy, dodaje nowe.
> Niestety nie jest to w żadnym przypadku zajęcie przyjemne chociaż na
> pierwszy rzut moja oka lista zadań jest prosta jak drut. Mam zajebiste
> problemy z nawigacją po kodzie źródłowym, z szukaniem w kodzie tych
> fragmentów, które mam zmienić, a jak je już znajdę i zobaczę co za syf
> tam jest naprodukowany to mam ochotę wyjebać cały kod do kosza i
> napisać to wszystko od nowa. Tak właśnie proste rzeczy okazują się
> niemożliwe do wykonania. Kilka przykładów poniżej.
>
> 1. Hibernate
>
> Do hibernate mam umiarkowany stosunek, w sumie sam w sobie jest ok,
> ale weźmy dwa przypadki:
>
> 1.a) Programista siada i klepie chociaż nikt tak naprawdę nie
> powiedział mu co robić, bo nawet klient nie spieszy się z
> doprecyzowaniem wymagań. Wtedy hibernate jest git, bo jak klient
> zmieni zdanie to dosyć prosto poprawić coś w mapowaniach, wyczyścić
> bazę i utworzyć tabelki na nowo przy pomocy wygenerowanych plików sql.
>
> 1.b) Jak już programista sie naprogramuje i korzystając z
> dobrodziejstw dystansu (dystans 2-3 tygodni) spojrzy na to co
> naprogramował to być może stwierdzi, że ten hibernate jest mu zupełnie
> zbędny i powoduje konieczność załączenia 20-30 jarów.
>
> Istnieje też spore prawdopodobieństwo, że programista w czasie pracy
> natknie się na sytuacje, które spowodują wypadanie włosów na głowie -
> niezrozumiałe wyjątki, które ciężko rozpracować, syf i niepoprawność
> danych spowodowana jakimiś drobnymi błędami, wreszcie niemożliwość
> obsłużenia specyficznych dla bazy danych błędów.
>
> Wniosek: żeby móc używać hibernate trzeba go znać na wylot, całego
> dokładnie, w pełnej okazałości, nie wystarczy sobie powiedzieć "chce
> tylko prostych struktur, bez skomplikowanych relacji, hibernate
> napewno da rade". Jeśli tak sobie ktoś powie to czemu nie użyje JDBC?
>
> 2. Spring, z którym się właśnie zetknąłem
>
> Do springa mam negatywny stosunek. Powtarzam tutaj, że program, który
> poprawiam działa na desktopie i ma okienka. Po co używać springa jako
> kontenera obiektów? Po co wogóle korzystać z tej całej konfiguracji w
> xml? Nie jest prościej zrobić sobie klaske, ze statycznymi finalnymi
> publicznymi polami?
>
> 3. Spring rich client, z którym też się właśnie zetknąłem
>
> To taki dodatek do springa, niestety od miesięcy pozostaje w wersji
> 0.2.1 albo coś koło tego. Pozwala toto budować okienka w jakiś
> naprawdę pojebany sposób, bo jak nazwać to, że trzeba korzystać z
> jakiegoś buildera i wywoływać metody, które budują gui "w tle", do
> tego wszystkiego trzeba jeszcze tworzyć setki interfejsów i klas
> modeli. Rany, mnie się wydawało, że prościej uruchomić sobie netbeansy
> i wyklikać gui, czy nawet napisać to gui ręcznie (doszedłem ostatnio
> do takiej wprawy w Swingu, że potrafię ręcznie zrobić gui z
> GridBagLayoutem). Autorzy programu, który poprawiam przeszli samych
> siebie i użyli spring rich clienta w wersji 0.3.0-SNAPSHOT :) Czyli
> takiej wersji, której nie ma nawet na oficjalnych stronach tej
> biblioteki i ponadto, przez kilka godzin nie mogłem znaleźć żadnych
> źródeł. Czemu ludzie są tak głupi, jeśli wersja czegoś tam zaczyna się
> od 0. to się tego nie dotyka.
>
> 4. AndroMDA
>
> W poprzednim zleceniu, które dotyczyło innego programu użyta była też
> AndroMDA - takie coś co z MagicDraw-a potrafi wygenerować kod dla
> hibernate-a, setki interfejsów, tysiące klas i.. za przeproszeniem
> chuj mnie strzelił jak zobaczyłem wynik. Klasy wygenerowane były
> zorganizowane tak - jeden interfejs, jedna klasa abstrakcyjna, jedna
> klasa z finalna implementacją, nawigacja po kodzie zerowa.
>
> Po co więc powstało to całe agile i xp? Na wikipedii piszą o
> iteracyjnym procesie produkcji programu. Rozumiem to tak, że ma być
> łatwo zmieniać istniejący kod programu kiedy trzeba wydać nową wersję.
> No i wszystko ładnie tylko, że ja mam na bieżąco do czynienia z tym
> całym agile i jakoś nie mogę tego potwierdzić. Na wikipedii piszą też
> coś o konieczności posiadania dużego doświadczenia przy pracy w agile,
> ale jeśli ktoś takowe posiada to raczej zastosuje obchodzenie szerokim
> łukiem niż da się w to wciągnąć.
>
> Zastanawiam się teraz po co sobie ludzie tworzą wszystkie te śmieszne
> metodologie, biblioteki, które nie wychodzą poza wersję beta,
> programy, w których nie da się poprawić wszystkich błędów. Chodzi o
> to, żeby się wyszaleć, żeby coś było ładne i zgodne z jakąś ideologią?
>
> Jakie macie wrażenia z używania agile i xp?
>
Nie rozumiem jaki związek ma agile i xp z Twoimi problemami. Może
poczytaj coś o tej metodologii bo jakoś zabierasz się do tematu od złej
strony:
http://helion.pl/ksiazki/javatw.htm
--
Robert Sajdok (Ris)
Szarak - 10-07-2007 00:01
Dnia 09.07.2007 22:16 ris napisał(a):
> poczytaj coś o tej metodologii bo jakoś zabierasz się do tematu od złej
> strony:
Zauważyłem, że dość często błędnie używa się słowa metodologia. Polecam:
http://pl.wikipedia.org/wiki/Metodologia
http://pl.wikipedia.org/wiki/Metodyka
Ok, już się nie wpierdzielam ;)
Pozdrawiam
Szarak
ris - 11-07-2007 00:01
Szarak pisze:
> Dnia 09.07.2007 22:16 ris napisał(a):
>> poczytaj coś o tej metodologii bo jakoś zabierasz się do tematu od złej
>> strony:
>
> Zauważyłem, że dość często błędnie używa się słowa metodologia. Polecam:
> http://pl.wikipedia.org/wiki/Metodologia
> http://pl.wikipedia.org/wiki/Metodyka
>
> Ok, już się nie wpierdzielam ;)
>
http://helion.pl/ksiazki/javatw.htm
Strona 48 "Metodologie wytwarzania oprogramowania"
--
Robert Sajdok (Ris)
Szarak - 11-07-2007 00:01
Dnia 10.07.2007 09:44 ris napisał(a):
> http://helion.pl/ksiazki/javatw.htm
>
> Strona 48 "Metodologie wytwarzania oprogramowania"
Helion już nie raz pokazał jak przykłada się do tłumaczeń. Dla mnie to
żaden autorytet.
Różnej maści słowniki i encyklopedie definiują te pojęcia podobnie. Np.:
http://portalwiedzy.onet.pl/64946,,,...gia,haslo.html
http://portalwiedzy.onet.pl/117548,,...yka,haslo.html
w skrócie: metodologia jest nauką o metodach. Metodyka zaś określa
sposoby wykonywania czegoś, dojścia do pewnego celu. Czyli agile, xp,
itp. są metodykami.
Pozdrawiam
Szarak
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
Strona 1 z 2 • Znaleźliśmy 67 postów • 1, 2
|
=?iso-8859-2?Q?=5Bpocz=B1tkuj=B1cy_uzyszkodnik_mysql=5D_probl em_z_MySQL_n?==?iso-8859-2?Q?a_Windows_XP?=
[Oracle] Instalacja Oracle10g EE na Windows XP
=?iso-8859-2?Q?program_foxpro_i_win_vista_=3F_w_xp_dzia=B3a=B 3o.?=
SQL Server 2000 i Analysis Menager pod Windows XP+SP1
[kupie] MS SQL Server 2000 na Windows XP
PostgreSQL Windopws XP SP2 - blad podczas instalacji
[PostgreSQL]Upgrade serwera na Windows XP Home
konfiguracja sql server 2000 na win xp
Instalacja Firebird problem po reinstalce systemu (xp)
sterowniki do notebooka Gateway Mt6451 pod Windows XP
zanotowane.pldoc.pisz.plpdf.pisz.pltejsza.htw.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
