Jak podają chyba wszystkie zagraniczne blogi twórca Javy James Gosling opuścił firmę Google (do której przeszedł po przejęciu Sun-a przez Oracle). Jak głosza plotki pan Gosling zajął stanowisko głównego architekta oprogramowania w firmie Liquid Robotics która zajmuje się tworzeniem robotów oceanicznych.

Więcej możecie przeczytać w źródłach:

1. Infoworld - Java founder Gosling leaves Google for startup
   
2. Liquid Robotics – James Gosling joins Liquid Robotics

Twitter to chyba największa strona napisana w języku Ruby (framework Ruby On Rails), a na pewno największa jeśli chodzi o moc obliczeniową jaką potrzebuje do codziennej pracy. Można powiedzieć, że była oczkiem w głowie programistów Ruby, jako argument, iż język jest dojrzały i bardzo dobry jeśli chodzi o poważne zastosowania. Jednak od jakiegoś czasu ktoś wyjątkowo wytrwale dłubie w tym oku, tym kimś jest nie kto inny jak sam Twitter który powoli przenosi swój kod do języków uruchamianych w JVM.

Wszystko zaczeło się jeszcze w 2010 roku kiedy to Twitter ogłosił, że programiści przepisali w języku Scala silnik kolejkowania oraz magazynowania wiadomości.
W kwietniu tego roku zmieniony został mechanizm składowania indeksów wyszukiwarki, od teraz za indeksowanie odpowiada Lucene dzięki czemu opóźnienie podczas wyszukiwania skróciło się trzykrotnie a przepustowość wzrosła dziesięciokrotnie, front-end wyszukiwarki również został zaktualizowany, od teraz zamiast Ruby On Rails wykorzystywany jest  mechanizm Blender (oparty o framework JBoss Netty).
Od kuchni Twitter do składowania danych używa bazy MySQL oraz rozproszonej bazy danych Cassandry. Do przetwarzania offline, używany jest Hadoop który ciągle zyskuje coraz większą popularność.

Powyższe zmiany w architekturze Twittera mogą świadczyć iż choć Ruby jest już językiem dojrzałym to nie nadaje się do projektów wymagających wysokiej wydajności o skalowalności (szczególnie jeśli chcemy zmniejszyć koszty działania).
Sam Twitter jest również niezłym laboratorium z którego wyników można czerpać garściami, z pewnością polecam obserwowanie dalszego rozwoju akcji.

Źródło:

1. http://www.infoq.com/articles/twitter-java-use
2. http://engineering.twitter.com

Wczoraj na stronach Oracle pojawił się wpis zapowiadający pojawienie się nowego magazynu traktującego o Javie. Magazyn pojawiać się będzie co dwa miesiące, i ma również zawierać artykuły tworzone przez społeczność.

Możliwość rejestracji oraz spis treści pierwszego numeru dostępne są na stronie magazynu.

Maj już się kończy a to oznacza rozpoczęcie sezonu DemoCamp-ów czyli konferencji około Eclipse-owych.
W Polsce pierwsze konferencje rozpoczną się 30 maja w Poznaniu. Po więcej szczegółów oraz możliwość rejestracji, zapraszam na wiki Eclipse DemoCamps Indigo 2011.

Tworząc mały modularny projekt natchnąłem się na pewien problem, jak udostępnić biblioteki współdzielone pomiędzy projektami. Oczywiście mogę po prostu dodać bibliotekę do ścieżki ale wiąże się to z utrudnioną ewentualną aktualizacją biblioteki (trzeba pobrać, skopiować itd.) no i jest trochę bezsensowne jeśli używa się mavena – aplikacji która została stworzona do rozwiązywania takich problemów. Niestety maven wymaga repozytorium z którego może pobrać odpowiednie biblioteki co dotychczas stanowiło dla mnie problem, dotychczas bo niedawno poznałem plugin wagon-ftp który potrafi zamienić serwer ftp/http w pełni działające repozytorium mavena.

Aby poprawnie skonfigurować wagon-ftp należy w pliku pom.xml projektu który chcemy przesłać do repozytorium dodać następującą konfigurację:

<build>
<extensions>
    <extension>
      <groupId>org.apache.maven.wagon</groupId>
      <artifactId>wagon-ftp</artifactId>
      <version>1.0-beta-7</version>
    </extension>
</extensions>
</build>

