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.

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.

Wrażenia ze spotkania "Wprowadzenie do języka Scala"

Właśnie wróciłem z Uniwersytetu Gdańskiego gdzie uczestniczyłem w spotkaniu Trójmiejskiego Java User Group. Prelegentem był Łukasz Kuczera.

Idąc na spotkania miałem wobec niego ogromne oczekiwania. Liczyłem na to, że "ktoś nauczy mnie w końcu Scali" i "nie będę musiał się przedzierać przez 'Programming in Scala'". Jeszcze przed wejściem byłem mile zaskoczony gdy na korytarzu przed audytorium zobaczyłem osobą wertującą ową książkę.

Na samym początku w kilku słowach została omówiona historia języka, jego twórców oraz to jak ich doświadczenie z Javą wpłynęło na kształt oraz możliwości Scali. Po tym wstępie autor zaprezentował hierarchię klas w Scali oraz dostępne ad hoc metody i funkcje. Pokaz możliwości języka rozpoczął się od przykładowej implementacji klasy Rational. Prelegent skupił się na: używaniu metod klasy jak operatorów, wykorzystaniu funkcji require oraz stworzeniu konwertera intToRational. W między czasie przewijał się wątek funkcyjności Scali - chociaż pokazana została typowo od strony obiektowej.
W dalszej kolejności zostały zaimplementowane kolejki - z wykorzystaniem klas abstrakcyjnych, a zaraz po nich przyszła kolej na traitsy, z pokazaniem możliwości ich sekwencyjnego wywoływania. Nie zabrakło też przykładu implementacji Aktorów.

Konferencja była poprowadzona bardzo chaotycznie. Było to chyba winą tego iż "starano się przedstawić wszystko", zamiast skupić się omówić kilka interesujących fragmentów. Sprawozdawca wciąż skakał z tematu na temat, miotając się, jakby nie mogąc zdecydować o czym opowiedzieć (a o czym nie (sic!)).

Ponieważ spotkanie było dla członków JUGu, co krok ktoś (czy to prowadzący,czy ktoś z audytorium) próbował odnieść się do Javy. Porównania były czasem mniej, czasem bardziej trafne.

To co najbardziej mnie zaciekawiło to doświadczenia prelegenta z użyciem Scali w środowisku produkcyjnym. Przepisując na Scalę projekt, napisany wcześniej w Java, otrzymał on 5 MB (tak dokładnie - megabajtowy) Applet! Rozmiar pliku był zdeterminowany zawarciem w nim - poza kodem - również całego środowiska Scala :) (wszak przeciętnie użytkownik ma po swojej stronie tylko Javę). Po odnalezieniu metody minimalizacji jego rozmiaru (zmalał do 300 KB - mniejszy niż w przypadku Java) okazało się, że metoda zawodzi w przypadku używania Server Pages (jednak nie jestem do końca pewien czy dokładnie o tą technologię chodziło). Po obejściu problemu zaczęto dopisywać fragmenty kodu z użyciem Swinga. Tutaj jednak projekt został zawieszony. Nie udało się zmusić Scali do rysowania po elemencie canvas. Całość została przepisana ponownie do Javy. Jak wspomina sprawozdawca mogła to być wina po stronie teamu - jednak nie było czasu szukać rozwiązania i przyczyn problemu.

Ostatecznie spotkanie zakończyło się chwilę przed 19:30. Osobiście oceniam je jako bardzo owocne:) Po prelekcji miałem okazję zamienić kilka słów z autorem wykładu:) Bardzo ucieszyła mnie ogromna pasja i optymistyczne nastawienie do Scali;) Zostałem nawet podwieziony do domu:] Osobiście zastanawiam się czy samemu nie przygotować serii wykładów na ten temat - zobaczymy:)

P.S. Pomimo krytycznej oceny autor wpisu zna realia mieszanki adrenaliny i audytorium liczącego kilkadziesiąt osób i wie z jak wielkim stresem wiąże się stanie "po drugiej stronie". Dodatkowo prelegent poinformował o swoim nie najlepszym samopoczuciu - i przeprosił za ewentualne, wynikające z tego, komplikacje.

