Od pewnego czasu pracuję z grupą pięciu developerów nad aplikacją webową pisaną w Pythonie oraz Rubim (powód takiej mieszanki to temat na zupełnie inny post). Większość naszego zespołu to początkujący programiści tych technologii, wiec kod który produkują wymaga szczególnej uwagi i kontroli. Ponieważ nie jestem wstanie przydzielić każdemu juniorowi – seniora konieczne stało się wdrożenie narzędzia do recenzji kodu (ang. code review).

Pierwszym pomysłem jaki przyszedł mi do głowy było wykorzystanie rozszerzenia do Eclipsa o nazwie Jupiter. Niestety, nie wszyscy członkowie zespołu podzielają moją miłość do tego IDE, a że programistów nie można zmuszać do wyboru narzędzi pracy, to wdrożenie zakończyło się fiaskiem a my problem tymczasowo rozwiązaliśmy poprzez mailowanie plików różnicowych. Dość bolesna i czasochłonna metoda.

Poszukując innego rozwiązania znalazłem video o Google’s Mondrian. Po jego oglądnięciu od razu wiedziałem iż jest to rozwiązanie mojego problemu, dodatkowo zostały w nim wymienione inne problemy z narzędziami standalone o których wcześniej nie myślałem. Niestety Mondrian jest projektem wewnętrznym Googla i jak wynika z prezentacji dość mocno zintegrowanym z całą infrastrukturą tej firmy więc szanse na to iż pewnego dnia zostanie on udostępniony szerszej publiczności są raczej nikłe, choć można przeczytać w kilku miejscach iż takie plany istnieją. Jednym z dostępnych przeglądarkowych rozwiązań jest CodeStriker.

CodeStriker to napisane w perlu narzędzie, które nie zachwyca interfejsem i możliwościami – nie posiada opcji recenzji kodu który nie znajduje się jeszcze w repozytorium. Aplikacja ta jest darmowa, co odróżnia ja od Crucible, narzędzia twórców FishEye’a, rekomendacje tego produktu można było usłyszeć choćby w jednym z odcinków Podcasta JavaPosse.

Crucible oferuje bardzo przyjazny interfejs i dość rozbudowane opcje jeśli chodzi o reviewu kodu. Narzędzie to jest ściśle zintegrowane ze wspomnianym już FishEyem. Jako ze nie miałem właściwie innej alternatywy poza CodeStrikerem, którego interfejs mnie naprawdę odstraszał, zaczęliśmy używać Crucible. Nielicząc kilku przypadków, kiedy to przestał on chwilowo odpowiadać i wymagany był restart serwera aplikacji, całość działała dość szybko i sprawdzała się w naszym zespole mimo iż nie możliwa była recenzja kodu jeszcze nie w repozytorium (problem ten został rozwiązany poprzez stworzenie oddzielnej gałęzi dla każdego z programistów).

Kiedy skończył się darmowy okres i mieliśmy już wykupić licencję na rok dość przypadkowo natknąłem się na ReviewBoard.

Reviewboard to darmowa aplikacja stworzona przez kilku programistów z firmy VMware napisana w Pythonie z wykorzystaniem frameworka Django. Autorzy na pewno zanim przystąpili do prac widzieli wspomniane wcześniej video o Mondrianie, jak również spotkali się z wymienionymi tutaj projektami. Z ich blogów wynika również iż poprzednio przechodzili przez takie męki jak nasza firma, zaczynając od przesyłania plików różnicowych, a kończąc na szukaniu gotowego rozwiązania. Projekt ten jest w dość wczesnej fazie, ale jak widać z poniższych ekranów charakteryzuje go dbałość o detale i przyjazny interfejs:

ReviewBoard oferuje dwie możliwości tworzenia recenzji – z pliku różnicowego i na podstawie zmian w repozytorium. Ponieważ bardzo zależało mi na posiadaniu opcji automatycznej weryfikacji kodu jeszcze nie dodanego do repozytorium to w niespełna 5 godzin zmodyfikowaliśmy ten projekt tak aby pobierał on zmiany z serwera developerskiego (siła open source oraz Pythona). W efekcie czego otrzymaliśmy produkt zbliżony do Mondriana. ReviewBoard posiada dodatkowo „integrację” z Traciem, który jest przez nas wykorzystywany do zarządzania zadaniami więc na dzień dzisiejszy posiadamy stabilne i szybkie rozwiązanie które możemy łatwo rozbudować.

Swoja drogą od dłuższego już czasu chodzi mi po głowie napisanie narzędzia podobnego do wspomnianego Mondriana całkowicie w Rubim. Idealny dla mnie produkt generował by pliki różnicowe raz dziennie z katalogów roboczych programistów oraz repozytorium kodu, a następnie na podstawie ustawień projektu przypisywał by zmiany do odpowiedniego recenzenta. Ciekawą opcją mogła by być również integracja z Google Gears – pozwalało by to na recenzje offline.

