Scala - scratch the surface

Nareszcie! Trafiłem na naprawdę fajne wprowadzenie do języka Scala, które ostatecznie dało mi posmak tego języka, zobligowało do za instalowania Scala IDE na komputerze i napisania kilku prostych klas, oraz fragmentu kodu.

Mowa oczywiście o Scala for Java Refugees Daniela Śpiewaka, żałuję tylko, że nie trafiłem na to trzy lata temu (wpisy są z 2008 roku), ale może to była też kwestia dojrzewania do tego języka? Nie wiem. Wiem jedno, że język jest naprawdę fajny, chociaż w przeciwieństwie do Rubego - to co napiszę zdarza się nie działać.

Język jest ogromny i jego poznawanie może mieć wyłącznie charakter stopniowy. Jest tego po prostu za dużo. Zresztą, każdy język programowania ma obszary, których nigdy nie potrzebowałeś, nie używałeś - Scala ma ich po prostu więcej.

Na razie jednak zaczynam pisać projekt w Rails-ach, a w świecie JVM przygotowuję się do Certyfikatu wydawanego kiedyś przez Sun, a teraz Oracle, dla programistów Java. Tak więc "mieszanie" sobie Scali z Javą może być niebezpieczne na tym etapie. Do następnego razu.

PhantomJS i Ruby - czyli przygody małe i duże

No więc stało się. Jestem programistą Javy. I co z tego? A no trzeba w domu jakoś odreagować.

Na pierwszy ogień poszedł Ruby i to nie byle jaki jak 1.9.3-p0. Windowsowa paczuszka ściągnięta wprost z RubyInstaller ślicznie zadomowiła się w moim systemie operacyjnym, dając mi nawet w trakcie instalacji dodać poleceni ruby do ścieżki systemowej.

No ale nie o Rube-go chodzi tylko o chęć napisania jakiegoś drobiazgu z meta-programowaniem. No więc potrzebny jest edytor.

gem install redcar

redcar install

redcar

I moim pięknym oczom ukazał się turbo edytor RedCar - i od razu zrezygnowałem nawet z myśli o płaceniu za TextMate na Mac-u. Napisałem sobie bardzo prosty program, który pozwolę sobie dumnie nazwać klient "REST". Tak naprawdę to prawie na jedno by wyszło jakby podziedziczył po Net::HTTP, ale że miało być "meta-programowanie" to wyszło tak:

require 'net/http'
require 'uri'

class REST
def self.method_missing(m, *args, &block)
uri = URI(args[0])
Net::HTTP.start(uri.host, uri.port) do |http|
puts "Calling #{m} REST call."
return http.send(m.downcase.to_sym, uri.path)
end
end
end

res = REST.GET("http://www.google.pl/")
puts res.body

Nikt, nie mówił, że jest się czym chwalić, ale coś mnie tchnęło, żeby pobrać (a co) zawartość wyżej wymienionej strony w PhantomJS. Trwa to wieki i gdyby tak działała przeglądarka to pewnie zrezygnowałbym z Internetu, albo kazał, za korzystanie z niego, sobie płacić, ale ... na szczęście Google Chrome ładuje WebKit raz a nie za każdym razem gdy otwieram zakładkę - więc da się żyć. Na stronie projektu, gdy napisałem już skrypt w JavaScript zauważyłem, że mogę też podawać skrypty w CoffeeScript pominę więc moje wypociny w JS i podam odrazu wersję Coffee, a jak interesuje Cię co napisałem w JS to wklej sobie poniższą zawartość na stronie Try CoffeeScript i będziesz wiedział.

page = new WebPage()

if phantom.args.length == 0
console.log 'Usage: google.coffee some-url'
phantom.exit()
else
t = Date.now()
address = phantom.args[0]
page.open address, (status) ->
if status != 'success'
console.log 'FAIL to load the address'
else
t = Date.now() - t
console.log 'Loading time ' + t + ' msec'
console.log 'Page content is \n' + page.evaluate () ->
document.documentElement.innerHTML
phantom.exit()

Edytor kodu na Blogger jak zwykle daje ciała nie wspierając wstawek kodu źródłowego, ale co tam. Najgorsze, że RedCar nie ma wsparcia dla CoffeeScript, ale może się dorobi jak skończy być Alphą. No nic, czas kończyć. Na dziś starczy już tego dobrego wracamy do Thinking in Java, którego autor i tak co 100 zdanień kończy stwierdzeniem w stylu "Java to ogromny krok na drodze postępu w tej dziedzinie, ale Python i tak robi to lepiej."