<distributionManagement>
    <repository>
      <id>darekzon-maven-ftp</id>
      <url>ftp://example.com</url>
    </repository>
</distributionManagement>

Powyższa konfiguracja w sekcji „extensions” dołącza plugin wagon-ftp do naszego projektu, następnie w sekcji „distributionManagement” konfigurujemy id repozytorium oraz adres do niego. Potrzebujemy jeszcze dane uwierzytelniające, jednak one nie powinny być składowane w pliku pom.xml który jak wiadomo jest udostępniany wszystkim. Dane te umieścimy bezpośrednio w konfiguracji mavena (u mnie plik ~/.m2/settings.xml).

<servers>
<server>
<id>darekzon-maven-ftp</id>
<username>mvn@example.com</username>
<password>jakies_haslo</password>
</server>
</servers>
</settings>

Powyższa konfiguracja definiuje serwer który ma działać w połączeniu z repozytorium o id maven-ftp (identyfikatory muszą się zgadzać) i ma wykorzystywać zadany login oraz hasło.

Po skonfigurowaniu wagon-ftp wystarczy w konsoli przejść do naszego projektu i wykonać polecenie

maven deploy

dzięki któremu maven skompiluje nasz projekt i automatycznie wyśle go na serwer.

Gdy już wrzucimy nasze biblioteki na serwer musimy dodać repozytorium do projektów, przykładowa konfiguracja wygląda jak poniżej:

<repositories>
<repository>
<id>moje-repo</id>
<url>http://example.com/</url>
<releases>
<enabled>true</enabled>
</releases>
</repository>
</repositories>

Firma CloudBees od jakiegoś czasu prowadzi beta testy swojej usługi skierowanej do programistów DEV@cloud.  Usługa zawiera w chwili obecnej serwer integracji Hudson z włączoną obsługą repozytoriów  GIT-a oraz SVN-a, obsługę Maven-a. Wyniki każdego build-a mogą być zapisywane do jednego z dwóch prywatnych repozytoriów maven-a (snapshot/release) by potem je wykorzystywać w projektach.

Póki trwa wersja beta, wszystkie usługi są całkowicie za darmo. Gdy usługa wyjdzie z bety pakiet podstawowy kosztować już będzie 25USD i zawierać będzie serwer continous integration Hudson, możliwość podpięcia 2 repozytoriów oraz maven proxy. Każdy build będzie nas dodatkowo kosztować w zależności od pakietu (zaczynając od 1centa/minute). Pełen cennik do obejrzenia na stronie producenta.

Warto dodać, że producent oferować będzie specjalne warunki dla beta testerów systemu więc jeśli ktoś szuka tego typu rozwiązania dla swoich projektów lub chciałby po prostu sprawdzić jak działa Hudson zapraszam gorąco.

Eduardo Pelegri-Llopart na swoim blogu podsumowuje rok jaki minął od przejęcia Sun Microsystems  przez Oracle. Jak od tego czasu mają się sprawy? Na pierwszy rzut oka wydawać  by się mogło, że idzie całkiem dobrze, co prawda wydanie 7 wersji Javy zostało przesunięte i okrojone o kilka nowości ale można to powiązać z procesem przejęcia Suna.

Jeśli jednak przyjrzeć się bliżej działaniom Oracle zauważymy, że zamyka bardzo dużo projektów (często ciekawych) które nie są zgodne z jego polityką (co jest raczej zrozumiałe). W ten sposób zamknięty zostało wiele mniejszych projektów takich jak OpenDS i Pymonkey. Część projektów straciła wsparcie Oracle i jest rozwijana przez społeczność (projekty DarkStar, Drizzle, a także Wonderland). Nadal nie wiadomo do końca co będzie z projektem Hudson, co prawda Oracle poinformowało, że go nie zakończy, jednak sytuacja może się zmienić o czym  można poczytać na stronie Hudson Labs. Problem może być również z bazą MySQL, co prawda będzie nadal rozwijana i udostępniana za darmo jednak po sieci krążą plotki jakoby Oracle miało w planach licencjonowanie silnika InnoDB.

Warto również zauważyć, że nowy właściciel Javy postanowił pozbyć się serwisu Kenai przenosząc go w struktury serwisu java.net (który notabene przechodzi duże zmiany).

Miejmy nadzieję, że Oracle nie zacznie zamykać ważniejszych projektów, choć gdyby tak się stało nie zdziwiłbym się.

