• Home
  • Events
  • About
  • Canoo Hosts Hackergarten, Open Source Benefits

    April 26th, 2010

    A few weeks ago on a Friday evening, Canoo opened its doors to the public and hosted a new programming user group called Hackergarten. The goal of the group is different from other user groups: instead of learning from listening to a presentation they want to learn by writing code. In their own words:

    Our goal is to create something that others can use; whether it be working software, improved documentation, or better educational materials. Our intent is to end each meeting with a patch or similar contribution submitted to an open and public project.

    We’re excited to say that their contribution to the Gradle build system was accepted last week! The next release of Gradle 0.9 contains an “Announce” plugin that can notify you and your customers of build events using Twitter, Snarl, or the Ubuntu notification system. You can notify yourself of local build failures or notify your customers of successful formal build releases. It was a long Friday night, but the group of over 10 developers are all happy to see their work accepted. As the group sponsor, Canoo is happy to have kept them caffeinated and well fed.

    The next Hackergarten is this Friday, 30 April 2010. The group plans to write some Griffon plugins, a desktop application framework written in Java and Groovy. The Griffon Project Lead (and Canoo employee)Andres Almiray will be present to help guide the group. If you are anywhere near the Basel area this Friday, then please stop by Canoo and come join the fun. Don’t worry if you’ve never seen Groovy or Griffon before, the point is to learn new skills and meet new people.

    You can find out more information on the Hackergarten mailing list or follow @Hackergarten to stay up to date.

    Come join the fun. Here’s what people are saying about the last event:

    .

    etienne

    The first Hackergarten was a great event, not only because there was free pizza, but primarily because it was a true team event with everyone actively contributing. Submitting a patch for a new Gradle plugin at the end of the night was our goal which we reached successfully. I look forward to learning more about Griffon at the next Hackergarten.

    Etienne Stuber

    .

    alberto

    I learned how easy and powerful Gradle is. The fact: with a little group and in a little time, we wrote a worth-making contribution to an open source project. Did I have fun? Definitely, it was like meeting with friends but for a beer but enjoying coding at the same time. In the future I am interested in writing Grails or Griffon plugins.

    Alberto Mijares

    .

    At Hackergarten I learned about the Pomodoro technique and how to use groovy closures to do exception handling in a smart way. And yes, I had a lot of fun! For future events I am interested in anything with new technologies but especially with testing different approaches on how to program in teams.

    Christoph Sperle

    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

    GWT UiBinder: Better Web App Separation of Concerns

    April 26th, 2010

    One of the newest features introduced in Google Web Toolkit 2.0 is the “UiBinder“. This new way of building views allows the developer to use a declarative approach when doing the layout of a GWT application.

    In case you have not heard about it, GWT is a set of tools that enables Java developers to develop “rich web applications” in the Java language. The term “rich web application” implies two things:

    • Desktop-like interaction, where a user action has immediate feedback (e.g.: input validation, search box terms suggestions, results highlighting, etc) without requiring a server round-trip (executing an HTTP request with the result of reloading the page being browsed). In the world of web applications, this is typically accomplished using Ajax (what is also what GWT does).
    • An application running within a browser, but using native browser technologies (HTML, CSS and JavaScript). If we were talking about applications held in browser plug-ins and running out-of-process within their own virtual machines or by mean of run-times, I would prefer to use the more general term “rich internet applications”. These are launched from a web browser but behave as black boxes for other user agents (e.g.: web crawlers).

    GWT allows us is write Ajax-based “rich web applications” using the Java language instead of the traditional JavaScript. GWT takes your Java code and compiles into JavaScript, HTML, and CSS. So while you write the program in Java, it is translated into a traditional web application.

    Building user interfaces in GWT

    The most common approach to building desktop application interfaces is using visual components called “widgets”. For developers with Swing experience, GWT seems a marvellous step forward because it allows you to leverage most of your knowledge with far less effort than the alternatives. I say seems because this can also be of disadvantage, as I’ll show with an example.
    If we had to create a web interface for a simple web search application, the most common way of doing the interface would be an HTML form for submitting the query and an HTML list to show the results:

    In the case of GWT, a Swing developer might write widget and layout code like this:

    This approach is a valid one and, with some CSS styling, produces a neat interface, but it introduces a too complicated DOM structure that does not scale well for bigger applications:

    Compare the handcrafted HTML tags with the DOM produced using GWT widgets, and the first one is simpler. One of the reasons of the extra verbosity of the GWT one is the use of “HorizontalPanel” to layout the search box horizontally. This is a panel based in tables and it introduces a “too verbose” HTML table for the layout. In the case of a horizontal layout, we can also use a FlowPanel, altogether with some CSS styles, to avoid the search box components stacking vertically (which is the default layout for the HTML “div” elements that a “FlowPanel” produces). The problem is that this approach mixes widgets for layout with CSS for layout (not for styling) what stops being a pure widget approach.
    The next thing to notice in the DOM produced by GWT is the excessive presence of GWT CSS classes (e.g.: “gwt-Label”, “gwt-TextBox”). While they are most times useful when it comes to style the widgets, they are many times not used or they do not fit always our CSS selectors strategy.
    Lastly, there is a lack of HTML semantics in the DOM produced by GWT. Almost every element is a “div”. From the point of view of web standards, it is much more convenient to use an HTML list for the results as it is to use a collection of “div” elements. Producing HTML labels associated with form fields (search box label) is also a usability and accessibility improvement. Using tables for layout should be avoided.
    For a real-world application that use input fields, trees, tables, “tab panels” or splitters, etc… all in the same screen, it is a good practice to get rid of the intermediate superfluous DOM elements. It reduces drastically the amount of “glue” elements, making the DOM much more compact and faster to modify. We should avoid “glue” and automatic generated code, because it needs to be compiled, loaded, executed and maintained. In the case of an overly verbose DOM structure, CSS issues may appear because of the complex structure interactions. Fixing them is akin to fixing bugs in generated code: very difficult!

    Mixing HTML and Widgets

    So how can we mix widgets and html properly? Before GWT version 2.0, the most common way was to use “RootPanel.get(‘someId’)” to access an HTML element in the application host page, and then create an object there to attach the widgets to (ie. a “RootPanel”). If we need to embed only a few widgets in the host page, this technique suffices. But doing this in a real application with a large number of widgets becomes complex and slow.
    UiBinder scales better because it does not inject widgets into the HTML of the host page. Instead, you declare your layout in a stand-alone HTML file that can be composed with other components as many times as necessary to build more complex interfaces. Composition entails componentization, allowing the developer to create subparts of the user interface (UI components) that can be packaged, re-used and tested in isolation.
    But let us see how with an example:

    Our example has been split into three files: the first one is the GWT entry point, that now only instantiates and inserts our new UI component at the interface top level. The second is an XML file representing the view and is required by UiBinder to act as a mark-up template. The third is the Java class implementing the component logic (that as of now is almost non-existent) and invoking UiBinder.
    If you run this code so far, you will notice that now the appearance is exactly the same as in the handcrafted HTML and that there is not yet real integration between the view of the component (mark-up template) and the logic of the component (Java class). Let us fix this by substituting the HTML input field with a GWT “TextBox”:

    Notice the changes in the template where the HTML input field has been substituted by “” and also the little change in the Java class that now has a field of type “TextBox” annotated with “UiField”. When the Java class is instantiated, the UiBinder creates and injects the “TextBox” using the matching field name and “ui:field” attribute. The result is almost the same DOM structure with only some extra attribute values generated by GWT. Note that we also eliminated the “id” HTML attribute. This last change is because of a current limitation in UiBinder which does not allow defining both attributes in the same element. This issue can be solved setting the id attribute in the constructor after the UiBinder has been invoked.
    As next step, let us now integrate the results list by writing out some simple HTML list elements:

    The changes in the UI Binder template is almost the same as the previous one with a subtle difference: in the previous step, we integrated a GWT widget (“TextBox”) replacing the HTML input element. In this second case, we performed a to “bind” the “ul” HTML element from the view because there is no GWT list widget that matches a simple HTML list. Instead of using the API of a GWT widget, we are using the GWT DOM API to directly modify it.

    Adding behaviour

    Let us now go back to the first GWT approach and modify it to create the results when clicking the button. This is what your pre-UiBinder code might look like:

    Here we introduced a “ClickHandler” that modifies the results container with some fake ones when the search button is clicked.
    Doing the same with the UiBinder approach results on the following code:

    We introduced a “Button” GWT widget in the mark-up template together with its corresponding field in the Java class. We also moved the code creating the results to its own method annotated with “UiHandler” (take into account that the signature must be compatible with a “ClickHandler”). Finally, we removed the “form” element from the mark-up (which is not required at all in an Ajax application).
    One of the core design principles in the development world is the benefits of separating logic and presentation. What would happen if now we wanted to change the place where the results appear in relation to the search box? Or, if we wanted to get rid of the “Results:” label because it is not necessary? In the first GWT approach taken, the way in which the widgets are created and nested is reflected in the Java code together with our logic, making necessary changes to this code. Also “static” presentational elements, like the “Results:” label, are embedded in the code where. Applying the separation of concerns principle tells us that they do not belong there. Making a change to either presentation or logic necessarily requires changing both presentation and logic. In the “UiBinder” approach, because of its inherent separation of concerns, these changes would happen only in the mark-up template or in the domain logic, not in both.

    Conclusions

    • When building a web application, no matter which framework you use, never forget that you are still using HTML, CSS and JavaScript. The simpler the DOM produced, the faster the application will perform and the less CSS issues you will find.
    • Web applications have web pages! Always try to use the most semantic HTML structure you can. It improves SEO, usability and accessibility and usually produces compact DOM structures.
    • Even when you program in your favourite language and do everything in code by mean of widgets, do not forget the advantages of principles like presentation and logic separation. Using UiBinder in GWT produces twice the number of files but each is simpler, cleaner, easy to manage, and easier to maintain.
    • With presentation separation, you can let your design team produce a HTML prototype of the different parts of your application that can be easily reused afterwards or even in parallel. Two teams being able to work in parallel reduces the project time span and using prototypes reduces the project risks.
    • Because different tasks require different skills, let the developers code and the designers deal with HTML and CSS. They all will be much happier and the application will be and look much 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

    Spock and Test Spies: A Logical Choice

    April 20th, 2010

    Here at Canoo many of us are preparing to spend the next three days in the Alps at a bi-annual retreat called “Code Camp”, where we stay up all night hacking with technologies and on projects that don’t always fit within our normal projects. This is my first time going, but I hear from the old timers that it is three days of a Spartan like existence focused on replacing sleep with marathon coding sessions, and where anyone causing a build failure is kicked into the Well of Souls with a scream of “FOR SPARTA!”. I am… nervous.

    Those who know me should not be surprised at my technology stack: Groovy for the language, Gradle for the build, and Spock for the unit tests. In preparation for the big event, I dropped Spock into our project, converted all the unit tests to Spock specifications, and then converted all the hand rolled mocks to Spock Interactions. (Why these aren’t called “Spock Mocks” or simply “Smocks” I do not know).

    First Reactions
    First, the Spock framework does some crazy language tricks that aren’t supported in Java or Groovy… and it does so in a statically typed way. Almost all my mocking code has the same IDE completion and navigation the Java solutions have. Pretty amazing stuff given the level of metaprogramming that is going on in the implementation. Optional static typing in Groovy is a very important feature, especially for tool support.

    Secondly, did you know the JVM supports long, punctuated, multi-line method names? Check out this example:

    These long method names are a feature of Spock, not Groovy. Some features of Groovy will not work if you try this in GroovyTestCase, such as using closures. Let’s move on to the mocking and spying code.

    Spying
    I wrote a post many moons ago about the difference between stubs, spies, and mocks. Spying on indirect output of a test is much more important to me than full blown mocking, and I feel extensive mocking is a design smell. So far, I’ve been impressed with the Spock’s ability to analyze test objects after the fact to determine what was and was not called on them. For instance, here is a simple Spock spec asserting that the mouseClicked was indeed called once:

    Mocks are created with the Mock() method in the setup: phase, the system is tested in the when: phase, and the system is verified in the then: phase. Anything in then: is considered an assertion.

    The assertion line reads in English, “expect one time that mouseClicked was invoked”. If mouseClicked is not called by the test then the test fails. If mouseClicked is called more then once then the test failes. If it is called with the wrong parameter… yes, it fails. Any number is supported, not just one, and ranges are supported as well in the same syntax:

    The range (2.._) means 2 to anything, or at least 2 times. (_..3) means from anything to 3, or at most 3 times. The little _ is the wildcard. But what is it doing as a method parameter? I’ll explain that in one second… first check out how regular expressions can be used to specify interactions:

    This says, “make sure neither mousePressed nor mouseReleased were invoked in this specification. Your excitement for this feature will depend on your excitement for Regexs in general.

    Method Constraints
    Spock reinvents Matchers, doing away with the verbose syntax. The previous examples used equality in the matches:

    This is going to perform an equals() comparison on the argument to make sure it matches exactly. You also briefly saw the _ constraint, meaning match anything at all no matter what:

    And there is also the wildcard with type constraint, which will match anything with the specified class:

    You can even get fancy with custom constraints, where you can easily specify in a closure the details of your match. That sure beats implementing IArgumentMatcher!

    Negatives work as well, such as “not null” or “not an instance”:

    There are a lot of options, and there are no subclasses or interfaces to implement. Everything is a one liner without a lot of DSL daisy chaining of method calls. I like it, and I’m excited to use it heavily up at camp next week.

    Target Constraints
    Matchers, or constraints, aren’t just for parameters in Spock. I have never seen this before, but you can add an expectation on the left hand side of mocks, not just the right hand side. In effect, there is a way to say, “expect that method X was invoked on any of my mock objects in scope, I don’t care which one”. In this example, there are 2 mouse listeners in scope, and mouseClicked is randomly invoked on only one of them. The assertion makes sure that at least one was invoked:

    Admittedly, I do not have a real use for this today. But it is unique, I have never seen it before.

    Failures Accumulate

    One last point to mention… failures in expectations accumulate. No exception is thrown until the end of the method, at which point all failures are reported in a batch. For instance, assume that the following expectations are run, and all of them fail:

    The resulting error message reports all failures, not just the first one:

    Great stuff. You can try out Spock in the SpockConsole, and you can see some photos from out last Code Camp on Flickr. And watch this space for future posts after we are all finished. Thanks!

    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 Day 2010: Impressions

    April 15th, 2010

    March 31th, Canoo Engineering AG celebrated it’s 10th anniversary. After some informative and actual presentations around business applications by Greg Hutchinson, Etienne Studer, Alexandra Teynor et al., we evidently had a lot of fun and some interesting chats with our customers. Here are some impressions of Canoo Day 2010:

    .

    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

    Interview with Hamlet D'Arcy

    April 15th, 2010

    Canoo Software Engineer Hamlet D’Arcy was interviewed for the GR8 conference about his professional background and his conference contribution as well as Groovy and the Canoo Hackergarten.

    Here’s the link to the interview! And here are some pictures of Hamlet during Canoo Day 2010:

    DSC_0750 DSC_0772 DSC_0777

    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