P.S. Moim ogromnym odkryciem w Ruby było odkrycie, że każdy operator to metoda. Kiedyś nie mogłem znaleźć w dokumentacji co dokładnie robi ~= (czy tam =~) bo szukałem jakiegoś działu dokumentacji Ruby-Doc, który definiowałby operatory zamiast sprawdzić metodę =~ klasy String albo RegExp.

Sposób na zrywane sesje SSH

Nie wiem dlaczego, ale albo mój router, albo mój dostawca (UPC) wciąż zrywa nieaktywne sesje SSH. Nie ma mowy o zostawieniu Puttego w tle choćby na kwadrans. Po kilku minutach okno informuje mnie iż połączenie zostało zerwane i muszę wracać do mojej pracy ponownie. Frustrujące.

Jest na to sposób. Zostawienie otwartego w konsoli Screena, który na dolnym pasku wyświetla godzinę. Tak więc wpis:

caption always "%`$USER%`@%H: %{kg} %L=%-Lw%45>%{yk}%n%f* %t%{-}%+Lw%-0< %= %{yk}%c%{kg} load:%l"

w pliku ~/.screenrc właściwie załatwia sprawę. Kwestia startowania sesji podczas każdego logowania. Można to załawić dodając na końcu pliku ~/.bashrc

# Start or resume screen
if [[ -n "`screen -ls | egrep '\.default(.*)(Detached)'`" ]]; then
    screen -r default
elif [[ -n "`screen -ls | egrep '\.default(.*)(Attached)'`" ]]; then
    false
else
    screen -S default
fi

Internet i MMSy w Play na HTC Dream

Teoretycznie skonfigurowanie telefonu w play to wysłanie SMSa o treści "play" na numer 9999. Jeżeli posiadasz HTC nie jest to tak proste. Na moim HTC Dream wymagało to podjęcia następujących kroków:
Menu > Ustawienia > Opcje bezprzewodowe > Sieci komórkowe >  Punkty Dostępowe > Menu > Nowa nazwa APN


Internet

• Nazwa: Internet
• APN: internet
• MCC: 260
• MNC: 06
• Typ APN: default

MMS

• Nazwa: MMS
• APN: mms
• MMSC: http://10.10.28.164/mms/wapenc
• Proxy dla wiadomości MMS: 10.10.25.5
• Port MMS: 8080
• MCC:260
• MNC: 06
• Typ APN: mms

Po zapisaniu uruchom ponownie telefon.

Ruby On Rails 3.1 - dzień pierwszy

Zawsze uważałem, że najlepszy poradnik, to zbiór wskazówek pisanych przez początkującego, nie koniecznie zaś zapełniane przez mądrego człowieka annały, które jak na początek, mogą być za mądre. Równocześnie, najlepiej aby początkujący miał już doświadczenie z innymi podobnymi zagadnieniami  jednak w danej technologii był początkujący. Taki układ daje duże szanse, że poradnik będzie profesjonalny, pisany prostym językiem i zrozumiały dla maluczkich, którzy oczekują prowadzenia krok po kroku. Mam nadzieję, że moje wpisy o Ruby On Rails 3.1 takie właśnie będą.

Dlaczego?

Mam za sobą już, od jakiegoś czasu, Rails for Zombies, czytałem o Ruby On Rails i jeszcze nigdy nie spotkałem się z osobą, która zaczęłaby kurs Railsów od RVM. Podstawy podstaw - jak na mój gust.

Gdy piszesz jakikolwiek program, aplikację musisz zdecydować się na dwie rzeczy: wersję języka programowania i wersję pozostałych bibliotek, które używasz. U mnie to wygląda tak: zaglądam na stronę języka programowania (w tym przypadku języka Ruby), zaglądam na stronę biblioteki (w tym przypadku Railsów) i nakręcam się na napisanie aplikacji w najnowszej wersji, która wprowadza najświeższe udogodnienia, nowości, nowatorskie technologie i wszystko co sprawia, że bycie geekiem jest piękne i pełne wrażeń jak przejażdżka górską kolejką w parku "Six Flags Great Adventure".

Później przychodzi faza druga, która nazywa się "sprawdźmy co jest na serwerze" i ta przynosi znacznie więcej rozczarowań, niż radości dopóki nie używasz ArchLinux lub nie jesteś twórcą biblioteki, której właśnie zamierzasz użyć. Wtedy klniesz pod nosem, że "przecież administrator mógł przejść na sida" i jakbyś tylko miał uprawnienia użytkownika root!

