Jak bylo na školení NetBeans Platform

English translation

Tímto příspěvkem bych chtěl poděkovat pánům ze Sun Microsystems za uspořádání tohoto školení. Přestože mým oborem jsou výhradně server side aplikace, rád jsem si rozšířil obzory v oblasti desktopu. Z tohoto důvodu se z mé strany pravděpodobně nedočkají významné kontribuce, a proto se snažím jim námahu vrátit alespoň touto reklamou na jejich edukační program.

Celkový dojem z dvoudenního školení je veskrze pozitivní - pokud bylo záměrem dostat do nás základní principy a procesy, které jsou pro další studium platformy třeba, myslím, že se dílo podařilo (alespoň v mém případě :-) ). Čeho si cením asi nejvíce, je možnost vyslechnout tyto informace přímo od autorů a mít možnost se vyptat na detaily přímo jich. Z čehož vyplývá závěr, že školení z tohoto hlediska může být přínosem i pro člověka z desktop oboru nebo přímo NetBeans kontributora. Jedním z příjemných překvapení bylo, že, obdobně jako Roumen si na nic nehraje, ani nikdo z jiných vývojářů nedával najevo nějaký odstup nebo dokonce nadřazenost, přestože by ze své pozice mohli. Přátelské pokecání u oběda řadím také mezi jedny z pozitivních bodů oněch dvou dnů.

Z technického pohledu bych hned zkraje školení v části, kde se osvětlují principy modularizace, uvítal podrobnější popis, jak to v NetBeans platformě funguje. Mne zajímalo především řešení izolace a propojení modulů na úrovni veřejného rozhraní. Tuto část se mi podařilo ujasnit až při obědě s Jardou Tulachem. Základem byla informace, že oproti standardní Javě, v NetBeansech může mít classloader modulu více "otců". Obdobně i rozhraní modulů je v NetBeansech explicitně vymezeno a překračuje hranice standardní viditelnosti rozhraní, kterou používá Java (public, protected, private, friendly). Myslím si, že pár dobře zakreslených schemat v prezentaci, by tuto část mohlo výrazně vylepšit. Takto musela přijít ke slovu tabule (a v mém případě i slánka, pepřenka a párátka na jídelním stole :-) ). Na obranu Jardy Tulacha, který tuto "session" vedl musím uvést, že já jsem v oblasti NetBeans úplný nováček a možná jsem příliš zatížený tím, jak fungují classloadery v aplikačních serverech, takže mi ten princip docela dlouho nedocházel.

Další pocit, který jsem si ze školení odnesl, je nadšení, které kluci pro svoji práci mají. Když jsem viděl zápal s jakým Jarda Tulach vysvětloval některá zákoutí implementace Lookupu, upamatovával jsem se na to, jak jsem já nadšeně rozkresloval principy modulárního řešení ve Springu kolegům ve firmě. Mmch. Lookup pattern používaný v NetBeansech je naprosto skvělá věc, která výrazně zjednodušuje runtime změnu chování na základě výskytu určitých "podmínek" (tzn. výskytu instancí implementujících požadované interfacy). Hezky v sobě kombinuje statický lookup (tzn. v této konkrétní chvíli mne zajímá, zda mám k dispozici objekty, které potřebuji), tak dynamický přístup ve smyslu - notifikuj mne okamžitě, kdy se změní dostupnost objektů, na kterých závisím. Navíc se tím Lookup stává centrálním místem, kudy probíhá komunikace, což má zcela zřejmé výhody. Tento pattern si vyrývám do paměti, protože si myslím, že se najde příležitost, kdy mi ušetří kus práce.

Vcelku zajímavá byla část o "FileSystemech" - je mi zcela jasná abstrakce nad "standardními" souborově orientovanými systémy (filesystem, ftp, JAR, VCS atd.), ale zdála se mi přinejmenším zvláštní aplikace stejné abstrakce na "konfiguraci" vlastních NetBeans. Pěkná je myšlenka layerů, která mi připomíná mechanismus, který existuje v Mavenu na úrovni dědičnosti (a přepisováním dat) v pom.xml. Použití v "systémovém FileSystemu" mi však více než co jiného připomělo Spring konfiguraci (se všemi těmi .intance, .shadow + možnostmi další konfigurace přes metadata). Pro tento účel mi však jako lepší připadá specializovaný "protokol" definovaný XML Schematem (respektive schematy), podobně jako jej znám ze Springu. Myslím si, že výrazová hodnota (tedy i rychlost orientace a pochopení) by byla větší. V hlavě jsem v danou chvíli viděl Spring namespacy jako je třebas tx, aop, které si drží stále vysokou úroveň pochopitelnosti (v úrovni zápisu konfigurace), přesto že již řeší "okrajové" části systému. Skoro bych řekl, že pokud by byl zápis jednoduší (s veškerou nápovědou, kterou by mohlo XML Schema dát), nebylo by až tak zapotřebí wizardů, které v současné podobě považuji za dost nezbytné. Nevím, jestli jsou za současným řešením historické důvody, či je tam něco, co se mi nepodařilo během školení chytit (bohužel jsem na toto téma otázku nepoložil :-( ).

Další session, kterou jsem si náramně užil byla část o podpoře Java editoru v oblasti hintů, quick fixů apod. Jako uživatel IDE jsem měl konečně možnost nakouknout pod pokličku a vidět, co se děje na pozadí, ve chvíli, kdy vám IDE podtrhává nesmyslné výrazy v kódu. Tato část mi opravdu přišla jako velmi atraktivní - a doufám, že vyškrábnu nějaký čas na to, abych si svůj hintík nebo quick fix taky vyzkoušel. Co mě mimořádně překvapilo, jak jednoduše je možné vytvořený hint (plugin a cokoliv dalšího) vyzkoušet rovnou ve spuštěném IDE.

Nemůžu se rozepisovat o všem, proto jen shrnu, že celé dva dny pro mě byly zážitkem a odjel jsem naprosto spokojen. Kvituji taky snahu předvádět dema naživo, což je věc, kterou si hodně lidí také netroufne. Pravda je, že některá dema nevyšla, ale to je věc zcela pochopitelná (kdo nezná generálský efekt, že?), ale pokud si představím sebe na jejich místě ...

Na školení jsem jel s myšlenkou na přizpůsobení NetBeans pro naše webaře (což v podstatě spočívá pouze v osekání současného IDE), ale odnesl jsem si daleko víc. Všem mohu jen doporučit (pokud si správně vzpomínám, Roumen sliboval ještě nějaké opakování tohoto školení v Čechách) a díky kluci!!!

Translation to English

I want to thank fellows from the Sun Microsystems for organizing NetBeans Platform training by this post. Although my primary domain is server side, I gladly extended my skills in the domain of desktop applications. Therefore they could hardly count, that I will contribute some code into the NetBeans platform, so I would like to return back some of their effort by writing this promotional article.

Overal impression from two-days training is throughoutly positive - if there were aim to learn us basic principles and processes necessary for futher learning of the platform, I think that, the intention was fulfilled (at least in my own case :-) ). What I appreciate the most is a chance to get this information from authors of the platform and have a chance to ask them directly about details involved. From that, you can deduce that that the training could be of use even for people from the desktop domain or even NetBeans contributor themselves. One of the pleasant suprises was the atmosphere of entire training - no one from the Sun developers did not behave like superior or someone who keeps his distance. Friendly chatting during the meal was one of the moments I place among ones of the most positive moments of these two days.

