Widzę jakieś marudzenie w komentarzarach do projektu, typu:
"Ponownie proszę o usunięcie "Projektu testowego", do testowania służą test case'y"
Fajnie, tak do testowania JEDNOSTKOWEGO służa test case'y, ale całości nie trzeba tego w cale używać.
Można napisać nowy projekt, któy będzie używać naszej klasy.
W ten sposób zostały znalezione błachę błed autora tego komentarza w klasie H2Connection.
Co do pytania po co usuwac tabelę, a to dlatego, że działamy jak każdy inny serializator, a
ten dla porównania np XML-owy opróżnia plik i serializuję nowy obiekt, a więc trzeba opróznić tabelę,
zanim sie coś doda.
W rewizji 67 jeszcze działalo serializowanie pojedyńczego pola typu
int zmiennaInt = 2;
ser.writeobject(zmiennaInt)
Proszę o wyjaśnienie czemu to nie działa już. Mam stack overflow.
Trzeba będzie cofnąć wszystko do rewizji 67 jak tak dalej będzie.
To że jest OK w testach jednostkowych nie interesuję mnie to.
Commity w SVN-ie służa do komentowania wysyłanego kodu, a uwagi proszę zachować dla siebie,
Kieruję to do użytkownika hommie5.
Last edit: kr3niu 2012-07-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hommie5 miał rację co do usuwania tabel, był błąd: tabele były usuwane tuż przed deserializacją. Grupa programistów deserializera we współpracy ze mną poprawiła to, modyfikując nieznacznie i serializer, i deserializer.
Błąd został wychwycony i poprawiony, zmniejszmy ciśnienie.
To co napisałem oczywiście nie oznacza, że wskazany przez Kr3niu błąd już nie istnieje.
Last edit: krych14m 2012-07-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Odpowiedz do kr3niu . Co do "Projekt testowego" to Dr Marciniak mowil, ze wszystko powinno byc w jednym projekcie, tak jak mu oddajemy. Co kolwiek robisz, cokolwiek sprawdzasz rob to tak, zeby bylo w jednym projekcie. Przeciez sam nie piszesz tego programu.
"Co do pytania po co usuwac tabelę, a to dlatego, że działamy jak każdy inny serializator, a
ten dla porównania np XML-owy opróżnia plik i serializuję nowy obiekt, a więc trzeba opróznić tabelę,
zanim sie coś doda."
-tabele były usuwane tuż przed deserializacją., POPRAWIONO
Ano widzisz byl duzy blad, ktorego Twoje testy nie wychwycily,
Co do tego, ze serializowanie nie dziala, przesledzimy dzisiaj dokladnie kod serializera i napewno uda nam sie go poprawic. A oprocz tego wrzucimy testy klas deserializer i serializer.
Pozdro i nie spinajcie posladow
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Serializowanie pola poprawione, problem był w niezgodnych metodach Object#isPrimitive(), do zgłaszania takich problemów służy system ticketów, a nie forum.
Kolejny błąd, który występuje - czyli serializacj tablic (opisane w ticket'cie #15). Ten błąd sprawdziłem także w rewizji 67, żeby nie było pretensji, że ktoś ci nagrzebał i tam też serializacja tablic nie działa.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<quote>
-tabele były usuwane tuż przed deserializacją., POPRAWIONO
</quote>
Tak sie nie działo zawsze. Wystarczy, że utworzylo się raz uchwyt do H2Connection, a były czyszczone przed derserializacją. Ale rzeczywiście to był bład, zwracam honory
<quote>
Serializowanie pola poprawione, problem był w niezgodnych metodach Object#isPrimitive(),
do zgłaszania takich problemów służy system ticketów, a nie forum
</quote>
Nom, ale forum też jest do prowadzenia dyskusji. Uważam, że ticketa dajemy w drobniejszych sprawach, a tutaj wszystko przestało działać.
Dobra Panie i Panowie to teraz rzeczywiście serializer znów działał, ale postanowiśmy
go grupą przepisać i już uwzględnie wszystkie detale. Aaa Deserializer jeszcze nie był przpeisywany, wymaga poprawek pod kątem chociażby wykrywania duplikatów obiektów.
Teraz serializuję pola prymitynwę, tablice, ArrayListy, klasy, interfejsy nie, ale to nie potrzebne. Uwzględnia transient oraz duplikaty.
Sematyke zapisy tych samych obiektów wyjaśnimy w innym wątku, kiedy będzię gotowy deserializator :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Każdy "request" zmiany w jakiejś części kodu odbywa się za pośrednictwem bug trackerów i ticketowania. Forum jest wyłącznie do dyskusji.
"Fajnie, tak do testowania JEDNOSTKOWEGO służa test case'y, ale całości nie trzeba tego w cale używać."
Trzeba. Nie wiesz o czym piszesz to nie pisz. Ty u siebie możesz na własne potrzeby testować kod jak ci się podoba, ale testy w projekcie mają być ustandaryzowane. Gdyby ten projekt wyglądał tak jak powinien wyglądać, czyli wykożystywałby Maven'a lub ANT'a, wyniki testów możnaby było załączać, obok dokumentacji, źródeł i binarek dla każdej ważniejszej rewizjii w formie archiwów jar, jak to ma miejsce w każdym porządnym projekcie programistycznym. JUnit nie służy do żadnego "testowania JEDNOSTKOWEGO", jest to zintegrowana platforma narzędzi testowych i do testów właśnie służy. Sformuowanie "jednostkowe" odnosi się do koncepcji testów mówiącej o tym, że najmniejszą jednostką testu jest metoda.
Skoro zamierzacie wprowadzać poważniejsze zmiany - kilka uwag co do samego funkcjonowania biblioteki:
- serializer i deserializer nie powinny przyjmować obiektu H2Connection w parametrze konstruktora, tylko same tworzyć i zamykać połączenie w swoim cyklu życia, poprzez tworzenie nowych obiektów H2Connection lub za pomocą jednego obiektu singleton, z synchronizowanymi metodami,
- z punktu widzenia użytkownika tej biblioteki dostępne powinny być tylko dwa interfejsy - serializatora i deserializatora, posiadające metodę read i write object, oraz fabryka tworząca nowy serializator lub deserializator. Cała reszta klas włącznie z samym serializatorem i deserializatorem powinna być niewidoczna. Takie podejście służy zapewnieniu odpowiedniego ograniczenia dostępnych metod za pomocą polimorfizmu.
Powodzenia, a osobom nie znającym zasad pracy w projektach grupowych polecam poczytać trochę na ten temat, żeby uniknąć dalszych nieporozumień.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<quote>
Trzeba. Nie wiesz o czym piszesz to nie pisz. Ty u siebie możesz na własne potrzeby testować kod jak ci się podoba, ale testy w projekcie mają być ustandaryzowane.
</quote>
Ojej, ojej...
A mówiąc poważnie, trzymając "standardy" - narzędzie PMD i jego wymagania co do trzymania dobrej jakości są conajmniej irytujące, weźmy, np. "Avoid if (x != y) ..; else ..;", nie mówiąc, że nie można wywołać konstruktora dla klasy Short - totalna porażka.
BTW. W tej chwili po dodaniu "loggera" do projektu pojawiło się masę błędów z nim związanych, zwiąanych z PMD.
<quote>
serializer i deserializer nie powinny przyjmować obiektu H2Connection w parametrze konstruktora, tylko same tworzyć i zamykać połączenie w swoim cyklu życia, poprzez tworzenie nowych obiektów H2Connectio
</quote>
<quote>
z punktu widzenia użytkownika tej biblioteki dostępne powinny być tylko dwa interfejsy - serializatora i deserializatora, posiadające metodę read i write object, oraz fabryka tworząca nowy serializator lub deserializato
</quote>
Z w.w. powodu nie może być dostępu tylko do serializatora i deserializatora.
<quote>
Powodzenia, a osobom nie znającym zasad pracy w projektach grupowych polecam poczytać trochę na ten temat, żeby uniknąć dalszych nieporozumień.
</quote>
Dziękujemy i również polecam zapoznać z powyższym linkiem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dacie Państwo radę skończyć do środy? Na stronie mat. Dydaktycznych wpisałem godziny konsulatcji we środę (ale zostanę dłużej jeśli będzie potrzeba).
From: kr3niu [mailto:kr3niu@users.sf.net]
Sent: Wednesday, July 04, 2012 12:39 AM
To: [java2rdb:discussion]
Subject: [java2rdb:discussion] Serializator nie działa
Trzeba. Nie wiesz o czym piszesz to nie pisz. Ty u siebie możesz na własne potrzeby testować kod jak ci się podoba, ale testy w projekcie mają być ustandaryzowane.
Ojej, ojej...
A mówiąc poważnie, trzymając "standardy" - narzędzie PMD i jego wymagania co do trzymania dobrej jakości są conajmniej irytujące, weźmy, np. "Avoid if (x != y) ..; else ..;", nie mówiąc, że nie można wywołać konstruktora dla klasy Short - totalna porażka.
BTW. W tej chwili po dodaniu "loggera" do projektu pojawiło się masę błędów z nim związanych, zwiąanych z PMD.
serializer i deserializer nie powinny przyjmować obiektu H2Connection w parametrze konstruktora, tylko same tworzyć i zamykać połączenie w swoim cyklu życia, poprzez tworzenie nowych obiektów H2Connectio
z punktu widzenia użytkownika tej biblioteki dostępne powinny być tylko dwa interfejsy - serializatora i deserializatora, posiadające metodę read i write object, oraz fabryka tworząca nowy serializator lub deserializato
Z w.w. powodu nie może być dostępu tylko do serializatora i deserializatora.
Powodzenia, a osobom nie znającym zasad pracy w projektach grupowych polecam poczytać trochę na ten temat, żeby uniknąć dalszych nieporozumień.
Dziękujemy i również polecam zapoznać z powyższym linkiem.
Zapoznałem się. To co podałem to były sugestie a nie uwagi, że coś jest nie tak i rozumiem, że wymagania określają, w jaki sposób powinno wyglądać wywołanie. Nie zmienia to faktu, że założenia można przekroczyć, choćby po to, żeby skompensować pewne braki.
"Z w.w. powodu nie może być dostępu tylko do serializatora i deserializatora."
Racja, ale nadal można to zrealizować w podobny sposób.
Przykład wywołania:
H2Serializer ser = H2Serialize.getSerializer();
H2Connection conn = new Connection();
ser.writeObject(conn, new JButton("Hello DB"));
gdzie H2Serializer jest interfejsem serializatora, a H2Serialize jest fabryką. Nie widzę tu żadnej różnicy poza uwidocznieniem H2Connection, za to projekt mocno zyskuje na bezpieczeństwie.
Widzę też jasno i wyraźnie określone w czym ma być projekt testowany:
"W trakcie przygotowywania testów jednostkowych należy korzystać opcjonalnie z bibliotek Junit lub TestNg oraz EasyMock (testy akceptacyjne)."
I widzę też jasno określoną metodę współpracy:
"Przydział zadań i raportowanie błędów ma być realizowane w systemie śledzenia biletów (Trac lub Bugzilla)."
Jeśli chodzi o PMD to chyba od tego jest programista, żeby umieć weryfikować na ile sensowne jest działanie narzędzia którym się posługuje, a ewentualna poprawa jakości może mieć miejsce, jak projekt zacznie spełniać swoją funkcjonalność.
Logger jest z kolei dodatkową funkcjonalnością, która ma na celu informować końcowego użytkownika o ewentualnych błędach w czasie uruchomienia.
Jednoznaczne jest to, że koordynacja w tym projekcie zwyczajnie leży, nie widziałem żadnych konkretnych zadań przydzielonych poprzez Trac chociażby, a o braku uprawnień już nie wspomnę.
Last edit: hommie 2012-07-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Widzę jakieś marudzenie w komentarzarach do projektu, typu:
"Ponownie proszę o usunięcie "Projektu testowego", do testowania służą test case'y"
Fajnie, tak do testowania JEDNOSTKOWEGO służa test case'y, ale całości nie trzeba tego w cale używać.
Można napisać nowy projekt, któy będzie używać naszej klasy.
W ten sposób zostały znalezione błachę błed autora tego komentarza w klasie H2Connection.
Co do pytania po co usuwac tabelę, a to dlatego, że działamy jak każdy inny serializator, a
ten dla porównania np XML-owy opróżnia plik i serializuję nowy obiekt, a więc trzeba opróznić tabelę,
zanim sie coś doda.
W rewizji 67 jeszcze działalo serializowanie pojedyńczego pola typu
int zmiennaInt = 2;
ser.writeobject(zmiennaInt)
Proszę o wyjaśnienie czemu to nie działa już. Mam stack overflow.
Trzeba będzie cofnąć wszystko do rewizji 67 jak tak dalej będzie.
To że jest OK w testach jednostkowych nie interesuję mnie to.
Commity w SVN-ie służa do komentowania wysyłanego kodu, a uwagi proszę zachować dla siebie,
Kieruję to do użytkownika hommie5.
Last edit: kr3niu 2012-07-01
Hommie5 miał rację co do usuwania tabel, był błąd: tabele były usuwane tuż przed deserializacją. Grupa programistów deserializera we współpracy ze mną poprawiła to, modyfikując nieznacznie i serializer, i deserializer.
Błąd został wychwycony i poprawiony, zmniejszmy ciśnienie.
To co napisałem oczywiście nie oznacza, że wskazany przez Kr3niu błąd już nie istnieje.
Last edit: krych14m 2012-07-02
Odpowiedz do kr3niu . Co do "Projekt testowego" to Dr Marciniak mowil, ze wszystko powinno byc w jednym projekcie, tak jak mu oddajemy. Co kolwiek robisz, cokolwiek sprawdzasz rob to tak, zeby bylo w jednym projekcie. Przeciez sam nie piszesz tego programu.
"Co do pytania po co usuwac tabelę, a to dlatego, że działamy jak każdy inny serializator, a
ten dla porównania np XML-owy opróżnia plik i serializuję nowy obiekt, a więc trzeba opróznić tabelę,
zanim sie coś doda."
-tabele były usuwane tuż przed deserializacją., POPRAWIONO
Ano widzisz byl duzy blad, ktorego Twoje testy nie wychwycily,
Co do tego, ze serializowanie nie dziala, przesledzimy dzisiaj dokladnie kod serializera i napewno uda nam sie go poprawic. A oprocz tego wrzucimy testy klas deserializer i serializer.
Pozdro i nie spinajcie posladow
Serializowanie pola poprawione, problem był w niezgodnych metodach Object#isPrimitive(), do zgłaszania takich problemów służy system ticketów, a nie forum.
Kolejny błąd, który występuje - czyli serializacj tablic (opisane w ticket'cie #15). Ten błąd sprawdziłem także w rewizji 67, żeby nie było pretensji, że ktoś ci nagrzebał i tam też serializacja tablic nie działa.
<quote>
-tabele były usuwane tuż przed deserializacją., POPRAWIONO
</quote>
Tak sie nie działo zawsze. Wystarczy, że utworzylo się raz uchwyt do H2Connection, a były czyszczone przed derserializacją. Ale rzeczywiście to był bład, zwracam honory
<quote>
Serializowanie pola poprawione, problem był w niezgodnych metodach Object#isPrimitive(),
do zgłaszania takich problemów służy system ticketów, a nie forum
</quote>
Nom, ale forum też jest do prowadzenia dyskusji. Uważam, że ticketa dajemy w drobniejszych sprawach, a tutaj wszystko przestało działać.
Dobra Panie i Panowie to teraz rzeczywiście serializer znów działał, ale postanowiśmy
go grupą przepisać i już uwzględnie wszystkie detale. Aaa Deserializer jeszcze nie był przpeisywany, wymaga poprawek pod kątem chociażby wykrywania duplikatów obiektów.
Teraz serializuję pola prymitynwę, tablice, ArrayListy, klasy, interfejsy nie, ale to nie potrzebne. Uwzględnia transient oraz duplikaty.
Sematyke zapisy tych samych obiektów wyjaśnimy w innym wątku, kiedy będzię gotowy deserializator :)
Każdy "request" zmiany w jakiejś części kodu odbywa się za pośrednictwem bug trackerów i ticketowania. Forum jest wyłącznie do dyskusji.
"Fajnie, tak do testowania JEDNOSTKOWEGO służa test case'y, ale całości nie trzeba tego w cale używać."
Trzeba. Nie wiesz o czym piszesz to nie pisz. Ty u siebie możesz na własne potrzeby testować kod jak ci się podoba, ale testy w projekcie mają być ustandaryzowane. Gdyby ten projekt wyglądał tak jak powinien wyglądać, czyli wykożystywałby Maven'a lub ANT'a, wyniki testów możnaby było załączać, obok dokumentacji, źródeł i binarek dla każdej ważniejszej rewizjii w formie archiwów jar, jak to ma miejsce w każdym porządnym projekcie programistycznym. JUnit nie służy do żadnego "testowania JEDNOSTKOWEGO", jest to zintegrowana platforma narzędzi testowych i do testów właśnie służy. Sformuowanie "jednostkowe" odnosi się do koncepcji testów mówiącej o tym, że najmniejszą jednostką testu jest metoda.
Skoro zamierzacie wprowadzać poważniejsze zmiany - kilka uwag co do samego funkcjonowania biblioteki:
- serializer i deserializer nie powinny przyjmować obiektu H2Connection w parametrze konstruktora, tylko same tworzyć i zamykać połączenie w swoim cyklu życia, poprzez tworzenie nowych obiektów H2Connection lub za pomocą jednego obiektu singleton, z synchronizowanymi metodami,
- z punktu widzenia użytkownika tej biblioteki dostępne powinny być tylko dwa interfejsy - serializatora i deserializatora, posiadające metodę read i write object, oraz fabryka tworząca nowy serializator lub deserializator. Cała reszta klas włącznie z samym serializatorem i deserializatorem powinna być niewidoczna. Takie podejście służy zapewnieniu odpowiedniego ograniczenia dostępnych metod za pomocą polimorfizmu.
Powodzenia, a osobom nie znającym zasad pracy w projektach grupowych polecam poczytać trochę na ten temat, żeby uniknąć dalszych nieporozumień.
<quote>
Trzeba. Nie wiesz o czym piszesz to nie pisz. Ty u siebie możesz na własne potrzeby testować kod jak ci się podoba, ale testy w projekcie mają być ustandaryzowane.
</quote>
Ojej, ojej...
A mówiąc poważnie, trzymając "standardy" - narzędzie PMD i jego wymagania co do trzymania dobrej jakości są conajmniej irytujące, weźmy, np. "Avoid if (x != y) ..; else ..;", nie mówiąc, że nie można wywołać konstruktora dla klasy Short - totalna porażka.
BTW. W tej chwili po dodaniu "loggera" do projektu pojawiło się masę błędów z nim związanych, zwiąanych z PMD.
<quote>
serializer i deserializer nie powinny przyjmować obiektu H2Connection w parametrze konstruktora, tylko same tworzyć i zamykać połączenie w swoim cyklu życia, poprzez tworzenie nowych obiektów H2Connectio
</quote>
Proszę zapoznać się z wymaganiami projektu:
http://www.uz.zgora.pl/~amarcini/wiki/index.php/Serializacja_Java2RDB
ser.writeObject(conn, new JButton("Hello DB"));
jak widać ma przyjmować H2Connection w uchwycie to ma
to nie jest nasze widzimisie, tylko takie jest założenie.
<quote>
z punktu widzenia użytkownika tej biblioteki dostępne powinny być tylko dwa interfejsy - serializatora i deserializatora, posiadające metodę read i write object, oraz fabryka tworząca nowy serializator lub deserializato
</quote>
Z w.w. powodu nie może być dostępu tylko do serializatora i deserializatora.
<quote>
Powodzenia, a osobom nie znającym zasad pracy w projektach grupowych polecam poczytać trochę na ten temat, żeby uniknąć dalszych nieporozumień.
</quote>
Dziękujemy i również polecam zapoznać z powyższym linkiem.
Dacie Państwo radę skończyć do środy? Na stronie mat. Dydaktycznych wpisałem godziny konsulatcji we środę (ale zostanę dłużej jeśli będzie potrzeba).
From: kr3niu [mailto:kr3niu@users.sf.net]
Sent: Wednesday, July 04, 2012 12:39 AM
To: [java2rdb:discussion]
Subject: [java2rdb:discussion] Serializator nie działa
Trzeba. Nie wiesz o czym piszesz to nie pisz. Ty u siebie możesz na własne potrzeby testować kod jak ci się podoba, ale testy w projekcie mają być ustandaryzowane.
Ojej, ojej...
A mówiąc poważnie, trzymając "standardy" - narzędzie PMD i jego wymagania co do trzymania dobrej jakości są conajmniej irytujące, weźmy, np. "Avoid if (x != y) ..; else ..;", nie mówiąc, że nie można wywołać konstruktora dla klasy Short - totalna porażka.
BTW. W tej chwili po dodaniu "loggera" do projektu pojawiło się masę błędów z nim związanych, zwiąanych z PMD.
serializer i deserializer nie powinny przyjmować obiektu H2Connection w parametrze konstruktora, tylko same tworzyć i zamykać połączenie w swoim cyklu życia, poprzez tworzenie nowych obiektów H2Connectio
Proszę zapoznać się z wymaganiami projektu:
http://www.uz.zgora.pl/~amarcini/wiki/index.php/Serializacja_Java2RDB
ser.writeObject(conn, new JButton("Hello DB"));
jak widać ma przyjmować H2Connection w uchwycie to ma
to nie jest nasze widzimisie, tylko takie jest założenie.
z punktu widzenia użytkownika tej biblioteki dostępne powinny być tylko dwa interfejsy - serializatora i deserializatora, posiadające metodę read i write object, oraz fabryka tworząca nowy serializator lub deserializato
Z w.w. powodu nie może być dostępu tylko do serializatora i deserializatora.
Powodzenia, a osobom nie znającym zasad pracy w projektach grupowych polecam poczytać trochę na ten temat, żeby uniknąć dalszych nieporozumień.
Dziękujemy i również polecam zapoznać z powyższym linkiem.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/java2rdb/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/
Zapoznałem się. To co podałem to były sugestie a nie uwagi, że coś jest nie tak i rozumiem, że wymagania określają, w jaki sposób powinno wyglądać wywołanie. Nie zmienia to faktu, że założenia można przekroczyć, choćby po to, żeby skompensować pewne braki.
"Z w.w. powodu nie może być dostępu tylko do serializatora i deserializatora."
Racja, ale nadal można to zrealizować w podobny sposób.
Przykład wywołania:
H2Serializer ser = H2Serialize.getSerializer();
H2Connection conn = new Connection();
ser.writeObject(conn, new JButton("Hello DB"));
gdzie H2Serializer jest interfejsem serializatora, a H2Serialize jest fabryką. Nie widzę tu żadnej różnicy poza uwidocznieniem H2Connection, za to projekt mocno zyskuje na bezpieczeństwie.
Widzę też jasno i wyraźnie określone w czym ma być projekt testowany:
"W trakcie przygotowywania testów jednostkowych należy korzystać opcjonalnie z bibliotek Junit lub TestNg oraz EasyMock (testy akceptacyjne)."
I widzę też jasno określoną metodę współpracy:
"Przydział zadań i raportowanie błędów ma być realizowane w systemie śledzenia biletów (Trac lub Bugzilla)."
Jeśli chodzi o PMD to chyba od tego jest programista, żeby umieć weryfikować na ile sensowne jest działanie narzędzia którym się posługuje, a ewentualna poprawa jakości może mieć miejsce, jak projekt zacznie spełniać swoją funkcjonalność.
Logger jest z kolei dodatkową funkcjonalnością, która ma na celu informować końcowego użytkownika o ewentualnych błędach w czasie uruchomienia.
Jednoznaczne jest to, że koordynacja w tym projekcie zwyczajnie leży, nie widziałem żadnych konkretnych zadań przydzielonych poprzez Trac chociażby, a o braku uprawnień już nie wspomnę.
Last edit: hommie 2012-07-04