Krzysiek vs. IT

Sprawdź to szybko z @Grapes

2010-01-26T23:08:00.005+01:00

W książce o Hibernate (którą sobie czytam) piszą, że uruchomienie Hibernate jest ciężkie i paskudne, bo trzeba dużo bibliotek zebrać, wrzucić na classpath i to wszystko skonfigurować. No, kilka ich jest. Jeszcze trzeba znaleźć w Internecie paczkę, ściągnąć, wybrać wymagane pliki itp. Wybrać jakąś bazę danych

To jest mało wygodne. To może maven? Hm, sprawdzam, integracja z Eclipse dalej leży choć wyraźnie się poprawiła w ostatnim roku, na Idea brak miejsca, Netbeans nie lubie. Hm, jeszcze jest Ivy...

Po analizie różnych rozwiązań, za najprostsze uznałem Grape. Grape to:

Deklaratywne zarządzanie zależnościami za pomocą adnotacji (@Grab).
To co potrzeba zostanie ściągnięte do lokalnego repozytorium i dorzucone do classpath w trakcie uruchamiania skryptu / klasy.
Obsługa linii poleceń – (grape install <groupid> <artifactid> [<version>])
Nic nie trzeba instalować jeśli ma się Groovy

Wystarczy deklaratywnie napisać czego nam potrzeba . Grape korzysta z Ivy, więc mamy dostęp do całego dobrodziejstwa znanego z repozytoriów Maven. Przykład z Hibernate:


package hello;

import javax.persistence.*;
import org.hibernate.*;
import org.hibernate.cfg.*;

//Wymagane zaleznosci:
@Grapes([
 @Grab(group='org.hibernate', module='hibernate-annotations', version='3.4.0.GA'),
 @Grab(group='hsqldb', module='hsqldb', version='1.8.0.7'),
 //niestety slf4j i javaassist trzeba dodać ręcznie bo w POM są pewnie jako opcjonalne (lub wcale), ale domyślnie wybierane przez Hibernate
 @Grab(group='org.slf4j', module='slf4j-simple', version='1.4.2'), 
 @Grab(group='javassist', module='javassist', version='3.4.GA')
])
@Entity 
class Book{
 @Id @GeneratedValue(strategy = GenerationType.AUTO)
 Long id
 String title
 String author
 String toString(){ "$title by $author" }
}

def prepareSessionFactory(){
 def config = new AnnotationConfiguration()
 [
  "hibernate.dialect": "org.hibernate.dialect.HSQLDialect",
  "hibernate.connection.driver_class": "org.hsqldb.jdbcDriver",
  "hibernate.connection.url": "jdbc:hsqldb:mem:demodb",
  "hibernate.connection.username": "sa",
  "hibernate.connection.password": "",
  "hibernate.hbm2ddl.auto": "create-drop",
  "hibernate.show_sql": "true",
  "hibernate.current_session_context_class": "thread"
 ].each{ key, value -> config.setProperty (key, value)}
 
 config.addAnnotatedClass(Book)
 config.buildSessionFactory()
}

def session = prepareSessionFactory().openSession();
Transaction tx = null;
try{
 
 tx = session.beginTransaction()
 def b = new Book(title:"Narrenturm",author:"Sapkowski")
 session.persist b
 tx.commit()
 
 tx = session.beginTransaction()
 Book b2 = session.createQuery("From Book").list().first()
 println b2
 tx = null
 
}catch(HibernateException e){
 if(tx != null) tx.rollback()
 println e
}finally{
 session.close()
}

Uruchamiam z poziomu Eclipse, można też wrzucić do GroovyConsole i uruchomić, wszystkie wymagane biblioteki powinny się ściągnąć same, przykład ze strony Groovy mi dział, a ten nie... To znaczy ściąganie działa, ale Hibernate nie. Z poziomu Eclipse mi to działa, z GroovyConsole wyskakuje za to błąd dostępu do pól, ciekawe... Pewnie kwestia generowania kodu. Na razie działające Eclipse z podpowiadaniem kodu mi wystarcza, no i mały skrypt co kopiuje wszystkie biblioteki ściągnięte przez Grapes do Eclipse ;)

Update

2010-01-26T15:29:00.001+01:00

No i minęło pół roku od ostatniego wpisu. W między czasie skończyłem studia w Polsce, pojechałem do Szwecji, tam właściwie też studia skończyłem, wróciłem, chwila odpoczynku, zachorowałem i wylądowałem na 3 antybiotykach... Teraz się doleczam i myślę, że najwyższa pora wrócić do tak zwanej "rzeczywistości".

Pracę magisterską oceniono mi na 5, a ja uważam ją za osobistą porażkę. Zabawa trwała za długo i za dużo mnie kosztowała. Przez ostatnie mniej więcej 1,5 roku zajmowałem się zabawkami na ogromnym poziomie abstrakcji. W Polsce znam tylko jedno miejsce gdzie korzystają z tych samych zabawek ale do czego innego (z pozdrowieniami dla Grześka ;) ). Praca w tym też jest tylko, że w Niemczech, Francji, Kanadzie ;) Po wstępnych badaniu kogo szukają we Francji ostatecznie stwierdziłem, że na razie nie chce wyjeżdżać.

To z kolei oznacza, że pora przypomnieć sobie Hibernate, nauczyć Spring itp.

Revenge of the Modelers !

2009-07-31T21:04:00.001+02:00

Jeśli nie lubicie modelowania to mam dla was złe wiadomości… poniżej. Najpierw małą dygresja.

Wakacje wakacjami, jednak przygoda z Erasmusem kończy się dla mnie ich brakiem (przynajmniej do września). Szkoda, bo dzieje się dużo. Moda na nowe języki jak Groovy, Scala czy nawet Clojure jest w pełni... I choć uważam Scala za nie najlepszy język to i tak pewnie będę się go uczył bo
a) jest statycznie typowany z inferencją typów i domknięciami
b) Java 1.7 domknięć nie będzie mieć
c) Groovy jest wyłącznie dynamicznie typowany
d) Fan jest fajny, ale stara się za bardzo być wieloplatformowy, a ja chcę po prostu lepszą Java, chociaż...

No i dalej nie ma dobrego języka na JVM!

Ps.:
Lepsze wsparcie dla Groovy w Eclipse
http://blog.springsource.com/2009/07/30/a-groovier-eclipse-experience/
Cywilizowane wymienienie czym Fan się wyróżnia
http://fandev.org/sidewalk/topic/675

Wracając do tematu,
Jakiś czas temu wyszedł Eclipse 3.5 - http://eclipse.org/galileo/projects.php. Jeśli ktoś przeglądnie listę projektów, to zauważy 17 linków do projektów związanych ściśle z modelowaniem. W Galileo mamy nowe wersje między innymi: Acceleo, ATL, EMF, CDO, JET2, GMF, OCL, Net4J, UML2, Teneo, QVTo, Xpand i Xtext. To nie wszystkie ciekawe projekty z działu modelowanie.

Przyszły Eclipse 4 jest w całości oparty na modelach, wersja alfa (e4 0.9) jest dostępna do testów. E4 to między innym model Workbench (perspektywy, komendy, okienka, to wszystko jest modelem, który można w dowolnym momencie zmienić), deklaratywne SWT -> XWT (taki odpowiednik HTML ale dla SWT, czyli kopia XAML), port SWT na Flash(Flex właściwie) ze wsparciem Draw2D więc, definiowanie wyglądu aplikacji SWT za pomocą CSS, wsparcie dla "dowolnego" języka przy pisaniu pluginów (JavaScript z pudełka), wsparcie dla DI wbudowane w platformę. Nowa platforma ma też zmiany w swoich wnętrznościach i właściwie nie widzi różnicy w tym, czy działa przez web, czy działa stacjonarnie, czy lokalnie, czy rozproszona :)
http://download.eclipse.org/e4/downloads/drops/R-0.9-200907291930/e4-news-all.html

Eh, i pojawia się problem - coraz więcej projektów Eclipse jest oparta lub wykorzystuje EMF (Eclipse Modeling Framework), a jest spory problem w tłumaczeniu co ta biblioteka właściwie robi. Nawet jej twórcy nie bardzo wiedzą jak ją sprzedać. No bo jeśli powiem komuś, że jest to meta metamodel z mapowaniami do Java(generacja kodu), XML Schema i UML to
a) przesadnie uproszczę temat i pominę dużo
b) słuchający ucieknie z krzykiem jak usłyszy "meta metamodel" i "generacja kodu"

Modele już nie czają się w krzakach. One atakują. Nowe projekty jak Microsoft Oslo i Quadrant, Eclipse Modeling Framework z Xtext i starym GMF, czy JetBrains MPS znalazły nową broń marketingową - DSL.

EMF nie zna litości, gdy ma się stworzony model, to nie dość, że można go bez problemu zapisać w pliku XML o dość dowolnej strukturze, to można go zapisać w pliku XMI, który każde narzędzie wspierające EMF potrafi otworzyć i edytować. Co gorsza taki model może być zapisany w zwykłym pliku tekstowym(XText), który wygląda jak nie pozorny język lub konfiguracja i jest czytelniejszy niż kod albo XML! Może też być obrazkiem jak diagram klas, albo encji(GMF). EMF również kpi sobie z baz danych i pozwala bez dodatkowej pracy się w nich przetrzymywać (Teneo, CDO), jeśli chce to nawet można zmienić zasady zapisu do bazy danych za pomocą Hibernate lub EclipseLink i ich mapowań. EMF ignoruje fakt, że pamięć jest ograniczona, a użytkownicy rozproszeni. Pozwala pracować na modelach większych niż dostępny ram, na dodatek w dowolnej lokalizacji, wielu użytkownikom równocześnie (CDO). Aplikacja E4 RCP mogłaby mieć model UI trzymany na serwerze i wtedy można by go zdalnie zmienić, a wszyscy użytkownicy systemu natychmiast mogli by zobaczyć zmiany w swoim interfejsie!

