IT Researches

Konferencja Warsjava 2010

2010-10-25T03:43:00.000+02:00

Konferencję Warsjava uważam za udaną. Ponowne spotkanie ludzi których pamiętam z java4people i pierwszej edycji COOLuarów. Dające do myślenia prelekcje i dyskusje po nich.

Niestety spóźniłem się. Trafiłem dopiero na 2 wystąpienie Pawła Lipińskiego. Gdy spytałem sąsiadów o temat, zyskałem beztroskie wzruszenie ramionami. Fakt, student ma inne rzeczy na głowie, gdy dostaje test za rozwiązanie którego można wygrać koszulkę czy też PlayStation :)

Jedna z koncepcji przedstawiona przez prelegenta nie daje mi spokoju: robienie jednej rzeczy jest lepsze niż wielu jednocześnie. Sam podczas rozwiązywania problemów staram się robić 2 rzeczy. Gdy zatnę się na jednej, ruszam z drugą. Pozwalam przetwarzać moim neuronom pierwszy problem w tle.

Czasami po prostu wiem, że kolejne zadanie spowoduje długie czekanie (na pobranie połowy netu przez Maven'a lub kolejny krok instalacji Oracle) więc staram się zrobić kilka drobnych rzeczy po drodze.

Zasada równoległej realizacji niezależnych zadań świetnie sprawdza się w zarządzaniu projektem i przetwarzaniu danych przez automaty. Tylko czy działa to na poziomie indywidualnej organizacji zadań?

Ileż to razy robiłem podwójny update bo spodziewając się że chwilkę zajmie - przełączałem się na struganie skryptu w oknie obok. Po powrocie do pierwotnego kodu nie pamiętałem czy zrobiłem ten update czy tylko chciałem go zrobić - więc dla pewności ... :)

Ileż razy musiałem ponownie zainstalować Oracle bo zapomniałem zaznaczyć jakieś ważnej opcji lub usunąć któregoś wpisu w rejestrze przy poprzednim odinstalowaniu Oracle :)

Więc może jednak warto spróbować z jedną rzeczą na raz.

Dariusz Łuksza swoją prezentacja o narzędziach do Git: egit (plugin do Eclipse), gitosis (serwer do utrzymywania repozytorium) gitweb (udostępnianie zawartości przez www), gerrit (system wspierający rewizje kodu) przypomniał mi, że miałem rozpoznać ten system kontroli wersji i jeszcze się za to nie zabrałem ... od 1,5 roku :)

Obserwowanie dobrego specjalisty, który potrafi wycisnąć ze swoich narzędzi 100% jest naprawdę rewelacyjnym doświadczeniem. Porównywalnym z czytaniem eleganckiego rozwiązania w kodzie.

Marcin Rzewucki oraz Jan Rychter przedstawili Clojure. Skoro są ludzie, którzy używają tego języka komercyjnie i istnieją narzędzia wspierające budowanie Leiningen może nadszedł czas odświeżenie i pogłębienie swojej wiedzy na ten temat.

Prezentacja Adama Michalika na temat czytania i pisania bytecode była zaskakująca. Sceptycznie do niej podszedłem ale zostałem mile zaskoczony. Jeśli ktoś potrudzi się, by za pomocą javap przeanalizować przykłady bytecode dla:
- klas implementujących covariant return types,
- konkatanacji String'ów
- traktowania wartości boolean, byte, short i int
- klas wewnętrznych
wówczas nie spojrzy już tak samo na kod źródłowy. Zastanawia mnie tylko, czy powszechna znajomość Jasmin wśród fanów przedwczesnej optymalizacji nie przyniesie nam chaosu i zniszczenia :)

Rafał Rusin przedstawił implementację standardu WS HumanTask przez projekty Apache HISE i Apache Camel. Ciekaw jestem w jakim zakresie te narzędzia znajdą zastosowanie.

Organizacja przebiegła sprawnie. Brakuje mi tylko eventu na LinkedIn :)

APM boost

2010-08-19T05:01:00.000+02:00

Better OS
------------
Till last weak I was using Windows XP as the base for my development effort (Try Vista, try Windows 7 - user friendly means too difficult to find tools under the annoying effects). But after a few experiences with different Linux distros (Ubuntu, Centos, Fedora) I've finally chosen most suitable for me.

Basic knowledge
It take some time to run computer with Linux instead of walking it ;) but it's worth the effort. I remember pushing to the limits regexp in Notepad++ and Eclipse diff to be close to desired result on Win. In the Linux world it's just standard option in grep, find, sed or awk (and it's not close to result - it's simple and accurate solution).

Keyboard
Microsoft Comfort Curve Keyboard 2000 is my current choice. It is slim and more ergonomic than classic keyboard. And big enough to use on armchair :D

Short cuts
A little learning about short cuts in Terminal, multiple workspaces, Firefox and some customization.

Finally great boost in APM's is finally mine. It's probably not the greatest idea to use keyboard to do precise pointing (play cRPG without mouse if you don't believe). Using mouse to do things that can be done by shortcut is even more painful (try playing cRPG without keyboard).

The reason is not because the time saving by using immediate short cut vs mouse point, choose and click but the time spend to distract you from whats on your mind currently. That's why I don't agree that mousefeed isn't decent plugin (well I would not agree if it didn't crash old Eclipse versions).

Brave new world

2010-08-19T04:03:00.000+02:00

Why in english?
---------------
I wanna learn as many different things as possible. I have heard that it's one of the key things to achieve 100+ lifespan :) So I'm writing in my sloppy english. Hopefully some French, German, Spanish or Japanese posts will occur ;)

Why new world?
--------------
The time when a was working for the current company very soon will end. And a new challenging events will follow (I hope).

Why brave?
----------
It only took me 1 day off work and suddenly plethora of crazy, impossible, revolutionary, amazing, a little scary, innovative and eventually profitable ideas come to my mind.

First Step
----------
The most crazy, impossible and terrifying one was to clean up my living space. After 5+ years of cleanup-by-putting-unnecessary-stuff-to-rarely-accessed-place introducing order take some time. Sorting notes from university, high school, and random notes gave me opportunity to watch some videos on InfoQ and YoutTube. Here are the ones I find interesting:

On TDD
Test Driven Development: Ten Years Later
Manager's Introduction to Test-Driven Development

On TDD by Misko Hevery
The Clean Code Talks - Don't Look For Things!
The Clean Code Talks -- Inheritance, Polymorphism, & Testing

On Agile Metrics
Agile Project Metrics

On iterative development and testing
Interview: Ron Jeffries on Running Tested Features

On Architecture
Learning from Five Years as a Skype Architect

By Joshua Kerievsky
all presentations and interviews are very interesting

And looking at the great pile of papers - I'll probably watch quiet a few more :)

break;

2010-05-12T21:09:00.002+02:00

Jakiś etap mojego funkcjonowania się zakończył. Powoli wycofuję się z bycia leaderem Lublin JUG - są ludzie o lepszych kwalifikacjach organizacyjnych i programistycznych. Od jakiegoś czasu nie piszę postów. Z wieloma zaprezentowanymi tu opiniami się nie zgadzam. Niektóre były niepotrzebnym rozrywaniem sobie koszulki lub wymądrzaniem się. Droga do bycia dobrym programistą nie jest prosta i bezstresowa a że głośno myślałem na blogu ... :) Niemniej z niektórych postów jestem po prostu dumny. Słyszałem, że niektóre przydały się innym jeszcze inne przydały się mi :P Jak przychodzę do domu, to już nie odpalam kompa, żeby sprawdzić co nowego w 20+ grupach dyskusyjnych IT, albo poeksperymentować z jakimś dziwnym feature'm na który natknąłem się gdzieś przypadkiem. Pędziłem szybko, biorąc na siebie obowiązki, angażując się w różne aspekty funkcjonowania - wszystko po to, by zostawić coś daleko za sobą. Praktyka pokazuje, iż nie wychodzi mi to. Trudno niech sobie tak będzie. Ja się zasapałem, więc teraz sobie odpocznę.

Czyżby zmiana kierunku (z Lisp'em w tle)

2010-04-15T21:32:00.005+02:00

Wysłuchałem dziś wywiadu w SE Radio na temat języka Lisp. Jestem pod silnym wrażeniem. Opowieść o historii powstania pierwszego kompilatora Lisp'a rzuciła mnie na kolana. Na tyle, że po powrocie do domu nie siadłem do 5 sezonu Stargate Atlantis. Opowieść o tym, jak kilka osób ze świata Lisp'a próbowało zrozumieć o co chodzi w programowaniu obiektowym pogłębiła efekt. Niektóre fragmenty są naprawdę zabawne. Niemniej, podczas słuchania, nie mogłem oprzeć się od myśli, iż programowanie obiektowe jest tylko trywialnym przypadkiem programowania funkcyjnego. Takim dla małych dzieci. Żeby sobie kuku nie zrobiły :) ... Dziedziczenie wielo-bazowe jawi się, jako przykład tego, jak te małe dzieci próbując rozbudowywać swoje zabawki poszły w jakimś dziwnym kierunku. Wypaczając ciekawą i dosyć naturalną ideę rozszerzania mixin'ów. ... Mam wrażenie, iż w dziedzinie tworzenia oprogramowania rozwój nie polega na wpadaniu na nowe koncepcje, przełomowe idee. Polega on na wygrzebywaniu starych, dużo lepiej rozwiniętych koncepcji w bardziej łopatologiczny i uproszczony sposób. Ubrany w lepsze marketingowo słowa. ... Od jakiegoś czasu noszę się z zamiarem zmiany kierunku moich riserczów. Może trochę trzeba odpocząć? A może zamiast podniecać się nowymi cieszącymi oko łeb-frejmłorkami i prze-ficzerami z bibliotek FOSS, lepiej dogłębnie poznać i zrozumieć podstawowe narzędzie każdego programisty - języki programowania (Scheme, Forth). Sprawdzić co, już dawno temu, zostało odkryte. ... A może zmienić kierunek zainteresowań jeszcze bardziej?

