Save and restore session of the Gnome Terminal

INFO: Unfortunately „–save-config” option is no longer supported in the new versions of gnome-terminal so this script will not work.

I use terminal quite often in my work. I have a specific way how I work with terminal. I usually have about 10 tabs open in different directories so I can quickly switch between them. I felt quite frustrated when I was in the middle of something, but I had to reboot the PC for some reason. It is because it means I would need to set-up my perfect multi-tab terminal from scratch.
Fortunately I found very easy solution for this issue. This article describes easy way to save and restore the terminal session.
Czytaj dalej

A bit about Java code conventions

Most commonly used set of Java coding conventions comes from Sun Microsystems and it is still available on Oracle website. The document describes many important aspects of formatting, naming conventions etc for Java.
However, for most of the teams it is not enough for two major reasons. First of all, the document has become quite outdated in some cases as it is has been created back in 1999. Things like maximum of 80 characters per line, when most of us use full HD monitors, does not seem right. The other reason is that Sun’s code conventions still leaves a lot of freedom and it is easier to maintain and read the code written in the similar fashion. This is why many teams decide to create additional code conventions on top of the Sun’s document adding more specific things.
In this post I am discussing two of the Java code conventions which are not part of the mentioned official Java code convention, but which are often added on top of it. These two are: keep all variables in the code as „final” and using „this” for every field and method access in class.
Czytaj dalej

ScalaTest with Maven

With multiple languages working on the same JVM now, it is possible (and easy) to use different languages for your production and test code.
Why not to take this opportunity when it can be easier and faster to write test code. This can be also a good way to learn a new language. You can keep your production code using the language you are the most comfortable with and write your tests in Scala or Groovy.

This post describes how to configure Maven project to use Java as a production code language and Scala with a ScalaTest framework for unit tests.
Czytaj dalej

Eclipse Juno toolbar problems

I have moved lately with my IDE to the newest Juno Eclipse. I do not want to write much about the whole default UI appearance in new Eclipse because enough has been written already probably. The first thing to do on new Eclipse is to change theme of Eclipse to Classic one and restart it. Then it starts to be usable and look quite good. However I still had one problem because of using Eclipse on a small notebook display.

Issue looks like this:

There is a huge waste of space in the main toolbar.
Fortunately I have found this post.

If you do not use main toolbar in Eclipse you can do the following:

1. Go to Help > Welcome

2. Go to Window > Show Toolbar which will magically appear there now

Unfortunately I could not find a way to keep the toolbar and remove wasted space. If you try to restore the toolbar, wasted space disappears but it will return if you restart Eclipse.

EasyMock dla nieznanych parametrów – matchers

W poprzednim poście pokrótce opisałem sposób działania EasyMock. W tym poście chciałbym skupić się na jednej z możliwości tej biblioteki.
Podczas testowania zdarzają się przypadki kiedy wiemy, że dana metoda obiektu zostanie wywołana i jaki wynik powinna zwrócić dla naszych testów, ale nie chcemy (albo nie jesteśmy w stanie) dokładnie analizować jakie parametry wywołania otrzyma. W takim właśnie przypadku możemy użyć matcher’ów EasyMock’a.

Wiedząc, że na mock’owanym obiekcie zostanie wywołana metoda xyz(String,int,long), równocześnie nie znając dokładnych wartości parametrów możemy przygotować mock na przyjęcie różnych parametrów.

W podanym przykładzie wywołanie na obiekcie „object” metody „xyz” spowoduje zwrócenie obiektu „knownObject” niezależnie od podanych do metody parametrów.

Ważne jest, że jeśli używamy matchera na chociaż jednym z parametrów to musimy użyć go na każdym z parametrów. Jeśli jednak chcemy żeby mock działał tylko dla dokładnie określonego parametru możemy zastosować matcher same(Object value) lub eq(Object value) jeżeli obiekt w parametrze ma być równy temu w matcher’ze.

Użycie matcherów może być szczególnie przydatne podczas testowania kodu używającego singletonów lub metod statycznych.

Pomijam poprawność tak skonstruowanego kodu. Należy wziąć pod uwagę, że często przychodzi nam testować kod różnej jakości, który nie zawsze można łatwo przepisać.

Metody listen(Formatter) nie dałoby się przetestować z użyciem EasyMock, gdyby nie matchery. Metoda listen(Formatter) powinna zwrócić swój nagłówek połączony z otrzymaną treścią wiadomości sformatowaną przez podany formatter. Formatter możemy zmockować, ale nie wiemy co zwróci DataResource.getMessage(). Test ma testować metodę listen(Formatter) nie powinien więc zwracać uwagi na to co będzie wynikiem DataResource.getMessage().

