To czym zdecydowanie różnią się książki Blocha od innych dotyczących programowania czy też javy, jest to że w każdej z nich skupia się na pewnej niszy w temacie o którym pisze. W przypadku efektywnego programowania, skupia się na praktycznych aspektach tworzenia oprogramowania, dobrych, sprawdzonych wzorcach postępowania przy jego projektowaniu oraz na specyficznych dla javy zagadnieniach. Autor porusza 78 tematów, z którego każdy to kilku stronnicowy artykuł szczegółowo omawiający problem. Materiał zawarty w książce został skatagoryzowany według pewnych większych grup problemów, które porusza. Autor rozpoczyna od omawiania zagadnień związanych z tworzeniem i usuwaniem obiektów, następnie przechodzi do tych związanych z projektowaniem klas, w tym aspektów specyficznych dla javy. Można tutaj dowiedzieć się m.in. dlaczego należy uważnie używać singletonów, podstaw działania garbage collectora, jak definiować prawidłowe metody hashCode czy equals, dlaczego warto stosować interfejsy czy zastępować dziedziczenie kompozycją. Na uwagę zasługe fakt, iż autor stara się być jak najbardziej obiektywny, dostrzega zarówno zalety proponowanych przez siebie rozwiązań jak i ewentualne wady. W dalszej kolejności omawia takie konstrukcje jak typy ogólne, wyliczeniowe i adnotacje. Udziela praktycznych wskazówek jakich konstrukcji języka i praktyk programowania używać, a jakie są już przestarzałe. W ostatnich rozdziałach omawia sposoby wydajnego i rozsądnego korzystania z wyjątków, dzieli się doświadczeniem w kwestii współbieżności oraz serializacji. Cała wiedza z książki jest gdzieś pewnie rozsiana po internecie w postaci pojedynczych postów na blogach czy artykułów. Wydaje mi się jednak iż warto takie kompendium wiedzy nt problemów specyficznych dla javy mieć zawsze pod ręką i od czasu do czasu odświeżyć swoją pamięć. Gorąco polecam książkę Java. Efektywne programowanie . Tymczasem uciekam do kolejnego dziecka Blocha – Java puzzlers .

Nagłówek artykułu sugeruje, że będę starał się dokonać porównania Javy i Pythona. Przecież to dwa kompletnie różne światy. Niemniej jednak postaram się w skrócie nakreślić czym cechuje się Python i opisać co poniektóre ciekawsze rozwiązania, z którymi spotkałem się podczas mojej krótkiej i burzliwej znajomości z tym językiem.

Intro

W odróżnieniu do Javy, Python jest językiem typowanym dynamicznie: zmiennych się nie deklaruje i tym samym nie określa się ich typu. Znaczy to mniej więcej tyle, że do tej samej zmiennej można przypisywać obiekty różnych klas bez potrzeby rzutowania, nie narażając się na odpowiednik javowego ClassCastException. Skoro już mowa o klasach – Python jest w pełni obiektowy, a więc typy proste (bool, int, float, complex) również są obiektami. Python jest językiem interpretowanym, nie wymagającym kompilacji (ten krok jest opcjonalny – interpreter może generować skompilowany kod do plików *.pyc). Fakt ten może spodobać się weteranom Javy – przecież nieraz budowanie złożonych projektów potrafiło zająć ładne parenaście minut. Jednak dynamiczne typowanie w połączeniu z brakiem konieczności kompilacji (który de facto często w pewnym stoponiu weryfikuje poprawność kodu) i nieuwagą programisty może przyczynić się do powstawania błędów. Ale to temat na osobną dyskusję.

Liczby.

Cechą, której nie miałem okazji specjalnie wykorzystać, a która bardzo pozytywnie mnie zaskoczyła, jest wbudowana obsługa liczb zespolonych. Dostępny mamy typ prosty complex.

>>> 1j * 1J
(-1+0j)
>>> 1j * complex(0,1)
(-1+0j)
>>> a=1.5+0.5j
>>> a.real
1.5
>>> a.imag
0.5