Ciężkie czasy idą ;)

Oracle = Java

2009-04-20T14:58:00.003+02:00

Oracle kupił SUN - http://www.sun.com/third-party/global/oracle/index.jsp

Hm, no to jedna firma kontroluje bazy danych - Oracle i MySQL. To co teraz z DB2 zrobi IBM? MS SQL da sobie jakoś radę.

Pojawia się kilka zabawnych konfliktów, do rozwiązania:

Oracle nie wydaje mi się firmą sprzętową
Solaris i Linux, może Oracle przestanie kopiować RedHat Linux?
Netbeans, JDeveloper i Eclipse. Oracle sam komituje sporo do Eclipse (EclipseLink, WebTools), a po kupnie BEA posiada komercyjne IDE oparte na Eclipse więc przewiduje dalszą migracje do Eclipse.
JavaFx, JavaMe i Oracle? Brzmi dziwnie.
Glassfish i Bea WebLogic.

Dobrze zapowiada się rozwój JSF jak i JVM. Mam nadzieje, że Oracle docenia nowe języki jak Groovy.

No to teraz IBM powinien też kupić coś ciekawego, może SpringSource albo RedHat?

ps. No to oczekuje teraz Oracle PaaS albo Oracle Cloud Database etc.

Google App Engine + Java, Groovy...

2009-04-08T09:46:00.003+02:00

Zgodnie z przewidywaniami Java jest już obsługiwana przez App Engine, na razie dla wybranych.

http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html

a najlepsze w tym jest oczywiście

http://blog.springsource.com/2009/04/07/write-your-google-app-engine-applications-in-groovy/

Grails jeszcze nie działa.

Ogólnie mamy http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine

W praktyce nowe obsługiwane języki to Groovy, Scala, Jytho, JRuby i Rails, JavaScript(Rhino)!

I po co w ogóle zaczynali samego Python-a? Nie ma praktycznie potrzeby dodawać już innych jezyków, wystarczy popracować nad wsparciem Java.

Odnośnie samej Java to:

Servlety 2.4, JSP, JSTL, JPA, JDO, Java Mail...

Nie wiadomo co z JSF, Spring działa częściowo, Struts nie działa, Hibernate i podobne również nie. Może takie projekty jak Seam zajmą się wsparciem GAE.

Przy okazji Groovy, polecam artykuł

http://www.codethinked.com/post/2009/04/05/Do-We-Create-Type-Systems-In-Dynamic-Languages.aspx

Moim zdaniem to działa w dwie strony. W językach dynamicznie typowanych tworzymy w testach coś co w dużej mierze sprawdza nam typy i mimo, że sprawdza je dynamicznie, to i tak pewna część kodu nie była by potrzebna. Nie widać tego, bo języki dynamiczne mają przeważnie ciekawszą składnie. Z drugiej strony w językach statycznie typowanych wdrażamy przeważnie dynamizm "kodując" w String-ach.

Groovy i Scala i C# 4 to ciekawe przykłady zmian. W Groovy można opisywać typy, ale dalej nie jest to statyczna typizacja. Scala jest statycznie typowana ale z silnym odkrywaniem typów. Ma dodatkowo składnie równie silną jak w językach dynamicznych (choć trochę przegieli) .

C# 4 to język silnie typowany z możliwym odkrywaniem typów i typami anonimowaymi (wszystko to plus lambda wyrażenia i budowa drzew składni jest potrzebne by LINQ mógł istnieć). Dodatkowo od wersj 4 będzie można powiedzieć, że wybrany element jest "dynamiczny"...

http://blogs.msdn.com/cburrows/archive/2008/10/27/c-dynamic.aspx

Dropbox - kontrola wersji dla nie programistów

2009-03-14T21:59:00.002+01:00

Systemy kontroli wersji są dobre, są też w pełni darmowe http://xp-dev.com i prawie darmowe http://assembla.com rozwiązania.

Jednak ludzie spoza IT z nie znanych mi powodód SVN nie akceptują ;)

Dropbox to aplikacja która pozwala na synchronizowanie danego folderu między wieloma komputerami wraz z kopią w internecie. Darmowa wersja pozwala na przechowywanie 2 gb danych i trzyma historię ich zmian.

Dropbox pozwala na współdzielenie folderów (ludziki na folderze Magisterka), udostępnianie folderu publicznie w internecie (jak również widać na rysunku) i teoretycznie działa na Windows, Linux i Mac.

Wystarczy zapisać dowolny plik w odpowiednim folderze, a ten automatycznie zostanie wysłany do internetu i synchronizowany z zarejestrowanymi komputerami.

W internecie możemy przeglądać pliki (włącznie z ich historią)

A zdjęcia są dostępne w postaci galerii, którą również można opublikować

Można uzyskać dodatkowe 250 MB dla siebie (i dla mnie) korzystając z tego linku:

https://www.getdropbox.com/referrals/NTQ4NDY0Mzk

Eclipse CDT i inne narzędzia do C++

2009-03-10T15:10:00.002+01:00

W zeszłe wakacje miałem ciekawy projekt i właśnie znalazłem zaległy post z tego czasu :)

Po 3 lata z Java i C# można zapomnieć co to jest segmentation fault albo destruktor. Jednak język to tylko narzędzie, jedno z wielu, a jeden telefon może sprawić by znów używać najlepszy i najgorszy z języków jakim jest C++. Na miejscu zbrodni zastałem Visual Studio 6. No tak, w sumie w zakresie C++ w Visual Studio względnie nie wiele się zmieniło przez te 10 lat, chociaż teraz jest to produkt darmowy również do zastosowań komercyjnych (trochę okrojony). W VC6 już pierwszego dnia, zaraz po ustawieniu środowiska i integracji z CVS (czyli instalacji WinCVS. Trudno o dobry plugin do jakiegokolwiek systemu kontroli wersji dla VS), przestała działać nawigacja po kodzie i autocompletion (lub jak kto woli IntelliSense). Wystarczy usunąć jeden plik i znów działa. Hmm, czekaj czekaj gdzie są zakładki w tym narzędziu? Nie znalazłem. Po trzech dniach uznałem, że cała gadanina o tym, że Java jest wolna nie może być dalsza od prawdy. Ctrl+S w VC6 oznacza, że mogę iść po wodę, po zmianie jednego pliku kompilacja oznacza, że mogę iść zrobić kawę. Problemu z Ctrl+S nie zniosłem, bo mam zwyczaj często ten skrót używać i pisać dalej, a nie czekać min. 30 sekund aż mi środowisko zacznie odpowiadać (nie VS6 nie ma czegoś takiego jak autobuild, nie ta liga, ot tak się po prostu działo). Pora poszukać alternatywy. Dawno, dawno temu używałem DJGPP, później prawdopodobnie największego przegranego wśród zwycięzców: bardzo dobrego C++ Builder 6. Również Dev-Cpp(ciekawe, wersja 5 jest wersją beta od przynajmniej 4 lat) i całkiem udany Code::Block który o ile dobrze pamiętam świetnie integrował się z darmowym kompilatorem od Borland. Oprogramowanie zmieniało się w razie potrzeby, odgórnej dyrektywy, dostępności licencji, ramu i wyposażenia biblioteki, stąd spora liczba środowisk których używałem (pomijając linuxowe jedno-projektowe przygody jak Anjuta). Przyszedł też czas na VS 2003 i skończyło się na VS 2005 - to było moje ostatnie środowisko, w którym używałem C++. Może przy okazji dam jeszcze szansę VS 2008. W omawianym zleceniu okazało się, że Notepad++ jest bardziej ergonomiczny niż VC6. Czasem lekki edytor jest wszystkim czego potrzeba. Przynajmniej póki tworze kod. Brakowało mi jednak możliwości efektywnego przeglądania tego co jest napisane (a jest tego dużo). No i czy naprawdę muszę odpalać kompilację, by dostać stos głupich błędów z powodu braku średnika ? Pora poszukać lepszego rozwiązania.

W praktyce z darmowych narzędzi polecam uwadze:

Eclipse CDT - systemy wbudowane, oprogramowanie dla Linux i podobnych, oraz jako "lekki" edytor plików cpp.
VS 2008 - oprogramowanie dla Windows, gry (choć wszędzie lepiej pasuje płatna wersja :) )
Code::Blocks - wszędzie ;) - lekkie choć kompletne IDE na różne platformy
MonoDevelop - Linux i/lub GTK, wygląda bardzo obiecująco - prosty i wystarczający, nie miałem okazji używać.

VC2008 odpadło z przyczyn środowiskowych. Zostaje Code::Blocks i Eclipse CDT. Już na wstępie Code::Blocks ma przewagę - obsługuje wszystkie sensowne kompilatory i projekty za równo VS jak i Dev-Cpp. Eclipse w praktyce wymaga gcc i gdb, na Windows działa to marnie i potrzeba Cygwin lub Mingw, a projekty portować trzeba ręcznie. Z drugiej strony Eclipse mogę wpiąć jako edytor w projekt nie zmieniając oryginalnego projektu, dalej mam dużo ciekawych. Niestety brak kompilacji i debug. Ostatecznie korzystałem z Notpad++ do szkicu kodu (tydzień pisania samego pseudokodu dla pierwszej wersji algorytmu :) ), Eclipse CDT do edytowania / chodzenia po kodzie i Visual Studio do kompilacji i debug. Eclipse CDT ma własny parser i stara się równać poziomem do JDT. To nie jest proste ze względu na specyfikę C++. Mimo to dostaje się mnóstwo dobrych dodatków jak śledzenie "include" (które bierze pod uwagę stan zmiennych preprocesora), nawigacja po kodzie metodą Ctrl+Click, inteligentne podpowiedzi edytora, wyszukiwanie elementów, podstawowy refactoring, outline, Mylyn itp.

