Miesięczne archiwum: Maj 2012

Porównanie algorytmów haszujących

Algorytmy haszujące mają bardzo wiele zastosowań. Jest ich jednak dość sporo, więc wybór tego optymalnego w danej sytuacji może być dość problematyczny. Z drugiej strony błędna decyzja może nas wiele kosztować w późniejszym czasie, kiedy wprowadzenie zmian jest o wiele kosztowniejsze. Dlatego też warto wspomóc się danymi zebranymi przez osoby, które zetknęły się z tym problemem przed nami. W tym miejscu można znaleźć dość obszerny „benchmark” najpopularniejszych algorytmów. Pod uwagę wzięte zostały m.in. szybkość działania, ilość kolizji, czy rozkład wartości wynikowych. Dodatkowo dane wejściowe podzielono na kilka kategorii. W teście brały udział:

  • DJB2
  • DJB2a
  • FNV-1
  • FNV-1a
  • SDBM
  • CRC32
  • Murmur2
  • SuperFastHash

Zapraszam do lektury.

Podświetlanie wystąpień w Eclipse IDE

Na pewno każdy, kto choć raz miał okazję korzystać z Eclipse IDE wie, że oferuje ono tzw. podświetlanie wystąpień. Zaznaczając np. nazwę zmiennej w jednym miejscu, wyróżnione są wszystkie jej wystąpienia w danym pliku. Ostatnio jednak natknąłem się na opis bardziej interesujących możliwości tego modułu. Zapraszam do lektury.

Czytaj dalej

Awaitility – łatwiejsze testy asynchronicznego kodu?

Niedawno opisywałem testowanie asynchronicznego kodu przy wykorzystaniu Mockito. Jeden z naszych Czytelników zwrócił jednak uwagę na to, że istnieją gotowe narzędzia zbudowane po to, by w takich sytuacjach pomagać. Jednym z nich jest Awaitility – mała, ale dość intensywnie rozwijana biblioteka mająca za zadanie uproszenie pisania testów jednostkowych kodu wielowątkowego. Jak spisuje się w praktyce? Na to postaram się odpowiedzieć.

Czytaj dalej

GeeCON University Day (Day 0) – relacja

Po 4Developers nadszedł czas na kolejną konferencję organizowaną w Poznaniu. Tym razem, programistów różnych narodowości przyciągnął do Polski GeeCON, aby wspólnymi siłami „poruszyli Javowy świat”. Konferencja zaplanowana została na trzy dni. Poniżej znajdziecie moje wrażenia z pierwszej części GeeCONa (tzw. „University Day”), która w założeniach miała być poświęcona na szkolenia i warsztaty. Czytaj dalej

Uwierzytelnianie i autoryzacja za pomocą SiteMindera i SpringSecurity w aplikacji Grailsowej

W jednym z artykułów opisywaliśmy podstawy implementacji uwierzytelniania przy uzyciu Spring Security w aplikacji webowej. Ale przecież wszyscy wiemy, że w rzeczywistości nie ma tak łatwo ;) Szczególnie, kiedy należy wprowadzić security do odziedziczonego kodu.

Załóżmy, że mamy prostą aplikację webową napisaną w Grailsach. Jej głównym zadaniem jest odpytywanie innych narzędzi i czynienie pomniejszej magii. Nie przechowuje żadnych informacji, w ogóle nie korzysta z bazy danych. Mimo, że ma zastosowanie administratorskie to bezpieczeństwo jest poniekąd pominięte, bo przecież jest ‚wewnętrzna’, schowana na jakiejś maszynce i kto tam o niej wie poza nami…  Pewnego dnia nachodzi nas (ewentualnie naszego menadżera/architekta/kolegę) zacna idea. Przecież można by troszkę dopisać, coś zmienić i udostępnić szerszej publice kawałek aplikacji w celach samoobsługowych (zwalniając przy tym zespól z części zadań administracyjnych, yay!). Sęk w tym, żeby ten ‚kawałek’ pozostał rzeczywiście kawałkiem. I to jest ten moment kiedy zakres dostępu zaczyna nas interesować. To tak tytułem wstępu ;)

Czytaj dalej

doclava – ładniejsze javadoci od Google

Nikogo chyba nie trzeba przekonywać do tego, że domyślne javadoci generowane dla klas Javy wyglądają dość przestarzale. Nawet pomimo niedawnego liftingu wciąż brakuje tak podstawowych funkcjonalności jak możliwość wyszukiwania. Problem ten zauważyło także Google, które to udostępnia niewielki projekt o nazwie doclava. Jest to nic innego jak doclet, którego można użyć, by odrobinę podrasować dokumentację. Prócz wspomnianego już wyszukiwania udostępnia również szereg dodatkowych parametrów i tagów, służących do personalizacji generowanych plików. Mamy też do dyspozycji rozbudowane mechanizmy styli. Niestety nie ma róży bez kolców – brakuje np. obsługi @author i @since, które to są dość szeroko używane. Mimo wszystko zachęcam jednak do zapoznania się z doclava. Więcej poczytać można na oficjalnej stronie projektu. Aby przetestować opisywane narzędzie, należy dodać do standardowego wywołania programu javadoc dodać poniższy fragment:

-doclet com.google.doclava.Doclava -docletpath <doclava.jar>

Nie ma także problemu z wykorzystaniem go z poziomu Anta czy Mavena.

P.S. Jeśli komuś wydaje się, że wynik działania doclavy jest łudząco podobny do dokumentacji API Androida, to nie myli się. Jak widać, Google postanowiło wykorzystać stworzony przez siebie projekt.

Zdaj OCEEJBD – pytanie 2

Które metody klasy TestBean będą częścią udostępnianego przez ziarno interfejsu biznesowego?

TestBean:

@Stateless
@LocalBean
public class TestBean extends BaseBean implements TestInterface {
	@PostConstruct
	public void init() {
		// init operations
	}
	
	@PreDestroy
	private void destroy() {
		// destroy
	}
	
	@Override
	public void method1() {
		// do something	
	}

	@Override
	public String method2() {
		// do something	
		return "method2";
	}
	
	private void privateMethod() {
		// do sth private
	}
}

BaseBean:

public class BaseBean {
	public void publicBaseMethod() {
		// do something
	}
	
	protected void protectedBaseMethod() {
		// do something
	}
}

TestInterface:

public interface TestInterface {
	public void method1();
	public String method2();
}

 

  1. Przedstawiony kod jest niepoprawny.
  2. Tylko metody interfejsu TestInterface
  3. Wszystkie metody klasy TestBean, niezależnie od wykorzystywanego modyfikatora dostępu.
  4. Wszystkie publiczne metody z wyjątkiem init() oraz destroy().
  5. Wszystkie publiczne metody klasy TestBean.

 

Pokaż odpowiedź »

Poprawna jest odpowiedź nr 5.
W przypadku ziaren EJB oznaczonych jako @LocalBean, interfejs biznesowy będą tworzyć wszystkie publiczne metody dostępne w danej klasie. W ziarnie TestBean będą to następujące metody:

  • init()
  • method1()
  • method2()
  • publicBaseMethod()

Zwróćmy uwagę na fakt, że metoda init() oznaczona jest adnotacją @PostConstruct. Nie jest to błąd, ale metody nasłuchujące na zdarzenia nie powinny być wywoływane bezpośrednio i co za tym idzie, nie powinny mieć publicznego modyfikatora dostępu.

Zdaj OCEEJBD – pytanie 1

Jaki wyjątek należy przechwycić w klauzuli catch(…) podczas wykonywania poniższego fragmentu kodu, odpowiedzialnego za wywołanie metody na ziarnie EJB?

import javax.naming.InitialContext;

public class Main {
	public static void main(String[] args) {
		try {
			InitialContext context = new InitialContext();
			StatefulBeanRemote bean = (StatefulBeanRemote) context.lookup("java:global/EJB1/EJBMODULE/StatefulSessionBeanRemote");
			System.out.println(bean.sayHi("Java Blog"));
		} catch (...) {
			// do sth.
		}	
	}
}

StatefulSessionBeanRemote:

@Stateful
public class StatefulSessionBeanRemote implements StatefulSessionRemote {
	public String sayHi(final String name) {
		String msg = "Hi " + name;
		return msg;
	}
}

 

  1. Klauzula catch jest zbędna.
  2. Należy przechwycić wyjątek biznesowy (Business exception).
  3. Należy przechwycić javax.naming.NamingException.
  4. Należy przechwycić javax.ejb.NoSuchEJBException.

 

Pokaż odpowiedź »

Poprawna jest odpowiedź nr 3.

Podczas odwoływania się do zasobów poprzez interfejs JNDI musimy obsłużyć wyjątki typu javax.naming.NamingException. W naszym przypadku wyjątek biznesowy nie zostanie rzucony ponieważ metoda sayHi działa w pełni prawidłowo i nie wykorzystuje żadnych specyficznych wyjątków informujących o wystąpieniu ewentualnej nieprawidłowości. NoSuchEJBException mógłby zostać rzucony jedynie gdyby bean, do którego się odwołujemy, został usunięty. Może się tak stać np. gdy wywołamy metodę oznaczoną jako @Remove.

Dodajmy testową metodę do klasy StatefulSessionBeanRemote (pamiętajmy o uwzględnieniu tej metody w interfejsie).

@Remove
	public void remove() {}

Następnie zmodyfikujmy kod klienta.

public static void main(String[] args) {
		try {
			InitialContext context = new InitialContext();
			StatefulBeanRemote bean = (StatefulBeanRemote) context.lookup("java:global/EJB1/EJBMODULE/StatefulSessionBeanRemote");
			bean.remove();
System.out.println(bean.sayHi("Java Blog"));
		} catch (NamingException e) {
			e.printStackTrace();
		}	
	}

Powyższy kod spowoduje rzucenie wyjątku typu javax.ejb.NoSuchEJBException. Pamiętajmy jednak, że wyjątek ten dziedziczy po RuntimeException więc jego obsługa nie jest wymagana.