I tutaj właśnie objawia się piękno RVM. Pozwala ono bowiem bez uprawnienia super-użytkownika zainstalować dowolne wersje języka Ruby, w locie podmieniać interpreter oraz wersje używanych bibliotek, które w wielu różnych kombinacjach mogą koegzystować w wirtualnych środowiskach zwanych gemsetami. Wszystko bez wychodzenia poza katalog domowy.

Jak korporacje dobierają narzędzia

Ten post jest próbą wyrzucenia z siebie drzemiącej głęboko frustracji dotyczącej fatalnego podejścia do doboru narzędzi, w korporacjach, z którymi się zetknąłem.

Trawestując znanego survival-owca oraz Naczelnika Skautów Wielkiej Brytanii "Narzędzia są po to aby wykonywały pracę za Ciebie - nie na odwrót.". Choć zdanie to dotyczyło konserwacji i ostrzenia piły, noża czy siekierki, to pasuje również do naszej, jakże przepełnionej narzędziami, informatycznej rzeczywistości.

Rozpoczynając pracę musisz wybrać narzędzia. Jednak samo ich posiadanie nie rozwiązuje problemu - musi nastąpić etap selekcji. Selekcji, która w dużych firmach podejmowana jest raz i nieodwołalnie, często kilka, anawet kilkanaście lat przed rozpoczęciem projektu, któremu przyjdzie z nich korzystać.

Innymi słowy, narzędzia wybierane są globalnie w skali całej firmy i w tej samej firmie ich używanie jest egzekwowane bez względu na charakter i rodzaj przedsięwzięcia. Zdarza się iż używany jest system kontroli wersji, którego początki pamiętają roku 1992, którego założenia koncepcyjne są na tle nowoczesnych systemów kontroli wersji z gruntu złe. Ogromna ilość pieniędzy, stworzona infrastruktura, ilość znanych rozwiązań problemów oraz doświadczenie tworzą pozorną wartość przekładającą się na równie pozorną łatwość w użyciu tak dobrze "sprawdzonego" i "sprawdzającego się" narzędzia w kolejnym projekcie.

Jednak wszystko to jest iluzoryczne. Przyzwyczajenia ludzi nie świadczą o jakości narzędzia, ani o sprawności jego używania gdyż nawet większa nieudolność, w wykorzystywaniu nowego oprogramowania na początku, może być błyskawicznie zniwelowana sumą zwiększonej prędkości jego działania oraz dobrze przygotowanym programem szkoleń dla osób początkujących, posuniętego nawet do algorytmów postępowania.

Równie fałszywe jest wrażenie "problemów, z którymi przyjdzie nam się zmierzyć". Często zakładamy, że skoro oprogramowanie zaproponowane przez firmę sprawiło nam wiele kłopotów, to wraz z wprowadzeniem nowego narzędzia pojawią się nowe. Nikt jednak, bardzo często, nie zauważa, że znaczna część tych problemów wynika z wieku narzędzia i architektury oraz koncepcji, które bardzo często nie przystawały do współczesnych realiów. Realiów, w których zostało stworzone nowe narzędzie, dzięki któremu będziemy mogli zminimalizować portfolio "dobrze znanych rozwiązań, dobrze znanych problemów" nawet o 90%.

W epoce kamienia łupanego ludzie do krojenia używali ostrych kamieni. Używali ich ponieważ sprawdzały się, a w pobliżu nie było nic bardziej dostosowanego do krojenia. Dzisiaj jednak używamy noży, toporów, siekier, pił i scyzoryków. Używamy ich na drodze prostej ewolucji, w której narzędzia mniej przydatne przestawały być używane, odchodziły w niepamięć, a zastępowały je lepsze, bardziej użyteczne odpowiedniki. O tym czy narzędzie i jego wykorzystywanie przetrwało do naszych czasów czy nie decydowała jego efektywność.

Kiedy się temu przyjrzymy, wydaje się to rzeczą naturalną. Można wręcz powiedzieć iż stwierdzenie przybliżone w poprzednim akapicie trąci truizmem. Truizm ten nie jest niestety oczywisty w korporacjach, w których w kółko i na okrągło wykorzystuje się stare, zakupione dekadę, albo dwie temu programy. Pomimo dziesiątek problemów i dawno stwierdzonych wad są używane w kolejnych projektach.

Jednak nie tylko wykorzystywanie archaicznych rozwiązań, na dużą skalę, może być błędem. Git to niewątpliwie fantastyczny system kontroli wersji. Pomyli się jednak ten, kto użyje go do projektu Visual Studio 2010, w środowisku opartym o kontroler domeny Windows. Wystarczy bowiem przyjrzeć się Mercurialowi aby dostrzec zalety w formie: natywnego wsparcia dla okienek, świetnej integracji z Visual Studio 2010 dzięki wtyczce VisualHG (znacznie lepszej niż jakakolwiek integracja Gita z Visualem), czy wsparcia dla Single Sign On w postaci HGKerberos, która działa z SPNEGO.