Linki:

http://kwesoly.net/programowanie/cpp/eclipse-cdt/

http://wascana.sourceforge.net/

W czym pisać "poważny artykuł" i jak to robić w grupie?

2008-10-10T00:49:00.001+02:00

Zanosi się na to, że praca magisterska będzie dla mnie projektem grupowym. Właśnie w dwuosobowym zespole przechodzimy pierwsze szlify, a to u mnie zawsze oznacza wybranie zabawek do skrzynki narzędziowej.

Z raportami / artykułami pojawia się parę problemów:

Zarządzanie bibliografią
Zarządzanie odniesieniami do bibliografii, figur, tabel etc.
Dbanie o wygląd całości
Dbanie o zgodność wyglądu i struktury z narzuconymi wymaganiami

Zajmowanie się poprawnością zarówno merytoryczną jak i wizualną jest męczące, a współczesne procesory tekstu wcale nie poprawiają tutaj sytuacji. Mimo zaawansowanych opcji do pracy grupowej jak porównywanie wersji, komentarze i rozwiązania do tworzenia linków, tabel, spisów treści, bibliografii i obsługi stylu... zawodzą. Jeśli artykuł jest krótki i zmiany wprowadzane są we względnie dużych odstępach czasu, to najbardziej znane oprogramowanie może się sprawdzić, a różne wersje można przesyłać mailem i korzystać z opcji ich porównania i komentarzy. W taki sposób pisałem ostatni "poważny" artykuł i poza problemem z trzymaniem się szablonu (który przychodził z własnymi makrami do formatowania) innych tym razem nie było.

Jednak dalej nie wszystko mi pasowało, więc przy kolejnej okazji spróbowałem czegoś innego. Informatyka twierdzi, że "Separation of Concerns" jest dobre, tak więc warto przetestować to i w tym wypadku.

Ostatecznie pudełko składa się z:

LaTeX + BibTex
SVN + Trac
Eclipse + Texlipse + ECF (Cola) + Subversive
Lyx

Wybór LaTeX-a pozwala zapomnieć o problemach zgodności z szablonem, właśnie dzięki oddzieleniu zawartości od opisu wyglądu. Wyglądu zwykle się tu nie opisuje ale znajduje odpowiednią klasę (na 95% jeśli gdzieś wymagają zgodności z szablonem od informatyka, to istnieje odpowiednia klasa LaTeX). Trzeba poświęcić odrobinę czasu by nauczyć się LaTeX-a, ale by prawidłowo używać współczesnego edytora tekstu trzeba go nie mniej. BibTex pozwala mi trzymać wszystkie referencje z każdej pracy w jednym miejscu. Referencje są tworzone tylko do tych źródeł, które rzeczywiście w aktualnej pracy używam. W każdej pracy są wyświetlane stosownie do wymaganego stylu. SVN pozwala na wygodną pracę grupową z porządną historią wersji, a LaTeX jako plik tekstowy idealnie się nadaje do wrzucenia na SVN. Trac z kolei pozwala na zarządzanie SVN, tworzenie planu i prowadzeniem wiki. Na naszym wiki pojawiły się definicje i opisy, które nie trafiły do aktualnego dokumentu, zbieramy wszystko co może nam się przydać w przyszłości w jednym, bardzo wygodnym miejscu. Wybór Texlipse pozwala na integrację edytora do LaTeX-a z SVN, jednocześnie z dodatkiem ECF można niektóre zmiany dyskutować na "żywo" (więcej [tutaj]). Czasem przeglądanie czystego TeX-a męczy, więc do przeglądu i poprawek używam Lyx, który na bieżąco edytuje przybliżony podgląd dokumentu jednocześnie nie pozwalając na nieprawidłowe formatowanie.

W efekcie otrzymuje się profesjonalnie wyglądający i po prostu ładny dokument.

Aktualności

2008-09-26T14:36:00.007+02:00

Całkiem sporo się stało w ciągu miesięcznej przerwy od bloga. Zakończyłem jeden projekt, zmieniłem tymczasowo miejsce mojego przebywania z Wrocławia na Szwecję, a Microsoft dołącza do OMG.

Ad. 1

Projekt uświadomił mi, że czasem istnieje potrzeba by używać C++ i Visual Studio 6. O ile obawiałem się jak będzie z powrotem do C++ po ostatnich miesiącach Java i .Net, o tyle problemem nie był język, ale środowisko VS 6. Jeśli ktoś musi korzystać z Visual C++ to i tak (w pełni świadomy tego co mówię) polecam Eclipse CDT. Nie ma co liczyć również na nowe wersje VS, wygląda jakby rozwój wsparcia dla C++ (zwłaszcza klasycznego, nie zarządzanego) się zatrzymał. Eclipse okazał się znacznie lepszym edytorem, zwłaszcza przy okazji przeglądania kodu (np. przeglądanie #include,
śledzenie referencji biorąc pod uwagę stan zmiennych preprocesora i mnóstwo innych drobiazgów). Mimo to w pracy używałem do kompilacji Visual Studio. Swoją drogą jeśli jest wystarczająco dużo RAM(minimum 512) to Eclipse jest odczuwalnie szybszy od VS6 (choć to jest bardzo dyskusyjne, bo część działa szybciej, część wolniej i pewnie zależy co kogo irytuje), ale przełączanie się na niego z innego programu, potrafi zająć trochę czasu.

ps.
Myślę, że normalna firma nie zaakceptuje Eclipse w projektach VS6 do póki nie pojawi się integracja z kompilatorem innym niż gcc i poprawi możliwość migracji projektów. Samo uruchomienie Eclipse CDT na Windows nie jest bezproblemowe. Polecam projekt Wascana – dystrybucja Eclipse razem z kompilatorem, która po prostu działa. Dodatkowo w Wascanie planowana jest integracja z kompilatorem Visual C++ (kompilacja, debug etc.), czyli większość tego, czego teraz brakuje.

Ad. 2

Trafiłem chwilowo na studia do Szwecji. Prowadzący przedmiot Software Architecture stwierdził, że studia w Szwecji można przedstawić tak:

Studia:

Nauka

Zabawa Sen

Wybierz dwa.

Można też zrobić funkcjonalność - budżet - czas. Polscy studenci doszli do wniosku, że w Polsce,
przynajmniej na PWr / IZ / IO można wybrać co najwyżej jedno.

Ad. 3

Microsoft i OMG? Dla mnie jest to bardzo istotna zmiana postawy. Podobno MS chce zacząć wspierać UML, a przede wszystkim zależy im na modelowaniu za pomocą DSL. Jeśli MS zdecydowałby się na wykorzystanie XMI i MOF to wtedy niewielkim nakładem pracy, wszystkie projekty powstałe w ramach Eclipse i inne związane z MDA będą mogły współpracować z Microsoft DSL Toolkit, który intensywnie się rozwija [DSL Tools, Software Factories and Oslo - Model-driven the Microsoft .NET way]. DSL Toolkit jest aktualnie jednym z najbardziej dostępnych narzędzi do tworzenia graficznych języków dziedzinowych. Nie ma praktycznie możliwości przekształcania między modelami (co zrozumiałe zwarzywszy na podejście) i ma totalnie archaiczny język do generowania kodu T4 (myślałem (zresztą nie ja jedyny) by spróbować połączyć oAW i DSL Toolkit).

Groovy w praktyce - part 6 - przykład z ANT, XML i plikami

2008-08-16T14:13:00.008+02:00

Pewnego dnia czekało na mnie czterdzieści parę projektów do statycznej analizy kodu. Pojawił się problem, ponieważ projekty pochodziły z SVN, wszystkie nazywały się tak samo i miały nie wygodną strukturę folderów. By policzyć metryki musiałem wszystkie projekty zaimportować do Eclipse. Groovy był wtedy na mojej liście narzędzi, które chce dodać do swojego pudełka. Poniższe skrypty powstały w około 30 - 40 minut wraz z nauką Groovy od zera i szukaniem odpowiednich poleceń ANT. Były pierwsze linijki kodu jaki napisałem w Groovy i wklejam je w wersji oryginalnej. Warto zauważyć, że Groovy jest produktywny już od momentu zaczęcia nauki. Skrypty pisane były w GroovyConsole.

Skrypt I
Kopiuje pliki \pXX\project\* bezpośrednio do \pXX\*

def f = new File("E:\\Pomiary")
AntBuilder ant = new AntBuilder()

