Thursday, November 29, 2007

A Glimmering Philosophy

In a previous post, Sneak Peak at Glimmer, I gave a basic introduction to the Glimmer JRuby DSL for SWT. In this post, I will go more into Glimmer's design philosophy and how Glimmer actually works.

Glimmer was designed with these API goals in mind:

  • Concise and DRY (Don't Repeat Yourself)
  • Asks for minimum info needed to accomplish task
  • Convention over configuration
  • As predictable as possible for existing SWT developers

Here is a more advanced example of Glimmer than the one previously shown:

shell {
  text "Login"

  composite {
  layout, false)

    label {
      text "Username:"
    text {
      text account.user_name

    label {
      text "Password:"
      text account.password

    button {
      text "Login"
      on_widget_selected { |selection_event|

In Java, to nest SWT widgets under a parent widget, you write code like this:

Label userNameLabel = new Label(parentComposite, SWT.NONE);
Text userNameText = new Text(parentComposite, SWT.BORDER);

As you can see, parentComposite was repeated for every nested widget.

Glimmer is DRY when nesting widgets because you specify the parent widget and children widgets once, and the parent/child relationships are inferred automatically from the code structure:

composite {
  label { text "Username:" }
  text { text account.user_name }

In Java, to set properties on a widget, you write code like this:

groupBox.setText("Account Information");
groupBox.setLayout(new GridLayout());

As you can see, groupBox was repeated multiple times, and so is the prefix "set" before every property.

Glimmer is DRY and concise when it comes to setting properties because after you define a widget, you do not need to explicitly call it again to set its properties. Simply declare them one by one within the widget block:

group {
  text "Account Information"
  font someFont

In Java, you must set a layout manager on every Composite widget, such as Shell, Composite, and Group. Otherwise, nested widgets are not automatically layed out on the screen (so you need to manually set absolute positioning.) Additionally, widgets always need a style even if 90% of the time you use SWT.NONE with Label and Composite for example.

Glimmer demonstrates convention over configuration by addressing these API usability issues with intelligent defaults.

For example, you do not have to specify a Composite widget's style and layout if you do not want to. Composite in Glimmer always defaults to SWT.NONE (SWT::NONE in JRuby) and GridLayout.

There are intelligent defaults for every widget in fact; here is an example relying on a default Composite layout and style and default Text style:

composite {
  text { text "Hello" }

Still, you can customize them:

composite {
  text(SWT::PASSWORD) { text "SavedPassword" }

Finally, Glimmer is designed to be as predictable as possible for veteran SWT developers. This is achieved with a few simple rules:

  • Any widget available in SWT, including custom widgets written by developers, can be accessed from Glimmer by downcasing/underscoring the widget's name (e.g. Composite -> composite, LabledText -> labeled_text)
  • Style can be optionally specified following the name of the widget (e.g. text(SWT::PASSWORD). If it is not specified, the intelligent default is used instead (e.g. SWT.BORDER for Text)
  • Widgets are nested within other Composite widgets to describe parent/child relationships
  • Properties available on SWT widgets are specified by listing them followed by their values, each on a line or separated by semicolons within the widget's block (e.g. label {text "Username:"; font someFont})
  • SWT Listeners are defined by appending the "on" prefix to a listener method name (adjusted to follow the Ruby style convention) and following it with a block that receives the particular listener's event object (e.g. on_widget_selected {|selection_event| doSomething() })

That concluded demonstrating Glimmer API philosophies of being DRY, concise, favoring convention over configuration, and being as predictable as possible for existing SWT developers.

Stay tuned for more details on how SWT listeners are supported in Glimmer.

Monday, November 26, 2007

Craftsmen vs Laborers

When I went to the No Fluff Just Stuff Great Lakes Symposium last weekend, I attended a two-part talk by Neal Ford titled "The Productive Programmer." One thing in the talk that really struck a chord in me was the contrast between craftsmen and laborers.

The laborer basically works with the tools he has for as long as needed to get the job done. The craftsman always pushes his environment to the max, creating new tools along the way to improve productivity and reduce the amount of manual labor.

The craftsman attitude yields a number of benefits:

  • By creating new tools, the craftsman skills are continuously sharpened beyond basic labor
  • Productivity is increased on the long run
  • Attitude remains upbeat and enthusiastic through out the greater challenges involved with craftsmanship

So, what kind of worker are you? A craftsman or a laborer?

Friday, November 23, 2007

Glimmer Shining Through

Glimmer's initial source has been committed to the code repository.

Follow this link for instructions on how to get it.

Stay tuned for a post that goes into more details about Glimmer's syntax and the philosophy behind it.

Monday, November 19, 2007

Sneak Peak at Glimmer

Ruby has been popularized for developing web applications using Ruby on Rails, but it has not gathered the same momentum in building desktop applications.

That can be changed by having a Ruby desktop development library that satisfies these goals/criteria:
  • Platform-independence
  • Native widget support
  • Industry-strength
  • Strong community support
  • Ease of use

  • Current available libraries for Ruby that accomplish some of the goals are:
  • TK
  • FXRuby
  • Shoes
  • GTK
  • wxWidgets

  • However, the library that seems to come closest to satisfying the goals listed above is the Eclipse SWT library, which is used as the foundation for building the Eclipse IDE UI. The only goal that it does not meet is "Ease of use" in Java.

    Java's syntax can be cumbersome for representing UI, which is a part of the reason why people use GUI visual builders and XAML-like authoring languages (e.g. XSWT.) However, Ruby proved to simplify coding a lot by providing the ability to build textual DSLs that are tidy, concise, and have a great expressive power.

    This is why I built Glimmer, a JRuby DSL that enables easy and efficient authoring of user-interfaces using Eclipse SWT. Glimmer currently supports painting widgets and adding listeners. Eventually, it will also come with built-in data-binding support to greatly facilitate synchronizing UI with domain models.

    Here's an example written with SWT in Java:

    Display display = Display.getDefault();
    Shell shell = new Shell(display);
    shell.setLayout(new FillLayout());
    Composite composite = new Composite(shell, SWT.NONE);
    composite.setLayout(new GridLayout());
    Label label = new Label(composite, SWT.NONE);
    label.setText("Hello World!");
    while (!display.isDisposed()) {
      if (!display.readAndDispatch()) {

    Here is the same example authored with the JRuby Glimmer DSL:

    shell {
      text "JRuby on SWT"
      composite {
        label {
          text "Hello World!"

    Need I say more about this? Stay tuned for more about Glimmer, delving deeper into the way it works and how to add event listeners to widgets.

    Initial version has been posted.

    Thursday, November 15, 2007

    Early Presentation of JRuby on SWT

    Tonight, Nick Malnick and I will be presenting an early version of my EclipseCon 2008 Long Talk Proposal "JRuby on RCP" as part of a ChiRb (Chicago Area Ruby Group) meeting.

    Glimmer, a new open-source project that I launched on RubyForge to facilitate UI development with Eclipse SWT, will be demonstrated for the first time during the presentation.

    To RSVP, please follow this link:

    Friday, November 09, 2007

    EclipseWorld 2007 Day 3

    Third day was presentation day.

    I gave the two presentations "Looking Good! Polishing Rich Client Applications" and "Practical Design Patterns for Rich Client Development." Both went well.

    Here are blog posts summarizing each presentation thanks to one of the attendees:
  • Thursday kick-off, about looking good
  • Patterns, the Andy Maleh way!

    I ended the day by attending a presentation on Groovy and Grails, and then enjoying an icecream and some conversations in the show booth area.

    Presenting was a truly wonderful experience and so was attending the conference. I will blog again when the next conference comes. ;)
  • Thursday, November 08, 2007

    EclipseWorld 2007 Day 2

    The second day was kicked off with a keynote speech by Uncle Bob (Robert C. Martin.) The title of the speech was "Craftsmanship and Professionalism."

    Here is a summary of the recommended practices of a professional developer:

    • Short Iterations: delivering working code every iteration makes it possible to decide deployment based on business reasons only
    • Don't wait for definition: build code as part of the software definition
    • Abstract away volitility: employ solid OO design and Design Patterns, separating volitle parts of the domain from involitle parts without creating strong coupling
    • Commission > Ommission: The building construction metaphor for creating software is not a very good one. In construction, we have blueprints as the specifications. In software, not only do the design documents and UML diagrams represent the specification, but also the source code itself. And, looking at it this way, we can see that constructing buildings from blueprints is different from constructing software from source code as the former takes many months to complete whereas the latter takes only a few mintutes with a compiler. So, with software, you can refactor the specs many times, and recompile the code. With buildings, that is very expensive and almost impossible.
    • Decouple from others and never be blocked (The Prime Directive)
    • Avoid Turgid Viscous Architectures: avoid big yucky architectures that try to address world peace
    • Incremental Improvement
    • No Grand Redesigns
    • Progressive Widening: start building small functionality as a small thread stretching from the front end to the back end, and then progressively add more to it.
    • Progressive Deepening: start with UI, deepen to middleware, and then to backend.
    • Don't Write Bad Code: Dahhhh
    • Go Fast. Go Well.
    • Clean Code: bad code slows the whole team down, so refactor mercilessly.
    • TDD: QA Should Find Nothing; 100% Code Coverage; Avoid Debugging

    At the end of the day, I attended another keynote by David Intersimone from Code Gear about the future of building software. It emphasized more and more automation of our tasks.

    One lecture I liked was titled Advanced UI Programming (with SWT/JFace/RCP.) It was good to learn that asyncExec calls can finally be replaced by instantiating the new UIJob class recently added to the Jobs API. Also, they finally cleaned up the act on menus and menu item contributions in RCP. Now, they can be contributed in a way that yields a predictable order on the screen.

    Another lecture I liked was titled Mastering the Graphical Editing Framework by Koen Aers. The presentation was super-focused on introducing the most relevant concepts from GEF to the audience. That was very helpful in giving newbies a good grasp on GEF.

    Stay tuned for more on Day 3, during which I gave my two presentations related to user interface design and practical design patterns.

    Wednesday, November 07, 2007

    EclipseWorld 2007 Day 1

    First day was Tutorial day. After having a wholesome breakfast of eggs and English muffins, I went to the Europa World Tour, and got to learn a few interesting things:

    • Europa and Callisto are Jupiter moons. In fact, all future Eclipse releases will be named with Jupiter moons, which leaves us with about 61 moons.

    • Eclispe does not only refer to the IDE or SDK, but also the platform, community, technology projects, eco-system, etc...

    • Eclipse can be run headless, boiling down to the plug-in framework. Some application servers are written on top of headless Eclipse like Websphere. That way, Eclipse is used as an OSGI component framework

    I also attended a talk about Web Tools platform and saw how you can visually design JSP and JSF pages with Eclipse 3.3 and easily link them to managed beans.

    After lunch, I attended Robert C. Martin's tutorial on Test-Driven Development. I entered just when he started talking about Fitnesse, an acceptance testing framework based on Fit. It was good to learn that every acceptance test can be written with Fitnesse by QA people and stakeholders after a little bit of training.

    I asked a question about contrasting UI testing with Acceptance testing. What I learned is that if you test all your business logic through the UI and then make a simple change in the UI, you break many tests even though the business logic may still be correct. Bob Martin advised us to use UI testing only to test presentation logic, and leave business logic testing to Acceptance tests. In fact, Acceptance tests done test-first end up producing an application API completely decoupled from the presentation.

    The day was concluded with a panel talk that included Mike Milinkovich from Eclipse Foundation, David Intersimone from Codegear, and Bob Martin from ObjectMentor. They discussed a number of topics. Bob talked about how when tools offered refactoring functionality, they lead developers towards following better practices due to how easy refactoring became. On the other hand, developers that are working with new dynamic languages like Ruby are leading tool makers towards providing new features to match what is available for static languages. Mike emphasized that an upcoming major version of Eclipse (e.g. 4.0) must definitely be faster, simpler, and lighter to succeed and fulfill developers' needs. David said that with Eclipse or any other platform, what matters the most is always getting better at fulfilling the user requirements and engineering software of high quality.

    Stay tuned for more. I will also add photos to my blog posts as I find the time.

    Monday, November 05, 2007

    Getting Ready for EclipseWorld 2007

    I am flying this evening to Reston/Virginia to attend the 3-day conference EclipseWorld 2007. I will be giving two presentations titled Practical Design Patterns for Rich Client Development and Looking Good! Polishing Rich Client Applications.

    I will keep you posted day-by-day on what goes on during the conference. For those of you who are also attending the conference, see you there.

    Sunday, November 04, 2007

    Why RESTful Web Services Matter: Part 4

    In Part 3, I concluded my discussion of the benefits of the uniform interfaces in RESTful web services. Today, I will compare message formats between SOAP and RESTful web services.

    SOAP Web Services require sending messages in XML. The format normally used is that specified by the SOAP XML Schema, which is very flexible and able to handle any complex combination of parameters and return values for invoking an operation. The messages consist mainly of an envelope and a body. The envelope describes the message and its encoding, and the body holds the details of the message regarding the request or response.

    For an example, please check this basic SOAP tutorial.

    As you can see, messages in SOAP include information about which operation is being invoked. On the other hand, messages in RESTful web services do not need to include such information as it is implied in the HTTP protocol method being invoked (e.g. GET -> Get, PUT -> Create, POST -> Update, DELETE -> Delete) Due to that, messages in RESTful web services do not need to follow a particular format either, and thus usually have a much ligher format than SOAP.

    Since SOAP messages follow a standard, they do not need to be manually coded as there are tools that can generate them and consume them automatically, based on existing interfaces in the language of choice. On the other hand, RESTful messages are usually proprietary, requiring extra effort on behalf of the programmers to design, generate and consume. That said, there have been efforts to standardize RESTful messages in particular domains and provide automatic generators and consumers. The best example for that is the Ruby on Rails RESTful web services generated using the Rails scaffold_service command.

    The benefits one gets from using SOAP messages are:

    • Flexibility to handle any method names, combination parameters, and return values

    • Preserving continuity of domain models across the wire, by being able to pretend you are working with a local service

    • Availability of Web Service generation/consumption tools due to having a standard

    The benefits in having a less-rigid message format as usually used in RESTful web services:

    • Easier to read messages when troubleshooting problems

    • Less data overhead in the message format, improving performance over the wire dramatically, especially when sending and receiving many small messages.

    • Breaking the domain model by switching to simple CRUD operations when data traverses wires reminds developers of the important concerns related to network communication, such as reliability and performance.

    If your integration use-cases are usually simple and not numerous, you can save yourself from dealing with a lot of complexity by employing RESTful web services instead of SOAP Web Services (or a hybrid approach), gaining generally better performance, scalability, reliability, and popularity for your web services. One of the best examples is the Amazon S3 web service, which due to RESTfulness has a very wide popularity over the web today.

    Saturday, November 03, 2007

    Why RESTful Web Services Matter: Part 3

    In Part 2, I talked about how the RESTful uniform interface facilitates learning and supporting RESTful web services. Today, I will talk about other benefits that are just as important.

    In RESTful web services, the HTTP operations GET and HEAD are required to be safe. In other words, performing them any number of times must not affect server state. They are meant to be used for querying purposes only.

    Additionally, the HTTP operations GET, HEAD, PUT and DELETE are required to be idempotent. What does that mean? Performing an idempotent operation once or more than once must have exactly the same effect. For example, if the contact manager web services had an idempotent DELETE operation, then if you call DELETE on to delete the contact with ID 35, and then a few seconds later repeat the call again, the server should be fine with that and not complain. Of course, the contact will only be deleted once.

    Finally, all basic HTTP operations in RESTful web services, including POST, must be implemented in a way that keeps the server as stateless as possible.

    What are the benefits we reap of having safety, idempotence, and statelessness in RESTful web services?

    • Reliability: Since networks are unreliable, connections sometimes break and you cannot guarentee that your requests went through. However, because GET, HEAD, PUT, and DELETE requests are safe and idempotent, you can repeat multiple times as needed.

    • Scalability: Stateless servers can be scaled very easily by adding as many servers as needed to handle the load.

    On the other hand, operations in SOAP Web Services are often completely tunneled through POST requests, usually missing out on the benefits of safety and idempotence.

    Stay tuned for a discussion about the advantages and disadvantages of having a standard message format for SOAP and no particular message format for RESTful web services.

    Go to Part 4 here.

    Friday, November 02, 2007

    Why RESTful Web Services Matter: Part 2

    In Part 1, I mentioned that RESTful web services normally have a unifrom interface. Today, I will talk about the benefits a uniform interface offers in general.

    There are a number of reasons why RESTful web services conform to a uniform interface. They are similar to the reasons JavaBean APIs only work with properties (often implemented as getters and setters). Given a uniform interface across different applications, clients can always expect the same operations to exist when given a resource name, thus one client can potentially be written to handle many different services.

    With RESTful web services, the standard operations are CRUD, which are typically handled through the HTTP operations PUT, GET, POST, and DELETE.

    For example, if a developer hears of a RESTful web service at that stores "contact" resources, the developer can assume that it is possible to perform an HTTP GET on to list all contacts, and to retrieve a contact with ID 35.

    Benefits of Uniformity in RESTful web services are:

    • Non-existent learning curve

    • Ease of consumption with minimal work

    • Accessiblity to a wide range of clients

    SOAP Web Services on the other hand require developers to make extra effort to learn application-specific APIs and adjust their code to handle them. This decreases the potential number of clients that will consume these services. For example, a banking service API may contain the operations withdraw, deposit, and checkBalance while an order service API may contain the operations listProducts, submitOrder, cancelOrder. Each application will require different consumption code.

    Nonetheless, one thing that kept me skeptical for a long time about RESTful web services is the fact that SOAP Web Services can better reflect the domain model's terminology by allowing operation names such as: withdraw, deposit, authorize, etc...

    Why am I finally over that obstacle? Martin Fowler mentions in his book Patterns of Enterprise Application Architecture that the majority of his enterprise integration projects involved no more than CRUD operations across the different applications. In other words, while Object-Oriented Design principles that encourage us to name operations according to domain terminology help immensely in managing complex domain concepts, the integration domain is usually simple enough that we can elect to leave that benefit behind in favor of ease of learning and support.

    Stay tuned for more discussion about the benefits of the uniform interface.

    Go to Part 3 here.

    Thursday, November 01, 2007

    Why RESTful Web Services Matter: Part 1

    Lately, I've been trying very hard to decipher the whole buzz around RESTful web services. After all, when I first heard about them, I had these first impressions:

    • It is cool that RESTful web services are simpler than SOAP Web Services, but do we really care given SOAP's automatic generation technologies?

    • Why CRUD??? This is heresy against Object-Oriented Design and Domain-Driven Design. After all, you normally want your operation names to match the language people use in the real world as closely as possible. It feels try-hard to twist the domain operation names into fitting the Create Read Update Delete scheme. For example, the stakeholders naturally think of authorizing payments, not posting a payment authorization. Of course, you can still do RESTful/RPC web services, which allow more operations on top of HTTP post, but according to O'Reilly's book RESTful Web Services, these are not truly RESTful.

    • I like how RESTful web services usually have a lighter format for message transmission.

    It took me a while to realize that there are two main differences between RESTful web services and SOAP Web Services:

    • RESTful web services generally have a uniform interface by limiting operations to CRUD. SOAP Web Services have varied interfaces with potentially many different operations.

    • Because of the previous reasons, RESTful web services do not seem to impose a standard on the message format. The HTTP protocol helps convey which operation you are performing regardless of the message data. SOAP on the other hand does impose a standard for the message format, which includes information about which operation is being performed.

    Stay tuned as I discuss each one of these points separately in different blog posts.

    Go to Part 2 here.