Już jutro w godzinach 11-15 odbędzie się w Krakowie Eclipse Demo Camp na którym prezentowana będzie najnowsza wersja o kodowej nazwie Galileo. Spotkanie odbędzie się w  klubie Baraka znajdującym się na skrzyżowaniu ulicy Warszauera i ulicy Estery. Więcej informacji na stronie spotkania.

Podczas zabaw z Grails spotkałem się z pewnym problemem, na moim serwerze podczas próby uruchomienia prostej Grails-owej aplikacji wyskakuje błąd:

Error executing script RunApp: : Error starting Sun's native2ascii:
gant.TargetExecutionException: : Error starting Sun's native2ascii:

Problem sprawia funkcja native2ascii konwertująca pliki zapisane w natywnym kodowaniu do kodowania UTF, aby pozbyś cię tego błędu wystarczy edytować plik Config.groovy znajdujący się w folderze twoj-projekt/grails-app/config.

Odnajdujemy tam linie:

grails.enable.native2ascii = true

i zamieniamy ją na:

grails.enable.native2ascii = false

Problem rozwiązany.

Jak zapewne wszyscy wiedzą, i jak pisałem w poprzednim wpisie, Google udostępniło w swoim App Engine obsługę języka Java. W tej chwili jest to wersja beta (dla 10k programistów którzy mieli refleks) ale niebawem wystartuje pełna wersja. Wraz z obsługą Javy Google udostępniło swoją bibliotekę JDK oraz plugin do eclipse.

Swoją przygodę z Java App Engine najlepiej rozpocząć od przeczytania poradnika który pokaże nam jak rozpocząć projekt, uruchomić go lokalnie a także wysłać na serwery Google.

Jak wcześniej napisałem, Google udostępnia plugin do App Engine, po jego instalacji, pojawia się nowy typ projektu „Web Application Project” a także kilka ikon

Dodatkowe ikony dodane przez plugin GooglaAppEngine

na pasku narzędzi.

Dla przykładu stwórzmy przykładowy projekt. Z menu File wybieramy New -> Web Application Project, w oknie które się pojawi wpisujemy nazwę projektu, nazwę pakietu a także SDK z którego skorzystamy (dostępne jest GWT oraz oczywiście App Engine).

Google Java App Engine server

Po kliknięciu Finish utworzony zostaje szczkielet projektu Hello World. Aby sprawdzić czy projekt działa lokalnie wystarczy z menu kontekstowego (i tylko tam) wybrać Debug as -> WebApplication. W tym momencie zostanie uruchomiony lokalny serwer google

A zaraz po nim przeglądarka z wynikami, jak łatwo się przekonać wynikiem działania naszego programu będzie wyświetlenie wszystkim dobrze znanego napisu „Hello world”.

Nasz program jest już wystarczająco zaawansowany, pora zrobić deploy. Deployment możemy zrobić na dwa sposoby, albo z menu kontekstowego projektu (prawy klawisz myszy na projekcie) wybrać Google -> Deploy to App Engine, albo kliknąć ikonkę samolotu (pierwsze zdjęcie, ostatnia ikona) która została dodana przez plugin Google.
W oknie które się pojawiło wpisujemy nazwę naszego projektu, a także dane (email oraz hasło) do naszego konta App Engine.

Wysyłanie aplikacji na serwer app engine

Po wpisaniu danych nie można klinąć Deploy? To normalne, musimy jeszcze ustawić nasz projekt, zrobimy to klikając w oknie App Engine project settings… . Jedyne co musimy zrobić w oknie które nam wyskoczy to wpisać Application ID. Application ID to nazwa naszej aplikacji którą tworzymy w panelu Google App Engine.

Konfiguracja projektu app engine dla javy

Jeśli go nie mamy wystarczy kliknąć na My applications, a następnie już w panelu naszego konta kliknąć Create application. To co wpiszemy w Application Identifier jest naszym Application ID.
Gdy już ustawimy wszystko jak należy klikamy Deploy i czekamy aż nasza aplikacja zostanie wysłana na serwer. Po zakończeniu procesu Deploymentu nasza aplikacja jest dostępna pod adresem: http://APPLICATION_ID.appspot.com.

Przykładowe aplikacje do zobaczenia pod adresami:
- http://hello-world-example.appspot.com/ – podstawowy projekt
- http://cyb3r.appspot.com/ – podstawowy projekt z wykorzystaniem GWT