Kolejną ciekawostką jest fakt, że ograniczeniem długości liczby typu long jest w zasadzie tylko ilość dostępnej pamięci operacyjnej. Dostajemy zatem „out-of-the-box” możliwość wyrażania odległości międzygalaktycznych w milimetrach. Tylko co, jeśli będziemy chcieli przekazać obliczony wynik na inną maszynę?

(), [], {}.

Zdarza się, że potrzebujemy, aby metoda zwróciła więcej niż jeden obiekt. Rzecz jasna mowa tu nie o liście/tablicy, ale o obiektach różnych typów. Jednocześnie nie widzimy sensu tworzenia nowej klasy, która i tak byłaby wykorzystana tylko w tym jednym miejscu. Wtedy (na przykładzie Javy) zaczyna się kombinowanie: może przekazywać jeden obiekt przez parametr, w metodzie wypełniać go danymi, a drugą część informacji zwracać przez return statement?; może przejrzeć pakiet *utils w poszukiwaniu generycznej klasy Pair<A,B> lub Trio<A,B,C> i we wspomnianej metodzie zwracać właśnie obiekt takiej klasy? a może spróbować użyć mapę?

Zdaje się, że m.in. wówczas przydałyby się znane z Pythona krotki – niemodyfikowalne sekwencje referencji dostępnych niezależnie. Dostęp do poszczególnych elementów odbywa się przez podanie indeksu (numeracja od zera).

>>> tuple = 12345, 54321, 'hello!'
>>> tuple
(12345, 54321, 'hello!')
>>> tuple = (12345, 54321, 'hello!')
>>> tuple
(12345, 54321, 'hello!')
>>> tuple[0]
12345

Idąc za ciosem – kolejnym typem danych jest lista, oznaczana przy pomocy nawiasów kwadratowych. Bardzo podobna do krotki, jednak daje możliwość modyfikacji swoich danych.

>>> list = ['spam', 'eggs', 100, 1234]
>>> list
['spam', 'eggs', 100, 1234]

Słowniki, które w Pythonie tworzy się przy użyciu nawiasów klamrowych, prezentują nieco inny sposób grupowania danych. Podczas gdy krotki i listy są numerowane na podstawie indeksów liczbowych, słowniki do indeksacji stosują nazwy – mogą to być litery, ciągi znaków lub symbole. Słowniki można porównać do java.util.Map, dane wkładamy podając klucz oraz odpowiadającą mu wartość, klucze muszą być unikatowe, jednak pod jednym kluczem wystąpić może wiele wartości.

>>> tel = {'jack': 4098, 'sape': 4139}
>>> tel['guido'] = 4127
>>> tel
{'sape': 4139, 'guido': 4127, 'jack': 4098}
>>> tel['jack']
4098
>>> del tel['sape']
>>> tel['irv'] = 4127
>>> tel
{'guido': 4127, 'irv': 4127, 'jack': 4098}

Ciekawym niuansem jest możliwość dostępu do elementów sekwencji podając ujemną wartość indeksu. W Javie chcąc pobrać ostatni element listy, potrzeba mniej więcej takiego kodu: list.get(list.size() – 1); podczas gdy w Pythonie wystarczy: list[-1]. Przechodząc kolejno elementy listy użylibyśmy indeksów od 0 do len(list)-1. Ten sam efekt można osiągnąć iterując od -len(list) do -1. Taka mała rzecz, a cieszy.

Istnieją również skróty na „krojenie” sekwencji. W Javie skorzystalibyśmy z metody List.subList(), która zwraca widok oryginalnej listy. Odpowiadająca temu instrukcja Pythona to zaledwie: list[a:b], gdzie a i b to indeks początkowy i końcowy nowej listy.

s = "ABCDEF"
s[2:5]  --> "CDE"
s[4:]   --> "EF"
s[:2]   --> "AB"
s[:-1]  --> "ABCDE"
s[-1:]  --> "F"
s[:]    --> "ABCDEF"