f.eachDir{ dir_pXX ->
print(dir_pXX)

dir.eachDir{d -> if(d.name == "project"){
  ant.move(todir: dir_pXX){
     fileset(dir: d, defaultexcludes: "no") {
        include(name: '**')
     }
  }
}
}

AntBuilder to klasa pozwalająca na używanie zadań Ant bezpośrednio w kodzie Groovy. Korzysta z kilku przedstawionych wcześniej map i domknięć. W wyrażeniu

ant.move(todir: dir_pXX){
fileset(dir: d, defaultexcludes: "no"){
  include(name: '**')
}
}

Wszystkie nawiazy klamrowe to domknięcia, a wszystkie parametry funkcji:

dir: d, defaultexcludes: "no"

to definicja mapy. Takie budowanie struktur jest powszechne w Groovy, nazywane Builder i dostępne przykładowo dla Swing i wielu innych struktur drzewiastych.

Skrypt II
W każdym ze skopiowanych folderów znajduje się projekt Eclipse o nazwie "project". Nie można importować kilku projektów o tej samej nazwie do Eclipse więc potrzeba te nazwy zmienić. Nazwa projektu jest zdefiniowana w pliku xml, przy odrobinie szczęścia wystarczyłoby podmienić za pomocą wyrażenia regularnego wystąpienia "project". No ale wtedy nie sprawdzimy jak Groovy radzi sobie z XML.

def f = new File("E:\\Pomiary")
f.eachDir{ dir ->
dir.eachFile{file ->
  if(file.name == ".project"){
     def projectDescription = new XmlParser().parseText(file.getText())
     projectDescription.name[0].value = dir.name
     def writer = new FileWriter(file)
     new XmlNodePrinter(new PrintWriter(writer)).print(projectDescription)
  }
}
}

Zauważyliście File.getText()? Małe a cieszy. Najciekawszą linijką jest linijka

projectDescription.name[0].value = dir.name

Groovy pozwala na korzystanie podstawowych wyrażeń XPath bezpośrednio w języku. Po tak wybranych elementach można się iterować z pomocą each, można pobierać lub przypisywać im wartość. Odwołanie do atrybutów też jest możliwe np. node.'@atrybut'. Nie wszystko da się zapisać tak samo jak w XPath, ale produktywność jest wspaniała. Może o XML napisze więcej w innym poscie.

Skrypt III
Plug-in liczący metryki zapisywał wyniki w folderach analizowanych projektów, więc jeszcze mały skrypt co zbierał wyniki w jedno miejsce.


def f = new File("E:\\Pomiary")
def ant = new AntBuilder()

f.eachDir{ dir ->
    dir.eachFile{file ->
           if(file.name == "results.xls"){
                  ant.copy(file: file,toFile: new File("E:\\Pomiary\\Wyniki\\${dir.name}.xls"))
           }
    }
}

Linki
Podstawy Groovy i ANT
Więcej informacji Ant Fileset, Ant Move, klasa File
Inne przykłady pracy z plikami Groovy i Pliki

ps. To były pierwsze kroki z Groovy i całkiem sporo elementów w tych prostych skryptach da się zrobić lepiej. Najbardziej mnie drażni w tym starym kodzie korzystanie "\\" i nie korzystanie z choćby File.eachFileMatch.

Groovy w praktyce - part 5 - mapy 2/2

2008-07-31T19:01:00.006+02:00

Pora wrócić do Groovy po drobnej przerwie.

Pewną szczególną cechą Groovy jest podejście do interfejsów w połączeniu z mapami i domknięciami. Tym razem włączam groovyConsole i...

interface Kaczka{
void kwa()
void lataj()
}

def PrawieJezioroLabedzie(Kaczka k){
6.times{k.kwa()}
}

def mapa = [ kwa:{println 'kwa'}, lataj: {println 'ja latam!'} ]
def kaczka = mapa as Kaczka

if(kaczka instanceof Kaczka){
PrawieJezioroLabedzie(kaczka)
kaczka.lataj()
}

Wynik:

kwa
kwa
kwa
kwa
kwa
kwa
ja latam!

To przecież jakaś herezja ! Dynamicznie tworzę instancję interfejsu za pomocą zawartości mapy. Jak to możliwe? W Javie od wersji 1.3 można dynamicznie tworzyć nowe implementacje klas i interfejsów! Jest to możliwe za pomocą Dynamic Proxy, łatwo można sprawdzić, że Groovy wykorzystuje ten mechanizm.

println java.lang.reflect.Proxy.isProxyClass(kaczka.class)

Wynik:

true

Wstrzykiwanie zależności, aspekty, zarządzane ziarna, binding, rmi ... wszystko to wykorzystuje dynamic proxy. Ma to swoje minusy. Proxy, jak przystało na twór dynamiczny, będzie wolniejszy od normalnej klasy. Jest to cena warta zapłacenia, jeśli chcesz stworzyć jakikolwiek zarządzany komponent to trudno nie wykorzystać proxy. .Net ma podobny twór o mniejszych możliwościach (bo m.in. w C# metody są domyślnie nie wirtualne, takiego wywołania nie można dynamicznie przechwycić, więc tylko niektóre metody proxy może implementować).

Można też rzutować pojedyncze domknięcie na interfejs

PrawieJezioroLabedzie({println "ćwir"} as Kaczka)

Wynik:

ćwir
ćwir
ćwir
ćwir
ćwir
ćwir

Wtedy wszystkim funkcją interfejsu zostanie przypisana jedna akcja. Co ciekawe niektóre z propozycji domknięć dla Java pozwalają na niejawne zamienianie domknięć na interfejsy. Jest to niebywale wygodne, gdy definiujemy zdarzenia np. w GUI.

Groovy sprawdza w trakcie wykonania typy obiektów dlatego poniższy kod jest nie poprawny.

PrawieJezioroLabedzie(mapa)
// powoduje
Exception thrown: groovy.lang.MissingMethodException: No signature of method: Script12.PrawieJezioroLabedzie() is applicable for argument types: (java.util.LinkedHashMap)

Jeśli jednak usunę informację o oczekiwanym typie z parametru funkcji, to funkcja nie będzie widzieć różnicy między klasą, a mapą i w obu przypadkach wykona się poprawnie.

def PrawieJezioroLabedzie(k){
6.times{k.kwa()}
}

PrawieJezioroLabedzie(mapa)

Wynik

kwa
kwa
kwa
kwa
kwa
kwa

Więcej w implementacja interfejsów w Groovy

Groovy w praktyce - part 4 - mapy 1/2

2008-07-30T22:34:00.007+02:00

Mapa w Groovy jest reprezentowana przez zwykłą klasę Javy, używać ją można jak zwykłą mapę, klasę asocjacyjną, a nawet obiekt.

groovy> a = [:]
===> {}

groovy> a.getClass()
===> class java.util.LinkedHashMap

// iteracje po mapie mozna wykonac na kilka sposobow
groovy> a = [a:'aa',b:'bb']
===> {a=aa, b=bb}

groovy> a.each{println it}
a=aa
b=bb
===> {a=aa, b=bb}

groovy> a.each{println it.key}
a
b
===> {a=aa, b=bb}

groovy> a.each{println it.value}
aa
bb
===> {a=aa, b=bb}

groovy> a.each{ key,value -> println key + ' - ' + value }
a - aa
b - bb
===> {a=aa, b=bb}

// ustawianie i odczytywanie elementów jest proste,
groovy> a.a
===> aa
groovy> a.b
===> bb
groovy> a.c
===> null
// ale z powodu takiej konwencji a.class == null, dlatego wcześniej użyłem getClass()


// na mapie można bezpośrednio tworzyć nowy element  w analogiczny sposób
groovy> a.c = 'cc'
===> cc
groovy> a
===> {a=aa, b=bb, c=cc}
groovy> a['d'] = 123
===> 123
groovy> a
===> {a=aa, b=bb, c=cc, d=123}

groovy> a.keySet()
===> [a, b, c, d]
groovy> a.values()
===> [aa, bb, cc, 123]

Klucz w mapie domyslnie jest traktowany jako string, chyba ze jest liczbą, wartością logiczną lub null.

groovy> b = [1:1,a:2]
===> {1=1, a=2}
groovy> b[1]
===> 1
groovy> b['a']
===> 2
groovy> b.'1'
===> null
groovy> b[a]
===> null

Jeśli chcemy jako klucz użyć coś innego niż liczbę czy string to możemy użyć notacji tabeli asocjacyjnej mapa[obiekt], albo nawiasów():

groovy> x = [1,2]
===> [1, 2]
groovy> y = [ (x):'abc' ] //dzieki nawiasom w tym przypadku kluczem będzie lista
===> {[1, 2]=abc}
groovy> y.keySet()*.getClass()
===> [class java.util.ArrayList]
groovy> y.each{println it.key[1]}
2
===> {[1, 2]=abc}

Jeśli mapa jest parametrem funkcji to większości przypadków można porzucić nawiasy []

groovy> f = {mapa -> mapa.values().each{ println it }}
===> groovysh_evaluate$_run_closure1@1e46a68
groovy> f([a:1])
1
===> [1]
groovy> f([a:1,b:2])
1
2
===> [1, 2]
groovy> f(a:1,b:2)
1
2
===> [1, 2]

nawet jeśli mapa nie jest jedynym parametrem

groovy> g = {mapa, foo -> println mapa}
===> groovysh_evaluate$_run_closure1@d480ea
groovy> g(a:1,2)
["a":1]
===> null
groovy> g(a:1,b:2,2)
["a":1, "b":2]
===> null

Języki dynamicznie z domknięciami mają ciekawą cechę, mapa odpowiada w pewnym stopniu obiektowi, np. w ActionScript 2 nie ma osobnej kolekcji "Mapa" - korzysta się z Obiektów i dynamicznie tworzy nowe pola wygląda to tak jak kod w 3 linijce.

groovy> a = [:]
===> {}
groovy> a.pole = 1
===> 1
groovy> a.funkcja = { x -> x * a.pole } // ! trzeba zapisać skąd pochodzi "pole", m.in. tym się różni od normalnego obiektu
===> groovysh_evaluate$_run_closure1@20f237
groovy> a.funkcja(2)
===> 2
groovy> a.pole = 2
===> 2
groovy> a.funkcja(2)
===> 4
groovy>

Teraz, chwila przerwy, by każdy czytelnik mógł się zastanowić jak proste jest tworzenie mocków w Groovy za pomocą takich opcji.

Istnieje jeszcze jedna specjalna klasa - Expando - która w pewien, jak na razie magiczny, sposób pozwala na bardziej naturalne tworzenie dynamicznych obiektów.

groovy> e = new Expando()
===> {}
groovy> e.pole = 1
===> 1
groovy> e.f = { x -> x * pole } // ! nie trzeba specyfikować z jakiego obiektu pochodzi pole, czyli to czego oczekujemy
===> groovysh_evaluate$_run_closure1@174aa60
groovy> e.f(2)
===> 2
groovy> e.pole = 2
===> 2
groovy> e.f(2)
===> 4

Przetestuj poniższy kod, zapamiętaj co się dzieje [ zakładam, że wiesz dlaczego ;) ]

a = [a:1]
e = new Expando()
e.a = 1
e.f = { x -> x * a }
e.f(2)

Więcej o mapach

Groovy w praktyce - part 3 - listy i kilka operatorów

2008-07-29T19:26:00.007+02:00

Najpierw parę operatorów.

*. - pozwala na zgrupowanie wyników pewnej operacji a*.b() odpowiada a.collect{ it.b()}, domyślny sposób nawigacji w OCL i XPath
?. - bezpieczna nawigacja - jeśli a= null to a?.b też wynosi null
?: - doskonały dla wartości domyślny - zwraca wartość po prawej jeśli po lewej jest null, pusty string, false lub 0

//
// Operator .*
//
groovy> "abc".toList()
===> [a, b, c]
groovy> a = "abc".toList()
===> [a, b, c]
groovy> a*.toUpperCase()
===> [A, B, C]
groovy> a.collect{ it.toUpperCase()}
===> [A, B, C]

//
// Operator ?.
//
groovy> class A{ def a }         
===> true

groovy> a = new A()
===> A@c1a0eb
groovy> a.a = new A()
===> A@ed9f47
groovy> a.a.a = new A()
===> A@1762027

groovy> a.a?.a
===> A@1762027

groovy> a.a = null
===> null
groovy> a.a?.a
===> null
groovy> a.a.a
ERROR java.lang.NullPointerException: null
     at groovysh_evaluate.run (groovysh_evaluate:1)
     ...

//
// Operator ?:
//
groovy> null?:2
===> 2

groovy> 1?:2
===> 1
groovy> 0?:2
===> 2

groovy> true?:2
===> true
groovy> false?:2
===> 2

groovy> ''?:2
===> 2
groovy> 'x'?:2
===> x

A teraz listy, niech kod mówi sam za siebie.


Groovy Shell (, JVM: 10.0-b22)
Type 'help' or '\h' for help.
-------------------------------------------------------------------------------

groovy> a = [1,2,3]
===> [1, 2, 3]
groovy> a.class
===> class java.util.ArrayList

groovy> a + 4
===> [1, 2, 3, 4]
groovy> a
===> [1, 2, 3]

groovy> a << 4
===> [1, 2, 3, 4]
groovy> a
===> [1, 2, 3, 4]

groovy> a - 3
===> [1, 2, 4]
groovy> a
===> [1, 2, 3, 4]

groovy> a -= 3
===> [1, 2, 4]
groovy> a += 3
===> [1, 2, 4, 3]
groovy> a
===> [1, 2, 4, 3]

groovy> a.sort()
===> [1, 2, 3, 4]

groovy> a + [5,6,7]
===> [1, 2, 3, 4, 5, 6, 7]
groovy> a
===> [1, 2, 3, 4]


groovy> a << [5,6,7]
===> [1, 2, 3, 4, [5, 6, 7]]


groovy> a.pop()
===> [5, 6, 7]

groovy> a
===> [1, 2, 3, 4]

groovy> a += [5,6,7]
===> [1, 2, 3, 4, 5, 6, 7]

groovy> a += (8..10)
===> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

groovy> a[0]
===> 1
groovy> a.get(0)
===> 1
groovy> a.getAt(0)
===> 1
groovy> a.getAt([0,-3..-1])
===> [1, 8, 9, 10]
groovy> a[-1]  
===> 10
groovy> a[4..-1]
===> [5, 6, 7, 8, 9, 10]
groovy> a == [*1..10]
===> true

groovy> a.each{println it}
1
2
3
4
5
6
7
8
9
10
===> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

groovy>a.reverseEach{ println it}
10
9
8
7
6
5
4
3
2
1
===> [10, 9, 8, 7, 6, 5, 4, 3, 2, 1]
groovy> a.reverse().eachWithIndex{it,i -> println "$i: $it"}
0: 10
1: 9
2: 8
3: 7
4: 6
5: 5
6: 4
7: 3
8: 2
9: 1
===> [10, 9, 8, 7, 6, 5, 4, 3, 2, 1]
groovy> a
===> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

groovy> a.find{it > 3}                                   
===> 4
groovy> a.findAll{it > 3}
===> [4, 5, 6, 7, 8, 9, 10]

groovy> a.every{it > 3}
===> false
groovy> a.any{it > 3}
===> true

groovy> a.max()
===> 10
groovy> a.min()
===> 1
groovy> a.sum()
===> 55

groovy> a.join()
===> 12345678910
groovy> a.join('-')
===> 1-2-3-4-5-6-7-8-9-10

groovy> a.intersect([8,9,10,11,12,13])
===> [8, 9, 10]
groovy> a.contains(1)              
===> true
groovy> a.containsAll([1,3,5])
===> true
groovy> a.disjoint([10,11])
===> false
groovy> a.disjoint([11,12])
===> true

groovy> a.multiply(2)   
===> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
groovy> a
===> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
groovy> a * 2
===> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

groovy> a = "abc".toList()
===> [a, b, c]

Więcej: Groovy - Kolekcje

Groovy w praktyce - part 2 - "zapomnij o pętlach" czyli elementy stylu funkcyjnego

2008-07-27T18:25:00.003+02:00

Dziś opowieść o funkcjach. Przyjmuje na razie pewne uproszczenie, bo tak naprawdę to nie funkcje ale domknięcia (closure) używam. Jednak wiedza czym domknięcia różnią się od funkcji nie jest na razie potrzebna i można.

Plan jest prosty

Jak używa się pętli w Groovy?
Jak to jest możliwe, że to da się tak zrobić?

Odpalam groovysh. Linijki zaczynające się od groovy> to kod wpisany do interpretera. Tekst zaraz za taką linijką, a przed ===> to wyniki println, wartość po ===> to wartość wyrażenia.

Pewną archaiczną konstrukcją języka odziedziczoną po Javie są pętle ;)