Na tym przykładzie widać, że narzędzia można dobrać lepiej lub gorzej, albo po prostu źle. Moim zdaniem idealnym rozwiązaniem jest tworzenie architektury "per-projekt", w których używane narzędzia będą symbolem "epoki", w której projekt startował. Doskonale rozumiałbym używanie tak archaicznego systemu kontroli wersji jak CVS w projekcie z lat 90siątych, tak jak używanie Subversion w narzędziu, którego początki są datowane na 2000 rok. Konsekwentnie, dobierając nowoczesne rozwiązania do projektów, które powstały na przestrzeni kilku ostatnich lat.

Świetny program do robienia screenów pod Windows

Zawsze zachwycały mnie screeny prezentowane w sieci przez użytkowników komputerów Mac. I nie chodzi mi o cukierkowy interfejs OS X, ale o ładnie opisane, zaznaczone, wskazane przejrzystymi strzałeczkami elementy.

Zacząłem szukać oprogramowania pod Windows, nawet płatnego, który pozwoliłoby tworzyć równie schludne obrazy, pozwalając na nanoszenie strzałek czy napisów.

Początkowo, wraz z wydaniem Windows 7, zwrócił moją uwagę program "Narzędzie Wycinanie" dostępny wraz z systemem operacyjnym. Był to pierwszy raz kiedy do robienia zrzutu ekranu nie używało się guzika Print Screen, a wykorzystywanym programem wcale nie był Paint.

Pomimo znacznie podwyższonej wygody korzystania możliwości "Narzędzie wycinanie" nie zachwycały. Kilka miesięcy później trafiłem na Screenpresso. O kupnie programu myślałem już nie raz jednak żadna z dostępny po zapłacie opcji nie jest mi do szczęścia potrzebna i darmowa wersja w stu procentach spełnia moje potrzeby i oczekiwania.

Po zainstalowaniu program podpina się pod klawisz PrintScreen przyciemniając ekran i dając nam możliwość wyboru obszaru, który chcemy umieścić na zrzucie. Już na tym etapie otrzymujemy dwa udogodnienia: małą lupkę w prawym dolnym rogu ekranu, która pozwala nam dzięki powiększeniu precyzyjnie dobrać współrzędne prostokąta oraz szalenie użyteczny detektor kontrolek Windows, który po najechaniu zaznacza jej obszar sugerując nam wykonanie screenshotu tego konkretnego okna, pola, przycisku czy obszaru.

Chwilę później możemy już skopiować zawartość zrzutu [CTRL]+[SHIFT]+[C], plik ze zrzutem [CTRL]+[C], zmienić nazwę pliku [F2] czy usunąć nasze dzieło [DEL]. Najciekawszą opcją jest otworzenie zrzutu w wewnętrznym edytorze [ALT]+[E].

Opcji dostępnych w otworzonym przed chwilą oknie nie powstydzi się nawet użytkownik MacOSX. Program pozwala nam:

• nanosić strzałki
• tekst
• zaznaczać eliptyczne lub prostokątne obszary
• dodawać dymki i ikony
• numerować punkty
• podświetlać lub zamazywać fragmenty obrazu

Wszystkie elementy wyglądają szalenie elegancko i schludnie a efekt końcowy naprawdę cieszy oko.

Jeżeli nie wystarcza nam zaznaczanie obszaru ScreenPresso oferuje wykonanie screenshotu poprzednio użytego regionu, całego ekranu lub wykonanie zrzutu tuż po puszczeniu paska przewijania jednego z okien.

Edit

W myśl dewizy "zarabiam - płacę" zakupiłem wspomniany program w celu odblokowania opcji kręcenia filmików dłuższych niż, dostępnych w wersji darmowej, 15 sekund.

To co mile zaskakuje - nie musimy ujmować na filmie całego ekranu - możemy wyznaczyć obszar, który zostanie ujęty na filmiku. Niestety, to wszystko co oferuje obecnie w tej materii ScreenPresso. Nie znajdziemy tu żadnych zaawansowanych efektów, możliwości podświetlania i zaznaczania, przejść czy podążania za kursorem - mam jednak nadzieję, że to czasowe :)

Po nakręceniu filmiku jest on zapisywany w formacie zrozumiały wyłącznie dla wewnętrznego edytora. Aby udostępnić pozostałym nasze dzieło musimy korzystać z opcji konwersji. Tutaj nie możemy narzekać na brak możliwości: MP4, WebM, OGV, WMV czy witryna HTML5. Podążanie za trendami twórców oprogramowania aż zaskakuje.