Kolejny interesujący feature to funkcja range(a, b, c), która zwraca listę liczb od a do b (z opcjonalnym krokiem c), i która często przydaje się przy definiowaniu pętli for..in. Funkcja xrange() spełnia taką samą rolę, jednak poleca się ją stosować przy dużych rozmiarach list: zamiast alokować zbędnie duży fragment pamięci tylko po to, aby trzymać w niej uporządkowane wartości – xrange() na potrzeby iteracji tworzy tzw. lazy-list, która generuje i udostępnia jedynie elementy potrzebne w danej chwili.

# liczenie silni ze 100:
product = 1L
for i in xrange(1, 100):
    product = product * i

Pozostałe małe plusiki

Bardzo istotnym elementem kodu Pythona są białe znaki, a konkretnie wcięcia. To one określają bloki kodu. Z jednej strony jest to plus – mniej pisania, mniej linii kodu. Jednak błędnie zaaplikowane wcięcia w kodzie (np. wynikające z popularnej techniki copy-paste) mogą spowodować ciężkie do wytropienia błędy.

Świetnym ułatwieniem, które przydałoby się w innych językach, jest możliwość szeregowania (chaining) operatorów porównań:

>>> x = 5
>>> 1 < x < 10
True

Porównania wartości String’ów w Pythonie to kwestia użycia operatorów == lub !=. Daje to sporo poziom przejrzystości kodu, w porównaniu do Javy, gdzie wykorzystalibyśmy String.equals(), compare() lub compareTo().

Podobnie jak w Scali, w Pythonie możliwe jest deklarowanie funkcji wewnątrz funkcji. Zamiast powielać ten sam fragment kodu, lepiej zdefiniować i wywołać nową funkcję. Taka fragmentacja szybko mogłaby doprowadzić do zmniejszenia czytelności interfejsu danej klasy (multum krótkich metod), toteż warto zastanowić się nad umieszczeniem nowej funkcji w ciele funkcji, w której będzie ona używana. Korzystać również możemy z funkcji lambda (któtkich funkcji anonimowych), znanych m.in. z C# i Scali.

„Talk less, more action”

Podaje się, że pisząc w Pythonie, można być 5-10 razy bardziej produktywnym niż w Javie. Trudno się temu dziwić, jeśli otwarcie i odczytanie pliku tekstowego w Pythonie sprowadza się do:

file = open('plik')
file.read()

Podczas gdy w Javie należałoby zadeklarować odpowiedni bufor, utworzyć strumień podając ścieżke pliku, prawdopodobnie czytać fragmentami w pętli, całość okraszając tłustą warstwą try {} catch().

Python pozwala na dużą swobodę. Jest językiem skryptowym, ale nie oznacza to, że nie można pisać w nim kodu zorientowanego obiektowo. Oferuje zaawansowaną modularność (wprowadza pojęcie modułu i pakietu), choć właściwie całą, nawet bardziej skomplikowaną aplikację można zawrzeć w jednym pliku *.py.

Python daje duże możliwości. Może być stosowany przy projektach z wielu dziedzin, jako język podstawowy, jak i uzupełniający. Zbudujemy w nim GUI (pyGTK), napiszemy testy jednostkowe (pyUnit), utworzymy zwięzły i treściwy skrypcik użytkowy, dostarczymy plugin do Firefox’a, tudzież rozszerzenie do Blender’a, połączymy się z relacyjną bazą danych, obsłużymy dokumenty XML (wbudowane parsery SAX i DOM, narzędzia walidacji, transformacji XML, dodatkowy pakiet PyXML), wreszcie w parudziesięciu liniach zmieścimy prostego klienta email, czy komunikator sieciowy, postawimy aplikację webową (framework Django), w międzyczasie korzystając z bibliotek pisanych w C lub C++.

Ok. Gdzie jest haczyk?