Jython - przydatny, bez szału

Wczoraj musiałem napisać malutką, multiplatformową aplikacyjkę. Chodziło o niewielką ikonkę w trayu, podpięte do niej menu z opcją "&Zamknij". Ikonka w zależności od zawartości pewnej witryny miała się zmieniać na kolorową lub czarnobiałą.

Z jednej strony chciałem napisać to w Pythonie: przenośność, prosta składnia, czytelność - po części znane mi biblioteki. Z drugiej nie chciałem użerać się z wxWidgets, którego w ogóle nie znam. Muszę przyznać, że moim faworytem do interfejsów jest zdecydowanie Java. Już samo Swing jest bardzo dobrze zaprojektowanym rozwiązaniem jednak jeżeli dorzucić do tego możliwość pisania kodu z SWT - bije chyba wszystkie inne rozwiązania na głowę. Ponieważ zależało mi na estetyce aplikacji pod wieloma systemami - Java wygrywała przede wszystkim na tym polu.

I tutaj pojawia się właśnie pomysł na użycie jythona. Idea okazała się bardzo prosta. Używanie składni Pythona do modułów Java. Na początku bardzo miłe zaskoczenie:

from org.eclipse.swt.widgets import *

po prostu szok. Normalna biblioteka Java a ja tu sobie ją importuję po pythonowemu. Super ! Zaraz potem mogłem sobie zrobić:

import urllib

i wszystko działało :) Zmiana implementacji pojawiła się przede wszystkim przy listenerach - gdzie nie mogłem tworzyć klas "in place" jak w Javie, ale musiałem tworzyć własne - dziedziczące po tych mi potrzebnych. Jednak to raczej wpłynęło na Pythonowo rozumianą czytelność programu. Co do struktury początkowej ten kto pisał w SWT na pewno się połapie:

class App(object):

    def __init__(self):

        """Główny kod aplikacji."""

        self.display = Display()

        self.shell = Shell(self.display)

self.setTrayIcon()

self.createMenuItems()

        self.timer = Timer(self.display, self.image, self.tray, self.trayItem)

        self.timer.checkIsUndoneTickets()

        self.display.timerExec(5 * 1000, self.timer)

        while not self.shell.isDisposed():

            if not self.display.readAndDispatch():

                self.display.sleep()

                

        self.display.dispose()

        

if __name__ == '__main__':

    App()

Moim zdaniem banalne i genialne zarazem :] Właściwie - to samo co w języku Java tylko zapisane z użyciem innej składni.

Niestety nawet w tak banalnym programiku odczułem kilka podstawowych rzeczy. Na początku chciałem użyć Timera Pythonowego. Nie mógł on jednak komunikować się  z wątkiem głównego programu - SWT. Cóż, zmuszony byłem wykorzystać ten SWTowy.

Kolejna rzecz. Mój program wymaga otworzenia domyślnej przeglądarki systemu. Po trafieniu na moduł webbrowser Pythona już się cieszyłem, gdy zauważyłem, że niestety w Jythonie jest on niedostępny. Tak więc zmuszony byłem po raz kolejny użyć Javy.

Desktop.getDesktop().browse(URI(ratunkuAdminURL))

Dodatkowo powyższy kod działa tylko po części tak jak chciałem. Otwiera mi firefox-a w systemie, w którym domyślną jest Chrome. Powyższy kod bazuje na składnikach przestażałej już w wielu miejscach biblioteki awt. Jestem ciekaw czy nie istnieje możliwość zrobienia tego samego lepiej w Java :]

Java - pierwsze spotkanie

PO laboratorium z Obiektowych Języków Programowania postanowiłem bliżej zapoznać się z językiem Java. Pomyślałem, że napiszę kolejnego G-mail notifiera: międzyplatformowego z natywnym interfejsem.

Java chyba nie ma sobie równych jeżeli chodzi o interfejs. Z biblioteką SWT Java staje się chyba bezkonkurencyjna pod tym względem choć już samo Swing pozawala na przenośność :] to SWT dodaje tej przenośności smaczku.