Tym sposobem formatter zawsze zwróci nam tą samą wartość niezależnie od otrzymanego od DataResource wyniku.

W EasyMock istnieje więcej matcher’ów. Ich listę można znaleźć w dokumentacji EasyMock.

EasyMock – łatwy sposób na testy jednostkowe

EasyMock to biblioteka języka Java, która umożliwia tworzenie obiektów w locie i wykorzystywanie ich jako mock’ów (imitacji prawdziwych obiektów). Dzięki tej możliwości testowanie jednostkowe może być o wiele prostsze, ponieważ możemy zastąpić prawdziwe, często ciężkie obiekty przez mock’i. Dodatkowo pozwala nam się to skupić na testowaniu jednej klasy podczas gdy zachowanie obiektów innych klas możemy dokładnie zaplanować.

Przykładowo mając klasę:

Chcąc przetestować działanie metody start() trzeba zapewnić silnik i komputer pokładowy dla samochodu. Metoda start() ma zlecić komputerowi sprawdzenie stanu systemów i jeśli wszystko jest w porządku odpalić silnik. Jeśli komputer pokaże, że któryś z systemów jest niesprawny, musi pobrać od niego listę problemów.
Chcąc skupić się na testowaniu samego samochodu, trzeba być pewnym w jaki sposób zachowa się w danej sytuacji obiekt komputera pokładowego i silnika. Te obiekty można więc mockować z użyciem EasyMock.

Klasa testowa będzie wyglądać następująco:

Pokazane testy sprawdzą nie tylko wynik zwrócony przez metodę start, ale także czy zostały wywołane odpowiednie metody w innych klasach.

Jak widać, użycie EasyMock wiele ułatwia. To może być szczególnie przydatne kiedy konieczne jest testowanie zachowania metod, a nie tylko do zwracanego wyniku.

Przestawiony przykład to tylko drobny pokaz możliwości EasyMock. Po więcej informacji odsyłam do bardzo dobrej dokumentacji dostępnej na oficjalnej stronie EasyMock

Zasady zdawania egzaminu na Sun Certified Java Programmer

Egzamin certyfikujący Sun Certified Java Programmer to potwierdzenie wysokich umiejętności i profesjonalizmu w programowaniu w języku Java.

Egzamin można zdać w jednym z centrów certyfikacyjnych, których lista jest dostępna na stronie firmy Prometric.

Aby zdać egzamin należy odpowiedzieć prawidłowo na przynajmniej 35 z 60 pytań wielokrotnego wyboru. Na rozwiązanie testu mamy 180 minut.

Zakres materiału egzaminacyjnego został podzielony na 7 części:

  1. Deklaracje
  2. Kontrola sterowania
  3. API
  4. Wątki
  5. Obiektowość
  6. Kolekcje i typy generyczne
  7. Podstawy

Web developement – alternatywa dla PHP

Jeśli chodzi o programowanie aplikacji internetowych to nie jest tajemnicą, że niepodzielnie żądzi tu nieśmiertelny język PHP obecny aktualnie w wersji 5. Niestety prawdą jest też, że w wielu aspektach jest to język przestarzały i nieprofesjonalny. Taki stan rzeczy zmieniają nieco frameworki takie jak Symfony, CodeIgniter czy wreszcie Zend Framework tworzony przez tą samą firmę która zajmuje sie rozwojem samego PHP. Mimo wszystko, po dłuższym używaniu PHP i spróbowaniu nieco (Symfony, CodeIgniter), lub nieco bardziej (ZF) frameworków do niego oceniam, że jest to język któremu daleko do uporządkowania i profesjonalizmu znanego z języków wysokiego poziomu używanych do pisania aplikacji desktopowych (Java, C++). Dlatego też zdecydowałem się na poszukiwania jakiejś alternatywy dla tego języka, a jest ich kilka i wcale nie łatwo zdecydować, który jest najlepszy.

ASP.NET

W tym języku miałem okazję pisać kilka małych aplikacji przez ostatni semestr na mojej uczelni. Wsparcie tak potężnej korporacji jak Microsoft na pewno jest sporym atutem tego języka. Co więcej, rozglądając się po rynku pracy, można zauważyć, że programiści ASP.NET nie będą mieli problemów ze znalezieniem pracy. I co… i tyle… nic więcej. Serwery pod ASP.NET muszą stać na Microsoft Server 2003/2008 co wiąże się ze sporymi kosztami. Ponadto używanie MVC w Zend Framework na tyle mi się spodobało, że nie chcę wracać do innego sposobu pisania kodu. Owszem istnieje wtyczka do .NET umożliwiająca tworzenie aplikacji w MVC jednak z moich wiadomości wynika, że póki co jest to proteza, a nie zintegrowane z główną linią narzędzie wspierane przez MS. Do minusów można doliczyć konfigurację serwera (może to tylko na studentlive.pl jest taka tragedia), konieczność używania MS Visual Studio, a także Windowsa (w chwili obecnej pracuje na Ubuntu).