Wyrażenia lambda na Lublin JUG

2010-03-09T22:07:00.003+01:00

Dziś Wojciech Gomoła na spotkaniu Lublin JUG wywołał niezłą dyskusję :) Widać wyraźnie, iż Java jest głęboko za .NET jeśli chodzi o wprowadzanie rozszerzeń języka. Spora część dzisiejszych uczestników LJUG'a widziała w prezentowanych wyrażeniach lambda, nową metodę na pisanie marnego kodu. Z oficjalnej informacji na temat nowości w Java 7 wynika, iż wprowadzenie czegoś podobnego do wyrażeń lambda, jest konsekwencją ułatwienia implementacji języków dynamicznie typowanych. Warto się chyba przyjrzeć nowym feature'om z pakietu java.dyn. Skoro będą w standardzie napewno będą używane i nadużywane. Na spotkaniu pokazana była biblioteka Google Collection. Na mnie zrobiła spore wrażenie. Wydaje mi się, że dało by się ją sensownie wykorzystać. Trzeba będzie dorzucić ją do skrzynki z narzędziami.

hamcrest - matchery

2010-03-07T10:35:00.005+01:00

W podstawowej bibliotece hamcrest hamcrest-core.jar dostępne są różne matchery, które można podzielić na kilka grup.

Dopasowanie napisów

startsWith(substr)	testItem.startsWith(substr)
endsWith(substr)	testItem.endsWith(substr)
containsString(substr)	testItem.indexOf(substr) >= 0

Na przykład:

import static org.hamcrest.core.StringContains.containsString;
import org.hamcrest.Matcher;

// ...

Matcher<String> matcher = containsString("ma");
boolean match = matcher.matches("ala ma kota"); // true

Sprawdzenie równości obiektów, null, typu

sameInstance(object)	testItem == object
equalTo(operand)	testItem.equals(operand)
notNullValue()	testItem != null
nullValue()	testItem == null
instanceOf(type)	testItem instanceOf type

Na przykład:

import static org.hamcrest.core.IsEqual.equalTo;
import static org.hamcrest.core.IsInstanceOf.instanceOf;
import static org.hamcrest.core.IsNull.notNullValue;
import static org.hamcrest.core.IsNull.nullValue;
import static org.hamcrest.core.IsSame.sameInstance;

import org.hamcrest.Matcher;

//...

Matcher<Integer> mSameObject = sameInstance( new Integer(0) );
boolean isSameObject = mSameObject.matches( new Integer(0) ); // false

Matcher<? super Integer> mEquals = equalTo( new Integer(0) );
boolean isEquals = mEquals.matches( new Integer(0) ); // true

Matcher<Bar> mNull = nullValue();
boolean isNull = mNull.matches( new Bar() ); // false

Matcher<Integer> mNotNull = notNullValue();
boolean isNotNull = mNotNull.matches( new Integer(0) ); // true

// ...

interface Foo {}
class Bar implements Foo {} 

Matcher<Foo> mInstanceOf = instanceOf( Foo.class );
boolean isInstanceOf = mInstanceOf.matches( new Bar() ); // true

Łączenie warunków, itp

anything()	true
anyOf(Matcher... matchers)	matcher1 \|\| matcher2 \|\| ...
allOf(Matcher... matchers)	mathcer1 && matcher2 && ...
not(matcher)	! matcher1

i trochę lukru składniowego:

is(matcher)	matcher
both(matcher1).and(matcher2)	matcher1 && matcher2
either(matcher1).or(matcher2)	matcher1 \|\| matcher2

Przeglądanie kolekcji

Najlepsze na koniec:

everyItem(elementMatcher)
hasItem(elementMatcher)
hasItems(Matcher... elementMatchers)

Na przykład:

import static org.hamcrest.core.Every.everyItem;
import static org.hamcrest.core.IsCollectionContaining.hasItem;
import static org.hamcrest.core.IsCollectionContaining.hasItems;
import static org.hamcrest.core.IsEqual.equalTo;

import org.hamcrest.Matcher;

// ...

List<String> stringList = Arrays.asList("eggs", "spam");

Matcher<?> mEveryItem = everyItem(equalTo("eggs"));
boolean isEveryItem = mEveryItem.matches(stringList); // false

Matcher<Iterable<? super String>> mHasItem1 = hasItem(equalTo("eggs"));
boolean hasItem1 = mHasItem1.matches(stringList); // true

@SuppressWarnings("unchecked")
Matcher<Iterable<String>> mHasItems1 = hasItems(
   equalTo("eggs"), equalTo("spam") );
boolean hasItems1 = mHasItems1.matches(stringList); // true

Dodatkowo jeśli sprawdzamy czy obiekt w kolekcji jest równy dnemu, możemy pominąć equalTo()

hasItem(T element)
hasItem(elementMatcher)
hasItems(T... elements)

Na przykład:

import static org.hamcrest.core.IsCollectionContaining.hasItem;
import static org.hamcrest.core.IsCollectionContaining.hasItems;
import static org.hamcrest.core.IsEqual.equalTo;

import org.hamcrest.Matcher;

// ...

List<String> stringList = Arrays.asList("eggs", "spam");

Matcher<Iterable<? super String>> mHasItem2 = hasItem("eggs");

boolean hasItem2 = mHasItem2.matches(stringList); // true
System.out.println(hasItem2);

Matcher<Iterable<String>> mHasItems2 = hasItems("eggs", "spam");

boolean hasItems2 = mHasItems2.matches(stringList); // true
System.out.println(hasItems2);

Dodatkowe matchery

W archiwum hamcrest-library.jar znajdują się matchery realizujące:

porównywanie liczb (w tym z daną dokładnością),
porównywanie napisów bez uwzględniania wielkości liter lub białych znaków,
czy napis jest pusty,
czy tablica lub kolekcja ma określony rozmiar lub czy mapa zawiera określony klucz lub wartość
testowanie występowania określonej ścieżki XPath

Zastosowanie

Oficjalna strona wymienia produkty wykorzystujące hamcrest. Najbardziej znane to weryfikacja w testach JUnit oraz tworzenie moków w Mockito. Wydaje mi się, iż pomija się tu jedną ciekawą cechę matcherów, która jest oczywista dla każdego, kto otarł się o języki funkcyjne. Matcher'y są tak naprawdę metodą na zapamiętanie funkcji. Zatem tak zapamiętaną funkcję nie tylko można przekazać jako parametr metody, aby wywołać ją od razu (assertThath() w JUnit) lub po jakimś czasie (thenReturn() w Mockito) lecz można zapamiętać warunek i (re)używać. Dlaczego, nie zapamiętać skonstruowanego matcher'a i wykorzystać w kilku różnych funkcjach?

hamcrest - podstawowe koncepcje

2010-03-07T08:58:00.003+01:00

Wspomniałem już o bólu przegryzania się przez bibliotekę hamcrest. Poniżej przegląd podstawowych elementów składowych hamcrest. Zawarte są w hamcrest-core.jar.

Matcher

Podstawowy typ klocków jakimi bawimy się w hamcrest to matcher. Reprezentuje on warunek opakowany w obiekt. Dzięki temu warunek ten możemy zapamiętać a następnie sprawdzać czy różne obiekty spełniają ten warunek. Każdy matcher rozszerza klasę org.hamcrest.BaseMatcher implementującej interfejs org.hamcrest.Matcher Oto hello world wykorzystujący hamcrest. Pokazuje on w jaki sposób działają matcher'y:

1 Matcher<String> condition = endsWith( "bar" );
2 
3 if ( condition.matches( "foobar") ) {
4    System.out.println( "hello world" );
5 } else {
6    System.out.println( "not this time" );
7 }

W linii 1, za pomocą metody statycznej endsWith, tworzymy matcher reprezentujący warunek "napis kończący się na bar". Następnie w linii 3 sprawdzamy czy napis "foobar" spełnia ten warunek.

Description

Kolejny podstawowy element hamcrest to Description (org.hamcrest.Description). Czyli obiekt reprezentujący opis matcher'a albo przeprowadzonej próby dopasowania. Opis jest ogólną koncepcją. W hamcrest core znajdują się 2 implementacje: opis tekstowy: StringDescription i nic nie robiący opis NullDescription. Oto identyczny warunek ale nieco bardziej gadatliwy:

 1 String expectedSuffix = "bar";
 2 String testedItem = "foobarbaz";
 3 
 4 Matcher<String> matcher = endsWith( expectedSuffix );
 5 
 6 Description properBehaviourDes = new StringDescription();
 7 matcher.describeTo( properBehaviourDes );
 8 
 9 if ( matcher.matches( testedItem ) ) {
10    System.out.println( "I wish " + properBehaviourDes ); 
11    System.out.println( "and my dream come true" );
12 } else {
13    Description invalidBehaviourDesc = new StringDescription();
14    matcher.describeMismatch( testedItem, invalidBehaviourDesc );
15 
16    System.out.println( "I wish " + properBehaviourDes ); 
17    System.out.println( "but " + invalidBehaviourDesc );
18 }