Python może nie wydawać się stabilną platformą, jeśli w danym momencie korzysta się z elementów, które z czasem się zmieniają. Jeśli chce się budować większą aplikację, warto trzymać się jednej wersji języka. Niestety takie podejście też nie jest najlepsze, bo:

• Nowsze wersje bibliotek zazwyczaj powstają tylko dla najnowszych wersji Pythona
• Pewne nowe elementy Pythona mogą spowodować subtelne zmiany w działaniu aplikacji, które nie dadzą się łatwo wykryć. To z pewnością nie sprzyja biznesowi.

Weźmy konkretny przykład. W Pythonie 2.3.4 i wcześniejszym poniższy snippet powoduje wygenerowanie wyniku, którego oczekuje się po programie napisanym w C:

>>> print "%x" % -2
fffffffe

Poczynając od wersji 2.4 widzimy z goła odmienny wynik:

>>> print "%x" % -2
-2

Przedstawiona zmiana może wydawać się błaha, ale tak nie jest. W nowszej wersji Pythona zmianie uległ sposób traktowania liczb całkowitych bez znaku. Ponieważ z liczb całkowitych korzysta się nawet w najmniejszym skrypcie, tego rodzaju zmiana może nieść kolosalne konsekwencje.

Innymi słowy – Python jest na tyle młodym językiem, że jego twórcy na razie nie przejmują się kwestiami zgodności i stabilności (przynajmniej nie tak bardzo jak w Javie, w której cykle życia oprogramowania obejmują niejednokrotnie 10 lat).

Python to nie tylko maszyna wirtualna, API i składnia – to także zbiór bibliotek otaczających podstawowe funkcje systemu operacyjnego. Z założenia skrypty pythonowe mają być przenośne pomiędzy systemami operacyjnymi i hardware’m. Często ochrona przed różnicami pomiędzy systemami jest iluzoryczna, zwłaszcza w kwestii obsługi protokołów sieciowych i wielowątkowości. Np. interfejs gniazd sieciowych, stosowany w wielu programach, zgłasza inne wyjątki pod Windows, a inne pod *nix. Więc albo wyłapuje się wszystkie wyjątki, albo stosuje się osobny kod dla tych przypadków.

Z mojego, subiektywnego punktu widzenia mechanizm dołączania dodatkowych zewnętrznych bibliotek do instancji Pythona jest niekiedy mocno przesadzony. Nie wszystkie biblioteki wymagają instalacji – niektóre zwyczajnie wrzucamy do katalogu PythonXX\Lib\site-packages i po wykonaniu odpowiedniej instrukcji importu od razu są widoczne z poziomu interpretera. Inne biblioteki dostarczają cały instalator, który teoretycznie powinien wszystkim się zająć.
Ku przestrodze: Instalacja Pythona 2.6.7 pod 64bitowym Windows7 nie powinna stwarzać problemów. Jednak potem doinstalowanie dodatkowych modułów może okazać się już nie takie proste – biblioteka szuka w rejestrze informacji o ścieżkce instalacji wymaganej wersji Pythona – i nic nie znajduje. Wtedy niezwykle irytujący staje się fakt, że byle biblioteka (której kod pewnie mieści się na paru ekranach), z wielce wyszukanym instalatorem, jest nie do zainstalowania, choćbyśmy ściągali coraz to inne wersje i samego Pythona i rozszerzeń. Jakby tego było mało – deinstalacja pod Win7 trwa ~8minut, i zostawia po sobie multum śmieci, m.in. w katalogach systemowych.

Dużym minusem jest brak możliwości debuggowania wątków (oczywiście można próbować to „obejść” przy pomocy logger’a, lub pisząc dokładne testy jednostkowe).

Outro