Java (Spring, Hibernate, J2EE)

Java jest językiem szeroko używanym do pisania profesjonalnych serwisów WWW. Poważym atutem jest tutaj ogromne wsparcie zarówno ze strony producenta (SUN Mircosystems) jak i społeczności zgromadzonej wokół poszczególnych projektów.  Ponadto Java jest językiem uniwersalnym, a mnogość bibliotek i frameworków decyduje o łatwości i elastyczności tego języka. Programista Javy potrafiący używać Hibernate, J2EE czy Spring Framework nie będzie miał najmniejszych problemów ze znalezieniem pracy. Minusem używania Javy jest koszt hostingu, który może być nawet 10-krotnie wyższy niż w przypadku PHP. Więcej minusów nie znajduję :).

Ruby – Ruby On Rails

Osobiście nie znam tego języka, a więc opieram się na tym co wyczytałem w internecie podczas poszukiwania informacji.
Jest to framework do szybkiego tworzenia aplikacji oparty na języku Ruby. Oczywiście jest w pełni obiektowy, zoptymalizowany specjalnie pod pisanie aplikacji webowych, bazuje na modelu MVC. Spora społeczność zgromadzona wokół projektu, a także książki wydane na jego temat gwarantują, że znajdziemy rozwiązania problemów jeśli takie wystąpią. Jednym z dużych atutów wymienianych przez twórców jest bardzo prosta praca z technologią AJAX co brzmi bardzo zachęcająco. Jeśli chodzi o serwery dostępne w Polsce dla RoR to nie jest najgorzej hosting tych aplikacji pojawia się coraz częściej i nie jest obarczony dodatkowymi kosztami. Nie można również pominąć plusa jakim jest prostota pisania w języku jakim jest Ruby, w czym dodatkowo pomaga framework RoR oraz znakomicie przygotowane IDE. Minusem jest słabe zainteresowanie ze strony pracodawców osobami z umiejętnością pisania w RoR.

Python – Django Framework

Django to framework do tworzenia aplikacji webowych oparty na języku Python. Również w tym języku nie miałem wcześniej okazji programować.
Szukając informacji o Django natknąłem się na częste porówniania z RoR. Oba jezyki są rozwijane na zasadzie OpenSource, oba bazują na modelu MVC a ich głównym zadaniem jest maksymalne przyspieszenie pisania aplikacji stron internetowych. Django powstało później od RoR dlatego też społeczność tego projektu jest mniejsza, a książek na ten temat praktycznie nie ma. Liczne informacje można jednak znaleźć na stronie projektu łącznie z darmową książką. Co więcej porównując języki bazowe Ruby jest jedynie podstawą dla RoR, a sam jest raczej nie używany, natomiast Python jest językiem o dużej i ciągle rosnącej, w dużym tempie popularności. To samo można powiedzieć o zainteresowaniu pracodawców… jeżeli mówić o samym Django to jest ono znikome (powodem może być świeżość Django), natomiast Python jest uznany w środowisku, a jego programiści poszukiwani na rynku pracy. Porównania szybkości działania RoR oraz Django wypadają zdecydowanie na korzyść tego drugiego, podobnie jak ilość kodu potrzebnego do napisania aplikacji. Jedną z zachwalanych cech Django jest automatyczne tworzenie panelów administracyjnych dla aplikacji, co znacząco przyspiesza tworzenie całej aplikacji. Co więcej tworzenie bazy nie wymaga znajomości języka SQL, a jedynie kodowania w Pythonie. Porównując jednak trudność pisania w Django oraz RoR, ten drugi okazuje się być lepszym wyborem.

Podsumowanie

Zdaje sobie sprawę, że wybrane przeze mnie alternatywy to jedynie część z istniejących rozwiązań, a ich opisy nie są wyczerpujące. Pod uwagę wziąłem tylko kilka aspektów, które interesowały mnie podczas wyboru alternatywy wobec PHP.
Gdyby nie koszta wynajmu serwera pod aplikacje pisane w Javie wybór byłby banalny i w 100% postawiłbym na Javę oraz jej frameworki. Biorąc jednak pod uwagę ten czynnik, pozostaje mi Django oraz Ruby On Rails.

Największe plusy Django to:

  • oparte na Pythonie
  • automatyczne tworzenie panelu admina

Największe plusy RoR to:

  • bardzo dobre i rozbudowane IDE (Aptana, Netbeans)
  • proste wykorazystanie technologii AJAX