Każdemu kto tworzy wiele instrukcji i szuka dobrego programu do ubogacania jej zrzutami serdecznie polecam!

Języki ponad-maszynowe

Odnośnie poprzedniego wpisu, moim zdaniem świat programistyczny powinien zainwestować więcej uwagi w kierunek jaki obrał chociażby PyPy czy Rubinius. Implementacje języków programowania, które są niezależne od maszyny wirtualnej, z której przyjdzie nam korzystać.

Pewne uniwersalna rodzina dialektów, które możemy wybierać do potrzeb danego zagadnienia nie zastanawiając się czy nasza aplikacja będzie działała na Androidzie, Linuksie, czy MacOS X. To jest moim zdaniem przyszłość.

Jeżeli o maszyny wirtualne chodzi - można zaobserwować ciekawe zjawisko. Pewien szczególny rodzaj maszyny wirtualnej, dostępnej wszędzie wytworzył się "przypadkiem". O dziwo jest nią przeglądarka internetowa. Połączony z tym rozwój takich standardów jak HTML5, CSS3 i projektów z nimi powiązanymi, problemy z technologią Flash na platformach mobilnych sprawiły, że dzisiaj przeglądarka internetowa/sieć jest najczęściej wybieraną platformą do tworzenia oprogramowania. Jeżeli już dziś chcemy napisać oprogramowanie, która za 20 lat będzie działało na kaczuszce do kąpieli naszego dziecka - zaimplementujmy to w JavaScript. Dzięki CoffeeScript, SprouteCore, ExpressJS, NodeJS JavaScript przychodzi pod strzechy. Za nią zaś stoją niewyobrażalnie zoptymalizowane maszyny wirtualne, które są od lat tuningowane i wystawiane do prezentowania swoich możliwości na torze zwanym Internet. Tutaj nie ma miejsca na pozorne rozwiązania - współzawodnictwo jest zacięte, a konkurencja nie śpi.

Może się wydać to nietypowe. Każdy język programowania posiada jedną maszynę wirtualną, stworzoną dla niego - JavaScript posiada ich aż kilka. Gdyby nie CoffeeScript - to z jej ohydną składnią i obleśną semantyką ociekającą toną wtfjs byłaby jak rozprzestrzeniające się na ogromną skalę trucizna. Na szczęście ludzie zaczęli ją oswajać i powoli uczą się ją wykorzystywać do tworzenia leków, znaleźli już wiele ciekawych zastosować.

Rodzi się pytanie - czy i jak JavaScript będzie można sprzedać? Język programowania, wykorzystywany do tej pory "dla bajeru", przez domorosłych informatyków, używany do pisania małych fragmentów, wstawek kodu staje się kompletnym rozwiązaniem z armią, przez lata optymalizowanych w wyścigu "zbrojeń" maszyn wirtualnych w drugim szeregu.

Język, w którym nie jest znana mi żadna metoda dająca zaczepienie oprogramowaniu "closed-source", gdzie jedyną metodą "chronienia" kodu jest jedynie jego zaciemnianie. Czyżby polimorfizm znany z pierwszych lat tworzenia wirusów? Zobaczymy.

Java w nowych projektach i racja jej bytu.

Czas języków programowania dawno minął - nastał czas dialektów maszyn wirtualnych.

Od kilku dni w firmie zatrudniani są programiści języka Java. Po rozmowie z zatrudniającymi managerami załamałem się - bo niby dlaczego Java?

Pisząc aplikację dla platformy Android, czy rozwijając Rational Team Concert to czego potrzebujesz to - plik wynikowy, zrozumiały dla JVM, napisany w konkretnej konwencji, używający konkretnych bibliotek a nie Java!

Jakie miejsce powinni zajmować dziś programiści C++ czy Java? Rozwijać dalej istniejące, dobrze napisane, oprogramowanie.

W dzisiejszych czasach możemy mówić o dialektach maszyn wirtualnych. Ślepe wybieranie dialektu języka Java do pisania oprogramowania dla JVM to po prostu zaściankowość i ciemnota.

Wiele innych: Clojure, jRuby, Jython, Noop czy chociażby Scala - mogą w danym zastosowaniu znacznie skrócić czas kodowania, podwyższyć jakość oprogramowania, obniżyć stopę występowania błędów, znacznie zwiększyć jakość kodu. W skrócie: skoro może być szybciej i lepiej to po co trzymać się języka Java? Trawestując Martina Klepmann : "Modern language programming is good 'quality filter' for people."

