• Home
  • Events
  • About
  • Hackergarten Welcomes Jazoon on Wednesday Night

    May 31st, 2010
    If you are reading this then you are quite likely a Jazoon 2010 attendee looking for more information about the mysterious “Hackergarten Jazoon” session blocked in your Wednesday night conference schedule. Welcome Aboard! Here is what you can expect:
    1. A room will be announced when we know it
    2. Drinks and food will be provided by Canoo
    3. During the evening, everyone will try to contribute in some way to an open source software project.
    Here are some of the contributions we made at past Hackergartens:
    * A Twitter plugin for the Gradle build system
    * A Growl/Notification plugin for Gradle
    * Several Swing related plugins for the Griffon application framework
    * A Grails Elastic Search plugin
    * An inhancement to the Groovy language to aid logging
    We have several ideas for projects to work on, but please feel free to show up with your own or leave a comment here with your idea. The past events have been Groovy focused, but Java, Scala, Clojure or whatever are all perfect.
    As people show up we Canooies will help you find other people with similar interests. Once you have 2-6 people in your group then it is up to you to start working. In the past, the most effective project groups are around 5-6 people, which creates 2 or 3 pair programming teams. Any larger than that and you spend too much time organizing yourselves. Near the end of the night you should wrap up your work and submit a patch to the project. Canooies are around to help you with patches, version control, tools, expertise, or anything else you might need.
    Here are some of our project ideas, but please leave a comment here with your own! And remember, you have at most 4 hours so think small. There is no project too small… a 2 line patch is the Open Source developer’s equivalent of a CHF 10 bottle of wine. It might not be appropriate to the current meal, but it is almost always appreciated.
    Griffon-Hudson Plugin  similar to the Grails plugin – http://wiki.hudson-ci.org/display/HUDSON/Grails+Plugin
    Griffon Substance Look and Feel Plugin
    Groovy Static Analysis Rules – Similar to Find Bugs but for Groovy
    Groovy @Log Transformation extensions – There is some small work to do in Groovy Core
    Find Bugs statis analysis rules for Java
    Gradle Find Bugs plugin
    Gradle JavaNCSS plugin
    Post your ideas below, and see you on Wednesday.

    If you are reading this then you are quite likely a Jazoon 2010 attendee looking for more information about the mysterious “Hackergarten Jazoon” session blocked in your Wednesday night conference schedule. Welcome Aboard! Here is what you can expect:

    1. A room will be announced when we know it
    2. Drinks and food will be provided by Canoo
    3. During the evening, everyone will try to contribute in some way to an open source software project.

    Here are some of the contributions we made at past Hackergartens:

    • A Twitter plugin for the Gradle build system
    • A Growl/Notification plugin for Gradle
    • Several Swing related plugins for the Griffon application framework
    • A Grails Elastic Search plugin
    • An inhancement to the Groovy language to aid logging

    We have several ideas for projects to work on, but please feel free to show up with your own or leave a comment here with your idea. The past events have been Groovy focused, but Java, Scala, Clojure or whatever are all perfect. A few of the speakers have said they would attend and Griffon project lead Andres Almiray will be there. Pairing with an expert is a wonderful way to learn.

    As people show up we Canooies will help you find other people with similar interests. Once you have 2-6 people in your group then it is up to you to start working. In the past, the most effective project groups are around 5-6 people, which creates 2 or 3 pair programming teams. Any larger than that and you spend too much time organizing yourselves. Near the end of the night you should wrap up your work and submit a patch to the project. Canooies are around to help you with patches, version control, tools, expertise, or anything else you might need.

    Here are some of our project ideas, but please leave a comment here with your own! And remember, you have at most 4 hours so think small. There is no project too small… a 2 line patch is the Open Source developer’s equivalent of a CHF 10 bottle of wine. It might not be appropriate to the current meal, but it is almost always appreciated.

    • Griffon-Hudson Plugin similar to the Grails plugin
    • Griffon Substance Look and Feel Plugin
    • Groovy Static Analysis Rules – Similar to Find Bugs but for Groovy
    • Groovy @Log Transformation extensions – There is some small work to do in Groovy Core
    • Find Bugs statis analysis rules for Java
    • Gradle Find Bugs plugin
    • Gradle JavaNCSS plugin

    Post your ideas below, and see you on Wednesday.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Canoo and Friends Release Open Source Griffon Plugins at Hackergarten

    May 14th, 2010
    Once again a group of Canooies and Friends joined together on a Friday night to write open source code and contribute back to the software community. By any measure, the April <a href=”http://hackergarten.net/”>Hackergarten</a> was a large success!
    The group developed and released 3 Plugins to the Griffon Framework, an open source Groovy and Swing desktop application framework.
    A recent Friday night
    3 plugins were released:
    JTreeMap – provides a JTreeMap component.
    Notify – integrates desktop announcements via lib-notify (Ubuntu), Snarl (Windows), Growl (MacOSX).
    Oxbow – provides a TaskDialog component
    The 4th plugin (DockingFrames) required a bit more of work than expected, however the team will be making a release soon.
    Project Lead (and Canooie) Andres Almiray
    I learned a lot about griffon plugin system. never thought how easy
    plugin developement for griffon is. learned some more stuff about git
    and about using the intellij idea with griffon. regards,
    René Groeschke
    At Hackergarten I learned how easy, and fun, the development of a standalone application can be using griffon.
    In just a few steps you are able to get something working, avoiding the painful process of setting up a build tool.
    I liked the use of the pomodoro technique during the evening, when used in team it helps avoiding that only one developer is doing all the steering.
    Francesco Durbin
    It’s amazing to see what you can achieve spending just a few hours in
    hackergarten: Before the last event griffon was completely unknown to me –
    now I am an official committer of that project. And besides that I had a
    great evening with beer and pizza and some nice people.
    Christoph Lipp
    The second Hackergarten was great! Not only did I learn Griffon, I had the
    best teacher in the world, Griffon project lead Andres Almiray himself!
    Working together with such talented people, as Hackergarten brings
    together, is sheer joy. Actually contributing to the open source
    community, seeing your stuff used by others, is just cream on top! I can’t
    wait until the next Hackergarten!
    Per Junel

    Once again a group of Canooies and Friends joined together on a Friday night to write open source code and contribute back to the software community. By any measure, the April Hackergarten was a large success!

    The group developed and released 3 Plugins to the Griffon Framework, an open source Groovy and Swing desktop application framework. The plugins were:

    • JTreeMap – An interesting take on tree visualizations based around the JTreeMap component.
    • Notify – A perennial hackergarten favorite, this adds nice alpha blended desktop announcements to Ubuntu, Windows, and MacOSX.
    • Oxbow – A mature project to standardize common task dialogs, an area Microsoft excels in but Java is just catching up with.

    We also got a good start on a 4th plugin (DockingFrames), but there was just too much work to do and we’ll try to finish and release in the next few weeks.

    Griffon Project Lead (and Canooie) Andres Almiray already blogged his thoughts about the night. Here is what some other participants are saying:

    ReneI learned a lot about Griffon plugin system. never thought how easy plugin developement for Griffon is. Also learned some more stuff about git and about using Intellij IDEA with griffon.
    Rene Groeschke

    At Hackergarten I learned how easy and fun the development of a standalone application can be using Griffon. In just a few steps you are able to get something working, avoiding the painful process of setting up a build tool. I liked the use of the pomodoro technique during the evening, when used in team it helps avoiding that only one developer is doing all the steering.
    Francesco Durbin

    It’s amazing to see what you can achieve spending just a few hours in hackergarten: Before the last event Griffon was completely unknown to me – now I am an official contributor of that project. And besides that I had a great evening with beer and pizza and some nice people.
    Christoph Lipp

    The second Hackergarten was great! Not only did I learn Griffon, I had the best teacher in the world, project lead Andres Almiray himself! Working together with such talented people, as Hackergarten brings together, is sheer joy. Actually contributing to the open source community, seeing your stuff used by others, is just cream on top! I can’t wait until the next Hackergarten!
    Per Junel

    The next two Hackergarten nights are on the road. If you’d like to join the fun then swing by or join the mailing list:

    • 19 May – GR8 Conference Copenhagen
    • 2 June – Jazoon Conference Zurich
    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Java Post Mortem with Gilad Bracha

    May 7th, 2010
    This year’s JAX.de conference hosted many great Java thought leaders, including one of my personal favorites Gilad Bracha. If anyone has the authority to critique Java and the Java platform then surely it is Gilad who spent years working for Sun on the language and platform tools. If you haven’t followed him recently, I recommend reading his papers on Pluggable Type Systems and Software as a Service.
    Lucky for me, my “Code Generation on the JVM” talk was sandwiched between his “Java: A Post Mortem” and “Newspeak: A Principled, Dynamic Language”. It was surreal to see my name next to someone I’ve revered for many years, and I felt a bit like the rookie professional athlete who has to play his first game against someone they grew up watching on TV.
    As expected, his talks were good mix of humor, strong opinion, and thoughtful analysis. Here are my favorite bits:
    If you can’t abstract over it then it doesn’t belong there.
    An original sin of Java was constructors. They are static methods that commit to returning a concrete implementation. Remember the design mandate “program to interfaces”? Constuctors subvert this and gave rise to a cottage industry of Dependency Injection frameworks to get around the issue (as long as you consider VMWare a cottage industry!). You wouldn’t need DI if your language supported proper inversion of control in the first place. The next generation of languages hopefully won’t have this limitation.
    Class initialization is absurd. There should be none.
    Static state is bad, bad, bad and read Gilad’s great blog post if you aren’t persuaded. Without static state there is no need for class initialization. We’ve all heard that the JVM start up times are slow, but that is a bit of a myth. The problem is that through class initialization we’re asking the JVM to do millions of operations that could be avoided without static state. A Lambourgini isn’t slow, but it sure seems that way if you try to drive it to the Moon. Likewise the JVM.
    Why should a high level language need a memory model in the first place?
    The original Java memory model was incoherent, the revised memory model is understood by only five people in the world, and the actors for concurrency idea existed since the Gulati paper of 1970. Bracha’s point wasn’t that we need a better Java memory model, it is that we should have made a language that did not need to expose a memory model to the developers. As with many of the Java original sins, Threads were the wrong level of abstraction and something better like Actors should have been chosen.
    Java is going to stay but it is going to stay where you don’t want to look
    Everyone wants to predict the demise of Java, don’t they? But few people offer a real, long-term alternative. There is enough risk with any of the other JVM languages to persude Enterprises that sticking with Java is the best choice. The evening’s speaker panel agreed (mostly) that the real successor to Java didn’t exist today. So where will the next big lanugage come from? Who can monetize a programming language? Microsoft has somehow done it with .NET, but show me the Oracle business plan that details how to get rich from writing a programming language. Or any other company for that matter. Here is my prediction: all this language innovation results in the best ideas making it into libraries and frameworks available for the Java language, and Java remains number one on our beloved TIOBE index, clunky syntax and all.
    Webapps make you reboot. It is called “session expired”
    Newspeak was funded to solve the problem of always on, always updated software. Quick question: what version of Google do you use? I’ve never in my life seen a version number at Google.com and that is a deployment success story. All software should work this way. I’m unclear how Newspeak is going to solve the session state problem but I’m also certain that I do <i>not</i> fully grasp the Newspeak vision.
    If you want a static language you should look at Egyptian heiroglyphics because it hasn’t changed in a long time
    And another quote from Brian Hurt: “Demand that you not have to learn something new to learn new languages, and then wonder why languages don’t improve much”. Newspeak is a bold change, and people are going to be very resistent. Incremental changes like Groovy are much easier to sell than big sweeping language changes. And an always changing language can hardly be adopted by the masses. I left the session wondering if Newspeak is an experiment meant to fuel language innovation or a real alternative as a mainstream programming language.
    Complicated is not a sign that you’re clever. It is a sign that you failed.
    Simple solutions can be achieved with a low number of non-overlapping concepts. If you need something more complicated then build it by composing the simpler pieces together. Special cases like primitive types are the road to ruin. Or the road to massive popularity and success as is the case with Java. In my humble opinion: success is an accident, much better to aim for happiness.
    Language development has moved away from professional language writer and into the hands of hobbiest developers
    As a hobbiest developer working on the Groovy language, I have averaged a mere 2-3 hours a week of work over the last 12 months. The good news: I’m clearing my schedule after the GR8 Conference to work on Groovy’s GEP-4. The bad news, I am and will remain a non-professional hobbiest developer hacking on a language in my spare time. Life couldn’t be better.

    This year’s JAX.de conference hosted many great Java thought leaders, including one of my personal favorites Gilad Bracha. If anyone has the authority to critique Java and the Java platform then surely it is Gilad who spent years working for Sun on the language and platform tools. If you haven’t followed him recently, I recommend reading his papers on Pluggable Type Systems and Objects as Software Services. Lucky for me, my “Code Generation on the JVM” talk was sandwiched between his “Java: A Post Mortem” and “Newspeak: A Principled, Dynamic Language”. It was surreal to see my name next to someone I’ve revered for many years, and I felt a bit like the rookie professional athlete who has to play his first game against someone they grew up watching on TV.

    As expected, his talks were good mix of humor, strong opinion, and thoughtful analysis. Here are my favorite bits:

    If you can’t abstract over it then it doesn’t belong there.
    An original sin of Java was constructors. They are static methods that commit to returning a concrete implementation. Remember the design mandate “program to interfaces”? Constuctors subvert this and gave rise to a cottage industry of Dependency Injection frameworks to get around the issue (as long as you consider VMWare a cottage industry!). You wouldn’t need DI if your language supported proper inversion of control in the first place. The next generation of languages hopefully won’t have this limitation.

    Class initialization is absurd. There should be none.
    Static state is bad, bad, bad and read Gilad’s great blog post if you aren’t persuaded. Without static state there is no need for class initialization. We’ve all heard that the JVM start up times are slow, but that is a bit of a myth. The problem is that through class initialization we’re asking the JVM to do millions of operations that could be avoided without static state. A Lambourgini isn’t slow, but it sure seems that way if you try to drive it to the Moon. Likewise the JVM.

    Why should a high level language need a memory model in the first place?
    The original Java memory model was incoherent, the revised memory model is understood by only five people in the world, and the actors for concurrency idea existed since the Gulati paper of 1970. Bracha’s point wasn’t that we need a better Java memory model, it is that we should have made a language that did not need to expose a memory model to the developers. As with many of the Java original sins, Threads were the wrong level of abstraction and something better like Actors should have been chosen.

    Java is going to stay but it is going to stay where you don’t want to look
    Everyone wants to predict the demise of Java, don’t they? But few people offer a real, long-term alternative. There is enough risk with any of the other JVM languages to persude Enterprises that sticking with Java is the best choice. The evening’s speaker panel agreed (mostly) that the real successor to Java didn’t exist today. So where will the next big lanugage come from? Who can monetize a programming language? Microsoft has somehow done it with .NET, but show me the Oracle business plan that details how to get rich from writing a programming language. Or any other company for that matter. Here is my prediction: all this language innovation results in the best ideas making it into libraries and frameworks available for the Java language, and Java remains number one on our beloved TIOBE index, clunky syntax and all.

    Webapps make you reboot. It is called “session expired”
    Newspeak was funded to solve the problem of always on, always updated software. Quick question: what version of Google do you use? I’ve never in my life seen a version number at Google.com and that is a deployment success story. All software should work this way. I’m unclear how Newspeak is going to solve the session state problem but I’m also certain that I do <i>not</i> fully grasp the Newspeak vision.

    If you want a static language you should look at Egyptian heiroglyphics because it hasn’t changed in a long time
    And another quote from Brian Hurt: “Demand that you not have to learn something new to learn new languages, and then wonder why languages don’t improve much”. Newspeak is a bold change, and people are going to be very resistent. Incremental changes like Groovy are much easier to sell than big sweeping language changes. And an always changing language can hardly be adopted by the masses. I left the session wondering if Newspeak is an experiment meant to fuel language innovation or a real alternative as a mainstream programming language.

    Complicated is not a sign that you’re clever. It is a sign that you failed.
    Simple solutions can be achieved with a low number of non-overlapping concepts. If you need something more complicated then build it by composing the simpler pieces together. Special cases like primitive types are the road to ruin. Or the road to massive popularity and success as is the case with Java. In my humble opinion: success is an accident, much better to aim for happiness.

    Language development has moved away from professional language writer and into the hands of hobbiest developers
    As a hobbiest developer working on the Groovy language, I have averaged a mere 2-3 hours a week of work over the last 12 months. The good news: I’m clearing my schedule after the GR8 Conference to work on Groovy’s GEP-4. The bad news, I am and will remain a non-professional hobbiest developer hacking on a language in my spare time. Life couldn’t be better.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Juggling with DLLs, WebStart and Maven

    May 6th, 2010

    Juggling with DLLs, WebStart and Maven

    Recently we were asked to implement a Drag & Drop mechanism between Microsoft Outlook and a Java based internet application. This necessitated our Java server having to communicate with COM objects on the client side. How do you do that?

    The good thing is that our application was built using UltraLightClient, so we had java on both the server and on the client side. And after some thinking, the steps seemed pretty clear, even if a tiny bit of juggling would be required. However, the juggle almost turned into a struggle when we encountered some unexpected pitfalls.

    In this blog I will give a quick sketch of our solution and point out some of the traps to be aware of.

    Step 1: Talking COM using JACOB

    In order to communicate with Microsoft programs from Java you need a Java COM Bridge.
    We were using JACOB and it was surprisingly easy to extract Outlook mails into Java objects.

    The idea:
    The following method extracts the selected outlook mails to a directory and returns the list of created files:

    The trap:
    Using the email subject as a file name is practical, but it can contain many weird characters which may not be supported when the files are created. We found out that JACOB has problems creating files containing even characters like “:” and “,”. Furthermore, no exception is thrown, although the file fails to be created completely.

    The solution:
    Replace potentially dangerous characters with something neutral using regular expressions:

    To be on the safe side we were using a whitelist approach. We treat everything as invalid except for characters which are listed after the “^” character.

    Step 2: Shipping a DLL with Webstart

    JACOB can talk to Outlook because it comes with a DLL which has to be present in the classpath. This means we either have to ensure that all our users have this library installed (yikes!) or we ship it together with the application client using Java Webstart.

    The idea:
    We include the DLL in the jar file and sign it with a valid certificate. Then it can be referenced from the JNLP file that launches your web application:

    The trap:
    We were using the optional parameter download=”lazy” to ensure that the library is only downloaded when it is really needed. The result was that it never got loaded at all(!) because we did not specify to which “part” the library belongs. This is another optional parameter which turns mandatory in combination with download=”lazy”.
    Unfortunately this little detail is not too well documented. The only hint found was this one (in german). It took me quite some time to find this critical information.

    The solution:
    Since the jar containing our DLL is really small we chose to use download=”eager” (which is the default anyway) instead of defining “parts” in our JNLP.

    Step 3: Using native lib references with the webstart-maven-plugin

    We already were using Maven as a build system and our client distribution is generated with the webstart-maven-plugin as follows:
    – We use a separate module with packaging type “pom” for the generation of the webstart client. Of course, this module is part of the multi module build for our application.
    – We provide a template for the JNLP file containing a parameter “$dependencies” which will be replaced by a list of the dependencies of the current module
    – At build time the dependencies will be signed and put into a zip file together with the JNLP file.
    – The zip file can be extracted to a java webstart server or, in our case, into a war file that will be deployed on a server.

    The idea:
    Since JACOB is available via Maven Central integration seemed pretty easy. We only have to generate the correct reference to the native library.

    The trap:
    Unfortunately the current version of the webstart-maven-plugin (1.0-alpha-2) does not support native libs (open issue). So we will need a workaround that wraps the jacob.dll into a jar file and generates the nativelib reference in our JNLP.

    The solution:
    Perform the following steps:
    – Change the packaging type for the module from “pom” to “jar”.
    – Configure the pom.xml to copy jacob.dll from the maven repository into the build directory of the module using the maven-dependency-plugin
    – Add the nativelib reference to the velocity template using the build artifact of the current module as a reference.

    Summary:

    After successfully having avoided the traps (okay: by stepping into them and finding a way out again) we got an application with a pretty cool feature integrated seamlessly in our build process. Nice!

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Java Business RIA redefined!

    May 2nd, 2010

    The future belongs to Rich Internet Applications (RIA) – they are increasingly replacing the classical desktop application. And it is no wonder, as this latest generation of web applications offers a totally new kind of interactivity. Furthermore, RIAs spare your budget thanks to their operating system independence and the fact that they can be used without installation. According to the market research organization Forrester Research, RIA technology will be deployed in around 60% of all software development projects in the coming years.

    RIAbox_middle

    The disadvantage of most of today’s RIA frameworks is that they were developed for the optimization of web sites. They rapidly reach their limits, therefore, with complex business applications. Canoo Engineering’s Canoo RIA Suite with its modular design provides a remedy. It’s heart is ULC (UltraLightClient), a proven and stable component for the development of RIAs – optimized for the performance requirements of business applications. Thanks to the 100% java-based homogeneous programming model, ULC reduces the complexity of RIA projects to a minimum. RIAs developed with ULC score highly due to their low development and maintenance costs, and are more than a match for classical desktop applications in user-friendliness, functionality, attractiveness, robustness and performance.

    Since March 31, 2010, ULC Core is available as a Beta Release. The Canoo Ria Suite will be released officially just before Pentecost 2010. The advantages at a Glance:

    • Up to 50% reductions in development costs
    • Puts business functionality on to the web without quality losses
    • Lower operational costs thanks to server side maintenance and standardized technology
    • Maximum security thanks to standard conformity
    • Straightforward and rapid development due to uniform Java basis
    • Robust and scalable architecture
    • No longer time-consuming client-side deployment
    • Enables highly interactive and user friendly interfaces
    • No browser adaptation required
    • Optimal user productivity due to rapid response times
    • Lower project risk thanks to well engineered, tried and tested technology
    • Impressive prototypes in minimal time

    “We switched to ULC in the middle of a large software project, as we were not able to implement all the requirements with the technology we were using at the time. ULC then enabled us to at least double our productivity, in turn allowing the project to be completed on time.”

    Greg Hutchinson, Principal Developer of a large Canadian financial institution

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    css.php