int i = -1;
while(i++ < 3){
 System.out.println(i);
}
// lub
for(int i = 0; i < 4; i++){
 System.out.println(i);
}

Groovy rzeczywiście akceptuje tak napisany kod.

groovy> for(int i = 0; i < 4; i++){ System.out.println(i); }
0
1
2
3
===> null

Ja jednak preferuje styl funkcyjny.

groovy> 4.times{ it -> println(it) }                      
0
1
2
3
===> null

// A najbardziej lubie

groovy> (0..3).each{ println it }
0
1
2
3
===> null

Mając więc do wyboru

for(int i = 0; i < 4; i++){
 System.out.println(i);
}

lub

(0..3).each{ println it }

Co wybierzecie? Gdzie łatwiej stwierdzić ile razy coś się wykona, albo co właściwie się stanie?
Nie przekonani? To może inny przykład

String s = "abcde";
for(int i = 0; i < s.length(); i++){
 System.out.println(i);
}

//względem

"abcde".each{ znak -> println znak }

No ale jak to jest właściwie możliwe ?
Wszystkie kolekcje oraz String i zakresy w Groovy mają przydatne funkcje jak each, find, collect, every, any itd. o których więcej w następnych częściach. Na razie wystarczy wiedzieć, że funkcje te pobierają jako parametr zmienną będącą funkcją. Funkcja ta pobiera jako parametr jeden obiekt z kolekcji.

No dobrze, ale żeby przesłać funkcję do innej funkcji najpierw trzeba ją zdefiniować.

W Java można tworzyć funkcje jedynie bezpośrednio w klasach, Groovy tak też potrafi.

// Java
class A{
 public void f(Object x){
     System.out.println(x);
 }
}

// Groovy
groovy> class A{ public void f(Object x){ System.out.println(x);} }
===> true

// W Groovy można też pominąć wszystkie typy, pozbyć się średnika i skrócić System.out... do samego println
class B{
  public f(x){
      println(x)
  }
}

//uruchamiam funkcję
groovy> a = new A()
===> A@1de498
groovy> a.f(1)
1
===> null

W Groovy można definiować funkcję praktycznie w dowolnym miejscu. Możemy to zrobić np. za pomocą def.

groovy> def f(x){ println(x) }
===> true
groovy> f(1)
1
===> null

// tak zdefiniowaną funkcje mogę już wysłać do innej funkcji np.:

groovy> (0..3).each(f)      
0
1
2
3
===> 0..3

W językach funkcyjnych często tworzy się funkcje anonimowe, które są przypisywane zmiennym lub parametrom innych funkcji. Przykładowo możemy przypisać zmiennej g funkcję pobierającą Object i wypisującą go na ekran jako:

g = { Object it -> println(it); } // ten zapis możemy uprościć pozbywając się informacji o typie i średnika
g = { it -> println(it) } // nawiasy też nie są potrzebne ponieważ f(x) == f x - podobnie jak w Ocaml
g = { it -> println it }

// ostatecznie mamy:
groovy> g = { it -> println it }
===> groovysh_evaluate$_run_closure1@10e434d
groovy> g(1)
1
===> null

// tak stworzoną funkcję możemy ponownie wysłać do innej funkcji:
groovy> (0..3).each(g)     
0
1
2
3
===> 0..3

(0..3).each(g) // możemy ponownie pozbyć się nawiasów
(0..3).each g  // właściwie nie ma powodu by definiować osobną zmienną, możemy funkcję zdefiniować natychmiast
(0..3).each { i -> println i} // tutaj nazwaliśmy parametr i,
// co ciekawe parametr o nazwie it jest parametrem domyślnym i nie trzeba go w ogóle specyfikować
// więc można napisać:
(0..3).each { println it }

Ostatnia linijka kodu definiuje anonimową funkcję pobierająca jeden obiekt pod nazwą it i każe wykonać tą funkcję dla każdego obiektu z zakresu od 0 do 3 włącznie.
I tym sposobem zatoczyłem koło.