Oczywiście: nadal istnieje wiele powodów, dla których utkniemy z kolejnym projektem w języku Java. Brak developerów danego języka na rynku to podstawowa przyczyna - choć może być ich więcej. Moim zdaniem należy jednak próbować, podejmować wyzwania i ryzykować bycie innowacyjnym - to się opłaci.

Continous integration i Python?

Czy ktoś widział może kiedyś budowanie projektu pisanego w Pythonie?

Może nie jestem czegoś świadom, albo myślę zbyt szablonowo ale: continous-integration jest dobrze zdefiniowane dla projektów, które trzeba kompilować. Wiadomo. Developer nie kompiluje kodu sam. System CI sam sprawdza za niego czy kod pozytywnie przechodzi etap kompilacji i wysyła powiadomienia.

Ale jak odnieść się do tego w świetle Pythona. No dobra, wyciągamy kod źródłowy z repozytorium - i co? Przecież go nie skompiluję. Wszystko, na stać moją wyobraźnię na dzień dzisiejszy, to hmm... scan pylint, pychecker, pep8, odpalanie metody .compile() na każdym module? Jeżeli już zdecydujemy się na skany: to jak zachować się w przypadku jakiś komunikatów. Kod nie musi być źle napisany, zresztą zakładamy, że przeszedł review, ale wtedy co? Sfailować build tylko dlatego, że kod Pythona programisty nie odpowiada pylint. To niczego nie udowadnia.

Piszę ten post w związku z sytuacją jaka miała miejsce kilka dni temu. Rozumiem, żeby w trakcie budowania projektu Pythonowego odpalać testy w ramach. W moim przypadku nie mam nawet czasu aby je pisać więc nie ma co odpalać. Przyjmuję argument, że to co wychodzi na produkcję powinno być numerowane. To bardzo pomocne i użyteczne. Jednak w Python 2 wszystko co sobie wyobrażam to otagowywanie kolejnych wersji w repozytorium. Podmienianie egga, który wywala serwer Apache ponieważ przestają mu się zgadzać sumy kontrolne - to jakaś porażka. To nie wiem co innego mógłbym robić? Dodawać komentarz z numerem buildu w jakimś umówionym pliku? Dodam jeszcze, że to aplikacja internetowa pisana w Django.

Jeżeli ktoś jest w temacie to jestem bardzo zainteresowany wymianą doświadczeń w tym temacie.

Webdevelopment i unit testy

Kilka tygodni temu zacząłem developować webowy frontend dla projektu gitolite o nazwie glboard. Gitolite to warstwa abstrakcji pozwalająca na kontrolę dostępu do repozytoriów systemu git podczas dostępu do serwera przez ssh.

Glboard od samego początku pisany był z myślą o testach, dlatego wraz z kodem publikowane były unit testy do udowadniania poprawności metod, klasy, która stanowi trzon funkcjonalności.

Podczas oglądania prelekcji "State of Pylons/Turbo Gears2/repoze.bfg", moją uwagę przykuły zarzuty postawione unit testom w web-developmencie.

W tym okresie spędziłem sporo czasu, w glboard, na poprawianiu unit testów. Jeżeli padłem ofiarą zbyt wczesnego testowania - to jaki sens ma Test Driven Development?

Podczas zmieniania głównej klasy, obsługującej operacje na repozytorium gita, uzyskałem pewien ciekawy efekt - witryna działała i mogłem dzięki niej wykonać wszystkie operacje - natomiast testy failowały. Wszystkie. Powód był prosty: klasa przyjmowała teraz nowy argument w metodzie __init__.

Wspomniana prelekcja uświadomiła mi jedną rzecz. Jeżeli nie wystawiasz czegoś na zewnątrz, nie wystawiasz API lub biblioteki, nie będziesz zobligowany do zachowywania wstecznej kompatybilności z jakimś stworzonym przez siebie interfejsem, które kiedyś udostępniłeś, tylko dlatego, że używają go klienci - nie używaj unit testów. Pisanie unit testów do elementów, które zostają w twoim projekcie i nie wychodzą w żaden sposób na zewnątrz - to strzelanie sobie w stopę.

Moim zdaniem pisząc aplikację we frameworku webowym to co powinno się testować - to działanie przez przeglądarce. Testy funkcjonalne wydają się wystarczające. Może są troszkę bardziej kosztowne niż unit testy, ale w gruncie rzeczy, dobrze napisane, testują dokładnie to co powinny. Nie skupiają się na API konkretnej klasy, funkcji, metody, ale na tym czy witryna działa - nie ważne jest jak.