Wynik działania programu:

I wish a string ending with "bar"
but was "foobarbaz"

W liniach 6-7 jest tworzony opis dla warunku. Wyświetlany w 10 i 16 przy użyciu metody toString(). W liniach 13-14 tworzymy opis dla sprawdzenia czy obiekt spełnia warunek. Wyświetlany jest w linii 17.

Factory

Ostatni element to adnotacja wykorzystywana do oznaczenia metod, tworzących matchery. Jest to org.hamcrest.Factory. Dzięki niemu można stosunkowo łatwo wyszukać dostępne metody tworzące matchery. Przyznaję, eleganckie rozwiązanie :)

hamcrest - deficyt informacyjny

2010-03-07T08:11:00.006+01:00

Ostatnio, gdy po ciekawemu zastosowaniu wzorca strategii chciałem przetestować jego działanie, napotkałem ponownie problem sprawdzenia czy w kolekcji jest napis coś tam zawierający. Po przygodach z Ruby pomyślałem sobie to powinno być proste! Po co muszę pisać pętlę, zabezpieczać się przed NPE, wprowadzać jakąś boolowską flagę dla sprawdzania wyniku i wrzucić do assertTrue(). I wtedy przypomniałem sobie o jakimś przykładzie w JUnit 4 z assertThat() i biblioteką hamcrest. Niestety przykład nie pasował dokładnie do moich potrzeb, szukam online API lub online Javadoc ... nie ma! Sięgam do kodów źródłowych, żeby zobaczyć jakieś dobre komentarze, które mi wyjaśnią o co chodzi ... no bieda niesamowita (na w każdym razie nie jest to javadoc jaki jest np w JUnit 4 gdzie czytasz opis klasy i widzisz snippet)! Sięgam do oficjalnego tutoriala hamcrest a tu opis hello world oraz jak rozszerzać hamcrest'a ... ech. No nawet na wpis o hamcrest na Wiki angielskiej jest co najmniej lakoniczny. Zdesperowany przeszukuję czytnik blogów ... tylko wzmianka że jest. Oczywiście API hamcrest nie jest specjalnie ciężkie, więc metodą prób i błędów coś tam się udało zrobić (choć nie aż tak oczywiste, jak np w Mockito), ... ... zaś brak dla jednych jest przygnębiającym i rozczarowującym faktem, dla innych - wyzwaniem i sytuacją rodzącą ciekawe możliwości :D

Clojure pierwszy nieśmiały kroczek

2010-02-14T22:29:00.005+01:00

W ten weekend niewiele udało mi się zrobić z Clojure. Byłem trochę zajęty: wygoliłem sobie irokeza na głowie, po drodze do sklepu zapisaniem się na kurs prawa jazdy i trochę imprezowałem na wyjeździe i w domu :D Ale jednak wystartowałem:

Ogólne info

Twórca: Rich Hickey
Nazwa: od closure zastąpiono s przez j
Licencja: Eclipse Public License
składnia: Jest to dialekt Lisp (wiec chyba kasiazki do Lisp moga sie przydac :)
Prawdopodobne zastosowanie: łączenie z kodem w Java do uzyskania wielowątkowego kodu (ciekawe czy aż tak wydajnie i niezawodnie jak w Erlang'u)
Pojawienie się języka: 2007
Pojawienie się stabilnej wersji: maj 2009 (czyli niestety bardzo młody ... a może jednak stety)

Ważne linki

Z oficjalnej strony:

Prezentacje i wideo:

Rich Hickey on Clojure's Features and Implementation
Clojure for Java Programmers część 1 i część 2
Clojure: Functional Concurrency for JVM

Instalacja i uruchomienie interpretera

Praca z interpreterem nazywana bywa REPL - read-eval-print loop. Pobieramy zip'a z Clojure. W środku powinna być biblioteka clojure.jar. Interpreter Clojure uruchamiamy poleceniem:

java -cp clojure.jar clojure.main

Warto zrobić sobie skrypt uruchamiający. Np na MS Windows zrobiłem tak: 1) zdefiniowałem zmienna środowiskowa CLOJURE_HOME wskazująca na katalog do którego rozpakowałem Clojure. 2) Dedalem na końcu do Ptah ;%CLOJURE_HOME% 3) Utworzyłem w katalogu CLOJURE_HOME plik clj.bat zawierajacy:

java -cp %CLOJURE_HOME%/clojure.jar clojure.main %1

Teraz skrypty w clojure można uruchamiać w postaci:

clj my_clojure_script.clj

Zaś sam interpreter:

clj

Hello World

Tworzymy plik hello_World.clj zawierający (println "Hello world")

Integracja z Java

No właśnie, Clojure byłby niczym więcej, niż tylko (n-1)-szym^[1], bardzo młodym dialektem Lisp'a ... gdyby nie mały szczegół - integracja z Java. Z poziomu kodu w Clojure można wywołać kod Java za pomocą składni:

(. nazwa_klasy_java (nazwa_metody arg1 arg2 arg3))

Na przykład

(. Integer (parseInt "12"))

Tu trafiło mi się pytanie na które nie znam jeszcze odpowiedzi: jak wywołać metodę z publicznego pola - czyli zrobić System.out.println? W drugą stronę wygląda to również dosyć prosto. Niestety nie znam jeszcze konstrukcji Clojure wykorzystanych do tego, więc zostawiam tylko linkę. Jak się zbiorą i uformują moje notatki, dot. składni, w sensowną całość to umieszczę w kolejnym poście.

^{1 Tak tu powinno być n+1 ale ponieważ n-1 jest świetną miarą ilości flaszek na n-osobową imprezę, więc jest n-1 :)}

Ruby dodany do skrzynki z narzędziami

2010-02-12T23:24:00.005+01:00

Popełniłem mój pierwszy skrycik w języku Ruby w celach komercyjnych. Ku mojemu niemałemu zaskoczeniu, sporo mi pomogły moje własne linki o Ruby. Rozwiązywałem problem bardziej administracyjno-wdrożeniowy niż programistyczny - niemniej czuję, jakbym w dziedzinie programowania osiągnął kolejny stopień wtajemniczenia :D Sympatycznie jest przypomnieć sobie, że usunięcie duplikatów z napisu nie wymaga pętli tylko małego regexpa:

'aaababbzzzzccjkk'.gsub(/(.)\1+/,'\1')

Z wcześniej wymienionej listy języków i podejść jakie chciałbym dodać do mojej skrzynki z narzędziami developerskimi dodałem 2 pozycje: język skryptowy oraz Ruby. Nie zamierzam zostawić tej wiedzy na obecnym poziomie. Niemniej wypadało by rozejrzeć się za jakimś godnym przeciwnikiem. Najlepiej jakby dało się ten język integrować z JVM, aby można było jakoś z tego skorzystać w razie napotkania odpowiedniej klasy problemu. Z drugiej strony, język ten powinien wnosić jak najwięcej świeżości do mojego warsztatu. Zastanawiam się nad językami: Scala i Clojure. Groovy jest zbyt ... webowy (trudno o bardziej miażdżący w swej sile i głęboko merytoryczny powód :). Przez googlowe okularki można znaleźć ciekawe porównanie różnych języków JVM Wprawdzie Scala ma bardzo dobry PR i ciekawe przykłady zastosowań, typu Twitter, jednak najprawdopodobniej będzie to Clojure:

nadrobię zaległości w zakresie programowania współbieżnego (owszem, miałem to załatwić przy pomocy Erlang'a, niemniej nie zanosi się na to aby podbijał on rynek IT)
to jest jakaś forma Lisp'a, a więc będzie to kontynuacja moich nieśmiałych prób z początku kariery
skoro jest to Lisp-owaty język więc może jakiś zakręt w kierunku sztucznej inteligencji?
czysto funkcyjny język ... kto wie może uda mi się znaleźć jakiś produktywny sposób wykorzystania tego podejścia do tworzenia dużych systemów

Niestety nie będzie tak łatwo zacząć jak z Ruby. Tutorial do Ruby leży w co drugiej skrzyni. (Tak mi powiedział, z okrutnym uśmiechem, pewien gracz M&M VII o mieczach +5, gdy zdobyłem, po kilku podejściach Furię Niebios.) Może uda się (za radą z tego blogu) wykorzystać projekt Euler jako źródło problemów (liczę na perm buff +5 do algorytmiki i tymczasowo +20 do satysfakcji z rozwiązywanych problemów). Jak mawia stare porzekadło, jak się trochę porozglądasz po świecie to i czapka dla Arogranina się znajdzie ... czy tam tutorial dla Clojure.

SCJP zdany i co z tym fantem?

2010-01-19T19:53:00.006+01:00

Dzięki uprzejmości mojej firmy w poniedziałek 18 stycznia 2010 przespacerowałem się po pierwszej ścieżce certyfikacyjnej Sun :) Rozgrzewka była solidna. Drugie czytanie SCJP Sun Certified Programmer for Java 6 Study Guide zajęło mi, mniej więcej, półtora tygodnia (pierwsze czytanie szło prawie rok bo między akapitami był WoW). Prawie 3 dni męczenia się nad zadaniami, z ww dzieła (wiadomo przerwy pół dniowe na oglądanie filmów). I ... O K!@#$ tylko 20% ja p!@@#$%. Zaczęło się. Kawa lub inne nośniki kofeiny, witaminy b12 i magnezu. Ciężka muzyka ewentualnie inne wyzwalacze adrenaliny. No i oczywiście ultra szybkie wertowanie snippetów oraz ociekających tłuszczem, fragmentów świetnie napisanej prozy Javowej. Skupiłem się na błędach z zadań oraz temu co przy 3 czytaniu mnie zaskakiwało. Notatki z tego czasu (niedziela wieczorem i w nocy) wystarczyły by do codziennego blogowania w 2010 :D Późne godziny nocne - testy, mocki, symulatory etc. Trochę snu. Zgodnie ze złotą zasadą iż, umysł jest najbardziej chłonny TUŻ PRZED EGZAMINEM sprawdzałem czym która metoda lubi sobie cisnąć, i jakie sformułowania wywołują grymasy kompilatora. Lektura mnie uśpiła ale udało się wchłonąć gorący lecz mały (by organizm nie tracił energii na trawienie) posiłek. Kofeina, batony czekoladowe, głębokie oddychanie (dla dotlenienie krwi), szybkie chodzenie (dla lepszego ukrwienia) i podnoszenie adrenaliny do ostatnich minut egzaminu rozważaniami nad tym jak powiedzieć szefowi, że się nie udało. I ... ... 96%!!! Układającym pytania udało się zatem znaleźć tylko 2 haki na mnie :) No nie-najgorzej :D Niestety, dzień po egzaminie, uświadomiłem sobie smutną sprawę. Mamy nową specyfikację Java EE, z nowymi ciekawymi egzaminami np egzamin z JSF. Egzaminy niestety jeszcze w przygotowaniu. Książek przygotowujących do nich nie ma i pewnie nie będzie szybko. Do tego jest ich teraz 5 a nie 3. Wygląda też na to, iż trzeba będzie zdawać nowe wersje, żeby uzyskać tytułu na poziomie master. No i mój harmonogram kolekcjonowania certyfikatów nieco się opóźnia :)

Jak pisać kod?

2010-01-17T12:48:00.004+01:00

Poszukiwałem informacji na temat tego jak należy tworzyć kod. Nie mogłem jakoś pogodzić ze sobą dwóch idei. Pierwsza sprowadza się do tworzenia prostych, rozwiązań bez jakichkolwiek upiększeń - czyli KISS oraz YAGNI. Druga, kładzie nacisk na tworzenie elastycznego kodu, łatwego do modyfikacji, rozszerzalnego akcentując różne zasady np DRY lub ich zestawy zasad np SOLID, GRASP. Nie można odmówić racji i jednemu i drugiemu podejściu. Lecz nie trudno zauważyć, iż dążenie do elastyczności, rozszerzalności itp może prowadzić do komplikacji kodu - czyli naruszenia YAGNI. Różni ludzie, z którymi zdarzyło mi się dyskutować, kładli nacisk albo na 1 albo na 2 podejście lub udzielali mi odpowiedzi 44. Dodatkowo dyskusje na ten temat, albo są teoretyczne, albo praktyczne z dokładnością do dobranych przykładów, albo dotyczą nieco wyższego poziomu abstrakcji - czyli projektowania. Nie mogłem jednym słowem znaleźć "mojej racji, która była by była najmojsza" ;) Ostatnio zacząłem czytać Implementation Patterns Kent'a Beck'a. W końcu doczekałem się swojego Aha! Ale nie przedstawię tu moich wniosków. Sięgnijcie do Kenta Becka - dokadniej do początkowych rozdziałów :)

Generowanie kodu brzydkim zapachem?

2010-01-17T12:13:00.005+01:00

Zdarzyło mi się napisać post o generowaniu kodu. Na c2.com znalazłem ciekawą dyskusję o tym, czy generowanie kodu jest oznaką kiepskiego rozwiązania: Code Generation Isa Design Smell. W ramach tego samego serwisu jeszcze How To Do Code Generation Well. IMHO ciekawe.

Manifest blogowania w języku polskim

2010-01-10T13:47:00.010+01:00

W społeczności blogów IT, zajmującej się językiem Java, widać tendencję do zmiany języka na angielski. Przykłady:

Paweł Stawicki, Java, the Programming, and Everything od wpisu English from now on,
Paweł Badeński, Pawel Badenski's IT Realms od wpisu Keywords vs API, continued,
Paweł Szulc, Whatever, we all gonna die anyway od wpisu svn merge -r:53:1

Nie mogę odmówić słuszności twierdzeniom:

chyba każdy programista Java, umie czytać w języku angielskim
większość, szukając rozwiązania używa Google i pisze słowa kluczowe w j.ang. nawet jeśli komunikat z błędem, problem jest ujęty w języku polskim
wypowiadając się w bardziej międzynarodowym gronie, lepiej jest wybrać język angielski
angielska terminologia dotycząca IT jest często czytelniejsza i bardziej zrozumiała niż w języku narodowym.

Jednak nie zamierzam przechodzić na język angielski. Nie będę w ten sposób protestować przeciwko pozbawianiu różnorodności, spłycaniu, pozbawianiu smaku i wrażliwości wielu obszarów związanych z kulturą i rozrywką, przez komercyjne produkty ze stanów i ich kopie. Mimo iż dostrzegam ten proces. To jednak nie ludzie z IT za to odpowiadają :)

Eric Raymond - zgadzam się, o ile dobrze rozumiem

Za migracje na angielski jest odpowiedzialny post na blogu Jeff'a Atwooda The Ugly American Programmer. Odniosę się, na początek, do obszernego cytatu z How To Become A Hacker (Eric Raymond, 2001, link nie działa oto kopia w archiwach Google). Being a native English-speaker does not guarantee that you have language skills good enough to function as a hacker. If your writing is semi-literate, ungrammatical, and riddled with misspellings, many hackers (including myself) will tend to ignore you. While sloppy writing does not invariably mean sloppy thinking, we've generally found the correlation to be strong — and we have no use for sloppy thinkers. If you can't yet write competently, learn to. Według mnie fragment, mówi iż, nie powinno się używać języka angielskiego niezgodnie z jego ortografią i gramatyką. Wcześniej Eric Raymond pisze, iż znajomość języka angielskiego jest wymagana do funkcjonowania w środowisku hakerskiem: As an American and native English-speaker myself, I have previously been reluctant to suggest this, lest it be taken as a sort of cultural imperialism. But several native speakers of other languages have urged me to point out that English is the working language of the hacker culture and the Internet, and that you will need to know it to function in the hacker community. W porządku. Posługiwanie się, językiem angielskim jest bardzo wskazane w projektach międzynarodowych: Linus Torvalds, a Finn, comments his code in English (it apparently never occurred to him to do otherwise). His fluency in English has been an important factor in his ability to recruit a worldwide community of developers for Linux. It's an example worth following. To bardzo dobry zwyczaj, by używać języka zrozumiałego dla postronnego słuchacza, nawet gdy się rozmawia z rodakiem: Back around 1991 I learned that many hackers who have English as a second language use it in technical discussions even when they share a birth tongue; it was reported to me at the time that English has a richer technical vocabulary than any other language and is therefore simply a better tool for the job. Wg. mnie przesłanie autora How To Become A Hacker brzmi: "Naucz się poprawnie posługiwać się językiem angielskim."

Jeff Atwood - nie zgadzam się

Nie zgadzam się z tezą, Jeff'a Atwooda w The Ugly American Programmer Advocating the adoption of English as the de-facto standard language of software development is simple pragmatism, the most virtuous of all hacker traits. If that makes me an ugly American programmer, so be it. Co oznacza przyjęcie języka angielskiego jako standardu w tworzeniu oprogramowania? Dla mnie oznacza to, zmuszenie do używania go. Wszędzie, gdzie mamy do czynienia z tworzeniem oprogramowania i komunikowania się na ten temat. Czy to znaczy, że mam przetłumaczyć moje posty na język angielski i jeśli już pisać, to w języku angielskim? Pal licho mój blog - są popularniejsze. Zresztą nie chodzi tylko o blogi. Co z grupami dyskusyjnymi, publikacjami akademickimi, książkami, czasopismami. Kończymy z tłumaczeniami? Zamykamy etap rozwoju języka polskiego w obszarze IT? Językiem wykładowców i studentów informatyki jest od dziś amerykański? Kolegów w pracy też mam po angielsku pytać o technologie, styl komentowania, co sądzą o danym rozwiązaniu projektowym?

Różnorodność, w tym języka, jest ważna

Literatura naukowa powstaje w różnych językach. Język, którym się posługujemy wpływa na nasz sposób opisywania, nazywania, wyodrębniania a zatem i postrzegania rzeczywistości. Więc niech będzie bogaty i różnorodny. Nie zamykajmy sobie kierunków rozwoju. Nie wybierajmy jednej właściwej słusznej drogi. I to tylko dlatego że popularnemu bloggerowi wydaje się, że ziemia jest płaska ;)