From the technical prospective, I would welcome more detail description of the basics of modularization. There was a session devoted to this, but I think, it rather kept on the surface. I was interested mainly in module isolation and solution of interaction among modules. I did not understand this part until I had a chance to discuss this with Jarda Tulach at the lunch. One of the key information was that classloaders in NetBeans unlike the standard classloaders in Java could have multiple parents. Similarly public interface of modules exceeds standard Java visibility scopes (public, protected, private, friendly) and must be explicitly defined during the process of module creation. I guess, that a few well-aimed schemes in presetation could improve overal understanding in this area much more. Currently some of the diagrams must have been drawn on the table (and in my case saltbox, pepperer and toothpick must have been used on the dining table :-) ). To defend Jarda Tulach, I have to say, that I am a newbie in the NetBeans Platform area and I am too encumbered by being used to classloaders in application servers and how they work. So maybe that therefor I could understand these basics of NetBeans Platform for so long.

Another feeling, that I experienced at the training, is the enthusiasm developers for their work have. When I saw the Jarda Tulach's passion explaining some quier corners of the Lookup implementation, I remember my on devotion when describing modular concepts with Spring to my colleagues in company. Btw. the Lookup pattern used in NetBeans is absolutely magnificent thing, that could dramatically ease behaviour change in runtime based on occurence of specific "constraints" (means occurence of instances implementing certain interfaces). It nicely combines static lookup (eg. in this particular moment I want to know if there are objects I need for my work) wit dynamic lookup in the sense of notification when accessibility of objects I depend of gets changed. Moreover the Lookup becomes the central place, where all communication takes place - and that has its advantages too. This pattern I grave in mind, because I know that there would be an opportunity, when it'll save my struggle.

The session about "FileSystems" was also interesting. It's clear to me an abstraction of "standard" file oriented systems (such as filesystem, fg, JAR, VCS and so on), but it souned strangely to me, that the same abstraction is used for configuration of NetBeans. I appreciate the idea of layering, that reminds me somehow mechanism used in Maven when extending (and overwriting) parts of configuration in pom.xml. When I hear about "system FileSystem" I saw a Spring configuration in my mind (with all those .instance, .shadow and further configuration via file metadata). For configuration purpose specialized "protocol" defined in XML Schema (or more precisely multiple schemes) seems better and more readable. When I compare the configuration in NetBeans to the Spring one, in NetBeans I have to use wizards (and even guys from Sun do) to make it right, when in Spring the XML Schemes guides me to do it right (I am constraned by scheme, notation of atributes/elements helps me, I have documentation at hand and its more transparent to link it all together and set properties). Even marginal parts of configuration are more predicative in Spring (tx, aop and other namespaces) while I can imagine, that in NetBeans these things would be solved by another bunch of metadata at the file or folder level. I don't know whether there are any historical reasons for this, or there are other, that I didn't realized during the training (regrettably I didn't ask them :-( ).

Another session I enjoyed much, was the part about Java editor support in the area of hints, quick fixes and so on. As a user of IDE I have an opportunity to look under the cover and see, what's happening behind at the moment when your IDE underlines wrong expressions in the code. That part seems very attractive to me and I hope I'll find some time to write my own hint of quick fix. I was suprised by the simplicity of integration of currently written hint (or plugin or whatever else) into the running IDE.

I cannot write about everything, so when I have to conclude somehow. Both two days were astonishing experience for me, and I left more than satisfied. I liked that demos were presented live and that is something that everybody wouldn'd dare to do at public. The truth is, that few of them didn't go well, but that is obvious (who doesn't know the general's effect?). And when I imagine myself at their place doing some live demo ...

I went to the training with idea of adapting NetBeans for our web developers (that involves only cutting out some features of current IDE), but I left with much more than I thought of. I can only recommend training to anybody and you have my thanks, guys from Sun!!!