Na taki styl pozwalają języki, które traktują funkcje jak zwykłe obiekty (First-class function), więc np. JavaScript, Ruby, Python, ActionScript, Scala. Jeśli pozwalają to na pewno z niego korzystają. Jeśli komuś się taki styl nie podoba, to muszę przyznać, że ma pecha. Nawet następny standard C++ (C++0x) będzie najpewniej mieć domknięcia, C# już je ma, a Java ma 3 propozycje domknięć i prawdopodobnie w Java 1.7 domknięcia już będą. Pewnie nie tak ładnie syntaktycznie jak w Groovy, ale będą.
Innymi słowy w 2010 wszystkie główne języki programowania będą obsługiwać domknięcia. I to pełne domknięcia, nie tylko funkcje jako obiekty (a co to tak naprawdę oznacza, to może innym razem).

Groovy w praktyce - part 1 - instalacja i String

2008-07-25T07:00:00.000+02:00

Wymagania wstępne
Java, najlepiej >=1.5. Na 1.4 będzie działać, ale bez niektórych opcji.

Instalacja - Linux

Ubuntu: sudo apt-get install groovy
OpenSuse >=10.2

Ewentualnie wszelkie pliki można dostać tu http://groovy.codehaus.org/Download w tym uniwersalny instalator i paczki dla innych dystrybucji.

Instalacja - Windows
Instalator Groovy 1.5.6 + Gant 1.3

Test
Po przeprowadzeniu instalacji pora przetestować GroovyConsole. W Windows powinna pojawić się pozycja w menu star. W obu systemach w linii komend powinno wystarczyć wpisanie groovyConsole, by włączyła się poniższa aplikacja. Wpisujemy w górną część print "Hello world" i klikamy zaznaczony przycisk:
GroovyConsole jest najprostszym edytorem Groovy, cały kod w edytorze / pliku jest wykonany, a rezultat zwracany.
W Windows kliknięcie na plik z rozszerzeniem .groovy powoduje ich wykonanie. Jak widać Groovy nie wymaga by kod był pisany w metodach.

Linia komend - groovyc
Kompilator, na razie nie będzie potrzebny.

Linia komend - groovy
Interpreter.

groovy Hello.groovy - wykonuje kod z podanego pliku
groovy -e " print 'Hello world' " - wykonuje bezpośrednio podany kod

Linia komend - groovysh
Interaktywny interpreter.
Interaktywny interpreter to ciekawa pomoc w nauce dostępna w językach takich jak Groovy, Ruby czy Python. A działa to tak:


kk@kkl:~$ groovysh
Groovy Shell (, JVM: 10.0-b22)
Type 'help' or '\h' for help.
-------------------------------------------------------------------------------
groovy:> a = "123" [enter]
===> 123
groovy:> b = 4
===> 4
groovy:> c = 5.0
===> 5.0
groovy:> a+b+c
===> 12345.0
groovy:> "$c - ${b} = ${c-b}"
===> 5.0 - 4 = 1.0 //to jest String !

W interpreterze możemy na bierząco tworzyć zmienne (nawet bez ich deklaracji) i przypisywać im dowolne wartości. Po każdej komendzie lub zestawie komend interpreter wykonuje kod i zwraca wynik. Wynikiem jest zawsze wartość ostaniej komendy.
Dla komendy 1 będzie to 1, dla komendy a = 1 będzie to 1, dla komendy 1;2;3 będzie to 3 a dla komendy print 1 będzie to null (po drodze zostanie wypisane 1).

Linijka13 - GString
Jeżeli Groovy spotka w String napis postaci $nazwa_zmiennej to wstawi w jej miejsce wartość zmiennej. Jeżeli spotka ${kod} to wstawi w to miejsce wykonany kod.
Dalej Stringi można zapisywać w formie:

"string" lub 'string' - zwykły String
/C:\Windows\system / - String w którym nie trzeba używać \
Stringi na kilka linijek:

def s = """\
String długi na
${a[1]} linijki
"""
Ten ma dokładnie 2 znaki nowej linii.

Kod w Stringach zauważa zmiany zmiennych:

groovy:> "abcdef".each{print "  $it"}
a  b  c  d  e  f===> abcdef

Zmienna it - domyślna zmienna dla funkcji iterujących - przyjmuje wartość kolejnych znaków i za każdym razem nowa wartość jest wstawiana do stringa.

groovy:> "abcde"[2..4]
===> cde
groovy:> "abcde"[2..-2]
===> cd
groovy:> "abcde"[3..0]
===> dcba

groovy:> "abcde".size()
===> 5
groovy:> "abcde".length()
===> 5

groovy:> "abcde" == "ab" + "c" + "de"
===> true

groovy:> "abcdeabcde" - "abc"
===> deabcde

Dla stringów zdefiniowano kilka ciekawych operatorów i funkcji.
Operator == porównuje względem wartości, a nie referencji jak w Java.
Groovy dekoruje istniejące klasy Java (jak string, tablice, kolekcje) dzięki czemu można wszędzie używać jednej metody size() zamiast raz size, a raz length.
Stringi można też odejmować - zostaje usunięte pierwsze wystąpienie odejmowanego napisu.

Dodatkowe informacje o String w Groovy.

PDD - uznana metodyka wytwarzania oprogramowania

2008-07-24T18:49:00.001+02:00

PDD - Presentation Driven Development ;)

Zasady pierwotnej wersji PDD:

Błędów się nie usuwa, to zajmuje za dużo czasu, błędy się omija lub wstawia dane na sztywno
Nie rozpatruje się przypadków brzegowych, żadnych
Nie rozpatruje się nic, czego nie można pokazać - np. wyjątki - nigdzie się ich nie łapie, albo łapie wszystkie i nie pokazuje, że coś poszło nie tak
Działanie nie musi być stabilne, a zarządzanie pamięcią w ogole istnieć - aplikacja ma tylko działać przez czas prezentacji
Jeśli jakieś zadanie zajmuje dużo czasu co powoduje, że oglądający prezentacje lub uruchamiający aplikację musi czekać, to dane do tego zadania wstawia się na sztywno lub wcześniej przygotowuje wyniki (nie konieczne będące efektem działania programu)
Kontrolki i ekrany muszą być ładne, najlepiej lekko animowane
Każdy przycisk ma znaczącą ikonke
Tworzy się jedyną ścieżkę krytyczną - ona musi wyglądać jakby działała i ją sie pokaże
Nie dba się o jaką kolwiek zgodność wsteczną (ale można przygotować port danych ze starej wersji i pokazać jak wygląda w nowej (mówiąc, że dane pochodzą ze starej :) ))

Niektóre firmy postanowiły zaadaptować PDD również dla oprogramowania, które trafia do klientów, wtedy pojawiają się pewneo zmiany (obsługuje się niektóre przypadki brzegowe), zasady pozostają podobne. Kilka zmian w PDD dla oprogramowania dostarczanego użytkownikowi:

Tworzy się kreatorki ułatwiające pracę na początku, nawet jeśli na dalszych etapach unimożliwiają pracę z powodu złożoności zagadnienia lub ilości danych
Oprogramowanie ma dobrze wyglądać i bardzo dobrze się sprawdzać dla małych prostych problemów, powinny być dla nich zaproponowane rozwiązania, nie muszą być ogólne
Nie dba się o skalowalność, czy złożone przypadki
Nie dba się o kompatybilność między wersjami np. wersja 2.0 jest nie kompatybilna z 1.1, a ta jest absolutnie nie zgodna z 1.0
Po wydaniu oprogramowania zbiera się maksymalnie wszelki feedback od użytkowników i zmienia się wersje pierwotną nawet, jeśli użytkownicy chcą zupełnie co innego niż zaplanowano, jeśli wystarczająco duża liczba użytkowników chce coś to można stworzyć kilka różnych produktów

Niektóre duże firmy z powodzeniem stosują tą metodykę. Jej najefektywniejsza forma jest nazwana $DD - Money Driven Development - stosuje się PDD, ale pierwsza wersja oprogramowania jest dokładną kopią cudzego produktu. Reszta zasad pozostaje bez zmian.

Nie będe oceniał tutaj PDD i $DD. Pamiętać trzeba tylko o jednym - jeśli firma korzysta z $DD to nigdy nie należy korzystać produkcyjnie z pierwszej wersji oprogramowania, a wersję 2.0 stosować tylko w razie potrzeby po przetestowaniu w rzeczywistym środowisku. Przeważnie wersja 3.0 jest już bardzo udanym produktem.

ps. Pierwszy raz zauważyłem stosowanie PDD w projekcie tworzonym przez studentów na konkurs, później zauważyłem komercyjne wykorzytanie odkrytej metodyki. Przypomniałem sobie o PDD z okazji Entity Framework i LINQ to SQL.

Języki na JVM - Scala

2008-07-22T22:57:00.000+02:00

Scala jest językiem, który moim zdaniem zyska dużo zwolenników. Podobnie jak Groovy został stworzony od podstaw i oparty na Javie. Również tutaj klasy Scala są poprawnymi klasami Java i dziedziczenie jest możliwe. Jednak wzoruje się na językach funkcyjnych takich jak SML i Ocaml, jest silnie, statycznie typowany i to bardzo odróżnia język od JRuby, Jython i Groovy.

Scala

Silna i statyczna typizacja - czyli po prostu jest i będzie szybszy niż 3 wcześniej wymienione, a narzędzia potencjalnie mogą być lepsze
Odgadywanie typu (type inference) - zdecydowanie mniej gadatliwy kod niż w Java

Czysto obiektowy (absolutnie wszystko jest obiektem)
Silnie funkcyjny z ładną obsługą powiązanych koncepcji
Przeciążanie operatorów
Pozwala na pewnego rodzaju wielodziedziczenie (mixin,trait)
Wzorzec singleton jest elementem języka