Kolejna rzecz, która cieszy to podstawowe operacje, elementy, klasy z których się korzysta są napisane tak iż korzystanie z nich to czysta przyjemność, szczególnie po moradędze z Visual C++ 2005. Wiele elementów z którymi w Visualu człowiek się męczył tutaj "po prostu działa". Język okazuje się wygodn, a proste programy pisze się błyskawicznie ponieważ można się skupić na pisaniu kodu a nie na szukaniu po sieci "jak to się robi i dlaczego nie działa ?".

IDE dla języka Java ... marzenie. NetBeans po prostu robi za nas wszystko chociaż i na Eclipse nie ma co narzekać - to jak na razie gdyby ktoś mnie zapytał co polecam poleciłbym NetBeans, prawdopodobnie dlatego, że Eclipse za słabo znam.

No dobrze - a teraz jak już tak nachwaliłem ... to teraz trzeba troszkę zganić, żeby było obiektywnie.

Po pierwsze: o ile Java jest super w zastosowaniach podstawowych o tyle przy późniejszych programach (TLS Sockets na przykład) zaczyna być ciężko. Są fora, na których społeczność naprawdę stara się pomóc, ale im temat bardziej specjalistyczny tym trudniej o pomoc, dokumentację, przykłady.

Po drugie: Instalacja bibliotek i używanie w swoich plikach bibliotek cudzych stanowi na początku pewien problem.

Inna sprawa. Ilość klas obecnych w Java może być dla kogoś zaletą (bo w sumie są klasy do wszystkiego), z drugiej strony czasem chciałbyś coś zrobić. Masz stringa, a metoda, którą chcesz użyć przyjmuje InputSource. Zaczyna się kombinowanie, myszkowanie po sieci jak z tego co masz uzyskać to co chce metoda... Ilość możliwości, opcji - wprowadza specyficzny nieład - jest tego po prostu za dużo... i gdy na początku można było się czegoś nauczyć... tutaj zaczynają się schody. Mylą się klasy, ich przeznaczenie i metody konwersji między nimi.

To w sumie tyle. Każdemu programiście polecam po programować troszkę w Java - naprawdę język uczy się na błędach protoplastów i wiele ułatwia. Polecam !

Base64 w Java

Spędziłem sporo czasu szukając biblioteki, która pozwoliłaby mi zakodować String w Base64. Ponieważ potrzebowałem tylko zakodować string idealna okazała się dla mnie biblioteka Igora Zhukovsky http://www.izhuk.com/painter/product/jsp/Base64.java

Uruchamianie aplikacji SWT pod Windows

Tutaj opis będzie banalnie prosty. Po ściągnięciu: http://archive.eclipse.org/eclipse/downloads/drops/R-3.3-200706251500/swt-3.3-win32-win32-x86.zip i rozpakowaniu przekopiowałem plik swt.jar do:

C:\Program Files\Java\jre1.6.0\lib\ext
C:\Program Files\Java\jre1.6.0_03\lib\ext

i wszystko pięknie działało :)

Dwa słowa o SWT

Co to jest SWT i o co tyle walki ?

Na uczelni uczono nas programować interfejs z użyciem biblioteki swing. Korzystaliśmy z narzędzia jakim jest NetBeans. Projektowanie interfejsu z użyciem swinga generowało okienka, rysowane piksel po pikselu, identycznie w każdy systemie, bez względu na to jak w danym systemie system okienek realnie wyglądał.  Oznacza to mniej więcej tyle, że jeżeli inaczej wyglądają okienka w Windows, inaczej w GTK a jeszcze inaczej w MacOS to z użyciem biblioteki swing okienka w każdym z tych przypadków wyglądałyby identycznie.

Inaczej jest z biblioteką SWT, w które wygląd okienek dopasowuje się do systemu w którym obecnie uruchamiamy aplikację. Ten sam program będzie wyglądał inaczej pod Windows, inaczej pod GTK inaczej pod MACami. Brzmi wspaniale nieprawdaż :) Zawsze lepiej jest mieć aplikację, do której wyglądu użytkownik danego systemu jest przyzwyczajony i która nie straszy swoją innością, choć nie mogę powiedzieć, żeby aplikacje pisane w Swing były nieschludne - poprostu są inne.

