Confitura: Ludzie z zapałem poszukiwani
Michal Margiel
Pozdrawiam/Best regards
Michał Margiel
http://www.confitura.pl
http://www.linkedin.com/in/MichalMargiel
Paweł Cesar Sanjuan Szklarz
A czy silnik jest/bedzie opensource??
2011/12/19 Michal Margiel <michal....@gmail.com>:
> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
Michal Margiel
Czesc
A czy silnik jest/bedzie opensource??
Pozdrawiam/Best regards
Michał Margiel
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu
Radosław Szmit
ale właśnie przeniosłem go na bitbucket.
Ale to jest chyba płatne powyżej 5 użytkowników?
--
Pozdrawiam serdecznie
Radosław Szmit
Paweł Cesar Sanjuan Szklarz
Chętnie zobaczę gdzie bym ewentualnie poświecał czas i dobrze sie bawił.
2011/12/20 Michal Margiel <michal....@gmail.com>:
Piotr Przybylak
W dniu 20 grudnia 2011 10:22 użytkownik Radosław Szmit
<radosl...@gmail.com> napisał:
> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
--
Pozdrawiam
Piotr Przybylak
Radosław Szmit
W dniu 20 grudnia 2011 10:27 użytkownik Piotr Przybylak <piotr.p...@gmail.com> napisał:
Nie dla projektów opensource.
No to git... znaczy hg :D
Michal Margiel
W dniu 20 grudnia 2011 10:27 użytkownik Piotr Przybylak <piotr.p...@gmail.com> napisał:Nie dla projektów opensource.
No to git... znaczy hg :D
Marcin Zajączkowski
>
>
> W dniu 20 grudnia 2011 10:47 u�ytkownik Rados�aw Szmit <radosl...@gmail.com> napisa�:
>
> > W dniu 20 grudnia 2011 10:27 u�ytkownik Piotr Przybylak <piotr.p...@gmail.com> napisa�:
> >
> > > Nie dla projekt�w opensource.
> >
> > No to git... znaczy hg :D
Nie wywo�uj flame'a (przynajmniej w tym w�tku ;) ). Przecie� Git jest bardzo fajny i dobrze spe�nia swoje zadanie :).
Marcin
> to jest stary kod:
> https://github.com/margielm/Confitura
> https://bitbucket.org/margielm/confitura
> ale przyznaj�, bez bicia, �e na razie kod jest s�aby. Tworzy�em go 97% sam, po godzinach i w po�piechu :)
> Tak�e prosz� o pohamowanie si� z publicznym linczem :)
> --
> Pozdrawiam/Best regards
> Michaďż˝ Margiel
>
> http://www.confitura.pl (dawniej Javarsovia)
> http://www.linkedin.com/in/MichalMargiel
> http://www.margiel.eu
>
>
> --
> Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
> Wi�cej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
> Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
--
http://solidsoft.wordpress.com/ - Working code is not enough
Michal Margiel
Dnia 20-12-2011 o godz. 10:55 Michal Margiel napisał(a):
>
>
> W dniu 20 grudnia 2011 10:47 użytkownik Radosław Szmit <radosl...@gmail.com> napisał:
>
> > W dniu 20 grudnia 2011 10:27 użytkownik Piotr Przybylak <piotr.p...@gmail.com> napisał:
> >
> > > Nie dla projektów opensource.
> >
> > No to git... znaczy hg :D
> No włąśnie właśnie.. bo dla mnie git to kit :PNie wywołuj flame'a (przynajmniej w tym wątku ;) ). Przecież Git jest bardzo fajny i dobrze spełnia swoje zadanie :).
Pozdrawiam/Best regards
Michał Margiel
Jacek Laskowski
> Nie wywołuj flame'a (przynajmniej w tym wątku ;) ). Przecież Git jest bardzo fajny i dobrze spełnia swoje zadanie :).
Pewnie jak każdy system ma swoje wady i zalety, i oby okazało się, że
wad jest stosunkowo niewiele do funkcjonalności, które oferuje (tyczy
się obu). Wielu zarzuca git'owi wersjonowanie z kosmosu, co *podobno*
w hg jest ładniej obsłużone.
Czemu się jednak dziwię Michałowi, to zarzucenie tych fajnych gadżetów
Githuba, gdzie zmiany można wprowadzać przez edycję strony. Dla wielu
byłby to baaaardzo niski próg wejścia i zachęciłby większą liczbę
zainteresowanych.
Wierzę, że Michał wsłucha się w potrzeby szarej gawiedzi i zechce
jednak rozważyć powrót do Githuba. Dla mnie osobiście to bez
znaczenia, ale dla budowania większego udziału społeczności, użycie
narzędzi, które postrzegane są jako lepsze (niekoniecznie nimi są) i
popularniejsze jest kluczem do sukcesu.
Pożyjemy, zobaczymy. To, czego Michał nie napisał, a jest równie
kluczowe, to fakt, że ten kod i tak zostanie użyty bez względu na jego
finalną postać! To ma swoje wady, ale pewne jest, że jeśli ludziska
się udzielą w nim, będą mogli pochwalić się tym, bo będzie publicznie
użyte. Na prawdę warto!
Jacek
--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl
"Hoping to save time by spending it" by David Blevins (Apache OpenEJB)
Vitaliy Oliynyk
--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Jakub Nabrdalik
> Czemu się jednak dziwię Michałowi, to zarzucenie tych fajnych gadżetów
> Githuba, gdzie zmiany można wprowadzać przez edycję strony.
Zamierzasz w javie edytować i pushować klasy przez stronę www, bez
odpalenia lokalnego wszystkich testów, ba, bez odpalenia kompilacji?
Faktycznie, KILLER feature :)
--
Jakub Nabrdalik
http://solidcraft.eu
Michal Margiel
Michal Margiel
2011/12/20 Marcin Zajączkowski <msz...@wp.pl>:
Pewnie jak każdy system ma swoje wady i zalety, i oby okazało się, że
> Nie wywołuj flame'a (przynajmniej w tym wątku ;) ). Przecież Git jest bardzo fajny i dobrze spełnia swoje zadanie :).
wad jest stosunkowo niewiele do funkcjonalności, które oferuje (tyczy
się obu). Wielu zarzuca git'owi wersjonowanie z kosmosu, co *podobno*
w hg jest ładniej obsłużone.
Czemu się jednak dziwię Michałowi, to zarzucenie tych fajnych gadżetów
Githuba, gdzie zmiany można wprowadzać przez edycję strony. Dla wielu
byłby to baaaardzo niski próg wejścia i zachęciłby większą liczbę
zainteresowanych.
Pozdrawiam/Best regards
Michał Margiel
Łukasz Lenart
Pozdrawiam
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl/
Michal Margiel
Można postawić Jenkinsa aby budował i testował cały kod, serwer mamy :-)
Jacek Laskowski
> Zamierzasz w javie edytować i pushować klasy przez stronę www, bez odpalenia
> lokalnego wszystkich testów, ba, bez odpalenia kompilacji?
>
> Faktycznie, KILLER feature :)
Dla nowicjuszy, którzy bardzo chcą, ale próg wejścia jest zbyt niski
jest to wspaniałe narzędzie. Kiedy zobaczą, że można, kiedy doświadczą
tego przyjemnego uczucia byciem częścią zespołu, od razu zyskasz
bardzo pracowitego i pożądanego członka zespołu.
Przy budowaniu zespołów bez posiadania hierachii służbowej, to
niezwykle przydatne.
Jacek Laskowski
> W życiu bym nie pozwolił na coś takiego. Może w Twoich projektach tak się
> robi.. nie w moich :) Także to kolejny argument żeby wylecieć z gitHuba.
> zresztą strona "społecznościowa" systemu kontrolii wersji średnio mnie
> interesuje i podnieca (nawet jeśli ma integracę z facebookiem i innego tegho
> typu "ważnymi portalami"). Dla mnie takie narzędzie ma być proste w
> obsłudze i intuicyjne, git moim zdaniem taki nie jest a plugin do eclipse
> jest tragiczny.
> Dlatego, nie - nie planuję powrotu na GitHuba
Zauważ, ile razy użyłeś "JA", a ile "MY", albo "ONI". Współczynnik
JA/(MY+ONI) >> 1 uważam za projekt dla zaawansowanych, a tym zwykle
brakuje chęci na zabawy po pracy :) Pożyjemy, zobaczymy.
Rozumiem powody i je szanuję. Pis ponad wszystko! :-)
Grzegorz Duda
Przy budowaniu zespołów bez posiadania hierachii służbowej, to
niezwykle przydatne.
Regards/Pozdrawiam,
Grzegorz Duda (http://www.dworld.pl/page/show/Grzegorz_Duda/)
33rd Degree conference for Java Masters (http://33degree.org)
Developers World (http://www.dWorld.pl)
JAVA exPress (http://www.javaexpress.pl)
Michal Margiel
2011/12/20 Michal Margiel <michal....@gmail.com>:
Zauważ, ile razy użyłeś "JA", a ile "MY", albo "ONI". Współczynnik
> W życiu bym nie pozwolił na coś takiego. Może w Twoich projektach tak się
> robi.. nie w moich :) Także to kolejny argument żeby wylecieć z gitHuba.
> zresztą strona "społecznościowa" systemu kontrolii wersji średnio mnie
> interesuje i podnieca (nawet jeśli ma integracę z facebookiem i innego tegho
> typu "ważnymi portalami"). Dla mnie takie narzędzie ma być proste w
> obsłudze i intuicyjne, git moim zdaniem taki nie jest a plugin do eclipse
> jest tragiczny.
> Dlatego, nie - nie planuję powrotu na GitHuba
JA/(MY+ONI) >> 1 uważam za projekt dla zaawansowanych, a tym zwykle
brakuje chęci na zabawy po pracy :) Pożyjemy, zobaczymy.
Rozumiem powody i je szanuję. Pis ponad wszystko! :-)
Michal Margiel
2011/12/20 Jakub Nabrdalik <jak...@gmail.com>:
Dla nowicjuszy, którzy bardzo chcą, ale próg wejścia jest zbyt niski
> Zamierzasz w javie edytować i pushować klasy przez stronę www, bez odpalenia
> lokalnego wszystkich testów, ba, bez odpalenia kompilacji?
>
> Faktycznie, KILLER feature :)
jest to wspaniałe narzędzie. Kiedy zobaczą, że można, kiedy doświadczą
tego przyjemnego uczucia byciem częścią zespołu, od razu zyskasz
bardzo pracowitego i pożądanego członka zespołu.
Pozdrawiam/Best regards
Michał Margiel
Jacek Kunicki
W dniu 20 grudnia 2011 13:55 użytkownik Jacek Laskowski <ja...@japila.pl> napisał:2011/12/20 Jakub Nabrdalik <jak...@gmail.com>:
Dla nowicjuszy, którzy bardzo chcą, ale próg wejścia jest zbyt niski
> Zamierzasz w javie edytować i pushować klasy przez stronę www, bez odpalenia
> lokalnego wszystkich testów, ba, bez odpalenia kompilacji?
>
> Faktycznie, KILLER feature :)
jest to wspaniałe narzędzie. Kiedy zobaczą, że można, kiedy doświadczą
tego przyjemnego uczucia byciem częścią zespołu, od razu zyskasz
bardzo pracowitego i pożądanego członka zespołu.Ok.. masz rację.. to moze uściśle trochę moją ofertę.Poszukujemy osób którzy znają, lub przynajmniej CHCĄ poznać, jakieś IDE. a nie edytowac kod w oknie przeglądarki ;)
http://logizkuchni.posterous.com
Jakub Nabrdalik
> 2011/12/20 Jakub Nabrdalik<jak...@gmail.com>:
>
>> Zamierzasz w javie edytować i pushować klasy przez stronę www, bez odpalenia
>> lokalnego wszystkich testów, ba, bez odpalenia kompilacji?
>>
>> Faktycznie, KILLER feature :)
>
> Dla nowicjuszy, którzy bardzo chcą, ale próg wejścia jest zbyt niski
> jest to wspaniałe narzędzie.
Jacek, pracowałeś tak kiedyś z kimś w Javie?
Wprowadzałeś w ten sposób zmiany do jakiegoś projektu?
Ja wiem, że programowanie w Javie bez IDE jest możliwe. Podobnie golenie
się siekierą.
Michał Gruca
Radosław Szmit
W dniu 20 grudnia 2011 13:41 użytkownik Michal Margiel <michal....@gmail.com> napisał:
Dla mnie takie narzędzie ma być proste w obsłudze i intuicyjne, git moim zdaniem taki nie jest a plugin do eclipse jest tragiczny.Dlatego, nie - nie planuję powrotu na GitHuba
Michal Margiel
Jakub Nabrdalik
> nie wywoluj vimowcow z lasu! ;)
Bo przylecą z siekierami? :)
Michal Margiel
W dniu 20.12.2011 14:36, Michał Gruca pisze:Bo przylecą z siekierami? :)
nie wywoluj vimowcow z lasu! ;)
Pozdrawiam/Best regards
Michał Margiel
Tomasz Bujok
pewno�ci� si� z Tob� nie zgodz�, np. pierwszi z brzegu: Ted Neward,
Howard Lewis-Ship, czy moja skromna osoba. Umiej�tno�� napisania kilku
klas nie w IDE jest czasem kluczowa i nie nazwa�bym tego goleniem sie
siekiera.
Inna rzecz to troche chyba dla sportu czepiacie sie Jacka, ktory
poruszyl temat "progu wejscia", podajac moze nie najlepszy przyklad
edycji z www - jednak to nie by�o chyba kwintesencja jego wypowiedzi...
Pozdro,
Tomek
On 20/12/2011 2:18 PM, Jakub Nabrdalik wrote:
> Jacek, pracowa�e� tak kiedy� z kim� w Javie?
>
> Wprowadza�e� w ten spos�b zmiany do jakiego� projektu?
>
> Ja wiem, �e programowanie w Javie bez IDE jest mo�liwe. Podobnie golenie
> siďż˝ siekierďż˝.
>
Michal Margiel
Dla Ciebie jest to może tak oczywiste, ale jest wielu ludzi, którzy z pewnością się z Tobą nie zgodzą, np. pierwszi z brzegu: Ted Neward, Howard Lewis-Ship, czy moja skromna osoba. Umiejętność napisania kilku klas nie w IDE jest czasem kluczowa i nie nazwałbym tego goleniem sie siekiera.
Inna rzecz to troche chyba dla sportu czepiacie sie Jacka, ktory poruszyl temat "progu wejscia", podajac moze nie najlepszy przyklad edycji z www - jednak to nie było chyba kwintesencja jego wypowiedzi...
Pozdrawiam/Best regards
Michał Margiel
Grzegorz Duda
Regards/Pozdrawiam,
Grzegorz Duda (http://www.dworld.pl/page/show/Grzegorz_Duda/)
33rd Degree conference for Java Masters (http://33degree.org)
Developers World (http://www.dWorld.pl)
JAVA exPress (http://www.javaexpress.pl)
--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Michal Margiel
"Spokojnych Świąt" nabiera nowego znaczenia ;)Swoja droga zastanawiam sie, czy jakby połączyć ludzi, którzy pracują nad narzędziami do zarządzania Confitura, GeeCONem i 33rd Degree, to już w przyszłym roku nie mielibyśmy fajnego narzędzia, który spełniałby wszystkie wymagania...
Jakub Nabrdalik
> Dla Ciebie jest to może tak oczywiste, ale jest wielu ludzi, którzy z
> Howard Lewis-Ship, czy moja skromna osoba. Umiejętność napisania kilku
> klas nie w IDE jest czasem kluczowa i nie nazwałbym tego goleniem sie
> siekiera.
A możesz się podzielić, w jakich sytuacjach korzystasz z tej techniki i
dlaczego?
U mnie w robocie mówią na to "golenie jaka":
http://en.wiktionary.org/wiki/yak_shaving
> Inna rzecz to troche chyba dla sportu czepiacie sie Jacka [...]
Racja. Sorry for that.
Radosław Szmit
W dniu 20 grudnia 2011 14:44 użytkownik Michal Margiel <michal....@gmail.com> napisał:
Dla mnie to jest argument, bo ja jestem użytkownikiem Eclipsa. A z tym mavenem to na prawdę nie rozumiem - ja nie mam ani jednego powodu do narzekania.
Michał Karolik
Chętnie pomogę w miarę możliwości, choć egoistycznie podchodzę do tego jako do nauki wicketa + mercuriala ; ) sam jestem dinozaurem, który nie bawi się ani gitem, ani mercurialem - stary dobry svn jak narazie mnie nie zawiódł.
Michal Margiel
Michal Margiel
Panowie... od jakiegoś czasu coraz ciężej czyta się grupę, bo wątek zawsze leci w offtopic.... ale to taki, że jak nie zajrzę przez godzinę to już naprawdę nie wiem o co chodzi ; )
Chętnie pomogę w miarę możliwości, choć egoistycznie podchodzę do tego jako do nauki wicketa + mercuriala ; ) sam jestem dinozaurem, który nie bawi się ani gitem, ani mercurialem - stary dobry svn jak narazie mnie nie zawiódł.
Michał Karolik
Tomasz Bujok
numeracji to zwykla pomylka :D
Tomek
On 20/12/2011 3:43 PM, Tomasz Bujok wrote:
> Ok. Jesli Twoim wymogiem jest Eclipse to chyba rzeczywiscie z Gitem
> daleko nie pociagniesz - chociaz slyszalem ze support sie poprawie (sam
> nie sprawdzalem przez ponad rok, wiec nie wiem). W IntelliJ dla
> porownania Git dziala swietnie.
>
> Wracajac do dzialajacego SVN'a - zgadzam sie ze wszystko zalezy od
> wymagan jakie sobie stawiamy. Zerknij na ponizsza liste i powiedz czy w
> SVN nie przeszkdzalo Ci nigdy, ze:
> 1.) jestes offline (np. w pociagu/samolocie), nie masz dostepu do
> internetu a tam jest Twoj SVN. Programujesz 3 wersje jednej
> funkcjonalnosci zeby sprawdzic ktora dziala najlepiej. Co robisz zeby
> zachowac historie swoich zmian.
> 2.) dwa tygodnie pracujesz na branchu, programujesz nowa funkcjonalnosc
> i po zakonczeniu prac chcesz zmergowac to do trunka gdzie przez dwa
> tygodnie commitowalo 8 developerow - konflikty oczywiscie sa.
> 3.) pracujesz nad nowa funkcjonalnoscia na branchu ale wprowadzasz
> rowniesz zmiany na trunku - w tym wypadku w Eclipsie musisz miec dwa
> workspacy i sie przelaczac lub otworzyc dwie instancje eclipse'a.
> 4.) robisz update, commit i trwa to 2 minuty
> 5.) robisz checkout brancha i trwa to tak samo dlugo jak swiezy checkout
> trunka, ktory masz juz lokalnie.
> 6.) nie chcesz commitowac do repo zeby Twoje zmiany nie byly jeszcze
> widoczne dla innych, ale dla siebie chcesz miec "drobno-ziarnista"
> kontrole zmian.
> 8.) zmieniasz nazwy pakietow, przenosisz klasy - szczegolnie w
> eclipse+svn dziala to w trybie remove/add -> co uniemozliwia Ci
> sledzenie historii zmian od poczatku istnienia "pliku"
> 9.) update'jesz projekt gdzie zmieniles cos w klasie ktorej kolega
> zmienil nazwe.
> 10.) itp, itd... mozna by mnozyc.
>
> Dla chetnych moge napisac co git w ww. obszarach oferuje - ale nie mam
> teraz za wiele czasu... jestem w pracy :)
>
> Jesli rzeczywiscie to Ci nigdy nie przeszkadzalo, to pytanie: Po co
> zmieniac SVN na cos innego? - nabiera jak najbardziej sensu.
>
> Dla mnie przestawienie sie na gita to niesamowity w jakosci pracy i ,
> ale 1.) uwielbiam konsole, 2.) pracuje w IntelliJ -> gdzie wsparcie gita
> jest super.
>
> Pozdro,
> Tomek
>
>
>
> On 20/12/2011 3:20 PM, Michal Margiel wrote:
>>
>>
>> W dniu 20 grudnia 2011 15:13 u�ytkownik Rados�aw Szmit
>> <radosl...@gmail.com <mailto:radosl...@gmail.com>> napisaďż˝:
>>
>>
>> W dniu 20 grudnia 2011 14:44 u�ytkownik Michal Margiel
>> <michal....@gmail.com <mailto:michal....@gmail.com>> napisaďż˝:
>>
>> Dla mnie to jest argument, bo ja jestem u�ytkownikiem Eclipsa. A
>> z tym mavenem to na prawdďż˝ nie rozumiem - ja nie mam ani jednego
>> powodu do narzekania.
>>
>>
>> Uwa�anie, �e co� jest s�abe, tylko dlatego, �e nie da si� tego
>> u�ywa� w Eclipsie, a dzia�a bardzo dobrze w Idei/Netbeans (nie wiem
>> jak jest z gitem) to nie jest warto�ciowy argument przeciw temu
>> czemu�, jest tylko i wy��cznie argumentem przeciw u�ywaniu tego
>> czego� wraz z eclipsem, ale przecie� sam napisa�e� "znaj�, lub
>> przynajmniej CHCďż˝ poznaďż˝, jakieďż˝ IDE" ;)
>>
>>
>> Dla mnie system kontroli wersji ma mi pom�c a nie przeszkodzi�. SVN w
>> eclipsie dzia�a �WIETNIE, je�li mia�bym przej�� na inny system to musz�
>> mieďż˝ ku temu jakieďż˝ argumenty. Jednďż˝ z cech jaka szukam w takim systemie
>> to integracja z moim IDE (czyli eclipsem) - je�li, �eby cokolwiek
>> zrobi�, musz� przechodzi� do konsoli - to jest s�abo. Je�li na ka�de
>> ctrl+s musze czekaďż˝ 5 sek bo "egit coďż˝ tam sobie robi", a edytor
>> konflikt�w dzia�a beznadziejnie - to jest to nie mam w og�le nad czym
>> si� zastanawia�. Po co mam wymienia� co� co dzia�a dobrze na co� co
>> dzia�a �le? Zw�aszcza, ze jest mercurial kt�ry dzia�a dobrze.
>>
>> Dlatego dla mnie integracja z eclipsem jest wa�na. ale jak podkre�lam -
>> DLA MNIE. Ty mo�esz mie� inne argumenty ZA gitem, np. mnogo�� funkcji
>> kt�re dla mnie nie stanowi� �adnej warto�ci.
>>
>> --
>> Pozdrawiam/Best regards
>> Michaďż˝ Margiel
>>
>> http://www.confitura.pl (dawniej Javarsovia)
>> http://www.linkedin.com/in/MichalMargiel
>> http://www.margiel.eu
>>
>> --
>> Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
>> Wi�cej informacji na stronie
>> http://groups.google.com/group/warszawa-jug?hl=pl
>> Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Tomasz Bujok
Pozdro,
Tomek
> Dla mnie to jest argument, bo ja jestem u�ytkownikiem Eclipsa. A
> z tym mavenem to na prawdďż˝ nie rozumiem - ja nie mam ani jednego
> powodu do narzekania.
>
>
> Uwa�anie, �e co� jest s�abe, tylko dlatego, �e nie da si� tego
> u�ywa� w Eclipsie, a dzia�a bardzo dobrze w Idei/Netbeans (nie wiem
> jak jest z gitem) to nie jest warto�ciowy argument przeciw temu
> czemu�, jest tylko i wy��cznie argumentem przeciw u�ywaniu tego
> czego� wraz z eclipsem, ale przecie� sam napisa�e� "znaj�, lub
> przynajmniej CHCďż˝ poznaďż˝, jakieďż˝ IDE" ;)
>
>
> Dla mnie system kontroli wersji ma mi pom�c a nie przeszkodzi�. SVN w
> eclipsie dzia�a �WIETNIE, je�li mia�bym przej�� na inny system to musz�
> mieďż˝ ku temu jakieďż˝ argumenty. Jednďż˝ z cech jaka szukam w takim systemie
> to integracja z moim IDE (czyli eclipsem) - je�li, �eby cokolwiek
> zrobi�, musz� przechodzi� do konsoli - to jest s�abo. Je�li na ka�de
> ctrl+s musze czekaďż˝ 5 sek bo "egit coďż˝ tam sobie robi", a edytor
> konflikt�w dzia�a beznadziejnie - to jest to nie mam w og�le nad czym
> si� zastanawia�. Po co mam wymienia� co� co dzia�a dobrze na co� co
> dzia�a �le? Zw�aszcza, ze jest mercurial kt�ry dzia�a dobrze.
>
> Dlatego dla mnie integracja z eclipsem jest wa�na. ale jak podkre�lam -
> DLA MNIE. Ty mo�esz mie� inne argumenty ZA gitem, np. mnogo�� funkcji
> kt�re dla mnie nie stanowi� �adnej warto�ci.
>
> --
> Pozdrawiam/Best regards
> Michaďż˝ Margiel
>
> http://www.confitura.pl (dawniej Javarsovia)
> http://www.linkedin.com/in/MichalMargiel
> http://www.margiel.eu
>
Radosław Szmit
W dniu 20 grudnia 2011 15:20 użytkownik Michal Margiel <michal....@gmail.com> napisał:
Dla mnie system kontroli wersji ma mi pomóc a nie przeszkodzić. SVN w eclipsie działa ŚWIETNIE, jeśli miałbym przejść na inny system to muszę mieć ku temu jakieś argumenty. Jedną z cech jaka szukam w takim systemie to integracja z moim IDE (czyli eclipsem) - jeśli, żeby cokolwiek zrobić, muszę przechodzić do konsoli - to jest słabo. Jeśli na każde ctrl+s musze czekać 5 sek bo "egit coś tam sobie robi", a edytor konfliktów działa beznadziejnie - to jest to nie mam w ogóle nad czym się zastanawiać. Po co mam wymieniać coś co działa dobrze na coś co działa źle? Zwłaszcza, ze jest mercurial który działa dobrze.Dlatego dla mnie integracja z eclipsem jest ważna. ale jak podkreślam - DLA MNIE. Ty możesz mieć inne argumenty ZA gitem, np. mnogość funkcji które dla mnie nie stanowią żadnej wartości.
"A ja tam jestem za pluralizmem i wolnością wyboru :)"
PS: A może by tak przestawić się na "DLA NAS" a nie "DLA MNIE" bo inaczej nie widzę szans na powodzenie tego projektu. Wydawało mi się, że Agile zakłada samoorganizujący się zespół, ale widocznie czegoś nie doczytałem...
Michal Margiel
W dniu 20 grudnia 2011 15:20 użytkownik Michal Margiel <michal....@gmail.com> napisał:Nie mam żadnych argumentów za gitem, bo nie o to chodzi, sam używam mercuriala, ale nie zamierzam krytykować jakiejś technologii tylko dlatego że wtyczka egit do gita w eclipse działa słabo, bo ta do svn'a też "świetna" nie jest. Widziałem wielokrotnie ludzi na WJUGu którzy podczas swoich prezentacji używali git+idea i nie zauważyłem żeby mieli jakieś problemy. Ja się w pełni zgadzam z TWOIM poprzednim zdaniemDla mnie system kontroli wersji ma mi pomóc a nie przeszkodzić. SVN w eclipsie działa ŚWIETNIE, jeśli miałbym przejść na inny system to muszę mieć ku temu jakieś argumenty. Jedną z cech jaka szukam w takim systemie to integracja z moim IDE (czyli eclipsem) - jeśli, żeby cokolwiek zrobić, muszę przechodzić do konsoli - to jest słabo. Jeśli na każde ctrl+s musze czekać 5 sek bo "egit coś tam sobie robi", a edytor konfliktów działa beznadziejnie - to jest to nie mam w ogóle nad czym się zastanawiać. Po co mam wymieniać coś co działa dobrze na coś co działa źle? Zwłaszcza, ze jest mercurial który działa dobrze.Dlatego dla mnie integracja z eclipsem jest ważna. ale jak podkreślam - DLA MNIE. Ty możesz mieć inne argumenty ZA gitem, np. mnogość funkcji które dla mnie nie stanowią żadnej wartości.
, i nie obchodzi mnie czy ktoś używa Eclipse/Idea/Netbeans/JDeveloper/vim/emacs/notepad/... to jego wybór i decyzja w czym mu się pisze wygodnie.
"A ja tam jestem za pluralizmem i wolnością wyboru :)"
PS: A może by tak przestawić się na "DLA NAS" a nie "DLA MNIE" bo inaczej nie widzę szans na powodzenie tego projektu. Wydawało mi się, że Agile zakłada samoorganizujący się zespół, ale widocznie czegoś nie doczytałem...
Jakub Nabrdalik
> [SVN] 2.) dwa tygodnie pracujesz na branchu
Ze strachu obsrałem w tym momencie krzesełko w pracy. Branchowanie w
svn'ie? Straszne rzeczy opowiadasz :D
Jedyne branche w svn'ie jakie mają IMHO sens, są typu fire&forget (np.
branch dla klienta który nie chce się aktualizować). Mergowanie w svn'ie
często kończyło się ręcznym paczem trunka.
Michal Margiel
Pozdrawiam/Best regards
Michał Margiel
Jakub Nabrdalik
>
>
> W dniu 20 grudnia 2011 16:02 użytkownik Jakub Nabrdalik
>
> W dniu 20.12.2011 15 <tel:20.12.2011%2015>:43, Tomasz Bujok pisze:
>
> [SVN] 2.) dwa tygodnie pracujesz na branchu
>
>
> Ze strachu obsrałem w tym momencie krzesełko w pracy. Branchowanie w
> svn'ie? Straszne rzeczy opowiadasz :D
>
> Jedyne branche w svn'ie jakie mają IMHO sens, są typu fire&forget
> (np. branch dla klienta który nie chce się aktualizować). Mergowanie
> w svn'ie często kończyło się ręcznym paczem trunka.
>
>
> A my pracujemy na branchach nawet dłuzej i nie mamy z tym większych
> problemów.
> Jeden nawet mieliśmy który żył ~ 4 miesięcy:)
Muszę zmienić kolejne krzesełko, ech...
Tomasz Bujok
Dla uscislenia - pytam SVN userow (glownie Michala) jak radza sobie w
SVNie ze wspomnianymi w punktach rzeczami.
Nie wiem czy jedyne branche w SVN'ie to te typu "fire&forget",
"experimental" tez pewnie wchodza w gre, ale wspolczuje przy mergu.
Na pewno nie da sie "branch-per-feature".
A swoja droga Kuba, to albo tam w tej firmie produkujecie kazdy software
ksiazkowo ("respect"), albo "teoria na liscie sobie" a "praktyka sobie",
bo nie uwierze ze nigdy nie pracowales na "long-living" branchu... albo
chociaz go nie widziales/dotknales/czy jak to dzisiaj masz w zwyczaju
obsrales ;)
Tomek
On 20/12/2011 4:02 PM, Jakub Nabrdalik wrote:
> W dniu 20.12.2011 15:43, Tomasz Bujok pisze:
>> [SVN] 2.) dwa tygodnie pracujesz na branchu
>
> Ze strachu obsra�em w tym momencie krzese�ko w pracy. Branchowanie w
> svn'ie? Straszne rzeczy opowiadasz :D
>
> Jedyne branche w svn'ie jakie majďż˝ IMHO sens, sďż˝ typu fire&forget (np.
> branch dla klienta kt�ry nie chce si� aktualizowa�). Mergowanie w svn'ie
> cz�sto ko�czy�o si� r�cznym paczem trunka.
>
Michal Margiel
Muszę zmienić kolejne krzesełko, ech...
Jakub Nabrdalik
>
> A swoja droga Kuba, to albo tam w tej firmie produkujecie kazdy software
> ksiazkowo ("respect"), albo "teoria na liscie sobie" a "praktyka sobie",
> bo nie uwierze ze nigdy nie pracowales na "long-living" branchu... albo
> chociaz go nie widziales/dotknales/czy jak to dzisiaj masz w zwyczaju
> obsrales ;)
Tak, widziałem/dotykałem 2tygodniowe i dłuższe branche w svn'ie. No i
często przy tree-conflictach (co jest nieuniknione przy refactorowanym
kodzie) po kilku godzinach się poddawaliśmy, wyciągaliśmy zmiany z
brancha i wrzucaliśmy ręcznie do trunka. Branch per feature odpadał, gdy
refactoring jest na porządku dziennym. Dopiero przy gicie zaczął ładnie
banglać.
Nie, nie robimy książkowo, ale też w moich projektach jedyne long-living
branche jakie robiliśmy to były:
a) bugfixy do starych wersji/instalacji (nigdy nie merge'owane, bo trunk
nie miał tych bugów)
b) doświadczenia i ryzykowne odjazdy na kilka osób (i to czasem
chcieliśmy merge'ować)
Jak ktoś sobie nawalił w svn'ie branchy, to po kilku tree-conflictach
szybko się uczył, że nie tędy droga.
W gicie branche zaczęły mi się podobać, choć nie jestem takim faszystą,
by wymagać pięknej historii w logu. Starczy, jeśli kod w HEAD mastera
mam czytelny. Sam robię niepotrzebne automatycznym merge pullem jak mi
się spieszy. Choć mi wstyd i wiem że robię źle z perspektywy historycznej :)
Michal Margiel
W dniu 20.12.2011 16:28, Tomasz Bujok pisze:Tak, widziałem/dotykałem 2tygodniowe i dłuższe branche w svn'ie. No i często przy tree-conflictach (co jest nieuniknione przy refactorowanym kodzie) po kilku godzinach się poddawaliśmy, wyciągaliśmy zmiany z brancha i wrzucaliśmy ręcznie do trunka. Branch per feature odpadał, gdy refactoring jest na porządku dziennym. Dopiero przy gicie zaczął ładnie banglać.
A swoja droga Kuba, to albo tam w tej firmie produkujecie kazdy software
ksiazkowo ("respect"), albo "teoria na liscie sobie" a "praktyka sobie",
bo nie uwierze ze nigdy nie pracowales na "long-living" branchu... albo
chociaz go nie widziales/dotknales/czy jak to dzisiaj masz w zwyczaju
obsrales ;)
Pozdrawiam/Best regards
Michał Margiel
Tomasz Szymański
Jacek Laskowski
> Ło matko, aleście się tego biednego Jacka czepili - chłopak nigdy nie
> pracował nad projektem w którym jest więcej niż jedna osoba i który robi
> więcej niż wypisuje na ekran niż "witaj przygodo", więc może nie wiedzieć
> jak to jest...
Cóż zrobić, kiedy seniorowi (z wieku i stażu pracy) płacą w Polsce
jedynie za to, aby wyjaśnić juniorom (z wieku i stażu pracy) dlaczego
coś działa w dany sposób. Nie mam wielkiego wyboru, kiedy kaska rządzi
moim życiem :)
Mam jednak propozycję, jak wyjść z tego impasu - czy mógłbyś, podczas
któregoś spotkania WJUGowego, wyjaśnić mi i pewnie znajdzie się więcej
osób zainteresowanych, którzy aspirują do zdobycia odznak sztuki
programistycznej, co kryje się w pracy w projekcie, w którym jest
więcej niż jedna osoba i robi więcej niż "witaj przygodo"? W maju są
wolne miejsca. Zapraszam(y)!
Jacek
--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl
"Hoping to save time by spending it" by David Blevins (Apache OpenEJB)
Michał Gruca
na eclipsie z racji potrzeby bycia bliżej tego co jego użytkownicy
mają w biurach.
Oczywiście vim, emacs, np++, etc są świetnymi narzędziami do rubiego,
pythona, clojure etc. Kodzenie w samej javie bez IDE nie jest zbyt
wygodne. Choć okazyjnych java koderów przyzwyczajonych do wyżej
wymienionych rozumiem.
A co do przykładu Jacka to nijak on ma się do życia.
Niedość że sam przykład z kosmosu wzięty (czy follow-up czyjś o pliku
readme... no killer ficzer) to jeszcze promujący technologię
podwyższającą barierę wejścia.
Korzystałem z 3 głównych rozproszonych systemów kontroli wersji i a
wcześniej z 2 scentralizowanych i na początek .hg zdecydowanie
łatwiejszy jest niż Git.
Konto na BB miałem przed githubowym i mi się tam podobało. Hmm, może
nawet moje przymiarki do systemu zarządzania knferencją nawet tam mam?
Aż poszukam :)
BTW Michał: dostałeś ode mnie na priv @? Pytam nie z niecierpliwości,
tylko Opera mnie po wysłaniu posta/maila na grupie nie przekierowuje
dalej i nie wiem czy poszło
On Dec 20, 3:02 pm, Tomasz Bujok <tom.bu...@gmail.com> wrote:
> Dla Ciebie jest to mo e tak oczywiste, ale jest wielu ludzi, kt rzy z
> pewno ci si z Tob nie zgodz , np. pierwszi z brzegu: Ted Neward,
> Howard Lewis-Ship, czy moja skromna osoba. Umiej tno napisania kilku
> klas nie w IDE jest czasem kluczowa i nie nazwa bym tego goleniem sie
>
> Inna rzecz to troche chyba dla sportu czepiacie sie Jacka, ktory
> poruszyl temat "progu wejscia", podajac moze nie najlepszy przyklad
> Pozdro,
> Tomek
>
> On 20/12/2011 2:18 PM, Jakub Nabrdalik wrote:
>
>
>
>
>
>
>
>
> > Wprowadza e w ten spos b zmiany do jakiego projektu?
>
> > Ja wiem, e programowanie w Javie bez IDE jest mo liwe. Podobnie golenie
> > si siekier .
Michał Gruca
nie wiem czy pamiętasz naszą rozmowę z 33degree. Mój plan w sumie
dalej może być aktualny, tylko w czasie się odwlókł z kilku powodów. W
sumie to z wielu większych i nagłych zmian w życiu :)
Ale soft do zarządzania konferencją, taki ogólnodostępny, dalej
chętnie bym tworzył/współtworzył :)
On Dec 20, 3:10 pm, Grzegorz Duda <grzegorz.d...@gmail.com> wrote:
> "Spokojnych Świąt" nabiera nowego znaczenia ;)
>
> Swoja droga zastanawiam sie, czy jakby połączyć ludzi, którzy pracują nad
> narzędziami do zarządzania Confitura, GeeCONem i 33rd Degree, to już w
> przyszłym roku nie mielibyśmy fajnego narzędzia, który spełniałby wszystkie
> wymagania...
>
> Regards/Pozdrawiam,
> Grzegorz Duda (http://www.dworld.pl/page/show/Grzegorz_Duda/)
>
> 33rd Degree conference for Java Masters (http://33degree.org)
> Developers World (http://www.dWorld.pl)
> JAVA exPress (http://www.javaexpress.pl)
>
>
>
>
>
>
>
>
>
> > W dniu 20 grudnia 2011 15:02 użytkownik Tomasz Bujok <tom.bu...@gmail.com>napisał:
>
> > Dla Ciebie jest to może tak oczywiste, ale jest wielu ludzi, którzy z
> >> pewnością się z Tobą nie zgodzą, np. pierwszi z brzegu: Ted Neward, Howard
> >> Lewis-Ship, czy moja skromna osoba. Umiejętność napisania kilku klas nie w
> >> IDE jest czasem kluczowa i nie nazwałbym tego goleniem sie siekiera.
>
> >> Inna rzecz to troche chyba dla sportu czepiacie sie Jacka, ktory poruszyl
> >> temat "progu wejscia", podajac moze nie najlepszy przyklad edycji z www -
> >> jednak to nie było chyba kwintesencja jego wypowiedzi...
>
> > Ja innego argumentu w wypowiedzi Jacka nie dostrzegłem, ale możliwe ze coś
> > pominąłem...
>
> > --
> > Pozdrawiam/Best regards
> > Michał Margiel
>
> >http://www.margiel.eu
>
> > --
> > Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> > Więcej informacji na stronie
> >http://groups.google.com/group/warszawa-jug?hl=pl
Tomasz Szymański
--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Tomasz Bujok
> Ko�cz�c (przynajmniej mam nadziej�) temat "rozproszony system kontroli
> wersji VS SVN" chcia�bym zaznaczy�, ze ja nigdzie nie napisa�em, �e ten
> pierwszy jest BE (w sumie to nawet nie wiem sk�d ta dyskusja i mail
> Tomka wyliczaj�cy zalety). jest super-fajny, ale SVN te� nie jest wcale
> beznadziejny.
Napisales wczesniej, ze "je�li mia�bym przej�� na inny system to musz�
mieďż˝ ku temu jakieďż˝ argumenty" -> no to napisalem te argumenty :)
Zgadzam sie ze SVN jest cool, ale pracujac z git'em nie mysle o rzeczach
o ktorych musialem myslec kiedy dzialalem z SVN'em. Niby mala rzecz, a
cieszy. Wiem, ze zmiana nazwy klasy to nie jest najczestszy przypadek,
ale sposob w jaki git sobie z tym radzi jest znakomity - no a jesli
chcesz pozostawic po sobie "Clean Code" no i jako prawi ta ksiazka, za
kazdym razem zostawic kod czytelniejszy i lepszy od tego ktory wlasnie
ogladasz, to nie mozesz sie bac, ze jak cos zmienisz to wszystkim sie
update-commit rozchrzani, bo ty zdecydowales sie na "egzotyczna" zmiane.
Pozdro,
Tomek
Jacek Laskowski
> Ale ale - w maju będę dalej w afryce, ale może taką prezentację jak
> prowadzimy projekty "the softłer mil łej" mógłbym zrobić... tylko nie wiem
> czy grupa odpowiednia ;-)
Potraktuj to jako zadanie reklamowe, co może podnieść rangę
wystąpienia na firmowej liście ToDo. Ściągacie z rynku najlepsze
kąski, więc należy się coś społeczności (tej niezatrudnionej) w
zamian. W końcu, kiedy ludziska zarobieni po pachy "folołin the
softłer mil łej", daj im trochę wytchnienia na "publik szoł-of".
Potrzeba więcej firm w naszych spotkaniach i SML (firma, nie język!)
mógłby być doskonałym prekursorem.
p.s. Jeju, jak trudno pisze się po angielsku tak, jak się mówi! Nie
zdawałem sobie z tego sprawy.
Jakub Nabrdalik
> Ale ale - w maju będę dalej w afryce, ale może taką prezentację jak
> prowadzimy projekty "the softłer mil łej" mógłbym zrobić... tylko nie
> wiem czy grupa odpowiednia ;-)
+1^49
Jak nie tu to na Agile Warsaw. Chętnych tak czy inaczej nie zabraknie,
bo "the softłer mil łej" jest imho dość unikalna i z pewnością warta
propagowania.
Jacek Laskowski
Michal Margiel
2011/12/21 Jakub Nabrdalik <jak...@gmail.com>:
> +1^49
Ja byłbym raczej za +1e49 :]
Pozdrawiam/Best regards
Michał Margiel
Wojciech Erbetowski
Jacek Laskowski
> Czasami się zastanawiam skąd wy bierzecie te niesamowicie śmieszne żarty...
Jakimś cudem to one przyciągają najwięcej uwagi :P
Jakub Nabrdalik
Racja :D Groovy mi wypaczył podejście do stringów.
Michał Gruca
informatykach ;)
splatch
Korzystam z Eclipse, Mavena i naturalnie z GIT i SVN w tym samym
czasie. Wykorzystuję do tego konsolę i nie jest mi w ogóle z tym źle,
nie muszę i nie lubię robić mvn install z IDE, bo jest mi to
niepotrzebne, kiedy i tak muszę przejść do okna z aplikacją i
zaktualizować moduł który właśnie uruchomiłem. Dodam również, że
integracja GIT-SVN działa bardzo dobrze i zmiany commituję również z
terminala. Jest mi z nim dobrze. Fakt, jest w Eclipse wsparcie dla GIT
i nawet mam ten plugin zainstalowany, ale nie korzystam w praktyce z
niego zbyt często. Do przeglądania zmian, historii wykorzystuję
SourceTree (jakiś czas temu atlassian dawało darmowe licencje) bądź
gitk (tak samo brzydkie jak przydatne). 90% commiterów apache wrzuca
zmiany do SVN, ale używa lokalnie GIT, z czystej wygody i powodów
wymienionych przez Tomka. Te dwa rozwiązania się nie wykluczają i bez
problemu ktoś może korzystać sobie z SVN bo lubi, i zna, robić do
niego commity, a druga osoba mieć GITa, który lokalne commity wrzuci
do SVN. Można też mieć GITowy mirror repozytorium SVN.
Naturalnie wszystko jest kwestią preferencji, ale wyznaję zasadę, że
projekt nie powinien być zależny od żadnego IDE, nie powinno być
deskryptorów projektów w repozytorium, niezależnie od tego czy
są to .project i .classpath, czy też inne Intelli. Ma się
zawsze budować z Mavena i tyle. :) Naturalnie ma się też łatwo
importować do środowiska.
Pozdrawiam,
Łukasz
> > <radoslawsz...@gmail.com <mailto:radoslawsz...@gmail.com>> napisa :
>
> > W dniu 20 grudnia 2011 14:44 u ytkownik Michal Margiel
> > <michal.marg...@gmail.com <mailto:michal.marg...@gmail.com>> napisa :
>
> > Dla mnie to jest argument, bo ja jestem u ytkownikiem Eclipsa. A
> > z tym mavenem to na prawd nie rozumiem - ja nie mam ani jednego
> > powodu do narzekania.
>
> > Uwa anie, e co jest s abe, tylko dlatego, e nie da si tego
> > u ywa w Eclipsie, a dzia a bardzo dobrze w Idei/Netbeans (nie wiem
> > jak jest z gitem) to nie jest warto ciowy argument przeciw temu
> > czemu , jest tylko i wy cznie argumentem przeciw u ywaniu tego
> > czego wraz z eclipsem, ale przecie sam napisa e "znaj , lub
> > przynajmniej CHC pozna , jakie IDE" ;)
>
> > Dla mnie system kontroli wersji ma mi pom c a nie przeszkodzi . SVN w
> > eclipsie dzia a WIETNIE, je li mia bym przej na inny system to musz
> > mie ku temu jakie argumenty. Jedn z cech jaka szukam w takim systemie
> > to integracja z moim IDE (czyli eclipsem) - je li, eby cokolwiek
> > zrobi , musz przechodzi do konsoli - to jest s abo. Je li na ka de
> > ctrl+s musze czeka 5 sek bo "egit co tam sobie robi", a edytor
> > konflikt w dzia a beznadziejnie - to jest to nie mam w og le nad czym
> > si zastanawia . Po co mam wymienia co co dzia a dobrze na co co
> > dzia a le? Zw aszcza, ze jest mercurial kt ry dzia a dobrze.
>
> > Dlatego dla mnie integracja z eclipsem jest wa na. ale jak podkre lam -
> > DLA MNIE. Ty mo esz mie inne argumenty ZA gitem, np. mnogo funkcji
> > kt re dla mnie nie stanowi adnej warto ci.
>
> > --
> > Pozdrawiam/Best regards
> > Micha Margiel
>
> >http://www.confitura.pl(dawniej Javarsovia)
> > Wiadomo z grupy Warszawa Java User Group (Warszawa JUG).
> > Wi cej informacji na stronie
> >http://groups.google.com/group/warszawa-jug?hl=pl
> > Zach camy do odwiedzenia naszej strony domowejhttp://warszawa.jug.pl
Irek Matysiewicz
splatch
Niekoniecznie, możesz te pliki generować z mavena, i nie musisz ich
wówczas wersjonować. Powiedzmy sobie też, że w dużej mierze są one
wykorzystywane do raportowania i śledzenia bałaganu w projekcie - czy
postępuje i dzięki komu. ;) Ja w przypadku korzystania z PMD i
Checkstyle tworzyłem te pliki przed importem przy pomocy mvn
eclipse:eclipse. Repozytorium jest od trzymania kodu aplikacji a nie
śmieci.
Pozdrawiam,
Łukasz
Irek Matysiewicz
Ustawienia są malutkimi pliczkami, więc nie jest to aż taki śmietnik. Tak źle i tak niedobrze.
--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
splatch
Dopóki kolega przez przypadek nie zmieni kolejności source folderów to
nie ma problemów z deskryptorami. Później przy każdym commicie trzeba
oddzielać .cośtam (bo jest różnica w nim) od tego co na prawdę powinno
pójść do repozytorium. Proste "update project configuration" powoduje
zmianę pliku. Dlatego też lepiej trzymać tego typu rzeczy w svn:ignore
bądź .gitignore. Każdy developer kontroluje swoje środowisko, a dla
początkującego wystarczy instrukcja - kilka zdań na wiki.
Większość pluginów w Eclipse można konfigurować per workspace, dzięki
czemu ich konfiguracje da radę w ogóle wykluczyć z wersjonowania.
Pozdrawiam,
Łukasz
On Dec 30, 9:16 pm, Irek Matysiewicz <iir...@gmail.com> wrote:
> Podejrzewam, że nie jest to tak wygodne jak po prostu wyklikanie ustawień i
> zakomitowanie ich.
> Ustawienia są malutkimi pliczkami, więc nie jest to aż taki śmietnik. Tak
> źle i tak niedobrze.
>
> W dniu 30 grudnia 2011 20:45 użytkownik splatch
>
>
>
>
>
>
> > Irek,
> > Niekoniecznie, możesz te pliki generować z mavena, i nie musisz ich
> > wówczas wersjonować. Powiedzmy sobie też, że w dużej mierze są one
> > wykorzystywane do raportowania i śledzenia bałaganu w projekcie - czy
> > postępuje i dzięki komu. ;) Ja w przypadku korzystania z PMD i
> > Checkstyle tworzyłem te pliki przed importem przy pomocy mvn
> > eclipse:eclipse. Repozytorium jest od trzymania kodu aplikacji a nie
> > śmieci.
>
> > Pozdrawiam,
> > Łukasz
>
> > On Dec 30, 8:33 pm, Irek Matysiewicz <iir...@gmail.com> wrote:
> > > Co do importowania projektów do Eclipsa: m2eclipse nie potrafi
> > zimportować
> > > ustawień Eclipsowych pluginów takich jak Checkstyle, PMD, Findbugs (a
> > > przynajmniej nie potrafił tego zrobić jakiś czas temu), a na pewno nie
> > > potrafi i nie będzie potrafił zimportować ustawień bardziej egzotycznych
> > > pluginów. Jeśli ustawienia takich pluginów mają być wspólne dla
> > wszystkich
> > > programistów warto jednak zakomitować też wszystkie pliki .cośtam
>
> > --
> > Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> > Więcej informacji na stronie
> >http://groups.google.com/group/warszawa-jug?hl=pl
Michal Margiel
Pozdrawiam/Best regards
Michał Margiel
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu
Michal Margiel
Bartek Zdanowski
jak idzie z postępami przy aplikacji? Jak z ochotnikami? Ktoś coś już koduje? Czy słomiany zapał się udzielił innym członkom WJUG?
--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
--
Pozdrawiam,
Bartek Zdanowski
Bloguję http://blog.bartekzdanowski.pl i twittuję http://twitter.com/bartekzdanowski
Confitura 2012 - największa bezpłatna konferencja programistyczna - http://confitura.pl
KO Warsjawa 2012 - warszawskie jesienne warsztaty javowe - http://warsjawa.pl
Vitaliy Oliynyk
Tomek Lipski
wrote:
> Witajcie,
>
> Powoli, lecz zdecydowanie (jak pociąg[1]) ruszamy z organizacją kolejnej
> (drugiej lub szóstej - w zależności jak liczyć ;) ) Confitury.
> Hołdując zasadzie "jak nas widzą tak nasz piszą" - musimy zadbać o naszą
> światową wizytówkę - czyli stronę internetową.
> Jak pewnie część z was wie od roku cała confitura.pl stoi na naszym własnym
> aplikacji.
> Aplikacji spełnia swoje podstawowe zadania lecz wciąż jej wiele brakuje.
> Dodatkowo nie brakuje nam pomysłów jej rozwój - jedyne czego nie jest u
> nas dostatek to głów i rąk (dokładnie w tej kolejności) do pracy.
Hej,
Rozumiem, że rozpoczęliście już prace i aplikacja zaczyna już jakoś
wyglądać, więc moja uwaga może być troszeczkę spóźniona.
Ale czy rozważaliście postawienie tego na Liferayu CE (http://
www.liferay.com) ?
Zajęłoby to nieporównywalnie mniej czasu niż robienie wszystkiego
samemu a efekt i funkcjonalności byłyby zapewne większe.
Pozdrawiam,
Tomek Lipski
Jakub Nabrdalik
> Ale czy rozważaliście postawienie tego na Liferayu CE (http://
> www.liferay.com) ?
> Zajęłoby to nieporównywalnie mniej czasu niż robienie wszystkiego
> samemu a efekt i funkcjonalności byłyby zapewne większe.
Ale fun mniejszy. Chłopaki u mnie w pracy właśnie psioczą pisząc
portlety na liferay'a, a my tu się nieźle bawimy wicketem :)
Poza tym, aplikacja tak naprawdę już dawno jest gotowa (dzięki Michałowi
Margielowi), my tylko grupowo dopisujemy ficzery.
--
Jakub Nabrdalik
blog.solidcraft.eu
Jakub Nabrdalik
> www.liferay.com) ?
Btw. zapytani o liferay'a developerzy z mojej firmy przekierowali mnie
na taki oto komentarz:
"You fail to mention that portlet/web development with Liferay is a
nightmare. It's buggy, it's needlessly complex, the code it serves to
clients is not W3C compliant and it will quadruple development times.
Not to mention the learning curve for it is practically a vertical line.
The community is weak, the documentation is poor and even if you have an
enterprise account, which we do, answers are slow coming. You can expect
to spend many hours banging your head against walls. There's even a
thread in Liferay's own forums where the majority of people involved
express their displeasure with it:
http://www.liferay.com/community/forums/-/message_boards/message/213570
That said, the back-end for the portlets is pretty decent. I really like
the use of design patterns and I enjoy programming with Java."
Aplikacje jednak zrobili, więc "da się" :)
--
Jakub Nabrdalik
blog.solidcraft.eu
Bartek Zdanowski
--
Jakub Nabrdalik
blog.solidcraft.eu
--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
Piotr Pietrzak
Wiadomość napisana przez Jakub Nabrdalik w dniu 16 lut 2012, o godz. 12:22:
> On 16.02.2012 10:29, Tomek Lipski wrote:
>> Ale czy rozważaliście postawienie tego na Liferayu CE (http://
>> www.liferay.com) ?
Fajnie by było stronę WJUG uruchomić na platformie Liferay z blogami, wiki i video:) z setkami portletów robionych przez użytkowników i tematami RIA, mobile...
>
> Btw. zapytani o liferay'a developerzy z mojej firmy przekierowali mnie na taki oto komentarz:
>
> [http://www.sanjeevg.com/2009/03/liferay-portal-review.html?showComment=1268175387639#c1830961972661496459]
>
> "You fail to mention that portlet/web development with Liferay is a nightmare. It's buggy, it's needlessly complex, the code it serves to clients is not W3C compliant and it will quadruple development times. Not to mention the learning curve for it is practically a vertical line. The community is weak, the documentation is poor and even if you have an enterprise account, which we do, answers are slow coming. You can expect to spend many hours banging your head against walls. There's even a thread in Liferay's own forums where the majority of people involved express their displeasure with it: http://www.liferay.com/community/forums/-/message_boards/message/213570
Istnieją sposoby uzyskania dokładnie takiej samej produktywności jak podczas pisania aplikacji webowej. Stosując JSF, GWT, czy Vaadin możesz pisać aplikację web a później osadzić ją poprzez odpowiednią konfigurację w portalu.
Swoją drogą komunikacja międzyportletowa (standardowa) w czasach RIA to trochę pomyłka i utrudnienie a nie rozwiązanie problemu.
Jakość Liferay CE jest dużo niższa niż kilka lat temu - pojawiają się problemy w podstawowych funkcjonalnościach: uprawnienia, udostępnianie dokumentów itd. Polityka Liferaya jest taka, że albo trzeba zapłacić abonament za używanie wersji EE, albo można zatrudnić zespół, który te problemy będzie rozwiązywał. Tanie utrzymanie portalu jest problematyczne a ceny EE oscylują w okolicach cen licencji Sharepoint. To powoduje, że we wdrożeniach Enterprise dużo bardziej popularny jest Sharepoint.
Po wypracowaniu jednak dobrego sposobu prowadzenia developmentu i delegacji zadań można w standardowy sposób zrównoleglić proces wytwarzania całego portalu zachowując przyzwoitą wydajność.
>
> That said, the back-end for the portlets is pretty decent. I really like the use of design patterns and I enjoy programming with Java."
Fakt.
>
>
> Aplikacje jednak zrobili, więc "da się" :)
Wszystko się da - trzeba tylko zbilansować zakres, czas i zasoby. Pewnie w Sharepoincie* też by dali radę.
*) Można wymienić na dowolną technologię, która pozwala kontrolować ciąg znaków przesyłanych przez port 80.
Piotr Pietrzak
P.S.
Mimo wszystko wybraliśmy Liferaya na platformę portalowa, używamy i działa.
Tomek Lipski
> On 16.02.2012 10:29, Tomek Lipski wrote:
>
> > Ale czy rozważaliście postawienie tego na Liferayu CE (http://
> >www.liferay.com) ?
>
> na taki oto komentarz:
>
> [http://www.sanjeevg.com/2009/03/liferay-portal-review.html?showCommen...]
Jasne. Na co warto zwrócić uwagę to to, że jest to recenzja
praktycznie sprzed 3 lat (bez 2 miesięcy). 3 lata może dla IBMa czy
Oracle to niewiele, ale dla sprawnej firmy
taki okres czasu to bardzo dużo i bardzo wiele w produkcie się
zmienia. Obserwuję, jak Liferay rośnie od wersji 4.1.2 czyli od ponad
5 lat i kierunek jest niezły moim zdaniem.
> "You fail to mention that portlet/web development withLiferayis a
> clients is not W3C compliant and it will quadruple development times.
> Not to mention the learning curve for it is practically a vertical line.
> The community is weak, the documentation is poor and even if you have an
> enterprise account, which we do, answers are slow coming. You can expect
> to spend many hours banging your head against walls. There's even a
>
> That said, the back-end for the portlets is pretty decent. I really like
> the use of design patterns and I enjoy programming with Java."
>
> Aplikacje jednak zrobili, więc "da się" :)
choć trudno mi się z nim zgodzić, to też należy pamiętać że dotyczy
bardzo starej wersji oprogramowania. Zauważcie, że w 2011, czyli kiedy
wyszły już później wersje 6.0 - nie ma narzekania.
Ale to nieważne - Liferay, jak każda technologia wymaga nauki i
zdobycie wiedzy o "best practices" (np. ile osób kaleczy się używając
np. GWT czy Springa w niewłaściwy sposób na początku?).
Inną cechą technologii jest to, że łatwo na nią zrzucić winę i
developerzy często mają takie ciągoty, wręcz uciechę, kiedy wydaje im
iż znaleźli/wykryli błąd - w używanej bibliotece. Tylko 95%
przypadków, nadal wina jest po stronie osoby używającej danej
technologii.
"Best practices" dla Liferaya są nieźle opisane (Liferay in Action,
Administrator's guide, itd.) i może po prostu problemem Liferaya jako
technologii jest to, że rozpoczęcie prac jest dziecinnie łatwe -
technologia jest otwarta, są źródła, raczej wszystko jest zrobione
zgodnie z wzorcami projektowymi, itd. Tylko rozpoczynając poważne
prace tak "z buta", często developer pada ofiarą tego podejścia, bo
okazuje się, że przy bardziej złożonych rzeczach, sam, przez własną
niewiedzę wpędził się w ślepy zaułek.
Pozdrawiam,
Tomek Lipski
Tomek Lipski
> > Aplikacje jednak zrobili, więc "da się" :)
>
> Mowa m.in. o mnie.
> Żeby dostać niektóre ficzery, to strasznie trzeba hackować. Ja bym nie
> chciał strony confitury na Liferayu. Sry.
Trudno mi tutaj osądzać przyczyny związane z koniecznością hackowania,
ale warto w cichości ducha zrobić rachunek sumienia - czy na pewno
było to zrobione zgodnie z tym jak producent zaleca?
Częstym błędem ludzi piszących na Liferayu (nie sugeruję w żaden
sposób że to dotyczy Ciebie), jest zmienianie kodów samego portalu
bezpośrednio (tzw. "na szybko") - zamiast korzystać z mechanizmów
dostarczanych do tego przez Portal. Wtedy faktycznie dosyć szybko
można zniechęcić się do tej technologii.
Pozdrawiam,
Tomek Lipski
Tomek Lipski
> > On 16.02.2012 10:29, Tomek Lipski wrote:
> >> Ale czy rozważaliście postawienie tego na Liferayu CE (http://
> >>www.liferay.com) ?
>
I to jeszcze w jeden wieczór ! ;-)
> Istnieją sposoby uzyskania dokładnie takiej samej produktywności jak podczas pisania aplikacji webowej. Stosując JSF, GWT, czy Vaadin możesz pisać aplikację web a później osadzić ją poprzez odpowiednią konfigurację w portalu.
deploymencie zmienianego kawałka aplikacji (http://www.liferay.com/web/
gregory.amerson/blog/-/blogs/new-liferay-6-1-feature-remote-
development-from-liferay-ide).
Poza tym Vaadin+JRebel na Liferayu powoduje zerowy narzut na
redeploymenty.
A jednak robiąc aplikację na Liferayu wieloma rzeczami nie trzeba się
martwić (nie mówię, że inne rozwiązania też tego nie zapewnią).
>
> Swoją drogą komunikacja międzyportletowa (standardowa) w czasach RIA to trochę pomyłka i utrudnienie a nie rozwiązanie problemu.
dodatkowe mechanizmy JavaScriptowe od dość dawna (z tego co pamiętam,
pod spodem jest jQuery Events - ale jakiś czas z tego nie
korzystałem), też np. w Vaadinie jest odpowiedni addon do IPC (Inter-
Portlet Communication).
> JakośćLiferayCE jest dużo niższa niż kilka lat temu - pojawiają się problemy w podstawowych funkcjonalnościach: uprawnienia, udostępnianie dokumentów itd. Polityka Liferaya jest taka, że albo trzeba zapłacić abonament za używanie wersji EE, albo można zatrudnić zespół, który te problemy będzie rozwiązywał. Tanie utrzymanie portalu jest problematyczne a ceny EE oscylują w okolicach cen licencji Sharepoint. To powoduje, że we wdrożeniach Enterprise dużo bardziej popularny jest Sharepoint.
Tak. Na pewno CE nie jest tak dobre jak EE i w EE jest włożone dużo
pracy. Coś za coś. Nikt jednak nie broni Liferayowi zostać sponsorem
Confitury, chociaż nie wiem czy coś takiego jest możliwe ze strony
Liferaya - trzeba by się ich spytać.
Pozdrawiam,
Tomek Lipski
Piotr Pietrzak
On 16 Lut, 15:08, Tomek Lipski <tomek.lip...@gmail.com> wrote:
> On Feb 16, 12:59 pm, Piotr Pietrzak <p10trpi3tr...@gmail.com> wrote:
>
> > > On 16.02.2012 10:29, Tomek Lipski wrote:
> > >> Ale czy rozważaliście postawienie tego na Liferayu CE (http://
> > >>www.liferay.com) ?
>
> > Fajnie by było stronę WJUG uruchomić na platformieLiferayz blogami, wiki i video:) z setkami portletów robionych przez użytkowników i tematami RIA, mobile...
>
> I to jeszcze w jeden wieczór ! ;-)
>
> > Istnieją sposoby uzyskania dokładnie takiej samej produktywności jak podczas pisania aplikacji webowej. Stosując JSF, GWT, czy Vaadin możesz pisać aplikację web a później osadzić ją poprzez odpowiednią konfigurację w portalu.
>
> Dokładnie. Na przykład w 6.1 jest już feature polegający na hot-
> deploymencie zmienianego kawałka aplikacji (http://www.liferay.com/web/
> gregory.amerson/blog/-/blogs/new-liferay-6-1-feature-remote-
> development-from-liferay-ide).
> Poza tym Vaadin+JRebel na Liferayu powoduje zerowy narzut na
> redeploymenty.
>
> A jednak robiąc aplikację na Liferayu wieloma rzeczami nie trzeba się
> martwić (nie mówię, że inne rozwiązania też tego nie zapewnią).
do przetwarzania danych osobowych w celu dostępu do LDAP i zapięcie
się do SSO trwało bardzo długo - teraz nie potrzebujemy tego robić, bo
rozbudowujemy funkcjonalność portalu i nasze portlety nie przetwarzają
danych osobowych w celu przyznania uprawnień a jedynie są uruchamiane
przez uprawnionych użytkowników. Organizacyjne corpo-turbo skraca czas
developmentu o połowę:)
>
>
> > Swoją drogą komunikacja międzyportletowa (standardowa) w czasach RIA to trochę pomyłka i utrudnienie a nie rozwiązanie problemu.
>
> To akurat raczej kwestia specyfikacji JSR286. Liferay ma swoje
> dodatkowe mechanizmy JavaScriptowe od dość dawna (z tego co pamiętam,
> pod spodem jest jQuery Events - ale jakiś czas z tego nie
> korzystałem), też np. w Vaadinie jest odpowiedni addon do IPC (Inter-
> Portlet Communication).
liferay implementuje w javascript taki eventbus, ale jest to
rozwiązanie własnościowe i do tego niezgodne z JSR286, bo JSR286 na
temat ajax milczy. W temacie komunikacji międzyportletowej po stronie
klienta nie słyszałem o żadnych próbach standaryzacji. Może ktoś,
gdzieś w tajnej bazie na Mazurach pracuje nad JSR368 - komunikacja
międzyportletowa po stronie klienta w javascript.
>
> > JakośćLiferayCE jest dużo niższa niż kilka lat temu - pojawiają się problemy w podstawowych funkcjonalnościach: uprawnienia, udostępnianie dokumentów itd. Polityka Liferaya jest taka, że albo trzeba zapłacić abonament za używanie wersji EE, albo można zatrudnić zespół, który te problemy będzie rozwiązywał. Tanie utrzymanie portalu jest problematyczne a ceny EE oscylują w okolicach cen licencji Sharepoint. To powoduje, że we wdrożeniach Enterprise dużo bardziej popularny jest Sharepoint.
>
> Tak. Na pewno CE nie jest tak dobre jak EE i w EE jest włożone dużo
> pracy. Coś za coś. Nikt jednak nie broni Liferayowi zostać sponsorem
> Confitury, chociaż nie wiem czy coś takiego jest możliwe ze strony
> Liferaya - trzeba by się ich spytać.
Piotr Pietrzak
Michal Margiel
Krzysztof Miksa
--
--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
---
Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „Warszawa Java User Group (Warszawa JUG)”.
Aby anulować subskrypcję tej grupy i przestać otrzymywać z niej wiadomości, wyślij e-maila do warszawa-jug...@googlegroups.com.
Więcej opcji znajdziesz na https://groups.google.com/groups/opt_out