Automatyczne tłumaczenie

Myślę, że w miarę rozgarnięty użytkownik internetu użyje sobie narzędzia w stylu: Babelfish lub Google Translate. I uda mu się przetłumaczyć wypowiedzi na swój język. Będą niezgrabne ale kod zapewne da się przeczytać.

Jakość literatury

Techniczne słownictwo w języku angielskim jest zapewne najbogatsze. Czy to jednak oznacza, iż nie należy starać się wypracować dobrych odpowiedników i zaadoptować to co jest nie daje się dobrze przetłumaczyć? Jeśli się spojrzy na tłumaczenia niektórych książek na język polski (np. Wzorce projektowe), to sposób tłumaczenia terminologii programistycznej, nie zawsze zachwyca. Jednak chyba sytuacja się poprawia - np: Refaktoryzacja do wzorców. Jednak tłumaczenia nie będą zwiększały swojej jakości, dzięki temu, iż wszystko będzie napisane w języku angielskim. Łącznie z blogami. Zapewne grupa dyskusyjna pl.comp.tlumaczenia ma na to większy wpływ, ale wszystko się liczy.

Co pikantniejsze komentarze

Post Jeff'a Atwood'a doczekał się ogromnej liczby komentarzy. Większość w stylu "dobrze gada dać mu wódki". Ale są też nieco inne. Trochę ad personam, lecz wg. mnie trafny: My question is, if the world becomes a different place in the future, are you ok with someone telling you that functional Hindi is required in order to be a true hacker? Sam chciałem tak skomentować: But you completely missed the point. What I'm saying is that there is a LOT of non-english programming sites, but YOU don't read them, and you didn't post IN THEM such discussion, so you don't get their feedback. Naprawdę rozbrajający: I predict in 200-300 years software developers are required to learn a dead language (English) so that they can maintain the legacy systems that run our technology infrastructure.

Najważniejsze dla mnie

No właśnie. Dla mnie pisanie po polsku jest zgodne z ... byciem sobą, tym jak siebie postrzegam.

Wniosek

Obecnie poprzestaję na języku polskim. Niemniej będę w miarę możliwości śledził też polską myśl deweloperską "na obczyźnie" :) Nie można zaprzeczyć, iż stanie się ona częściej wygoogliwana. Postaram się również, zwrócić pilniejszą uwagę na język moich wypowiedzi. Na gramatykę, stylistykę i interpunkcję. Jeśli coś, gdzieś zrobię niezgodnie ze sztuką, proszę o informacje. Postaram się poprawić. Dziękuję AGS za zwrócenie mi na to uwagi.

Piotrze, zapoznaj się z tym!

2010-01-08T10:16:00.005+01:00

Te linki chcę mieć w jednym miejscu. Prowadzą one do informacji, które zamierzam w najbliższym czasie poznać, zrozumieć i przemyśleć. W przeciwieństwie do większości innych treści, które wystarczy pobieżnie przejrzeć lub co najwyżej raz przeczytać.

Martin Fowler: Articles
Object Mentor artykuły i nagrania audio i wideo
Principles of OOD - Robert Martin (Uncle Bob), oraz ciekawy zbiór odnośników o SOLID na blogu arek.borek
c2.com wiki, przeglądanie można zacząć np tu: DRY, KISS, Code Smell, Anti-Patterns - lista, Design Patterns - w podziale na kategorie, testing, YAGNI, OO Design Principles
Blog Misko Hevery - bardzo ciekawe koncepcje i słownictwo związane z tworzenie łatwego do testowania kodu
blog Kent'a Beck'a

Jeszcze 2 ciekawe prezentacje na InfoQ o projektowaniu. Kent Beck - Responsive Design, w którym Kent Beck porusza sporo kwestii m.in. rekomenduje 2 książki (Implementation patterns oraz Structured design), podaje ciekawą definicję projektowania oprogramowania, opisuje co różni jego decyzje projektowe od decyzji ludzi z którymi projektował i tworzył kod, systematyzuje różnice podając 4 wzorce czy raczej tendencje a dalej nie wiem bo padłem koło 2 w nocy :) What Drives Design?. Rebecca Wirtfs-Brock opowiada o *DD w tym ciekawie przedstawia na czym skupiają się poszczególne podejścia i jak to jest z ich łączeniem. Szerzej opisuje Responsibility Driven Design. I na koniec coś z czym kilka razy się spotkałem ale sceptycznie podchodziłem do tej teorii: model braci Dreyfus - poziomów umiejętności.

JRuby praktycznie

2010-01-05T21:56:00.003+01:00

Dzięki komentarzom do posta Dlaczego Ruby osoby ukrywającej się pod pseudonimem lopex (być może jeden z komiterów JRuby) dowiedziałem się, iż nowo powstające języki czy też, jak w tym przypadku, implementacje istniejącego od jakiegoś czasu języka - czyli JRuby są wykorzystywane w praktyce. Stosunkowo łatwo można wyszukać info o projektach, które wykorzystują JRuby czy nawet dzielą się swoimi doświadczeniami w używaniu tej implementacji. Nie było by to warte nowego posta gdyby nie 3 ciekawa strona. Mamy na niej długą listę obszarów w USA gdzie jest JRuby wykorzystywany, krótszą z różnymi krajami europejskimi a tu nagle ... POLSKA !!! Dacie wiarę :) Czujecie jak wasze uczucia patriotyczne zostały mile połechtane? Ba można by rzec iż wbrew silnym tendencjom na rynku by pozostawać przy starych sprawdzonych rozwiązaniach (np CVS, Ant, edytor tekstu zamiast IDE, itp) są projekty w których stosuje się innowacyjne podejścia. Mi się łezka zakręciła w oku nie tylko z powodu dumy narodowej i obserwacji dążenia do rozwoju technologicznego lecz ... ze względu na pewne przemyślenia natury ... hmmm ekonomicznej ... lub powiedzmy to w końcu wprost - marketingowej :)

Blog Miško Hevery - polecam

2010-01-04T13:02:00.005+01:00

Polecam blog pana Miško Hevery, dotyczący przede wszystkim tworzenia kodu łatwego do testowania (przynajmniej do drugiej połowy 2008 roku bo dotąd doczytałem). O blogu usłyszałem na prezentacji Pawła Szulca [1] [2] na konferencji java4people (Szczecin 2009). Wg. mnie warto zacząć od obejrzenie nagrania wideo Clean Code Talk - Unit Testing. A czemu akurat ten blog? Proste autor jest trenerem (czyli wie jak opowiadać) tworzenia testów i testowanego kodu w Google (czyli kwalifikacje odpowiednie ma). Większość osób pisząc o testach jednostkowych robi to mniej więcej tak. Pisanie testów jednostkowych jest piękne, łatwe i przyjemne. Każdy kto tego nie robi jest co najmniej dziwny. Kto choć hello world zrobił w junit (lub testng) nigdy nie będzie chciał zacząć implementacji nowych funkcji bez testu. Brzmi znajomo :) Możliwe nawet że tak faktycznie jest, jeśli tworzy się kod w ramach dobrze zaprojektowanego, dobrze zaimplementowanego, przetestowanego, udokumentowanego projektu bez presji terminów. Ciągle brzmi znajomo :P Miško Hevery bardzo realistycznie przedstawia w jak wielkiej d... jest deweloper który zaczyna pisać testy do własnego, nietrywialnego kodu bez przygotowania. Dlaczego? Bo każdy ma wrodzoną, często przez długi czas rozwijaną, umiejętność pisania trudnego do testowania kodu. I nie dosyć że, zapewne, nie zdaje sobie z tego sprawy to jeszcze nawet nie wie w czym tkwi problem. Trudne w testach jednostkowych nie jest samo pisanie testów, tylko tworzenie łatwego do przetestowania kodu. Sporo jest informacji o pisaniu zgodnie z prawem Demeter, wstrzykiwaniu zależności, rozdzielaniu konstrukcji obiektów od ich użycia. Zapewne każdy wie że wzorzec Singleton, stan globalny i metody statyczne to zło. Ale czy każdy wie dlaczego? A nawet jeśli zna krótką odpowiedź to czy zna uzasadnienie? A jeśli nawet wie to wszystko to czy wie kiedy te złe rzeczy powodują problemy a kiedy nie? Lektura naprawdę poszerza horyzonty. W każdym razie moje :)

Eclipse + Maven2 + TestNG + Cobertura

2010-01-03T23:47:00.008+01:00

Eclipse konfiguracja Maven2

W Eclipse wystarczy dodać plugin do obsługi Maven2 z update site http://beust.com/eclipse. Resztę narzędzi typu TestNG, Cobertura integruje się z Maven'em. Maven2 - podstawowe zmiany Ustawienie poziomu kompilacji na 1.6 w pom.xml:

<project>
  <!-- ... -->
  <build>
    <!-- ... -->
    <plugins>
          
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>

      <!-- ... -->
    </plugins>
  </build>
  <!-- ... -->
</project>

Lub jeszcze lepiej przez zdefiniowanie zmiennej (więcej o propertis):