Bardzo możliwe iż niebawem do taglinu mojego bloga trzeba będzie dodać kolejny język – Javascript. Do niedawna kojarzony on był przez programistów ze śmiesznymi skryptami wykonywanymi po stronie przeglądarki i raczej nikt nie brał go poważnie. Najczęściej programowanie sprowadzało się do prostych operacji na dacie, modyfikacji wyglądu strony przez zmianę stylu lub komunikacji z użytkownikiem za pośrednictwem dwóch funkcji – confirm() oraz alert(). Ostatnie kilka miesięcy to ogromna popularyzacja tej technologii dzięki AJAXowi, który to przy okazji bańki web 2.0 pojawia się obecnie prawie w każdej nowo powstałej aplikacji webowej. Jednak przez cały ten czas język ten pozostawał w jednym, jasno określonym miejscu – w przeglądarce.

Niedawno Steve Yegge przeportował znany wszystkim framework Ruby on Rails do JavaScriptu. Wykonywanie JavaScriptu po stronie serwera możliwe jest dzięki Rhino, otwartej implementacji JavaScriptu w Javie. Do operacji po stronie serwera, jak również do komunikacji z bazą wykorzystywane są biblioteki dostępne w Javie – zaleta programowania w języku uruchamianym na JVM’ie podobnie jak w JRuby czy Groovy.

Innym przykładem zastosowania JavaScriptu poza przeglądarką może być iPhone. Poza ekranem dotykowym oraz masą wodotrysków od standardowego telefonu komórkowego odróżnia go również to iż nie jest on wyposażony w JVM. Inżynierowie, a może nie tylko oni, w Applu stwierdzili iż jest ona nie potrzebna i aplikacje można pisać miedzy innymi przy wykorzystaniu JavaScriptu.

Jeśli się nad tym dłużej zastanowimy to perspektywa pisania aplikacji na wiele platform, interpretowanych zarówno po stronie klienta jak i serwera jest ciekawą opcją na przyszłością. Czy tą technologią będzie JavaScript? Możliwe, ale niekoniecznie, zależy to od wielu czynników – jednym z nich są biblioteki a tych obecnie jest na lekarstwo jeśli popatrzymy na tą technologie od strony serwera. Pewne jest jednak jedno, nie można już lekceważyć JavaScriptu- jak to miało miejsce jeszcze kilka lat temu, osobiście od dzisiaj postrzegam go jako język a nie dodatek do przeglądarki.

Update: Kilka dni po tym jak napisałem ten post Ola Bin na swoim blogu napisał dość podobny wpis, rozpatrując JavaScript bardziej od strony semantycznej. Zgadzam się z większością postawionych tam argumentów jak również z tym iż bardzo możliwe iż nie będziemy już mieli do czynienia z dominacją jednego języka taką jaka to miała miejsce jeszcze kilka lat temu, ponieważ sposób prowadzenia projektów i podejścia do technologi się zmienił. Przykład? Choćby ilość języków uruchamianych przez JVM.

Własnie otrzymałem email informujący iż rejestracja na tego roczną konferencje railsową w Berlinie została otwarta. Długo czekałem na ten moment i specjalnie zapisałem się do oreilly’wego newslettera żeby nie przegapić zapisów. Ceny są dość wysokie – koszt uczestnictwa w dwóch dniach wykładów i jednym dniu tutoriali to 745 E (przy cena promocyjna dla wczesnych rejestacji). Dla studentów i pracowników naukowych istnieje możliwość zniżek do 65%.

Sam program konferencji jest nieco uboższy od jej amerykańskiej odpowiedniczki. Wydaje mi się iż może to być ciekawe wydarzenie i napewno jedna z lepszych (jeśli nie naj) imprez o tej tematyce w naszym rejonie w tym roku. Sam się juz zapisałem i napewno na bieżąco będe informował o przebiegu konferencji na blogu.

Andrzej Krzywda zamieścił na swoim blogu porównanie tworzenia prostego okienka w IronPython, Groovy oraz JRuby. Szczególnie ciekawie wyglądają te dwa ostatnie, ponieważ używają tej samej bilbioteki – pozwala to na znakomite porównanie języków – ich czytelności i ilości kodu jaki należy napisać aby otrzymać działający kod.

Już na pierwszy rzut oka widać iż (J)Ruby ma bardziej przejrzystą składnie, która pozwala prawie każdemu programiście na dość szybkie przeanalizowanie kodu i zrozumienie jego działania. Kod Grooviego jest tutaj dużo krótszy (w komentarzach do tego postu została zamieszczona wersja maksymalnie skompresowana), jednak jest dużo mniej czytelniejszy dla osób nie znających wszystkich detali języka i biblioteki. Co do wersji Pythonowej to mimo ze samego Pythona bardzo lubie przedstawiony kod nie przypadł mi do gustu. Ale o gustach się nie dyskutuje – może dlatego iż C# nie jest do końca moją ulubioną technologią. Sam wpis dał mi dużo do myślenia i zamierzam również niebawem napisać nieco większe porównanie tych dwóch języków i przeanalizować je pod róznym kontem na bardziej skomplikowanych przykładach.