Python jest narzędziem zorientowanym na maksymalną zwięzłość, prostotę i wysoki stopień abstrakcji. Dzięki temu pozwala na szybkie i efektywne tworzenie aplikacji. Pozwala skupić się na samej funkcjonalności programu, odkładając kwestie niskopoziomowe na dalsze tło. Byłby świetnym wyborem, kiedy przyjdzie potrzeba napisania na szybko prostego skryptu, czy niewielkiej aplikacji w ramach uczelnianego projektu. Zdaje się, że nie jest to jeszcze język na tyle dojrzały, ustabilizowany i konsekwentny, aby na jego podstawie pisać rozbudowane aplikacje biznesowe o długim cyklu życia. Chyba, że jako wyjątkowo wysoko-poziomowy język uzupełniający, stanowiący niewielką część całości aplikacji.

Polecam

http://stackoverflow.com/questions/101268/hidden-features-of-python

Jednogłośnie uznaliśmy, że najlepszym wykładem był Domain-Driven Design Sławomira Sobótki, który w bardzo przystępny sposób pokazał tą technikę projektowania i modelowania systemów. DDD ma zastosowanie szczególnie tam, gdzie model domenowy jest bardzo złożony, a czas życia systemu liczy się w latach.

Ciekawa była również prezentacja Bartka Majsaka „Jak wycisnąć maksimum z testów”. TDD nie jest nam obce, ale podejścia jakie pokazał Bartek bardzo nam przypadły do gusty. W szczególności mam tu na myśli testy behawioralne oraz nagrywanie wykonania testów techniką screen-capture, co pozwala nam błyskawicznie przejrzeć testy funkcjonalne, które nie zakończyły się sukcesem.

Dwa wykłady były poświęcone tylko i wyłącznie Scali, którą nazywa się czasem następcą Javy. W szczególności pasowały one Pawłowi, który jest zapalonym miłośnikiem tej technologii i firmowy ekspertem w tej dziedzinie. Szczególnie zaciekawiło nas usytyuowanie Scali w klasie rozwiązań Enterprise, które prezentował Paweł Dolega.

Oczywiście nie ominęliśmy też prelekcji o architekturze modelu dla rozwiązań NoSQL. Prowadzący spotkał się z niemałymi sprzeciwami z widowni, dzięki czemu prezentacja nabrała dynamiki i zmusiła Jarosława do usilnego bronienia swoich poglądów :-)

Podsumowując, konferencję oceniamy pozytywnie. Nie ma zarzutów co do organizacji, która była na prawdę na wysokim poziomie, aczkolwiek mieliśmy wrażenie, że 45 minutowe prezentacje rzadko komu wystarczały, żeby przeprowadzić pełny wykład. Większość prelekcji była dobrze przygotowana i przeprowadzona, aczkolwiek zdarzały się też takie, które wymagają większego wysiłku w przyszłości :-) Generalnie Confiturę uznajemy za udaną i z chęcią wybierzemy się również w przyszłym roku.

Dzisiejszy wpis będzie o znanej i generalnie dość znanej i mającej wiele zalet metodyce Design By Contract. Temat „wypłynął” ponownie dla wielu javovców tym razem dzięki wydaniu biblioteki  CoFoJa (o którym właśnie będzie ten post) przez dwóch pracowników Google przy ścisłej współpracy z autorem pierwowzoru tego projektu. Dlaczego jednak nietypowy tytuł posta – „trzeźwe spojrzenie”? Ponieważ w odróżnieniu od niektórych nie oceniam technologii na podstawie „wow factor” a realnej używalności. Gotowi mini review tego toola? No to lecimy… :-)

Contracts For Java

Na początek warto rzucić okiem na googlowy blog gdzie ogłoszono premierę tego narzędzia oraz oczywiście samą stronę domową projektu CoFoJa. Oczywiście na samym przekierowaniu nie poprzestanę więc zaczniemy od mini definicji od strony użytkownika metodyki design by contract. Jak możemy przeczytać chociażby w pragmatycznym programiście metodyka ta ma dość spory potencjał i ciekawe możliwości – generalnie chodzi o określanie „kontraktów” na naszych metodach. Zakładanie kontraktów ma pewną wyższość nad pisanie testów jednostkowych ponieważ możemy kontrakt założyć na interfejsie a wszystkie implementujące go klasy będą z nim związane