<project>
  <!-- ... -->     
  <properties>
   <source-level>1.6</source-level>
  </properties>

  <!-- ... -->
  <build>
    <!-- ... -->
    <plugins>
      <!-- ... -->
    
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>${source-level}</source>
          <target>${source-level}</target>
        </configuration>
      </plugin>
  
      <!-- ... -->
    <plugins>  
    <!-- ... -->
  </build>    
<!-- ... -->
</project>

Ustawienie kodowania plików z zasobami na UTF-8 w pom.xml (na podstawie):

<project>
  <!-- ... -->
  <build>
    <!-- ... -->
    <plugins>
          
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <configuration>
          <encoding>UTF-8</encoding>
        </configuration>
      </plugin>

      <!-- ... -->
    </plugins>
  </build>
  <!-- ... -->
</project>

TestNG konfiguracja pod Maven2 Dodanie biblioteki TestNG do pom.xml:

</project>
  <!-- ... -->
  </dependencies>
  <!-- ... -->

     <dependency>
       <groupId>org.testng</groupId>
       <artifactId>testng</artifactId>
       <version>5.11</version>
       <scope>test</scope>
       <classifier>jdk15</classifier>
     </dependency>

    <!-- ... -->   
  </dependencies>
  <!-- ... --> 
</project>

Instalacja biblioteki TestNG w repo Mavena (sprawdzałem bez instalacji z poprzednimi wersjami też były problemy).

C:\Documents and Settings\piter>mvn install:install-file 
  -DgroupId=org.testng 
  -DartifactId=testng 
  -Dversion=5.11 
  -Dclassifier=jdk15 
  -Dpackaging=jar 
  -Dfile=LOKALIZACJA_TEST_NG\testng-5.11\testng-5.11-jdk15.jar

Wskazanie ścieżki do pliku konfiguracyjnego dla TestNG (testng.xml) w pom.xml (można dodać konwersję wyników do html):

<project>
  <!-- ... -->
  <build>
    <!-- ... -->
    <plugins>
          
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
          <suiteXmlFiles>
            <suiteXmlFile>${basedir}/src/test/resources/testng.xml</suiteXmlFile>
          </suiteXmlFiles>
        </configuration>
      </plugin>

      <!-- ... -->
    </plugins>
  </build>
  <!-- ... -->
</project>

Przykładowy plik konfiguracyjny dla TestNG:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
  
<suite name="suite-all" verbose="1" >

  <test name="TestClient" >
    <classes>
       <class name="com.blogspot.itresearches.moj.pakiet.TestClient" />
    </classes>
  </test>
 
  <test name="all-package">
    <packages>
      <package name="com.blogspot.itresearches.moj.pakiet" />
   </packages>
  </test>
</suite>

Więcej o konfiguracji TestNG oraz konfiguracji TestNG w Maven2. Uruchomienie:

mvn test

Cobertura konfiguracja pod Maven2 Modyfikacja w pom.xml (więcej o konfigu Cobertury w Maven):

</project>
  <!-- ... -->
  <reporting>
   <!-- ... -->
 
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>cobertura-maven-plugin</artifactId>
  <configuration>
         <outputDirectory>${basedir}/target/test-coverage-report</outputDirectory>
        </configuration>
      </plugin>
    </plugins>

    <!-- ... -->
  </reporting>   
  <!-- ... -->  
</project>

Uruchomienie:

mvn cobertura:cobertura

Dzięki zmianie ścieżki output nie trafia tam gdzie reszta danych przy generowaniu site tylko w target/test-coverage-report.

Pozostałe narzędzia do analizy kodu

Jeszcze się nie bawiłem, ale pewnie warto sprawdzić: Findbugs, PMD, Checkstyle, JDepend.

Prawo Demeter na polskiej Wiki

2010-01-03T00:16:00.006+01:00

Pomyślałem a co anglojęzyczni mają być lepsi? No i tak oto dorzuciłem kolejną cegiełkę do budowy świata - czyli wpis na polskiej Wikipedi o prawie Demeter. Przy okazji natrafiłem na ujmujące tłumaczenie Law of Demeter na digipedia: prawo Demetera. Prawda że ujmujące :)

Rozwiązania quick and dirty ... do właściwych problemów

2010-01-01T21:03:00.004+01:00

I znowu odpowiedź na komentarz tym razem właściciela filmy Bottega Pracownia IT. Co mam na myśli mówiąc język do rozwiązań quick and dirty? Mam na myśli język w którym zamierzam automatyzować czynności, które zdarza mi się wykonywać więcej niż 2 - 3 razy. Czasem jest to czynność którą wykonujemy raz lecz składa się ona z 400 podobnych ruchów :) Przykłady? Weźmy dla przykładu prostą operację. Tworzymy sobie system. Wszystko jest fajnie i zabawnie. Dodajemy funkcjonalności. Testujemy je dodając testowe dane. Wszystko bryka pięknie. Ale załóżmy, że tworzymy jakieś raporty z ciekawymi diagramami pokazującymi dynamikę zmian zróżnicowanie sprzedaży produktów z podziałem na kategorie cenowe i jakieś tam inne na przestrzeni pewnego czasu. No nie głupio by było wklepać powiedzmy 12 (liczba miesięcy w badanym okresie rozliczeniowym) * 2 (dynamika czyli porównujemy dane z 2 kolejnych lat) * 5 (kategorie produktów) * 3 (kategorie cenowe) * 1 + random(10) (aby pojawiły się sumy a nie pojedyncze wartości sprzedaży) czyli od 360 do 3600 ... np wpisów bazodanowych. Jeśli jeszcze damy odważne założenie że w systemie jest więcej niż jedna tabela powiązana jakimiś konstraintami to wygląda, że do zobaczenia tych wykresów w aplikacji trzeba by tak na miesiąc zatrudnić kilku bardzo-szybko-nap!@#$cych-w-klawiaturę-gości lub uzyskać dane od klienta :) Zapewne problem ten dało by się jakoś chytrze rozwiązać (usunąć konstrainty, wbić dane w pętlach korzystając z zapewne już zaimplementowanej funkcjonalności zapisywania danych w systemie, itp). Ale proszę się nie czepiać wymyśliłem przykład na poczekaniu. Więc dosyć dobrym rozwiązaniem było by na poczekaniu strzelić jakiś mały program, który wygenerował by nam takie dane o pożądanych właściwościach. Ba może spodobały by nam się coś tam jeszcze zmienić w tych danych, żeby zobaczyć specyficzne zachowanie np brak prezentacji danych których wartość sprzedaży nie przekracza jakiegoś progu itp. No i fajnie by było, gdyby jednak nie trzeba było armi klepaczy ponownie zatrudniać do każdego wariantu :) Do tego typu problemów język Java nie nadaje się najlepiej. Za dużo trzeba się opisać, ale nie tylko. Wiele cech mainstreamowych języków wykorzystywanych do tworzenia softu jest tak skonstruowanych aby bronić programisty przed zrobieniem sobie kuku (zasada iż lepiej zgłosić błąd na poziomie kompilacji a nie w czasie uruchamiania itp). Dodatkowo zapewniają mechanizmy typu bezpieczeństwo, przenośność, czytelność itp itd. które nie są z punktu widzenia rozważanej klasy problemów istotne. Ale przecież my tu potrzebujemy prostego skryptu który uruchomimy tylko raz! Więc nie potrzebujemy tego. Więc załóżmy, iż nie wiemy nic o wyłączaniu konstraintów a dane nie pochodzą z naszego systemu i nie ma możliwości ich zapisania. Jakie cechy zatem powinien posiadać język w którym napiszemy nasz program generujący dane:

zwięzły - więc niech ma te wszystkie sprytne metody machania listami, hash, string'ami, fajne operatory umożliwiające pominięcie kilku warunków i pętli, zapamiętywanie wyników przeprowadzonych operacji, itd
dynamicznie typowany - czasem do pi chcę sobie przypisać 3,14 a czasem "Produkcja Internetowa" a czasem new ProductInfo(Info.SPAM, new Product("egg"))
interpretowany - nie potrzebuję kompilacji
prosta, intuicyjna składnia
łatwy w nauce

oraz a może raczej przede wszystkim solidna (prosta, łatwa w użyciu, wymagająca małej ilości kodu) obsługa takich zagadnień:

wyrażenie regularne
operacje na napisach
tworzenie, usuwanie, kopiowanie, edycja plików tekstowych i katalogów
obsługa sieci ale nie jakieś generowanie HTML czy tworzenie serwera do obsługi komunikacji na wskazanym porcie lecz wczytywanie zawartości i nagłówków stron HTML czyli wygodna obsługa HTTP
łatwe uruchamianie innych programów