Odnosząc się do narzekań na Selenium i długiego czasu trwania testów w nim napisanych: myślę, że możemy spodziewać się rewolucji w świecie testów web-aplikacji dzięki PhantomJS. Nie znam jego wydajności, ale funkcjonalność jest w tej dziedzinie bardzo obiecująca i daje znacznie więcej możliwości niż zwykłe funkcyjne testy. Równocześnie nie używa całego niepotrzebne osprzętu jakie ładuje przeglądarka.

Wszystko co w tej chwili mi pozostaje to usunąć unit testy z glboard i napisać functional testy :)

Co w językach programowania i web developmencie piszczy

Od czasów, kiedy skończyłem studia bardzo interesowałem się rozwojem języka C++. Na początku bibliotkę Boost, w której ląduje co ciekawsze pomysły, które mają w przyszłości zagościć w języku a potem wersją C++0x. Dzisiaj spojrzałem na wsparcie dla składni C++0x w gcc-4.6 i powiem szczerze, że nie mogę się doczekać kiedy Ubuntu i Debian zostaną skompilowane na tym właśnie kompilatorze. Na razie nie jest dostępny na żadnej dystrybucji - niestety brak go również w paczkach Ubuntu 11.04, ale użycie tego kompilatora będzie szalenie ekscytujące.

Lista wszystkich zaimplementowanych nowinek jest dostępna tutaj: http://gcc.gnu.org/gcc-4.6/cxx0x_status.html

Mnie cieszą dwie: składnia dla for znana z python - gdzie iteruje się po elementach, nie po indeksach oraz lambdy - czyli funkcje nienazwane, które można przekazywać jako parametry.

W sumie powiem szczerze, że mam szaloną chęć napisać coś w C++ :) na przykład stronkę - jest framework Web Toolkit więc czemu by nie spróbować :] Jak się patrzy na listę możliwości to pojawia się UTF-8 i 16, HTML 5 native, async I/O, VML, SVG, PDF, PNG/GIF, SSL, TLS właściwie wszystko czego dusza zapragnie, a czym nie chwalą się żadnej inne frameworki należące do języków skryptowych, które borykają się z różnymi problemami w tej dziedzinie (ostatnio szczególnie frameworki Pythonowe). Można deployować przez FastCGI, postawić na dedykowanym serwerze dostarczonym z frameworkiem albo podpiąć do IIS. Brzmi super :)

C++ staje się naprawdę fajnym językiem, może mniej fajnym niż Go (z frameworkiem web.go) :) ale naprawdę wartym uwagi. Pozostaje czekać tylko czym będzie język Noop i cieszyć się z tego co przyniosą najbliższe lata :)

Jeżeli zaś ktoś chciałby popróbować development na wirtualnej maszynie to przychodzą mi na myśl wyłącznie Lift z języka Scala i z troszkę innej beczki :) ExpressJS dla języka Node.JS.

Jako ciekawostkę dodam, że jeżeli ktoś chce się nauczyć, w jakimś subiektywnym aspekcie języka "idealnego" to istnieje świetny kurs do języka Haskell pod tytułem "Learn You a Haskell for Geate Good!" . Web Development też jest wtedy możliwy - dzięki frameworkowi Snap.

O zapomniałbym. Ostatnio (no już trochę czasu minęło) Zed Shaw stworzył (ten gość chyba się po prostu nudzi) Tir - framework do web developmentu w języku skryptowym Lua. Co więcej wszystko w ramach projektu Mongrel2, który jest jeszcze bardziej imponującą kontynuacją znanego developerom Ruby On Rails serwera Mongrel - tym razem, w drugiej wersji wspiera chyba każdy język programowania.

Przy okazji - dla tych, którzy siedzą wciąż w świecie Python i Ruby. Jeżeli szukacie jakiegoś hiper wydajnego frameworka to nie tylko najnowszym i najnowocześniejszym w architekturze, ale również ewidentnie najszybszym jest Pyramid - jeżeli wierzyć wynikom z artykułu "The great web technology shootout – Round 4: Pyramid vs Django vs TG vs Rails 2 & 3" - bije na głowę dosłownie wszystko. Jednak jest to framework stricte w filozofii i podejściu wykorzystywanym w Pylons - i jego sukcesorem. Co miłe jest to "najszybciej wydany" framework w dziejach macro-frameworków jakie w życiu widziałem bo development zaczął się w Grudniu 2010 a pod koniec Stycznia 2011 wyszła stabilna wersja 1.0 - chociaż to troszkę naciągane bo projekt nie startował od zera ale był adaptacją już wcześniej wydanego Repoze BFG.