Kontrakt może na przykład zapewnić:

• wykonanie danej metody tylko i wyłącznie wtedy gdy przekazane jej argumenty spełniają pewne kryteria (w kontekście CoFoJa byłoby to @Requires)
• zagwarantowanie spełnienia pewnych warunków po opuszczeniu metody (w kontekście CoFoJa byłoby to @Ensures ewentualnie @ThrowEnsures jeśli chcemy mieć kontrakt na rzucenie wyjątku)
• zagwarantowanie ogólnych warunków na konkretnej np. klasie (@Invariant)

Ok, skoro znamy podstawowe building blocks (zaczerpnięte skądżeby inąd niż z Eiffla oczywiście) zobaczmy jakieś przykładowe poadnotowane nimi API:

A teraz praktycznie

Najlepiej jest chwilkę się w niego wgryźć, powinien być stosunkowo zrozumiały. Nie chcemy nigdy mieć ujemnej ilości bananów – spowodowałoby to złamanie kontraktu. Podobne przykładowe kontrakty wejściowe/wyjściowe widzimy na metodach oraz jeden mały tip: metoda old() jest dostarczana automagicznie i oznacza „starą wartość tego wywołania” czyli przed wykonaniem metody na którą zakładamy ten kontrakt. Poza tym mamy tutaj do czynienia w sumie z zwyczajnym kodem Java który niestety jest wewnątrz stringa… Świadomy programista zapewne już ma zapaloną lampkę alarmową, że to będzie nie refaktorowalne i bez sensu… Na pocieszenie dodam iż kod Java zawarty w tych stringach faktycznie jest „kompilowany”i jak coś popsujemy składniowo, kontrakty się nie skompilują i dostaniemy normalne informacje jakby to się nam nie kompilował normalny „nasz kod”. Co do wygody refaktoringu… Na szczęscie korzystam z porządnego IDE (IntelliJ IDEA) i takie „problemy” mnie nie dotyczą ;-). Wybrałem inject języka Groovy do tych stringów aby parser składniowy nie dziwił się pojawienia się metody old() „z nikąd”: Problem z „nie podpowiadaniem metod” jak i „nie da się refaktorować” jak widać został od razu wyeliminowany :-) Hooray for JetBrains. Poszukajmy jednak kolejnego problemu z tym API… Tak jest, @ThrowEnsures jest trochę brzydki a nie koniecznie musi być cały w stringu. Jak działa obecnie? Przekazujemy mu listę stringów gdzie parami występują „wyjątek” + „warunek kiedy ma zostać rzucony”. Chętniej zobaczył bym to w formie podobnej do poniższej (tylko szybki szkic taki), a wy?

Ok czas na uruchomienie kodu z „włączonymi kontraktami”… I… niestety nie okazało się to takie trywialne na obecnym etapie projektu. Niestety trzeba sobie ręcznie poustawiać processowanie adnotacji (norma, tutaj się niewiele zmieni) jednak trochę problemów nastarcza mi obecnie widoczność klas/pól dla CoFoJa w intellij. Classpath (dla procesora) zdaje się być ustawiony poprawny oraz jego klasa jak i inne opcje też jednak nie dochodzi do poprawnego przeparsowania wszystkich reguł. No cóż, może jutro się uda – tymczasem odsyłam do poradnika dla użytkowników Eclipse gdzie to członek społeczności sprawnie poradził sobie z tym problemem :-)

Trzeźwe spojrzenie: „Czy obecnie warto?”