Kompilowany do bytecodu
Bezpośrednie korzystanie z typów Java
Możliwe dziedziczenie po klasach Java
W przyszłości będą możliwe cykliczne zależności tak jak w Groovy
Podobno ma lepsze generics niż Java :)
Obsługują adnotacje
Podsumowując możemy używać wszędzie tam gdzie Java, np. w JPA / Hibernate

Wspiera programowanie współbieżne (dzięki aktorom)

Jest i będzie szybszy niż Groovy, Ruby/JRuby, Python/Jython, JavaScript etc.

Istnieje kompilator Scala dla .Net

Przykładowe aplikacje w Scala: Lift

Język od początku został zaplanowany jako język funkcyjny, co to oznacza ? Szybki (mimo, że w kompilatory języków funkcyjnych nie zainwestowano tyle czasu co w kompilatory C/C++ to i tak zawsze są blisko czołówki w rankingach wydajności), łatwiejsza obsługa wielordzeniowości, język ładny, kompaktowy, naturalny w obliczeniach matematycznych...

def qsort(lst: List[Int]):List[Int] =
 lst match {
    case Nil => Nil
    case pivot::tail =>  qsort(tail filter { _ < pivot }) ::: pivot ::: qsort(tail filter { _ >= pivot })
 }

Oto definicja funkcji (w Scali do zmiennej można przypisywać funkcje, stąd taka notacja). Oczywiście algorytm to QuickSort. Teraz bardziej znajoma encja JPA:

@Entity
class SomeClass {
 @Id @Generated
 var id: Long = -1
 var name: String = _
}

Jest dużo różnic między Java a Scala, bardzo dużo. Prawie każda koncepcja jest zmieniona lub nowa. Krzywa nauki jest z tego powodu stroma. Przy okazji jeszcze różnice między Java Groovy i Ruby.
Studiując różnice nie da się zauważyć, że najłatwiej zrozumieć Groovy, można go wprowadzać stopniowo zaczynając od Java, albo uczyć się od podstaw od razu w nowym stylu. Pewnie dlatego będzie cześciej spotykany od Scali, mimo że Scala jest/będzie szybszym, gotowym na wielordzeniowość - ogólnie scalowalnym językim. Może jednak wprowadza zbyt wiele zmian? Czy zwykłego szarego programiste można nauczyć Scali?

Wszystkie 4 dotychczas opisane języki posiadają konsolę - interpreter na bieżąco wykonujący podany mu kod, dzięki czemu możemy błyskawicznie uczyć się poznawać konstrukcje języków.

Jaki powinien być dobry język według mnie? Powinien być silnie i statycznie typowany z refleksją i odgadywaniem typów wszędzie gdzie to możliwe, mieć spójny model semantyczny, który jest zamienialny na sensowny diagramy akcji i sekwencji, pozwalać na styl funkcyjny, mieć domknięcia i definicję rozszerzeń języka.
Myślę, że pojawi się więcej lub zyskają na popularności języki funkcyjne lub tylko trochę "brudne obiektowo" lub nawet czysto funkcyjne, które będą bezpieczne we wszelkich obliczeniach równoległych (więc w sam raz na serwery web, usługi sieciowe, komunikatory i desktopy skoro za parę lat będziemy mieli 64+ rdzeni). Już widać powrót i ponowne wykorzystanie starego języka Erlang. Pewnie będą próby tworzenia systemów operacyjnych w takich językach. ok, kolejne posty będą bardziej praktyczne.

Języki skryptowe dla JVM - Groovy, Python, Ruby

2008-07-22T07:00:00.000+02:00

Maszyna wirtualna Java jest świetną platformą, która udowodniła, że radzi sobie nieźle z nowymi językami. Moim zdaniem na razie liczą się tylko (aż?) 3 języki Jython, JRuby i Groovy. W przyszłości na pewno dołączy do nich Scala (wiki). Są to dojrzałe implementacje, czego nie można powiedzieć o odpowiednikach na platformę .Net.

Cechy wspólne języków
Jython, JRuby, Groovy

Mogą być kompilowane do bytecode
Moga być interpretowane za równo z konsoli jak i w programach Java z plików lub zwykłego String
Mogą wykorzystywać a nawet dziedziczyć po klasach Java
Są to języki dynamiczne
Pozwalają na przeciążanie operatorów
Mapy, listy itp to natywne konstrukcje języka (np. [a: 1, b: 2] to mapa)
Pozwalają na pisanie w stylu funkcyjnym

Są to języki z typizacją w stylu "Duck Typing". Troche więcej na ten temat w stopce.

Co ciekawe Jython, JRuby są szybsze niż ich natywne wersje pisane w C. Można porównać testy. W tych testach polecam nie patrzyć na języki spoza JVM, ponieważ procedura testowa nie jest do tego odpowiednia (jak w prawie każdych micro testach). Przy okazji warto zauważyć gdzie jest Scala względem pozostałych trzech i Java.

Jython
Stara sprawdzona implementacja języka Python na JVM i robi to dobrze. Python to jeden z 3 "dozwolonych" języków w Google (obok Java i C). Cecha szczególna - wcięcia zamiast nawiasów klamrowych. Google App Engine obsługuje jak na razie tylko Python.

Znane aplikacje Python: Django, Plone, Zope, Trac (ostatni warty uwagi nawet jeśli nie chcemy pisać w Python).

JRuby
JRuby zapewnia bardzo dobrą kompatybilność z Ruby. Ruby to wcale nie taki młody język, kiedyś znany właściwie tylko w Japonii. Praktycznie całą aktualną popularność zawdzięcza powstaniu webframeworka Ruby on Rails. Sun wpiera implementację JRuby (zatrudnił na stałe kilku jego programistów). Na polskiej Wikipedii znajduje się dobry opis Ruby.

Znane aplikacje Ruby: Ruby on Rails, Basecamp

Zarówno JRuby jak i Jython dostarczają bazowe biblioteki znane z natywnych wersji swoich języków jak i pozwalają korzystać z bibliotek Java.

Groovy
Groovy nie jest portem istniejącego języka, został pomyślany od początku jako "nowa lepsza Java". Większość kodu napisanego w Javie jest jednocześnie poprawnym(choć strasznie przegadanym) kodem Groovy.

Groovy ma najlepszą integrację z Javą:

Może być silnie typowany, ale nie musi
Klasy Groovy po kompilacji to stare dobre klasy Java, ale nie każdą metodę można wywołać bezpośrednio (w końcu to język dynamiczny, więc pewne metody nie istnieją w trakcie kompilacji)
Klasy JDK mają dodatkowe metody, zwykle są one szalenie przydatne
Jako jedyny pozwala na dwustronne dziedziczenie (Java -> Groovy i Groovy -> Java) (a odkąd wspiera łączoną kompilację Java + Groovy, możemy mieć cykliczne zależności (dziedziczenie, zawieranie, korzystanie z metod) między klasami Java i Groovy, w Scali też kiedyś pojawi się taka możliwość).
Z tych 3 języków tylko Groovy ma możliwość używania adnotacji i generics, a klasy Groovy są poprawnymi klasami Java, czyli możemy sobie oznaczyć klasę Groovy jako "@Entity" i używać dla nich Hibernate - to wykorzystuje np. Seam)

Znane aplikacje w Groovy: Grails (w pewnym sensie (koncepcyjnie) odpowiednik Ruby on Rails, wykorzystuje m.in. Spring i Hibernate)

Gdy się zna Java nie skryptowego języka prostszego do nauki niż Groovy. Nauka może przebiegać w małych krokach - zmieniamy rozszerzenie pliku klasy Java na groovy, a później usuwamy niepotrzebny kod dzięki jakiejś nowo poznanej opcji. Wydaje mi się, że nie pozwala również na klasy wewnętrzne i anonimowe (nie pamiętam teraz). Groovy namiętnie używa pewnej koncepcji nazwanej "builders". Są to takie mini języki tworzące w banalny sposób wszelkie struktury drzewiaste, czyli XML, Swing, SWT, JSP, ANT... Jest to możliwe w innych językach - tu jest jedną z podstawowych koncepcji i ładnie wygląda. Jeśli utknęło się na starej wersji Java np. 1.4.2 to dalej można wykorzystać większość opcji z Groovy (bez np. adnotacji itp.).

Jeszcze troche o typizacji
O typizacji mówi się czasem, że jest słaba lub silna, albo statyczna lub dynamiczna, jest z tym sporo zamieszania i nie mam zamiaru opisywać wszystkiego.
Groovy potrafi udawać statyczną typizacje znaną z Java. Domyślnie tak jak reszta ma dynamiczną typizację, w formie nazywanej "Duck Typing" mi ten termin bardziej by pasował do Ocaml, no ale trudno - tak się przyjeło. W skrócie wszystkie trzy języki pozwalają na przesyłanie czegokolwiek, gdziekolwiek i tylko w trakcie wykonania mogą się poskarżyć, że dany typ jest nie taki bo nie ma funkcji, którą staramy się wywołać.

Przykład z http://onestepback.org/articles/groovy/ducktyping.html

class Duck {
 quack() { println "I am a Duck" }
}

class Frog {
 quack() { println "I am a Frog" }
}

quackers = [ new Duck(), new Frog() ]
for (q in quackers) {
 q.quack()
}

Kod jest poprawny według zasady, że "jeśli coś wygląda jak kaczka i zachowuje się jak kaczka to jest kaczką".