SWT w Ubuntu

Ostatnie kilka dni spędziłem na walczeniu z SWT w ubuntu. SWT to technologia dostępna w języku programowania Java pozwalajaca tworzyć interfejsy użytkownika wyglądające jak natywne okienka dostępne w systemie z którego korzystamy.

Na początku wpisałem sobie w synapticu SWT i zainstalowałem co następuje:

libswt3.2-gtk-gcj

libswt3.2-gtk-java

libswt3.2-gtk-jni

Paczka gtk-java zawiera pliki jar, zaś paczka jni pliki so. Później przyszedł czas na eclipse. Wiem, że na dzień dzisiejszy dostępna jest wersja 3.3, ale prawdopodobnie na moim poziomie zaawansowania nie zauważyłbym nawet różnicy w funkcjonalności :] więc zainastalowałem sobie:

eclipse

eclipse-jdt

eclipse-pde

eclipse-platform

eclipse-rcp

eclipse-source

Nie wiem czy to wszystko jest potrzebne, ale :) z tym wszystko działa w porządku. Oczywiście o:

sun-java6-jdk

nie wspomnę. Po zainstalowaniu tych wszystkich paczek mamy dwie opcje. Zrobić dowiązanie symboliczne w katalogu rozszerzeń jre do swt.jar tak, że będzie automatycznie lądowało w projekcie (wyglądał poprostu ładnie), albo dodawać do projektów w których korzystamy SWT za każdym razem zewnętrzne pliki JAR (pojawia się kolejna pozycja w menu). Jeżeli chcemy zrobić dowiązanie to w katalogu:

sudo ln -s /usr/lib/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_3.2.2.v3236.jar /usr/lib/jvm/java-6-sun/jre/lib/ext/swt.jar

Teraz uruchamiamy Eclipse wchodzimy do: Window\Preferences\Java\Installed JREs, zaznaczamy java-6-sun, wybieramy Edit..., Add External JARs..., wyszukujemy dowiązanie symboliczne /usr/lib/jvm/java-6-sun/jre/lib/ext/swt.jar, OK, OK, OK. Teraz pozostaje nam jeszcze ponowne uruchomienie Eclipse. Od tej pory wszystkie projekty jakie będziemy tworzyć będą posiadały możliwość używania SWT. 

Jeżeli chcemy samodzielnie dołączać SWT do projektu podczas tworzenia nowego projektu w widoku Java Settings w zakładce Libraries możemy wybrać Add External JARs i analogicznie do poprzedniego opisu dodać ją samodzielnie. Podaję kod przykładowej aplikacji:

package widok;

import org.eclipse.swt.widgets.*;

public class Okienko {
   public static void main(String [] args) {
     Display display = new Display();
     Shell shell = new Shell(display);
     shell.setText("Hello World !");
     shell.open();
     while (! shell.isDisposed()) {
          if(! display.readAndDispatch())
               display.sleep();
     }
     display.dispose();
   }
}

Podczas uruchamiania z menu Run\Run As musimy wybrać SWT Application.

Aby stworzyć plik jar z menu File wybieramy export Java \ Jar File, zaznaczamy nasz projekt i klikamy kolejno Next aby w widoku JAR Manifest Specification ustawić MainClass na widok.Okienko. Powiedzmy, że zapiszemy plik pod nazwą morficzneOkienko.jar

Ponieważ java nie wie gdzie dokładnie ma szukać sobie informacji o swt dlatego aplikację musimy uruchomić:

java -Djava.library.path=/usr/lib/jni -jar morficzneOkienko.jar

wskazując javie, gdzie znajdują się biblioteki potrzebne do uruchomienia naszego programu.

Aby móc cieszyć się SWT w NetBeans 6 klikamy w prawym panelu "Projects", klikamy prawym przyciskiem myszy na nasz projekt i wybieramy Properties. W części Categories wybieramy Libraries i w zakładce Compile:

/usr/lib/eclipse/plugins

Wybierzmy teraz Run i do pola VM Options wpiszmy:

-Djava.library.path=/usr/lib/jni

i już możemy cieszyć się SWT w NetBeans 6