Pozostaje pytanie… Czy warto się zainteresować CoFoJa jak i samym DBC? Pytanie jest chyba równie ogólne jak „czy warto meta-programować?” także wprost odpowiedzi nie udzielę. Miejmy jednak na uwadze że jak na razie używanie CoFoJa nie jest zbyt wygodne a adnotacje można by jeszcze trochę poszlifować. Trzeba by jeszcze rzucić okiem jak stoimy z integracją tego z Maven – aby normalnie testując bądź klikając sobie po projekcie te kontrakty mogły się przydawać. Sama idea jest ciekawa i jakby integracja z narzędziami była wygodniejsza – a może od razu pluginy do IDE – można by się nad tym porządniej zastanawiać. Jak na razie projekcik odkładamy ten projekt spokojnie na półkę „worth watching” i liczymy na rychłe wydanie 2.0. :-)

PS: Jeżeli interesują Cię takie jak i inne ciekawe metodyki i sposoby tworzenia pięknego, czystego kodu, zapraszam serdecznie na co 2 tygodniowe spotkania SCKRK gdzie obecnie dyskutujemy w formie „reading club” nad Domain Driven Design :-)

Na pierwszy ogień poszedł Łukasz Lenart, który opowiedział troszkę o byciu lepszym programistą, miękkich umiejętnościach oraz na przykład Zen To Done lub znanym Pomodoro. Prezentacja bardzo przyjemna i omawiająca rzeczy „wydawałoby się że oczywiste”. Problem leży w tym że czasami (hah! A może nawet „często”?!) o tych rzeczach najprostszych się zapomina wpadając w wir ślepego klepania kodu… ;-)

Drugą prezentację prowadziłem ja, a temat był oczywiście jednym z dla mnie obecnie bardzo (bardzo) istosnych: rozproszone systemy kontroli wersji, a konkretniej: git. Była to moja pierwsza prezentacja przed „większą” publicznością i mimo drobnych komplikacji („demo syndrome”… ;-)) przekazałem uczestnikom dość dobrą dawkę użytecznych informacji na temat git’a, co może potwierdzić wzmożone zainteresowanie i migracje wśród znajomych od czasu tej prezentacji…

Po przerwie na pizzę ufundowaną przez XSolve, do prezentowania przystąpił Łukasz Żmudziński. Proszanym tematem był projekt Lombok – który swoją drogą niedługo później autorzy bardzo wesoło prezentowali na niemieckim Devoxx :-). Lombok za cel stawia sobie zdjęcie z programistów Java smętnego klepania tak zwanego boilerplate („ten szum który musimy naklepać w każdym POJO etc etc”).

Ostatnia prezentacja tego dnia poruszyła tematykę również mi bardzo bliską i ciekawą: TDD, na przykładach. Łukasz Czerpak pokazał na licznych przykładach jak powinny wyglądać dobre testy. Jego przykładowe testy (których było mnóstwo) były dla mnie dość ciekawe jako, że z EJB większej styczności dotychczas jeszcze nie miałem.

To by było na tyle nagrań z piątej edycji JavaCamp’u. Zapraszamy na przyszłe (już niebawem) oraz oczywiście na nadchodzący wielkimi krokami GeeCON. :-) W razie zainteresowania innymi nagraniami i przyszłymi spotkaniami Polskiego JUGa, zapraszamy na java.pl oraz nasz kanał na parleys.com… :-)

Invalid memory access of location 00000010 eip=901a277b

Odrobina googlowania podsunęła rozwiązanie: http://code.google.com/p/google-web-toolkit/issues/detail?id=4220#c22

1. Należy ściągnąć aktualny build WebKit pod MacOS stąd: http://nightly.webkit.org/
2. Otworzyć dwuklikająć plik .dmg, przeciągnąć WebKit do /Applications/
3. W Eclipse wybrać Run -> Run Configurations z menu.
4. Po lewej stronie wybrać naszą aplikację (pod Web Applications)
5. Wybrać zakłądkę „Environment”
6. Dodać zmienną:
   Name: DYLD_FRAMEWORK_PATH
   Value: /Applications/WebKit.app/Contents/Frameworks/10.5
7. Zapisać

Problem powinien być rozwiązany.