Można powiedzieć, że tak naprawdę nie wywołujemy metody na obiekcie ale przesyłamy komunikat do obiektu z nazwą funkcji i parametrami, a sam obiekt stara się coś z tym zrobić. Dzięki temu możemy obsługiwać funkcje, których nie ma (powiedzmy, że przeciążamy funkcję MethodMissing i tam każemy dla funkcji o sygnaturze hello_xxx wypisywać xxx na ekran). Pozwala to na tworzenie doskonałych bibliotek o bardzo czytelnym kodzie, ale jednocześnie powoduje, że podpowiadanie składni, statyczna analiza kodu, automatyczne wyszukiwanie błędów, czy zwykła nawigacja po kodzie nigdy nie będą tak dobre jak to jest możliwe w Java czy C#. Jednocześnie m.in. z tego powodu języki te zawsze będą wolniejsze niż Java (istnieje dodatkowy narzut na wykonanie każdej funkcji, utrudnia to też pracę JIT).
Tu znów pewnym wyjątkiem jest Groovy, który pozwala na statyczną typizację, tylko nie wiem czy z tego korzysta do optymalizacji. Z drugiej strony jest jedynym z wymienionych języków, który natywnie wspiera Multiple Dispatch, czyli multimethods(dobry krótki przykład) jak to nazywają w Groovy, a to wymaga badania rzeczywistego typu każdego parametru funkcji i ponownie zmniejsza wydajność kodu.

Wracając do Ocaml - tu typizacja jest silna i statyczna (z odgadywaniem typów) mimo to kod często przypomina języki skryptowe. W Ocamlu istnieje coś jak dziedziczenie choć są pewne różnice. Dalej obiekt jest zgodny z jeśli mają te same metody (w uproszczeniu). Ciekawie to działa w praktyce (tak jak na poprzednim przykładzie ale zwróciło by błąd w trakcie kompilacji, gdyby któraś z klas nie zawierała metody quack()). Typy choć na codzień tego się nie dostrzega to dość złożone zagadnienie, dalszych informacji można szukać w google i na wikipedii pod hasłami covariance i contravariance. Przydatne do paru problemów z generics i ze zwykłymi tabelami.

w następnej części opis Scali.
Już teraz specjalnie dla Anke: The Cake Pattern.

Blogger i Syntax Highlighter

2008-07-15T23:27:00.000+02:00

Niech pojawia się kolorki.

<pre name="code" class="java">
//Komentarz
public Klasa{
 public static void main(String args[])
 {
   System.out.println("Hello World!"/*jakie to oryginalne*/);
 }
}
</pre>

Zamieni sie na:


//Komentarz
public Klasa{
 public static void main(String args[])
 {
   System.out.println("Hello World!"/*jakie to oryginalne*/);
 }
}

Można to osiągnąć poprzez odwołanie do kodu SyntaxHighlighter z szablonu bloggera. Przechodzę do edycji szablonu bloga (Dostosuj -> Układ -> Edytuj Kod HTML).

Najpierw potrzebne mi jest miejsce w sieci, gdzie umieszczę SyntaxHighlighter np. google pages, app engine lub dowolny inny darmowy hosting. Można też wykorzystać istniejące lokalizacje, próbowałem również odwołać się do SVN projektu, jednak plik css coś nie chciał współpracować, dlatego korzystam z googlepages.
W kodzie html szablonu dodaje kod z odwołaniami do skryptów dla odpowiednich języków (umieszczam kod zaraz przed </body>). Dodatkowe języki (Scala, Bash etc.) mozna znaleźć w sieci.


<link href="'http://toolsmatter.googlepages.com/SyntaxHighlighter.css'" rel="'stylesheet'" type="'text/css'/">
<script language="'javascript'" src="'http://toolsmatter.googlepages.com/shCore.js'/">
<script language="'javascript'" src="'http://toolsmatter.googlepages.com/js/shBrushScala.js'/">
<script language="'javascript'" src="'http://toolsmatter.googlepages.com/shBrushXml.js'/">
<script language="'javascript'" src="'http://toolsmatter.googlepages.com/shBrushShell.js'/">
<script language="'javascript'" src="'http://toolsmatter.googlepages.com/shBrushJava.js'/">
<script language="'javascript'" src="'http://toolsmatter.googlepages.com/shBrushSql.js'/">
<script language="'javascript'" src="'http://toolsmatter.googlepages.com/shBrushJScript.js'/">


<script language="'javascript'">
dp.SyntaxHighlighter.ClipboardSwf = 'http://toolsmatter.googlepages.com/clipboard.swf';
dp.SyntaxHighlighter.BloggerMode();
dp.SyntaxHighlighter.HighlightAll('code');
</script>

Minus takiego podejścia jest prosty - zmiana szablonu wymaga odrobine pracy. Nie zmienia się szablonu często więc jest to ok. Jednak jedno wklejenie kodu uświadamia mi, ze ten blog potrzebuje szerszego szablonu.

ps. w przypadku kodu xml / html, trzeba zamieniać przed wysłaniem '<' na '<'

Blog i kolorowanie kodu

2008-07-11T23:56:00.000+02:00

Kobiety widzą kolory. A mężczyźni ? Dla mężczyzn łososiowy to yyy smak, fiołkowy może być zapach, pomarańcza to owoc, a kremowy? Masz na myśli kremową konsystencje chyba?
No dobrze, może płeć mniej piękną nie potrafi doradzić, czy do niebieskich oczu lepiej pasują lazurowe, czy turkusowe kolczyki jednak kilka kolorów nazwać umiemy! Podobno statystycznie od 6 do 8, a zdarzają się tacy co dobiją do 16. Pomijam oczywiście w statystyce artystów, im pokrewnych i spowinowaconych.

A ile kolorów rozróżniają programiści ?

Hmm, String, komentarz, identyfikator, słowo kluczowe, operator, liczba. Razem 6 - jak widać nie odbiegamy od przeciętnej.

Dobrze, a jak zmusić by na blogu kod był w kolorach?

Kopiować kolorowy kod z edytora (jako HTML)
Skorzystać z uniwersalnego skryptu zamieniającego kod na pokolorowany HTML
Skorzystać ze skryptu JavaScript, który koloruje kod po stronie klienta

ad 1.
Używany edytor kodu musiałby umieć bezpośrednio zapisać kod w HTML lub (co częstrze) pozwolał na skopiowanie kolorowego kodu np. do Word, z którego można wysłać notkę bezpośrednio na blog lub zapisać do HTML. W takim rozwiązaniu każdy język będzie najpewniej miał własny styl kolorowania.

ad 2.
np. Quick Highlighter który obsługuje znacznie więcej języków niż jestem w stanie nazwać. Nawet Apache Log File, Lotus Script, czy robots.txt ! A zresztą po co pisać - menu skopiowane ze strony:

Select a language

Z ciekawych opcji - nazwy klas dla Javy mają automatycznie przypisany link, który pozwala na wyszukiwanie ich w google. Przy takim rozwiązaniu styl jest konsekwenty, a linie ponumerowane.

ad 3.
Najwygodniejsze rozwiązanie, po integracji wystarcza jeden tag, wybór języka i sam kod.
Czyli w przybliżeniu taki html:


<kod jezyk="obslugiwanyJezyk">
   printf "Hello World"
   ...
</kod>

Zamienia się na kolorowy kod. I to wszystko na koszt klienta.
Właśnie tak działa SyntaxHighlighter, istnieją pluginy do WordPress i innych platform, które pozwalają na prostą integrację z blogiem. Są też inne rozwiązania np. highlight.js, czy google-code-prettify. Nie widze pluginu do Bloggera, wieć następny post będzie o integracji wybranego skryptu z Bloggerem.

init()

2008-07-11T08:30:00.000+02:00

Koniec sesji to dobra okazja by stworzyć blog. Ten ma na celu pewną systematyzację moich poczynań przy zabawie, a czasem walce z technologiami.

W związku z moją pracą dyplomową, na blogu najpewniej pojawi się sporo z zakresu języków dziedzinowych, modelowania, transformacji między modelami, tworzeniu kodu na podstawie modeli etc. Temat jest spory, a blog wymusza pewien porządek, jest trwały i może przekona mnie do systematycznej pracy.

Poniżej lista skrótów, które mają szansę się pojawić, jeśli ktoś jest zainteresowany jakimś tematem to czekam na sugestie.

! - prawie pewne
? - mało prawdopodobne

Modelowanie

UML! czyli najlepszy i najgorszy zarazem język do modelowania
Ecore
openArchitetureWare!
ATL?
Eclipse EMF, bo całe Eclipse jest Model Driven!
ADM, MDA na opak, czyli jak z istniejącego kodu coś wyciągnąć, albo przetłumaczyć na inny

DSL*

GMF, czyli własny język w 2 tygodnie
MS DSL Toolkit, czyli własny język w tydzień
ANTLR, czyli własny język w weekend
oAW XText, czyli własny język w godzinę

* Czasy nie poparte żadnymi badaniami ;)

Web

JSF + Seam! lub Shale?
Struts2
Spring MVC + WebFlow
Stripes
Wicket?
ASP.NET MVC
Flex
GWT

Frameworki

Spring IoC
Eclipse RCP
Google App Engine
ADO.NET Entity Framework, czyli czego w Javie się nie da, co da się w C# i czemu należy czekać na wersję 2.0 w przypadku produktów Microsoft

Języki

Groovy! po co generować setery...
Scala? bo silna typizacja to lepsze (potencjalnie) narzędzia i prędkość
C# 3.0, styl funkcyjny i jak zrobić własny Linq, czyli dlaczego C# zaczyna mi się podobać
Erlang? bo i tak będziemy mieli kilkadziesiąt rdzeni | najprostszy z języków ?
AspectJ? bo aspekty są dobre

Toolbox

Małe i duże narzędzia przydatne na co dzień

Wygląda na to, że tematów starczy mi na kilka najbliższych lat...
Lista pozwoli na pamiętanie pomysłów, a blog ma też na celu uświadomienie mi, że niestety wszystkiego poznać i opisać nie można...

Teraz pora na wybór.