Thursday, September 27, 2007

JRuby on RCP for EclipseCon 2008

Long Talk submission:

"Writing SWT/JFace presentation code in Java can be very verbose and may involve a lot of boiler-plate work. Additionally, Java syntax makes it hard to map the code to the actual user-interface, making maintenance difficult and time-consuming. Enter the world of scripting with JRuby, a JVM implementation of Ruby, which is an Object-Oriented dynamic language that has an incredibly succinct syntax and many features that can help improve code readability and quicken testing cycles. For example, with Ruby blocks, widgets can be nested within composite widgets in a way that maps closely to how the user-interface looks like. This is similar to how HTML tags in an HTML document can be nested within other tags and map closely to how visual components are shown in a web-page. Due to the dynamic nature of JRuby, the user-interface can also be tested while it is being developed, thus improving productivity considerably. Furthermore, Ruby’s terse syntax helps in writing easier to understand business logic by quickly authoring a domain specific language and employing it in the implementation of business use-cases. A sample application will be demonstrated to clearly illustrate the benefits of JRuby in RCP development. Attendees will walk away with good knowledge of what JRuby provides over plain Java and a solid understanding of how JRuby can improve maintainability and productivity while building RCP applications. This talk is for Java developers who are familiar with Eclipse RCP development and Ruby developers who are interested in doing desktop application development with Eclipse RCP."

Thursday, September 20, 2007

AOP Why? When? Where?

The other day, I attended a Chicago Java Users Group (West) presentation titled "Aspect-Oriented Programming and Software Design in Java and AspectJ" by Dean Wampler. I had a number of burning questions on my mind before I went there:
  1. Why invest time learning AOP?
  2. When do we need to apply AOP?
  3. Where in our code do we apply AOP?

Well, the answers that I got go as follows:

  1. AOP helps separate mixed concerns that OOP cannot. For example, OOP does not have an easy mechanism to separate the transaction concerns from your business domain logic. AOP on the other hand can handle that transparently or provide developers with an annotation to apply on a method when a transaction is needed.
  2. We need AOP whenever our code is becoming unreadable and hard-to-maintain due to intersection of many different domains, such as the business domain, transaction domain, security domain, logging domain, and others.
  3. AOP is applied at the points of domain intersection, usually keeping the business domain code in the main application classes, yet separating code from other intersecting domains into applied aspects. So for example, the logic for "checking if the logged in user has access to the task they are executing" can be separated out into its own aspect outside the business domain code.

Next, I had a concern about how long it would take all the team developers to learn AOP before being able to reap its benefits. After all, AOP seemed to have a learning curve that is as steep as OOP's.

Well, here is one pattern that can be followed to start reaping AOP's benefits before everybody on the team has caught up with it. Have the first developer or two generate Java annotations that embed useful aspects (like a transaction annotation, method logging annotation, or security authorization checking annotation), and then provide it to the rest of the team for free use wherever needed. This will give the team a chance to learn AOP gradually and still reap the benefits while doing it.

Next, I wondererd how do you introduce AOP into a team with success?

Well, simply start using AOP to improve your development processes first. For example, use AOP to check your code at compile time for any violations of MVC principles (is the View talking directly to the database or is it going through the Model tier first?) This will help the team get acquainted with AOP without the risk of releasing malfunctioning software as AOP is only used for development purposes.

Last but not least, what are some of the recommended AOP libraries?

  1. Spring AOP
  2. JBoss AOP
  3. AOPAlliance (comes with Guice)

One note is that many AOP features are sort of built into Ruby, so Ruby developers rarely need to use AOP formally. The "begin" and "after" hooks in Rails controllers are an example of AOP.

If you are currently using AOP or have utilized it in the past, please let us know how things went and what benefits or drawbacks were reaped.

Tuesday, September 18, 2007

Presenting at EclipseWorld 2007

EclipseWorld 2007
Nov. 6-8, 2007
Reston, VA

Thursday, Nov. 8, 8:30 am – 9:45 am
502 Looking Good! Polishing Rich Client Applications
Given the presentation's popularity last year and people's requests for more in-depth material and code examples, I will present a revised version this year. I will start the presentation by breezing through general UI design do's, don'ts, and best practices, and then dedicate the rest of the presentation to demonstrating Eclipse RCP widget customizations to fit customer business needs as well as specific best practices relating to the customizations.

Thursday, Nov. 8, 2:00 pm – 3:15 pm
802 Practical Design Patterns for Rich Client Development
Last year, the focus was on Gang of Four Design Patterns. Due to popular demand for more advanced material and patterns specifically related to Eclipse RCP, I revamped the presentation completely. I will start this year's presentation with more sophisticated applications of Gang of Four Design Patterns, and then move on to RCP-specific Patterns and Anti-Patterns, illustrating each with screenshots and code examples.

Stay tuned for the fun mini-exercises I will be conducting in my presentations!