Zdradzę jeszcze, że dowiedziałem się iż na PyCon 2011 US, który odbywa się w Marcu odbywają się sprinty, które mają na celu portowanie Pyramid na Python 3 tak więc możemy mieć pierwszy framework działający na Py 3k :) Czy to nie ekscytujące?

Co w ostatnich tygodniach.

Dawno nie pisałem na blogu. Gdy jeszcze dzieliłem czas na studia i pracę starczało mi czasu na wszystko. Obecnie obcowaniem z komputerem staram się ograniczać do siedzenia przed nim w pracy, a wieczory i weekendy spędzać w inny sposób.

Ćwiczę Angielski. Umiałem go świetnie przed maturą, jednak studia inżynierskie skutecznie uwsteczniły mnie w tej materii. Jakiś już czas temu, bo w zeszłym roku, mój manager widząc braki, zorganizował spotkania z lektorką dzięki czemu wtorki i czwartki zaczynam lektoratem z języka angielskiego :) co skutecznie poprawia mi humor na pozostałą część tygodnia.

Co do języków programowania - wciąż używam Pytona, ze względu na jego znajomość zostałem zatrudniony i przez ostatnie 1,5 roku zostawiłem po sobie na tyle skryptów i aplikacji zapisanych w tym dialekcie, że ciężko codziennie się z nim nie stykać. Jednak moje marzenia i pasje kierują się w stronę Node.JS oraz wciąż zagadkowego dla mnie języka Scala.

Node.JS chciałem rozpocząć od przebrnięcia przez fantastyczny podręcznik do JavaScript "Eloquent JavaScript". Niestety, silnie funkcyjne podejście autora do sprawy skutecznie utrudnia mi przyswojenie lektury, a problemy zaczęły się już w rozdziale 4.

Co do Scala jest lepiej. Wiele zawdzięczam prelekcji Mikołaja Sochackiego Aplikacje webowe w Scala i Lift wygłoszonej na Zimowisku TLUGu. Sama prezentacja, jak i późniejsza wymiana doświadczeń w prywatnej rozmowie z prelegentem, pozwoliły mi dojść do wniosku, że trzeba przestać przejmować się, że "czegoś" nie rozumiem i opanować Scalę na miarę swoich możliwości - z czasem poznając ją może po prostu lepiej.

Tak też narodził się pomysł na prostego bloga, z przykładowymi aplikacjami w języku Scala, które skupiałyby się na konkretach i w prosty sposób pozwoliły na zapoznanie się z językiem. Co z tego wyjdzie - zobaczymy. Obecnie robię rozeznanie w silnikach, na których warto byłoby taki "blog" postawić. Z dotychczasowych poszukiwań wszystko wskazuje na Joggera - chyba, że znajdą się jakieś fundusze na zakup i utrzymanie domeny - wtedy będzie to Wordpress. Przy okazji trafiłem na Polski Portal Scala, na którym już w tej chwili można zapoznać się z niemałym zbiorem przykładów kodu w tym języku.

Jednak pierwszeństwo przed projektem Scalowym ma stworzenie Planety Pythona, którego podjąłem się niedawno w ramach mojej działalności w Polish Python Coders Group - wszak na koszulkę jakoś trzeba sobie zasłużyć :). Twarzą w twarz poznałem większość ekipy dopiero na PyCon.pl 2010 i co tu dużo gadać - są genialni. Kocham tych chłopaków za kawał dobrej roboty jaki odwalają, szczególnie na IRCu i Forum - uważam, że mamy fantastyczną scenę Pythonową w Polsce jakiej można tylko pozazdrościć i każdy kto chce zacząć przygodę z tym językiem nie mógłby sobie wymarzyć lepszej społeczności niż obecna.

Wracając do Zimowiska Linuksowego TLUG - było naprawdę fajnie. Dzięki zakwaterowaniu w Puckim HOMie czułem się jak na wczasach, do tego urok małego miasteczka jakim jest Puck - genialnie. Prelekcje były zróżnicowane, poziom wielu z nich naprawdę wysoki i profesjonalny. Szczególnie dało się to odczuć w prezentacjach Piotra Macuk, Tomasza Torcz (wiem, że gdzieś prowadzi bloga, ale nie mam adresu), Roberta Jaroszuk, Grzegorza Borowiak oraz Dariusza Puchalak. Subiektywnie jednak bardziej interesują mnie technologie webowe i ten charakter konferencji, która moim zdaniem była zaadresowana głównie do administratorów systemu Unix, nie przypadł mi specjalnie do gustu.

Co do spędzania czasu po pracy zagospodarowuję go w znacznej mierze treningami Aikido w Shoshin Dojo. I grubsza tyle z nowinek - wracam chorować :]