Ostatnio społeczność związana z frameworkiem Wicket ma kilka powodów do zadowolenia. Po pierwsze pojawiła się finalna wersja 1.4. Najważniejsza zmiana w porównaniu z wersją 1.3 to całkowite przejście na Javę 1.5 i wprowadzenie generycznego interfejsu IModel wraz z implementacjami. O wszystkich nowościach i zmianach można poczytać tutaj.
Jednocześnie z pojawieniem się wersji 1.4 został opublikowany ostatni upgrade wersji 1.3 o numerze 1.3.7 poprawiający kilkanaście "bugów". Autorzy zapowiadają, że jeśli nie pojawią się krytyczne błędy to ta gałąź nie będzie dalej rozwijana. W związku z tym należy się powoli przygotowywać do migracji na wersję 1.4 w aplikacjach używających Wicketa 1.3.x. Problem dotyczy również i mnie, bo moja magisterka używa wersji 1.3.6.
Kolejnym wydarzeniem istotnym dla fanów Wicketa jest opublikowanie w serwisie RefCardz ściągawki (ang. cheatsheet) o tym frameworku. Na kilku stronach zebrano najważniejsze informacje, najlepsze praktyki i spor porad bardzo przydatnych dla osób używających Wicketa. Całość można pobrać tutaj.
I na koniec informacja bardziej z naszego, polskiego poletka. Paweł Szulc pracuje nad mavenowym archetypem znacznie przyśpieszającym rozpoczęcie pracy z Wicketem. Projekt nazywa się WicketCool i można się z nim zapoznać pod tym adresem. Bardzo podoba mi się pomysł stworzenia czegoś takiego i mam nadzieję, że pomysł zyska na popularności, a Pawłowi należą się podziękowania za poświęcony czas i po prostu za dobrą robotę.
Dodam tylko, że sam projekt miał premierę na prezentacji Pawła podczas tegorocznej Javarsovii.
31 lipca 2009
30 lipca 2009
Efektywny programista Java, część 2 - łatwiejsze tworzenie parametryzowanych kolekcji i obiektów
Tym razem spróbujemy ułatwić sobie tworzenie parametryzowanych typów kolekcji i obiektów. Pierwsza myśl jaka nam przychodzi do głowy to po prostu użycie konstruktora:
To jeszcze nie są zbyt skomplikowane przykłady, ale jeśli okaże się, że musimy stworzyć Mapę złożoną z obiektu i innej kolekcji:
to pojawia się spora ilość zdublowanego kodu z informacją o typach parametrów po lewej i prawej stronie deklaracji.
Okazuje się, że można tego uniknąć wykorzystując tzw. "wnioskowanie typów". Kompilator będzie wiedział jaki tym parametryzowanej instancji ma zwrócić na podstawie tego, do jakiej zmiennej będziemy chcieli zwracany obiekt przypisać. Wygodnym sposobem jest zebranie wszystkich takich metod w jednej klasie użytkowej:
Teraz możemy zobaczyć o ile krótszy i wygodniejszy jest kod stosujący wnioskowanie typów:
Możemy skorzystać z wnioskowania typów również przy tworzeniu parametryzowanych obiektów innych niż kolekcje, ale tutaj zaleta jego użycia jest widoczna najbardziej.
// ...
List<User> usersList = new ArrayList<User>();
Map<IpAddress, User> ipUsersMap = new HashMap<IpAddress, User>();
// ...
To jeszcze nie są zbyt skomplikowane przykłady, ale jeśli okaże się, że musimy stworzyć Mapę złożoną z obiektu i innej kolekcji:
// ...
Map<IpAddress, List<User>> ipUserMap = new HashMap<IpAddress, List<User>>();
// ...
to pojawia się spora ilość zdublowanego kodu z informacją o typach parametrów po lewej i prawej stronie deklaracji.
Okazuje się, że można tego uniknąć wykorzystując tzw. "wnioskowanie typów". Kompilator będzie wiedział jaki tym parametryzowanej instancji ma zwrócić na podstawie tego, do jakiej zmiennej będziemy chcieli zwracany obiekt przypisać. Wygodnym sposobem jest zebranie wszystkich takich metod w jednej klasie użytkowej:
package pl.tdziurko.effectivejava
import java.util.ArrayList;
import java.util.HashMap;
import java.util.HashSet;
/**
*
* @author Tomasz Dziurko
*/
public class Helper {
// Do not instantiate this class, this is utility class
private Helper() { }
public static <E> ArrayList<E> newArrayList() {
return new ArrayList<E>();
}
public static <E,K> HashMap <E,K> newHashMap() {
return new HashMap<E,K>();
}
public static <E> HashSet <E> newHashSet() {
return new HashSet<E>();
}
}
Teraz możemy zobaczyć o ile krótszy i wygodniejszy jest kod stosujący wnioskowanie typów:
// ...
List<User> usersList = new ArrayList<User>();
List<User> usersList2 = Helper.newArrayList();
Map<IpAddress, User> ipUsersMap = new HashMap<IpAddress, User>();
Map<IpAddress, User> ipUsersMap2 = Helper.newHashMap();
Map<IpAddress, List<User>> ipUserMap = new HashMap<IpAddress, List<User>>();
Map<IpAddress, List<User>> ipUserMap2 = Helper.newHashMap();
// ...
Możemy skorzystać z wnioskowania typów również przy tworzeniu parametryzowanych obiektów innych niż kolekcje, ale tutaj zaleta jego użycia jest widoczna najbardziej.
Efektywny programista Java, część 1 - singletony
Zgodnie z zapowiedzią w poprzednim poście, dzisiaj początek cyklu postów z najciekawszymi poradami z książki "Java. Efektywne programowanie". W pierwszej kolejności postaram się przedstawić te tematy, z którymi programista Java może zetknąć się najczęściej.
Najczęściej singleton w Javie wygląda następująco:
W powyższym przykładzie widać od razu, że jest to singleton: prywatny konstruktor i statyczne pole finalne z jedyną instancją klasy dają o tym wystarczająco jasny sygnał.
Drugi sposób przedstawiony w książce jest bardzo podobny:
Stosując powyższe podejście mamy większą elastyczność przy późniejszych modyfikacjach naszej klasy. Możemy bez problemu (czyli bez widocznych zmian w zewnętrznym wyglądzie klasy) zmienić implementację metody getInstance(), tak aby zwracała nie jedyną instancję Zbigniewa Bońka, ale na przykład jedną instancję dla danego wątku czy danego klienta.
Oba podejścia nie są niestety odporne na refleksję, nie są również przystosowane do serializacji. Jeśli chcemy, aby nasz singleton po serializacji i deserializacji był ciągle singletonem poza dodaniem implements Serializable musimy przeładować metodę readResolve() tak, aby zwracała obiekt INSTANCE.
Z kolei przed refleksją można się uchronić dodając blok w konstruktorze, który rzuca wyjątek w momencie, gdy istnieje już instancja obiektu tej klasy.
Ostatnim (i najbardziej polecanym przez autora książki) sposobem na tworzenie singletonu jest zastosowanie typu wyliczeniowego:
Dzięki zastosowaniu typu wyliczeniowego mamy za jednym zamachem załatwiony problem singletonu, bezpieczeństwa serializacji i zabezpieczenie przed użyciem refleksji. Wszystko zapewnia sam język i nie musimy się o to martwić.
Osobiście najczęściej stosowałem podejście z polem private final static i metodą getInstance(), ale myślę, że zastosowanie typu wyliczeniowego jest bardzo interesującą alternatywą, którą warto dodać do swojego repertuaru :)
Trzy sposoby na tworzenie singletonów
Najczęściej singleton w Javie wygląda następująco:
package pl.tdziurko.effectivejava;
public class Boniek {
public static final Boniek INSTANCE = new Boniek();
private Boniek() {
// stwórz jedyną instancję Zbigniewa Bońka
}
public void doMagicWithBall() {
// dokonaj czegoś niesamowitego na boisku
}
}
W powyższym przykładzie widać od razu, że jest to singleton: prywatny konstruktor i statyczne pole finalne z jedyną instancją klasy dają o tym wystarczająco jasny sygnał.
Drugi sposób przedstawiony w książce jest bardzo podobny:
public class Boniek {
private static final Boniek INSTANCE = new Boniek();
private Boniek() {
// stwórz jedyną instancję Zbigniewa Bońka
}
public Boniek getInstance() {
return INSTANCE;
}
public void doMagicWithBall() {
// dokonaj czegoś niesamowitego na boisku
}
}
Stosując powyższe podejście mamy większą elastyczność przy późniejszych modyfikacjach naszej klasy. Możemy bez problemu (czyli bez widocznych zmian w zewnętrznym wyglądzie klasy) zmienić implementację metody getInstance(), tak aby zwracała nie jedyną instancję Zbigniewa Bońka, ale na przykład jedną instancję dla danego wątku czy danego klienta.
Oba podejścia nie są niestety odporne na refleksję, nie są również przystosowane do serializacji. Jeśli chcemy, aby nasz singleton po serializacji i deserializacji był ciągle singletonem poza dodaniem implements Serializable musimy przeładować metodę readResolve() tak, aby zwracała obiekt INSTANCE.
Z kolei przed refleksją można się uchronić dodając blok w konstruktorze, który rzuca wyjątek w momencie, gdy istnieje już instancja obiektu tej klasy.
Ostatnim (i najbardziej polecanym przez autora książki) sposobem na tworzenie singletonu jest zastosowanie typu wyliczeniowego:
public enum Boniek {
INSTANCE;
void doMagicWithBall() {
// dokonaj czegoś niesamowitego na boisku
}
}
Dzięki zastosowaniu typu wyliczeniowego mamy za jednym zamachem załatwiony problem singletonu, bezpieczeństwa serializacji i zabezpieczenie przed użyciem refleksji. Wszystko zapewnia sam język i nie musimy się o to martwić.
Osobiście najczęściej stosowałem podejście z polem private final static i metodą getInstance(), ale myślę, że zastosowanie typu wyliczeniowego jest bardzo interesującą alternatywą, którą warto dodać do swojego repertuaru :)
28 lipca 2009
Dobiega końca pierwszy (najtańszy) etap rejestracji na Java Developers' Day 2009
Jeszcze tylko kilka dni mają wszyscy, którzy chcą się załapać w pierwszym (najbardziej promocyjnym) etapie rejestracji na konferencję Java Developers' Day 2009 w Krakowie, która odbędzie się 16 października 2009.
Do 31 lipca studenci mogą zaopatrzyć się w wejściówkę już za 167zł, co za całodniową, anglojęzyczną konferencję o Javie jest kwotą bardzo, ale to bardzo małą. Programiści "starsi wiekiem" ;) zapłacą za bilet 219 zł. Im bliżej października tym cena będzie rosła, więc jeśli ktoś wie, że na pewno chcę się wybrać do grodu Kraka posłuchać o Javie, to warto zapłacić już teraz. Oferta last minute dla spóźnialskich to wydatek prawie 600 złotych (swoją drogą last minute kojarzyło mi się zawsze z okazjami, no ale widocznie coś się ostatnio w tej kwestii pozmieniało :))
Niestety agenda nie jest jeszcze gotowa, ale po przejrzeniu relacji z poprzednich edycji mam nadzieję, że tegoroczne JDD nie będzie gorsze.
PS: Sponsorem tego posta jest Dworzec Zachodni w Warszawie, firma PKP i jej spóźniony o ponad 60 minut pociąg.
Do 31 lipca studenci mogą zaopatrzyć się w wejściówkę już za 167zł, co za całodniową, anglojęzyczną konferencję o Javie jest kwotą bardzo, ale to bardzo małą. Programiści "starsi wiekiem" ;) zapłacą za bilet 219 zł. Im bliżej października tym cena będzie rosła, więc jeśli ktoś wie, że na pewno chcę się wybrać do grodu Kraka posłuchać o Javie, to warto zapłacić już teraz. Oferta last minute dla spóźnialskich to wydatek prawie 600 złotych (swoją drogą last minute kojarzyło mi się zawsze z okazjami, no ale widocznie coś się ostatnio w tej kwestii pozmieniało :))
Niestety agenda nie jest jeszcze gotowa, ale po przejrzeniu relacji z poprzednich edycji mam nadzieję, że tegoroczne JDD nie będzie gorsze.
PS: Sponsorem tego posta jest Dworzec Zachodni w Warszawie, firma PKP i jej spóźniony o ponad 60 minut pociąg.
26 lipca 2009
Java. Efektywne programowanie - wrażenia
Ostatnio kupiłem książkę, na którą miałem chętkę od dłuższego czasu: polską edycję "Effective Java" autorstwa Joshuy Blocha. Przeczytałem o niej sporo pozytywnych opinii i recenzji (tutaj te z Amazon.com) i sam po jej przeczytaniu mogę powiedzieć jedno:
Jeśli za najlepszą książkę z podstawami Javy uważam serię Core Java, to najlepszą książką dla bardziej doświadczonych programistów jest właśnie Java. Efektywne programowanie.
Po jej przeczytaniu moja świadomość jak powinien wyglądać dobry, wydajny i łatwy w modyfikowaniu kod bardzo wzrosła. Poznałem dużo ciekawych i wartych zastosowania podejść i sposobów tworzenia kodu w różnych sytuacjach. Samą książkę czyta się bardzo przyjemnie, choć kilka tematów jest trochę ciężkich i trzeba się mocniej skoncentrować, żeby w pełni zrozumieć rady w nich zawarte.
Porady, które przedstawia autor przydadzą się każdemu programiście, nawet takiemu, który uważa, że o programowaniu w Javie wie bardzo dużo. Ja jeszcze do takich nie należę, więc nowych sztuczek i trików poznałem naprawdę sporo :) Najbardziej przydatne wydały mi się rozdziały o efektywnym tworzeniu nowych obiektów, stosowaniu typów wyliczeniowych i wprowadzaniu typów ogólnych do metod i klas. Najmniej "porywający" był rozdział o serializacji, ale to głównie dlatego, że nigdy wcześniej nie zagłębiałem bardziej się w ten obszar języka.
Dużą zaletą książki jest modularyzacja treści. Każdy temat można czytać oddzielnie. Jeśli jakieś zagadnienie interesuje nas bardziej, swobodnie można do niego przeskoczyć, jeśli jakieś tematy nie wydają nam się w tej chwili warte uwagi, możemy je ominąć bez uszczerbku dla rozumienia dalszych rozdziałów.
Moim zdaniem "Java. Efektywne programowanie" to pozycja warta uwagi. Porady w niej zawarte przydadzą się każdemu programiście Java, więc książka ta powinna leżeć u każdego z nas na półce i być częstym źródłem inspiracji jak tworzyć dobry i efektywny kod. Może nie każdy temat poruszony w książce przyda nam się już tu i teraz, ale warto mieć tak dobre źródło wiedzy pod ręką i często z niego korzystać.
Najciekawsze i moim zdaniem najbardziej przydatne porady postaram się umieścić na blogu, co może zachęci niektórych do zakupu i zapoznania się z całą książką.
Jeśli za najlepszą książkę z podstawami Javy uważam serię Core Java, to najlepszą książką dla bardziej doświadczonych programistów jest właśnie Java. Efektywne programowanie.
Po jej przeczytaniu moja świadomość jak powinien wyglądać dobry, wydajny i łatwy w modyfikowaniu kod bardzo wzrosła. Poznałem dużo ciekawych i wartych zastosowania podejść i sposobów tworzenia kodu w różnych sytuacjach. Samą książkę czyta się bardzo przyjemnie, choć kilka tematów jest trochę ciężkich i trzeba się mocniej skoncentrować, żeby w pełni zrozumieć rady w nich zawarte.
Porady, które przedstawia autor przydadzą się każdemu programiście, nawet takiemu, który uważa, że o programowaniu w Javie wie bardzo dużo. Ja jeszcze do takich nie należę, więc nowych sztuczek i trików poznałem naprawdę sporo :) Najbardziej przydatne wydały mi się rozdziały o efektywnym tworzeniu nowych obiektów, stosowaniu typów wyliczeniowych i wprowadzaniu typów ogólnych do metod i klas. Najmniej "porywający" był rozdział o serializacji, ale to głównie dlatego, że nigdy wcześniej nie zagłębiałem bardziej się w ten obszar języka.
Dużą zaletą książki jest modularyzacja treści. Każdy temat można czytać oddzielnie. Jeśli jakieś zagadnienie interesuje nas bardziej, swobodnie można do niego przeskoczyć, jeśli jakieś tematy nie wydają nam się w tej chwili warte uwagi, możemy je ominąć bez uszczerbku dla rozumienia dalszych rozdziałów.
Moim zdaniem "Java. Efektywne programowanie" to pozycja warta uwagi. Porady w niej zawarte przydadzą się każdemu programiście Java, więc książka ta powinna leżeć u każdego z nas na półce i być częstym źródłem inspiracji jak tworzyć dobry i efektywny kod. Może nie każdy temat poruszony w książce przyda nam się już tu i teraz, ale warto mieć tak dobre źródło wiedzy pod ręką i często z niego korzystać.
Najciekawsze i moim zdaniem najbardziej przydatne porady postaram się umieścić na blogu, co może zachęci niektórych do zakupu i zapoznania się z całą książką.
15 lipca 2009
Protect your balls, man!
In spite of title, this post is about really, really serious thing.
We all (ok, probably almost all) have laptops and use them in many places, of course to spend time as effectively as possible. Everyday I see people using their laptops in train, bus, on a bench in the park and, most often, in bed. In all those cases laptop lies on their laps.
This is so common that we don't realize this is WRONG AND DANGEROUS!
Medicine researches state that drivers, especially truck and bus drivers more frequently have problems to become fathers. Their sperm isn't in best condition because of their work.
"What the heck I have in common with truck drivers?!" you could ask. The answer is simpler than you think. We all work for serveral hours in sitting position and this is not good for our sperm.
Male balls (testiculars) are placed outside body for one reason: better cooling. High temperature causes damage to sperm cells making them incapable of doing their job properly. If you are using laptop on your laps everyday for some time, your sperm don't have possibility to recover. Sometimes this state could become irreversible and as a result your wife or girlfriend will never be happy mummy.
How can you prevent this horrible scenario?
If you really can't live without working with computer on your laps there are some ways to make you and your balls much safer.
1. Put a large book between laps and laptop.
Pros:
- the cheapest solution
- it's not heavy if book is large but thin
- small, easy to carry
Cons:
- instability, when you move your laptop also moves.
- no place for mouse
2. board made of isolating material
Pros:
- lighter than book
- small, easy to carry
Cons:
- not so cheap
- instability
- no place for mouse
3. notebook/laptop coolers (example 1, example 2)
Pros:
- they cool laptop and help to exchange air between your laps and laptop.
Cons:
- price
- not all are lightweight and easy to carry
- some are cheap but some are really expensive (Zalman for example)
- instability
- no place for mouse
4. small table for laptop (example 1, example 2, example 3)
Pros:
- perfect to use in bed or sofa
- stable, laptop lies on the table not on your laps
- some of them have place for mouse
Cons:
- price
- large size
- rather impossible to use them in train
Summary
As you can see there are many ways to protect our balls from heat and ensure safety of our future parenthood. Some of these solutions won't cost you anything except a little effort so I think they are worth trying.
We all (ok, probably almost all) have laptops and use them in many places, of course to spend time as effectively as possible. Everyday I see people using their laptops in train, bus, on a bench in the park and, most often, in bed. In all those cases laptop lies on their laps.
This is so common that we don't realize this is WRONG AND DANGEROUS!
Medicine researches state that drivers, especially truck and bus drivers more frequently have problems to become fathers. Their sperm isn't in best condition because of their work.
"What the heck I have in common with truck drivers?!" you could ask. The answer is simpler than you think. We all work for serveral hours in sitting position and this is not good for our sperm.
Male balls (testiculars) are placed outside body for one reason: better cooling. High temperature causes damage to sperm cells making them incapable of doing their job properly. If you are using laptop on your laps everyday for some time, your sperm don't have possibility to recover. Sometimes this state could become irreversible and as a result your wife or girlfriend will never be happy mummy.
How can you prevent this horrible scenario?
If you really can't live without working with computer on your laps there are some ways to make you and your balls much safer.
1. Put a large book between laps and laptop.
Pros:
- the cheapest solution
- it's not heavy if book is large but thin
- small, easy to carry
Cons:
- instability, when you move your laptop also moves.
- no place for mouse
2. board made of isolating material
Pros:
- lighter than book
- small, easy to carry
Cons:
- not so cheap
- instability
- no place for mouse
3. notebook/laptop coolers (example 1, example 2)
Pros:
- they cool laptop and help to exchange air between your laps and laptop.
Cons:
- price
- not all are lightweight and easy to carry
- some are cheap but some are really expensive (Zalman for example)
- instability
- no place for mouse
4. small table for laptop (example 1, example 2, example 3)
Pros:
- perfect to use in bed or sofa
- stable, laptop lies on the table not on your laps
- some of them have place for mouse
Cons:
- price
- large size
- rather impossible to use them in train
Summary
As you can see there are many ways to protect our balls from heat and ensure safety of our future parenthood. Some of these solutions won't cost you anything except a little effort so I think they are worth trying.
13 lipca 2009
SCJP - preparations for exam and impressions after
Readers from Poland: this is English version of my old post written in Polish which has additional information interesting only for Polish readers.
It's been some time since I passed my Sun Certified Java Programmer 1.5 (SCJP) exam, but I hope this post will help somebody to choose their way of preparations to the exam and consequently achieve better final result.
Teaching aids
- SCJP Sun Certified Programmer for Java 5 Study Guide (Exam 310-055), definitely "must have" book for everyone planning to pass SCJP. This book covers everything you could encounter on exam. I read it whole once but some chapters twice (mainly Generics and Threads which I didn't catch on at first).
- simulator EnthuWare JQ+, it costs only 28$ or 18$ (for students) but wihout it my score would have been lower.
- Java Language Specification and javadocs for further reading about small details
- your favourite IDE to test your own ideas and experiment with questions from example tests. Question 'What would be if I change ..." is one you should ask often while learning :)
- forum SCJP at JavaRanch.com, where you can meet many people who already passed SCJP and also authors of SCJP book.
General tips
1. I think trying to pass the exam without doing some example tests isn't good idea. Questions are rather specific and after few hundreds of example questions your speed and accuracy will increase significantly. Additionally you will be able to see some problems and errors right after you look at the code, almost without deeper analyze.
2. Money spent on SCJP simulator are never wasted money.
3. Play with code. If you are unsure about how something works, check it with your IDE. Try changing some code and see how it works then. My experiments with NetBeans give me a lot of additional knowledge.
4. Don't learn too long. I know it's hard to say with great confidence "I am ready for the exam", but you should pick a date (even in 3-4 months) and do not change it unless you are really, really justified. With such deadline in your head, you will be more motivated to learn regularly with better final effect. A friend of mine is learning for SCJP for 6 months without any plan and his preparations seem to be endless :)
More user stories about how people prepare for SCJP could be found at:
JavaRanch SCJP Wall of Fame.
PS: My result was 80% :)
It's been some time since I passed my Sun Certified Java Programmer 1.5 (SCJP) exam, but I hope this post will help somebody to choose their way of preparations to the exam and consequently achieve better final result.
Teaching aids
- SCJP Sun Certified Programmer for Java 5 Study Guide (Exam 310-055), definitely "must have" book for everyone planning to pass SCJP. This book covers everything you could encounter on exam. I read it whole once but some chapters twice (mainly Generics and Threads which I didn't catch on at first).
- simulator EnthuWare JQ+, it costs only 28$ or 18$ (for students) but wihout it my score would have been lower.
- Java Language Specification and javadocs for further reading about small details
- your favourite IDE to test your own ideas and experiment with questions from example tests. Question 'What would be if I change ..." is one you should ask often while learning :)
- forum SCJP at JavaRanch.com, where you can meet many people who already passed SCJP and also authors of SCJP book.
General tips
1. I think trying to pass the exam without doing some example tests isn't good idea. Questions are rather specific and after few hundreds of example questions your speed and accuracy will increase significantly. Additionally you will be able to see some problems and errors right after you look at the code, almost without deeper analyze.
2. Money spent on SCJP simulator are never wasted money.
3. Play with code. If you are unsure about how something works, check it with your IDE. Try changing some code and see how it works then. My experiments with NetBeans give me a lot of additional knowledge.
4. Don't learn too long. I know it's hard to say with great confidence "I am ready for the exam", but you should pick a date (even in 3-4 months) and do not change it unless you are really, really justified. With such deadline in your head, you will be more motivated to learn regularly with better final effect. A friend of mine is learning for SCJP for 6 months without any plan and his preparations seem to be endless :)
More user stories about how people prepare for SCJP could be found at:
JavaRanch SCJP Wall of Fame.
PS: My result was 80% :)
getBlog().addLanguage(Locale.ENGLISH), was: getBlog().setLanguage(Locale.ENGLISH);
After a while when I was blogging in Polish, my native language, I decided to make an attempt to switch completely to English, "esperanto of IT world". Main factors which lead me to this decision were:
- feeling that my English language skills are becoming more and more rusty, especially in areas not closely connected with IT and technical language. I know that writing new posts will take more time, but I think it's worth the effort.
- need to be more involved in filling Internet with useful programming stuff and solutions. No one could deny that posts in English are really more helpful than those in other languages. This is even more true if we take into consideration only IT world, when English is language of all information we need and consume everyday: tutorials, documentation, most actual books, etc.
- some voices from Web: post by Paul Szulc in Polish and another convincing post by Jeff Atwood. They both pointed out some good reasons why we all should blog about IT in one, unified language.
In spare time I will translate some old posts from Polish and update page content to conform to "English only" rule :)
So from now on only English posts here. I am eager to read your opinions about this change so feel free to post them in comments :) Also impressions about new blog template from http://www.zenplate.blogspot.com/ are welcome.
UPDATE (two weeks later): I was thinking about formula of this blog and some doubts appeared in my head. Do I really have content which is unique in whole Internet? Recently I thought so, but when I was preparing post in English about book "Effective Java", I found that many, many other people already wrote about similar things and enthusiasm about my post almost disappeared. So what now? I think that most of my post will be in Polish, because I don't want them to duplicate other content from the Web. Moreover writing in Polish will allow me to share some more personal opinions and experiences from programming and my live in general than if I was writing in English. Of course some posts that in my opinion are more unique or interesting will be translated to English.
I apologize for the confusion and my earlier rash decision. I hope it won't happen again :)
- feeling that my English language skills are becoming more and more rusty, especially in areas not closely connected with IT and technical language. I know that writing new posts will take more time, but I think it's worth the effort.
- need to be more involved in filling Internet with useful programming stuff and solutions. No one could deny that posts in English are really more helpful than those in other languages. This is even more true if we take into consideration only IT world, when English is language of all information we need and consume everyday: tutorials, documentation, most actual books, etc.
- some voices from Web: post by Paul Szulc in Polish and another convincing post by Jeff Atwood. They both pointed out some good reasons why we all should blog about IT in one, unified language.
In spare time I will translate some old posts from Polish and update page content to conform to "English only" rule :)
So from now on only English posts here. I am eager to read your opinions about this change so feel free to post them in comments :) Also impressions about new blog template from http://www.zenplate.blogspot.com/ are welcome.
UPDATE (two weeks later): I was thinking about formula of this blog and some doubts appeared in my head. Do I really have content which is unique in whole Internet? Recently I thought so, but when I was preparing post in English about book "Effective Java", I found that many, many other people already wrote about similar things and enthusiasm about my post almost disappeared. So what now? I think that most of my post will be in Polish, because I don't want them to duplicate other content from the Web. Moreover writing in Polish will allow me to share some more personal opinions and experiences from programming and my live in general than if I was writing in English. Of course some posts that in my opinion are more unique or interesting will be translated to English.
I apologize for the confusion and my earlier rash decision. I hope it won't happen again :)
4 lipca 2009
Javarsovia 2009 - wrażenia
Właśnie wróciłem z konferencji Javarsovia 2009. Ogólne wrażenia jak najbardziej pozytywne, dokładniejsza relacja poniżej. Najbardziej żałuję, że nie udało się mi wyciągnąć tylu znajomych ilu chciałem, no i że nie wygrałem kubka ;)
GODZ. 9:00 - Intro
Na miejscu byliśmy wcześnie, bo tuż przed 9, dlatego spore było nasze zdziwienie, gdy okazało się, że przy rejestracji ustawiły się już trzy wężyki z uczestnikami. Na szczęście wszystko przebiegło sprawnie, każdy otrzymał trochę materiałów spamowo-informacyjnych, smycz, długopis, notatnik i identyfikator na szyję z rozkładem jazdy konferencji na rewersie (super pomysł!). Potem nastąpiło krótkie rozpoczęcie i każdy mógł udać się na wykład lub warsztat, który go najbardziej interesował.
Ja z dostępnych prezentacji wybrałem następujące:
GODZ. 9:45 - Testy wspaniałe zdobywają Warszawę by Szczepan Faber
Wykład fajnie przeprowadzony i ciekawy. Ogólnie o testach, jak je pisać, żeby się później nie wstydzić :) Szczepan zaprezentował szablon testów, który w dużym uproszczeniu wygląda następująco:
@Test
public void shouldDoSomethingWeWantToTest() throws Exception {
// given
// tutaj przygotowujemy dane to wykonania metody, którą chcemy przetestować
// when
// tutaj wykonujemy metodę, którą chcemy przetestować
// then
// tutaj sprawdzamy czy wynik jest zgodny z oczekiwaniami
}
Dzięki zastosowaniu takiego szablonu każda metoda testująca ma określony cel i jest łatwa do zrozumienia nawet po pobieżnym spojrzeniu w kod.
Kluczowe są cztery elementy każdej metody:
1. słowo "should" w nazwie metody testującej
Dzięki niemu wiemy co dokładnie ma testować metoda nawet bez zaglądania do jej wnętrza. Jest to tym bardziej istotne im więcej mamy testów w aplikacji. Jeśli uruchamiamy testy i zobaczymy informację, że shouldLoadOldestUser() nie wykonał się poprawnie, to od razu wiemy co w aplikacji nie zadziałało jak powinno.
Dodatkowo słowo "should" sprawia, że metoda musi mieć konkretny cel swojego istnienia. Nie może testować kilkunastu rzeczy, bo wtedy nazwa metody byłaby bardzo dziwna np. shouldLoadOldestUserAndShouldSendOldestUserEmailWithInfo().
2. słowo given
W tym miejscu przygotowujemy dane do testów. Powinno znajdować się tam jak najmniej kodu, czyli ustawiamy tam tylko te właściwości i te dane, które są nam rzeczywiście potrzebne do wykonania tego właśnie testu.
3. słowo when
Tutaj wykonujemy metodę, którą chcemy przetestować.
4. słowo then
Tutaj sprawdzamy, czy wynik wykonanej metody jest zgodny z oczekiwanym.
Schemat jest bardzo prosty w swej budowie i chyba właśnie w tej prostocie kryje się jego moc. Przyznaję, że moje testy nie są szczytem elegancji i czytelności, więc przy najbliższej okazji pisania mojej magisterki wypróbuję w boju zalecenia Szczepana, bo wydaje mi się, że dzięki temu znacznie zyskają na jakości.
W dalszej części prezentacji Szczepan zaprezentował kilka pojęć i bibliotek, z którymi wcześniej się nie zetknąłem. Poniżej lista:
- płynne interfejsy (fluent interfaces), więcej tutaj na blogu Martina Fowlera
- biblioteka Hamcrest do budowania matcherów. Używana najczęściej w testach, walidacjach i przy mockowaniu obiektów. Zapowiada się ciekawie.
- fest, biblioteka upraszczająca tworzenie testów jednostkowych
- Mockito, biblioteka do mockowania (imitowania) obiektów podczas testowania kodu.
- plugin do Eclipse'a (nazwa wyleciała mi niestety z głowy), który odpala testy w tle, gdy my równolegle kodujemy. UPDATE: To narzędzie to Infinitest, dziękuję Tomkowi Nurkiewiczowi za podpowiedź :)
Podsumowując, bardzo dobry wykład. Nie oczekiwałem po nim niczego super ciekawego, ale na szczęście pozytywnie mnie zaskoczył :) Szczepan poprowadził całość w dość młodzieżowym stylu i wyszło mu to bardzo fajnie. Dodatkowo pokazał jak można naprawdę szybko pisać kod wykorzystując dostępne w IDE skróty klawiszowe :) Mój numer jeden tej konferencji.
GODZ. 11:00 - Ciągła Integracja w procesie wytwarzania oprogramowania by Kuba Kubryński
Ciekawy wykład o ciekawej tematyce, posłuchałem sporo o rzeczach, z którymi nie miałem nigdy styczności: continuous integration, Hudson, itd.
Z rzeczy, które wydały mi się najbardziej ciekawe i potencjalnie warte bliższego zapoznania:
- narzędzia do badania jakości tworzonego kodu, znajdowania miejsc potencjalnie zawierających błędy: PMD, CheckStyle, FindBugs, JavaNCSS
- JUnitPerf - biblioteka rozszerzająca możliwości JUnita o testowanie szybkości i skalowalności istniejących już testów jednostkowych.
- Sonar, najciekawsze z narzędzi, które pojawiły się na prezentacji. Prawdziwy kombajn do zarządzania jakością tworzonego kodu. Analizuje kod, wykrywa potencjalne błędy (używając narzędzi wymienionych PMD, CheckStyle, a także Cubertura), pokazuje zmiany parametrów w czasie rozwoju projektu. A wszystko to w przejrzystej graficznej formie. Naprawdę zapowiada się super!
Ten wykład to także pozytywne zaskoczenie. Styl prowadzenia inny niż u Szczepana, mniej luzacki, ale nie przeszkadzało to w odbiorze treści. To było dobrze spędzone 60 minut.
GODZ. 12:15 - Apache Wicket by Paweł Szulc
To był mój faworyt na najciekawszy wykład tej konferencji. Wicket to mój ulubiony framework frontendowy i ciekawiło mnie co też nowego dowiem się z tej prezentacji. Okazało się jednak, że nie za wiele, bo wykład był bardziej skierowany do osób, które tylko o Wickecie słyszały lub ewentualnie bawiły się tylko w jakieś proste przykłady. Oczywiście nie mogę uznać tego za wadę, bo Paweł ciekawie i nieszablonowo zaprezentował zalety i cechy tego frameworka. Na tyle ciekawie, że mojego znajomego, który wcześniej kodował w JSF, zachęcił do wypróbowania Wicketa.
Na koniec pojawiła się też rzecz dla mnie nowa. Otóż Paweł zaprezentował szablon mavenowy, który tworzy prototyp aplikacji w Wicket. W odróżnieniu od quickstarta ze strony frameworku jest on jednak dużo bardziej rozbudowany (o DAO, service layer, autoryzację) i pokazuje pewne wzorce architektury, których warto przestrzegać już od samego początku tworzenia projektu w Wicket. Bardzo fajna sprawa i jak tylko Paweł udostępni szablon na swoim blogu, na pewno się z nim dokładnie zapoznam.
Paweł Szulc ciekawie i niestandardowo pokazał cechy Wicketa. Ci którzy znali ten framework skorzystali mniej, ale dzięki takiemu a nie innemu poziomowi zaawansowania omawianych zagadnień, grono osób, które przychylnie spojrzą na pomysł wyboru Wicketa do rzeczywistego projektu znacznie się powiększyło. I o to chodziło! :)
GODZ. 13:15 - Break
Po wykładzie o Wicket nastąpiła przerwa obiadowa. Organizatorzy spisali się na medal i każdy chętny mógł spokojnie zjeść smaczny, ciepły i darmowy posiłek. Nie zauważyłem, żeby dla kogoś zabrakło ;) Przy okazji można było zakręcić się koło rejestracji i zdobyć koszulkę z konferencji :)
Po posileniu się, pełny nowych sił wyruszyłem na kolejny wykład.
GODZ. 14:15 - Android z perspektywy programisty Java by Jacek Zadrąg
Wykład zapowiadał się ciekawie, bo tworzenie aplikacji na systemy mobilne jest coraz popularniejsze. Prowadzący pokazał w skrócie jak w łatwy sposób można stworzyć aplikację do szybkiego wybierania numerów na telefon od Google. Niestety kilka razy zgubił się przy implementacji i sporo czasu stracił na tworzenie kodu. Zamiast tego można było spróbować pokazać przyrostowo na slajdach jak wygląda dodawanie kolejnych elemenów do aplikacji, a na koniec pokazać działającą aplikację i efekt byłby moim zdaniem lepszy.
Ogólnie wykład ciekawy, ale można było go poprowadzić lepiej.
GODZ. 15:30 - Praca z odziedziczonym kodem by Jakub Dziwisz
Prowadzący pokazał jak programista rzucony do projektu, w którym pojęcie testów jednostkowych nie istnieje, może próbować się odnaleźć. Zaproponował sekwencję kroków, którą warto wykonać, tak aby zabezpieczyć się przed zepsuciem działającego rozwiązania, ale żeby możliwe było także jak najbardziej bezbolesne zmodyfikowanie kodu zgodnie z żądaniami klienta.
Z rzeczy, które pojawiły się podczas prezentacji warto wymienić:
- AgileTuning, gdzie można znaleźć podcasty o lekkich metodykach programowania.
- narzędzia do automatycznego generowania testów: płatne JTest, AgitarOne oraz darmowy TestGen4J.
- JDepend, narzędzie do generowania metryk kodu i badania zależności pomiędzy klasami.
- http://www.objectmentor.com/ - strona z poradami, kursami o programowaniu obiektowym, Extreme Programming, TDD, Agile, itp. Wszystko zebrane w jednym miejscu.
- Refactoring To Patterns (Joshua Kerievsky), książka warta przeczytania w kontekście omawianych na wykładzie zagadnień. Widzę, że nawet jest wydanie polskie (http://helion.pl/ksiazki/refawp.htm), niestety aktualnie niedostępne.
Wykład ciekawy, trochę mniej techniczny, bardziej koncepcyjny, ale i tak warto było posłuchać jak ktoś może mieć prze****ne, gdy trafi do projektu, w którym nic nie było robione zgodnie ze sztuką ;)
GODZ. 16:45 - Google Web Toolkit i JBoss Seam, czyli piękny wygląd z bogatym wnętrzem by Łukasz Kobyliński
Ten wykład wybrałem głównie po to, żeby posłuchać o GWT w kontekście użycia go w mojej pracy magisterskiej. Część Seamowa interesowała mnie już mniej :)
Całość została przeprowadzona na dobrym poziomie, ale w odróżnieniu od prezentacji o Wicket, tutaj zastosowano bardziej standardowy plan prezentacji. Było to co w większości prezentacji o frameworkach: opis ogólny, cechy, filozofia, zastosowania czy wady i zalety. Dla mnie jako osoby, która przyszła dowiedzieć się czym w ogóle jest GWT bez żadnej wcześniejszej z nim styczności, taki sposób zaprezentowania biblioteki zdał egzamin. Dostałem dawkę informacji, której oczekiwałem :)
PODSUMOWANIE
Plusy:
- wysoki poziom wykładów
- 4 ścieżki, każdy znalazł coś dla siebie
- dobra organizacja: informacja, minimalne poślizgi, dobre jedzenie :)
- wygodne aule i sale wykładowe.
Minusy:
- szkoda, że jednodniowa. Fajnie by było spędzić na takim evencie cały weekend.
- catering zwinął się ponad 1h przed zakończeniem i musiałem "o suchym pysku" iść na ostatni wykład :)
- w paru wypadkach zabrakło miejsc siedzących dla wszystkich chętnych.
Ogólnie plusy są mocne, a minusy to raczej detale, które nie wpływały na sumaryczny odbiór konferencji. Tak po prostu, żeby organizatorzy mieli świadomość, że nie było idealnie :)
Subskrybuj:
Posty (Atom)