Być może jeszcze dobrze by było mieć możliwość podpięcia się do popularnych (dowolnej) baz danych, obsługa FTP i XML, kompresja ale to już trochę przesadzam. W takim języku proste powtarzalne problemy się łatwo wykonuje. Alternatywa to opanować do perfekcji inne narzędzia np menadżer plików, program archiwizujący, przeglądarka WWW, programistyczne edytory tekstu, wyszukiwarkę systemową, komendy linii poleceń OS. Wbrew pozorom takie problemy pojawiają się dosyć często. Może to być, np generowanie jakichś xml, czy dodanie do naszego ulubionego ORM'a funkcji generującej dodatkowe artefakty bo tak wg. nas powinno to wyglądać. Inna sprawa iż zwykle pojawiają się nie w ramach programowania. Głównym narzędziem programisty jest język programowania który dzięki np OOP pozwala przy mniejszym lub większym nakładzie pracy osiągnąć DRY. Ale nie w każdym języku da się to osiągnąć. Np dosyć często kuleje pod tym względem SQL. Raczej jest do zmora testerów, wdrożeniowców, administratorów, tzw computer power users itd. Niemniej czasem przytrafia się też ludziom, którzy poza tworzeniem kodu są też odpowiedzialni za jego działanie i jakość a czasem po prostu programistom. Fakt, definicja quick-and-dirty podawana przez wiki: crude solution or programming implementation that is imperfect, inelegant, or otherwise inadequate, but which solves or masks the problem at hand, and is generally faster and easier to put in place than a proper solution Rozwiązania każdego typu problemów w ten sposób to zaciąganie kredytu - ktoś będzie musiał za to zapłacić i to z odsetkami. Idea rozwiązania tymczasowego jest taka, iż łata ono dziurę ale w tym miejscu gdzie widać. Prędzej czy później ktoś jednak spojrzy też na te miejsca gdzie jednak tymczasowe rozwiązanie nie zakrywa dziury. I zwykle stanie się to podczas prezentacji u klienta. Jednak szybkie rozwiązanie jest dokładnie tym czego potrzebujemy, gdy chcemy wygenerować jakieś dane. W końcu nie ma sensu do każdego problemu pisać fajnego frameworku, który rozwiązuje problem elegancko i pozwala jeszcze dodać interfejs w kilku językach :) Nie twierdzę też, że język który nadaje się do pisania szybkich programików automatyzujących nie pozwala na czytelnie lub wręcz eleganckie tworzenie kodu. Mi konstrukcje z Ruby wydaję się bardzo potężne i jasne zarazem.

Dlaczego Ruby?

2010-01-01T16:03:00.004+01:00

Skoro najbardziej znany blogger polskiej sceny Java'owej zadał mi pytanie w komentarzu do posta o instalacji Ruby warto by na nie udzielić odpowiedzi. Ni z gruszki, ni z pietruszki pojawia się wpis o Ruby?! I jak tu człowiek ma się rozeznać, po co mu to? Według mnie Ruby ma kilka ciekawych cech:

Nadaje się do tworzenia programów typu quick and dirty (nie będzie mu łatwo się przebić, gdyż opanowałem Notepad++, Excel i kilka innych narzędzi ułatwiających automatyzację powtarzalnych czynności dosyć dobrze)
Jest wykorzystywany w grach jako język osadzony - chyba bardziej popularna jest Lua ale jeśli Lua to pewnie skończył bym grając w WoW ... tego kierunku chciałbym uniknąć
Ruby on Rails - chyba warto poznać u źródeł ideę jedno-kliknięciowego tworzenia przeglądarek do bazy danych
Jest m.in. językiem funkcyjnym więc rozwinę mój warsztat o nowe idee, pomysły, techniki
Filozofia tworzenia kodu: krótko za pomocą potężnych konstrukcji ale w miarę możliwości czytelnie. W Perl'u poza zwięzłością zapisu ceniona jest oryginalność¹ co jest mocno skorelowane z nieczytelnością. W Python'e zaś chyba za bardzo skupiono się na przejrzystości kodu². To ważna lecz drugorzędna cecha języka do zastosowań quick and dirty.
W Ruby dosyć łatwo tworzy się DSL.

Wszystkie te przymioty przekonują mnie, iż w Ruby może być dla mnie przydatny w praktyce i dać mi możliwość poszerzyć moje horyzonty w IT. Ale może lepiej zobaczyć jak wygląda opinia o Rubym przedstawiana przez firmę ThoughtWorks, która miała z nim sporo doświadczeń. Sądziłbym, że z jruby będzie Ci łatwiej i bliżej, a tu czyste Ruby. Nie wybrałem jruby czy innych takich wynalazków biegających pod JVM ponieważ obecnie nikt tego nie używa w praktyce. Poza oczywiście twórcami blogów, prelegentami konferencji, autorami samej technologii oraz grupą zapaleńców piszących kod do szuflady (czy tam do własnego dysku twardego) ... oraz ludźmi którzy faktycznie piszą w nich oprogramowanie i to zupełnie na poważnie :D

UPDATE 5 stycznia 2010 !!! Istnieją projekty wykorzystujące tak niepochlebnie opisywane przeze mnie języki J*. W poprzedniej wersji tego posta krzywdząco wypowiedziałem się, jakbym soft w JRuby pisany był do dysku twardego. Przepraszam wszelkie osoby, które poczuły się przez to sformułowanie obrażone lub wprowadzone w błąd. Dziękuję osobie ukrywającej się pod pseudonimem lopex za wyprowadzenie mnie z błędu :) END OF UPDATE 5 styczna 2010

I co ważniejsze: nie ma nic wspólnego z Java. A to spora zaleta jeśli się człowiek przez 8+ h namorduje z czymś to potrzebuje odmiany. Na zakończenie argument za językami J*. Wg. mnie zastosowanie wielu języków programowania, kompilowanych do wspólnej postaci niskopoziomowej to przyszłość tworzenia softu. Zresztą przejawia się to nie tylko w tym, iż istnieje wiele języków które działają na JVM czy na .NET Framework to tylko jeden przejaw tego trendu. Inny to tworzenie DSL, language oriented programming. Zresztą powstają już narzędzia do tego np MPS.

¹ Oryginalność nie wynika dosłownie z filozofi Perla. Ale zwróćmy uwagę na oficjalnie akceptowany przez użytkowników Perl'a koncepcję Tim Toady. Dodajmy do tego jeszcze żart mówiący o tym jak powstała składnia języka: kot Larrego Wall'a przeszedł się po klawiaturze. Coś tam na ekranie się pojawiły jakieś dziwne znaczki i ciągi znaków. Larry: nie wiem co to jest ale fajnie by było gdyby dało się zrobić język programowania w którym miało by to sens. W Perlu trochę programowałem i rozmawiałem z fanami tego języka. ² Kilka osób, które zna Pythona i stosuje chwali sobie ten język. jednak mnie odrzuca pomysł stosowania wcięć do określenia bloków, granic funkcji itp dla programów quick and dirty. Chociaż w innych zastosowaniach czemu nie.

Jak być programistą dobrym a może lepszym?

2009-12-31T15:16:00.005+01:00

Swego czasu podpytywałem, nieśmiało, ludzi tworzących soft jaki powinien być dobry programista: [1], [2]. To było ciekawe doświadczenie. Jeszcze ciekawszym pytaniem na jakie chciałem znaleźć odpowiedź to, co robić aby być lepszym programistą. Można znaleźć sporo postów na ten temat na blogu Jeff'a Atwooda. Na przykład How To Become a Better Programmer by Not Programming traktuje wprawdzie na nieco inny temat, ale komentarze do niego są naprawdę niezłe. Drugie dobre źródło ciekawych wypowiedzi to Stackoverflow. W szczególności spodobały mi się odpowiedzi do pytaniaRoadmap to a better programmer. W serwisie The Server Side spotkałem się z 2 ciekawymi pozycjami:

TSS.NET asks: What makes a "good" software developer?

Damien Katz asks: Are you a bad programmer?

Pierwszy nawiązuje do wspomnianego posta J. Atwooda. Drugi odnosi się do artykułu Signs You're a Crappy Programmer (and don't know it) Damien'a Katza. No koniec pisania drętwych postów w tym roku: Wszystkiego dobrego w 2010 :) PS Cytowany w TSS oraz CodingHorror, wywiad z Bill'em Gates'en znalazłem w Dr. Dobbs Journal.

Ruby - quick & dirty - linki

2009-12-28T13:08:00.003+01:00

Wygrzebane linki dot. korzystania z Ruby w kontekście szybkiego i niekoniecznie eleganckiego rozwiązywania problemów. Najlepsze źródła:

Programming Ruby - The Pragmatic Programmer's Guide online 1 wydanie książki, b. dobry indeks w lewym dolnym rogu
Ruby Documentation 1.9 opis całego API

Miejsca w RDoc przydatne do Quick & Dirty

wyrażenia regularne: Regexp i MatchData
napisy, tablice, hash
pobieranie przez sieć OpenURI
operacje na systemie plików: File, Dir
kompresja: GzipReader, GzipWriter

Tutoriale:

http://ruby-doc.org/docs/ linki do tutoriali
Tutorial na Learning Ruby tutorial, sporo przykładów
Ruby Basic Tutorial wygooglany, z tego się uczyłem

Ruby - clousure, proc, lambda, block

2009-12-27T23:18:00.006+01:00

Domknięcie to tajemnicza czarna magia, której ujarzmieniem szczycą się języki funkcyjne, języki skryptowe (typu Python, Ruby), różne języki biegające po JVM (Clojure, Scala, Groovy). Próbowałem wzbogacić swój warsztat o tę technikę przy okazji nauki Erlang'a a jeszcze wcześniej Lisp'a. W końcu udało się ale w Ruby 1.9 ... A wszystko dlatego, że słabo mi idzie nauka do SCJP :) Do rzeczy póki, jeszcze pamiętam o co w tym chodzi:

Bloki i iteratory w Ruby

Iteratory i bloki w Ruby pozwalają na łatwe przechodzenie po tablicy i wykonywanie jakichś operacji na jej elementach. Tablicę w Ruby

tab = ["first", "second", "third"]

można wyświetlić klasycznie w pętli:

for i in 0...tab.length
   puts tab[i];
end

lub krótko:

print tab

Można też użyć do tego iteratora each, do którego przekazujemy blok

tab.each do |elem|
   puts elem;
end

Generalnie blok można przekazać nie tylko do iteratora ale również do dowolnej funkcji poprzez umieszczenie za jej wywołaniem tego bloku:

#definiujemy funkcje
def my_fun()
   puts "In function"
end

# wywolujemy ja przekazujac jej blok
my_fun() do
   puts "In block passed to function"
end

Wynik działania programu

In function

wskazuje, iż mimo przekazania do funkcji myFun bloku nie została wykonana instrukcja zawarta w bloku. Aby blok, przekazany do metody, został wykonany w niej, należy wywołać metodę yield.

#definiujemy funkcje
def my_fun()
   yield
   puts "In function"
   yield
end

# wywolujemy ja przekazujac jej blok
my_fun() do
   puts "In block passed to function"
end

Wynik działania programu mówi sam za siebie:

In block passed to function
In function
In block passed to function

Blok może posiadać argumenty, których wartości określamy wywołując go w yield:

#definiujemy funkcje
def my_fun()
   yield "BEFORE" 
   puts "In function"
   yield "AFTER"
end

# wywolujemy ja przekazujac jej blok
my_fun() do |a|
   puts "In block passed to function " << a
end

Co powoduje pokazanie się na konsoli:

In block passed to function BEFORE
In function
In block passed to function AFTER

Dodatkowo z bloku przekazanego do funkcji mozna zwracać wartości podobnie jak w zwykłych funkcjach. Można by zatem stwierdzić, iż blok jest takim dziwnym tworem przypominającym funkcję. Z tym, że nie ma nazwy, co skutkuje specyficznym sposobem "deklarowania" parametrów w bloku i niezwykłym mechanizmem jego przekazania i wywoływania z poziomu innej funkcji. Bardziej formalnie: jest to grupa instrukcji, którą wiążemy z wywołaniem danej funkcji. W ramach tej funkcji, można wspomnianą grupę instrukcji wykonać przez wywołanie yield. Iterator natomiast jest funkcją, która przechodzi po elementach kolekcji (niesamowite nieprawdaż) i wywołuje w określony sposób przekazany jej blok. Poza ciekawą składnią nic niezwykłego.

Proc.new

Bloku nie można bezpośrednio zapamiętać w zmiennej i sobie go uruchomić byle gdzie. (Trzeba go zdefiniować przy wywołaniu jakiejś funkcji a funkcja musi wiedzieć, że ma go uruchomić.) Można jednak blok skonwertować do obiektu Proc. Wówczas możemy go zapamiętać w zmiennej:

rememberedBlock = Proc.new do
   answer_to_life_the_universe_and_everything = 42
   puts answer_to_life_the_universe_and_everything
end

a następnie wywołać w stosownym momencie:

rememberedBlock.call()

Blok skonwertowany do obiektu Proc można przekazać jako argument funkcji

def funExecProc(the_proc)
   puts "fun in here"
   the_proc.call();
end

myProc = Proc.new do puts "in block" end;

funExecProc(myProc);

Można również zwrócić go jako wynik funkcji:

def get_fun_add()
   newFun = Proc.new do |n| n + 3 end
   return newFun;
end

# utworz funkcje
my_fun = get_fun_add();

# wywolanie
puts my_fun.call(1);

clousure (domknięcie)

Ciekawe w tym jest to, iż w momencie konwersji bloku do obiektu Proc następuje zapamiętanie stanu środowiska w jakim ono było w trakcie konwersji. Zobaczmy to na przykładzie. Oto funkcja, która inne funkcje (bloki konwertowane na Proc) dodające pewną wartość do argumentu:

def make_fun_add(how_much)
   # nowa funkcja, ktora dla argumentu n zwraca
   # ten argument zwiekszony o wartosc how_much
   newFun = Proc.new do |n| n + how_much end
   return newFun;
end

# utworz funkcje w ktorej how_much = 3
add3 = make_fun_add(3)
# utworz funkcje w ktorej how_much = 5
add5 = make_fun_add(5)

# kilka wywolan
puts add3.call(1)

puts add5.call(5)
puts add5.call(10)

Funkcja make_fun_add zwraca nowo utworzoną funkcję newFun. Zobaczmy, iż w momencie wywołania add3 = make_fun_add(3) zmienna how_much w funkcji make_fun_add przybrała wartość 3. Ta wartość jest zapamiętana, dzięki czemu wywołania funkcji add3 powodują dodanie 3 do argumentu. Bardziej formalnie: dla Proc add3 zmienna how_much została powiązana z wartością 3. Podobnie została zapamiętana wartość 5 przy wywołaniu add5 = make_fun_add(5). Wartości jakie zostały przypisane do zmiennych, można odczytać za pomocą metody eval przekazując jej nazwę parametru oraz obiekt reprezentujący powiązania zwracany przez binding:

def make_fun(arg)
   return Proc.new do end
end

fun1 = make_fun(12);
fun2 = make_fun("foo");

puts eval("arg", fun1.binding); # 12
puts eval("arg", fun2.binding); # foo

No i w końcu dochodzimy do sedna sprawy. Blok skonwertowany na obiekt Proc, w którym zapamiętano stan środowiska w momencie definiowania tego bloku jest nazywany domknięciem (ang. clousure). Warto dodać, iż funkcja, która przyjmuje jako argument lub zwraca inną funkcję nazywana jest funkcją wyższego rzędu Tyle w kwestii definicji.

lambda vs proc

Istnieje jeszcze jeden nie tak znowu drobny szczegół. Załóżmy, iż mamy funkcję generującą Proc, który wyświetla argumenty. Można to zrobić za pomocą Proc.new podobnie jak w przykładzie z dodawaniem, lecz można zamiast tego użyć funkcji lambda lub funkcji proc. Zobaczmy

def make_fun_show_new()
   return Proc.new do |n, m| print n, " ", m, "\n" end;
end

def make_fun_show_lambda()
   return lambda do |n, m| print n, " ", m, "\n" end;
end

def make_fun_show_proc()
   return proc do |n, m| print n, " ", m, "\n" end;
end

pn = make_fun_show_new();
pl = make_fun_show_lambda();
pp = make_fun_show_proc();

pl.call(2,3);
pn.call(2,3);
pp.call(2,3);

Wyniki wywołania

2 3
2 3
2 3

funkcji zdefiniowanych za pomocą Proc.new, proc i lambda niczym się nie różnią ... dla prawidłowej liczby argumentów. Zobaczmy jednak co się stanie, gdy spróbujemy przekazać za mało lub za dużo argumentów. Dla Proc.new i proc:

puts "Dla Proc.new do end"
pn.call(10);
pn.call(1,2,3);

puts "Dla proc do end"
pp.call(10);
pp.call(1,2,3);

dostajemy:

Dla Proc.new do end
10
1 2
Dla proc do end
10
1 2

Natomiast dla funkcji zdefiniowanej przez lambda do end próba wywołania z mniejszą liczbą argumentów:

puts pl.call(10);

kończy się błędem:

wrong number of arguments (1 for 2) (ArgumentError)

dal odmiany zaś, próba wywołania z większą

puts pl.call(1,2,3);

zaskakuje nas tak:

wrong number of arguments (3 for 2) (ArgumentError)

Jak widać Proc utworzony za pomocą Proc.new oraz proc zachowuje się identycznie i umie sobie radzić z błędną liczbą argumentów. Natomiast Proc utworzony za pomocą lambda jest mniej ogarnięty i w razie problemów poddaje się.

lambda?

O tym czy Proc do którego odnosi się zmienna jest typu lambda czy typu proc można stwierdzić za pomocą metody lambda? Wywołanie

print "Proc.new is lambda ", pn.lambda?, "\n"
print "proc     is lambda ", pp.lambda?, "\n"
print "lambda   is lambda ", pl.lambda?, "\n"

pokazuje na konsoli:

Proc.new is lambda false
proc     is lambda false
lambda   is lambda true

arity

Skoro bloki opakowane w obiekty Proc za pomocą lambda są tak wrażliwe na ilość argumentów nie od rzeczy było by odpytać się obiekt Proc'a o to ile argumentów by sobie, życzył:

proc0 = Proc.new do || end
puts proc0.arity # 0

proc1 = Proc.new do |x| puts x end
puts proc1.arity # 1

proc2 = Proc.new do |x,y| puts x + y end
puts proc2.arity # 2

Niestety w mniej trywialnych przypadkach funkcja arity może zwrócić wartości ujemne.

Powrót do teraźniejszości

Miałem zamiar rozgryźć i opisać funkcję curring oraz popełnić niezwykle popisowy, wycierający podłogę czytelnikami, kopiący po jajkach i w ogóle przykład z generowaniem Proc reprezentującego jednomian ... ale chyba lepsze do tego jest programowanie obiektowe ... zresztą trzeba wracać do SCJP :(