Then Google came along and launched their Java version of their Cloud environment(Google App
Engine). Since this one seemed to be easy and free to try, I decided to give it a try with the tutorial. ( App Engine the java platform , so not only the java language is supported, but languages like groovy and jruby also work, but I stayed with ‘just’ Java)  

Within a time span of 5 to 10 minutes I had registered my cloud application and was ready to get started. The registration is not much different than for a Gmail account. Then I decided to install the eclipse plugins, this also worked as a charm.
Next, I generated a GWT App engine project with hello-world example code and pressed deploy and my ‘hello world’ was running in the cloud.

The total time taken for this test run was less than 15 minutes and additional applications would be deployed even faster because the environment is all ready installed.

The benefits of this over a normal hosting provider for me are ease of use (the java hosting providers i am used to take a lot more time for installing a build), and scalability (the app engine requires you to work in way no local file access to enable distributed computing which enables them to scale your application).

And just as an exercise I decided to port a normal small java project of mine into my cloud project. Not much had to be changed, the local property file access was replaced by a classpath resource, and I had to hack my way into GWT which i never had used before. And that last part cost me the most time.

For the few interested in my IMDB profile compare tool see: http://film-freak.appspot.com/ It’s supposed to help film freaks compare which films they both saw and which the other didn’t saw. (If you have an imdb vote history you need to make it public first before you can use your profile number, and some large profiles are not handled right but the feature this service uses is not yet supported by IMDB)

Is the app engine flawless? yeah, well even though app engine comes with a local environment that resembles the real app engine, I had a bug that occurred in the real one but not the local one. The bug was related to the character parsing of the app engine (the bug is still in my application btw)

Also this application didn’t use the datastore, but I heard quite some troubles with the use of frameworks and standards (JPA) on the appengine. To summarize this; the appengine has a special datastore, BigTable, which is fast but not a RDBMS, and to use JPA or JDO plugins for frameworks have to be created and the quality of those plugins define what part of JPA and JDO is available and at this moment this seem to be quite limited. Maybe later this year I’ll take some time to play around with this datastore.

Also see:
http://www.theserverside.com/news/thread.tss?thread_id=54919

http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine

J2SE 1.4.2 is in its Java Technology End of Life (EOL) transition period. The EOL transition period began Dec, 11 2006 and will complete October 30th, 2008, when J2SE 1.4.2 will have reached its End of Service Life (EOSL).

This doesn’t mean that Sun doesn’t support Java 1.4 anymore - with Sun’s Java SE for Business you can get up to 15 years of support for older Java versions.

However, if you’re on a project that still uses Java 1.4 you should really upgrade to Java 6, if you have any say into which Java version is being used. Besides the new features added in Java 5 and 6, you’ll enjoy the performance enhancements and bug fixes.

If you’re a Java programmer and you still didn’t learn the new Java 5 features… then you’re in trouble.

The SCJP exam for Java 1.4 has been discontinued this month.

I will try to give more insight into PA by using a more formal approach. In the section below I will use the definitions “success state” and “system” a lot. I will define these first:

Success state: P_1 and P_2 and … P_N

P_x (1 <= x <= N) is a predicate, for example: P_1 == (All timesheets employees are submitted), P_2 == (All submitted timesheets are correct).

System: S

S => P_i and P_i+1 and … P_i+m and Q_j and Q_j+1 and … Q_j+n

where P_i and P_i+1 and … P_i+m is a subset of our success state P_1 and P_2 and … P_N

Q_j and Q_j+1 and … Q_j+n are additional predicates, not in our success state.

Instead of system you can also read solution. A system can be an already existing system or something that can be built. To illustrate the difference between traditional strategies and the PA strategy, we will do a step by step construction towards an at first unknown success state T_success. We will start from an empty state T_empty.

Traditional strategy 1:
Step 1) Design new component C_1.
Step 2) Check new state T_1 with customer: is this state the success state? Yes: done, No: proceed.
Step 3) Design new component C_2, connect C_2 to C_1.
Step 4) Check new state T_2 with customer: is this state the success state? Yes: done, No: proceed.
Step 5) Design new component C_3, connect C_3 to C_2 and C_1.
Step 6) Check new state T_3 with customer: is this state the success state? Yes: done, No: proceed.
…

The first strategy starts building new components, one at a time. After each component is finished we check if success state is reached. This is not unlike many hobby projects where you start from scratch and build a component at a time. Once you are happy with result you have reached T_success.

Traditional strategy 2:
Step 1) Apply systems S_q, S_q+1, … , S_q+k (short: S_q’) to T_empty.
Step 2) Check new state T_k’ with customer: is this state the success state? Yes: done, No: proceed.
Step 3) Design new component C_1, add this component to S_q’.
Step 4) Check new state T_k1′ with customer: is this state the success state? Yes: done, No: proceed.
Step 5) Design new component C_2, add this component to S_q+1′.
Step 6) Check new state T_k2′ with customer: is this state the success state? Yes: done, No: proceed.
…

The second strategy starts from a combination of, most likely existing, systems. We then add components one at a time. After each component we check if we have reached the success state. This is a way of building systems which is used often when adding functionality to legacy systems.

Traditional strategy 3:
Step A.1) Apply a permutation of systems S_q, S_q+1, … , S_q+k (short: S_q’) to T_empty.
Step A.2) Check new state T_k’ with customer: is this state a good enough approximation of the success state? Yes: proceed to B.1), No: proceed.
Step A.3) Apply a different permutation of systems S_q, S_q+1, … , S_q+k (short: S_q1′) to T_empty.
Step A.4) Check new state T_k1′ with customer: is this state a good enough approximation of the success state? Yes: proceed to B.1), No: proceed.
Step A.5) Apply a different permutation of systems S_q, S_q+1, … , S_q+k (short: S_q2′) to T_empty.
…
Step B.1) Design new component C_1, add this component to previously found near success system permutation S_q”.
Step B.2) Check new state T_k1” with customer: is this state the success state? Yes: done, No: proceed.
Step B.3) Design new component C_2, add this component to previously found near success system permutation S_q”.
Step B.4) Check new state T_k1” with customer: is this state the success state? Yes: done, No: proceed.
…

The third, somewhat less traditional, starts by finding a good combination of systems. This combination should give a good approximation of the final state the customer wants to achieve. Only then you start adding new components.

Classic PA strategy:
Step A.1) Create a definition of T_success, called T_success’.
Step A.2) Check T_success’ with customer: is this state the success state? Yes: proceed to B.1), No: proceed.
Step A.3) Change the definition of T_success’ resulting in a new definition called T_success1′.
Step A.4) Check T_success1′ with customer: is this state the success state? Yes: proceed to B.1), No: proceed.
…
Step B.1) Directly derive definitions of components C_1, … C_u from best definition T_success”.
Note that C_1, …, C_u => P_1 and P_2 and … P_N must hold.
Step B.2) Match components C_1, … C_u with systems S_q, S_q+1, … , S_q+k.
Step B.3) Choose best matching(s). For these matchings T_success” must be a subset of resulting state T_matching.

PA first creates a state definition as close as possible to the success state. It then reviews and alters this state iteratively. Only when the definition is satisfactory the next phase starts. In this phase component definitions are derived from the success state definition. These component definitions are then matched with systems and the best matchings are chosen. Simplicity is important in PA: we always strive for a correct succes state with minimal size.

Note that the first two traditional strategies have no real focus on the final success state. This means that during development the chosen success state might actually be (a lot) different than the real success state. The biggest difference between the third strategy and the PA strategy is that in PA we disregard existing systems (read: solutions) until a really good success state definition has been found. Also, we extract as much information as we can from the success state definition. We then use this information to define components. Each component definition should represent a part of the success state. These component definitions should be mutually exclusive (i.e. no overlap) and all component definitions together should imply the success state. Next we match the component definitions with all known systems and come up with the best matchings. Classic PA is almost done here. We now compare the best matchings and present them, with cost figures, to the customer.

As mentioned earlier an important aspect of PA is the separation of the success state from any solution. This is important because of the reduced effort needed: anyone involved in the process can just think about the success state and can forget about (existing) systems. Depending on the number of systems this can be a serious advantage.

When there are only few solutions and the customer really doesn’t know what he or she wants, starting from an existing solution and building from that is the way to go. However, when there is one clear success state and many possible (existing) solutions PA will shine.

• [1]: http://www.procesacceleratie.nl/

The idea behind SOA is actually very good. It loosely couples the service and the front-end, thus separating our concerns. The term seperation of concerns (SoC) was first introduced by Edsger Dijkstra about 35 years ago. The Wiki has an interesting qoute on SoC [2]:

“All programming paradigms aid developers in the process of improving separation of concerns. For example, object-oriented programming languages can separate concerns into objects, and a design pattern like MVC can separate content from presentation and data-processing (model) from content. Service-oriented design can separate concerns into services.”

In this context SOA really looks like the next step in programming.

Assuming your company is planning to “go SOA” in near future, what challenges await?
Here are some of the implications that come to mind when using SOA:

• use of external services means higher internet bandwidth usage
• exposure of internal services to external companies means additional security measures become necessary
• using just a single connection to external services means a higher chance of losing messages
• use of possibly badly written external services means additional infrastructure and code measures, such as timeouts, become necessary
• when chaining services complex behaviour can emerge and message based testing tools are highly advised

Using SOA we also have to be more aware of:

• connection failure
• message loss
• service failure

By using a polling mechanism we could improve our awareness, but the transition to a Service Oriented Architecture will still be a step-by-step process [3], where we will learn by doing.

• [0]: http://www.finalist.com/content/19787/hot_or_not_contest_vermaakt_bezoekers_j-fall_
• [1]: http://www.nljug.org/jfall/
• [2]: http://en.wikipedia.org/wiki/Separation_of_concerns
• [3]: http://it.toolbox.com/blogs/the-soa-blog/soa-benefits-challenges-and-risk-mitigation-8075

The keynote today was held by Richard P. Gabriel and Guy L. Steele, Jr. It was… strange. Very, very strange. Bizarre, in fact. The two of them went through the history of programming languages in a colourful slideshow spiked with music and video clips and singing and ringing on cowbells. They didn’t talk but recited, like they were reading poems instead of giving a tech talk. Bizarre, just bizarre. I couldn’t quite decide if it were madness or genius. So I suppose it must be art.

Session 1: Five Considerations for Software Developers by Frank Buschmann and Kevlin Henney
I attended this session mostly because of Kevlin Henney. I listened to one of his talks last year and it was hugely entertaining, as well as insightful. This session wasn’t quite that entertaining, but it had a lot of good content. The five considerations were: Economy (strive for minimalistic solutions), visibility (your ideas should be visible in your code), spacing (keep separations between domain, services and infrastructure), symmetry (keep the code clean and balanced) and emergence (do not build too much explicit control in your code, let it emerge instead).

Session 2: LEGO Develops a new robotics platform WeDo
This session was a disappointment. It was not a presentation on robotics or WeDo or LEGO’s vision for robotics in the future, or much of anything, really. Most of all it was a presentation of LEGO as a business, and of LEGO’s business processes. As if the audience was a group of business managers, and the speaker was trying to sell stocks. I should have attended Kevlin’s second talk instead.

Session 3: Real-world Refactoring by Neal Ford
This was another session with a lot of content. It’s hard to summarise what he said in just a few sentences, but I’ll try anyway. First of all, he presented two principles to keep in mind when refactoring: The composed method (break down large methods into smaller well-named methods until it reads like a series of steps in an algorithm) and SLAP (keep the same level of abstraction in a method). Next, he gave us two things to be cautious about: Dependencies on third-party frameworks and spider web dependencies among our own classes. In addition, he talked about detecting duplication in our code with the tool cpd, avoiding duplication of code in tests, doing large refactoring on branches and doing ‘scary’ refactorings of brittle code. Lastly, he advised us to use code metric tools to discover when and where to use refactoring.

Session 4: Patterns of Internal DSLs by Martin Fowler
Martin Fowler is another of my favourite speakers. He always speaks loudly and clearly and I always feel as if I learn something when I’m reading one of his books or listening to him talk. This session was no different, although it was rather more technical than I had hoped for. He gave us several techniques for writing internal DSLs, but no pointers at all on when to use DSLs in the first place.

Session 5: Building DSLs with External Workbenches by Neal Ford
Neal Ford opened this session with one interesting observation: IDEs are slowly moving from working on text files to working directly on the abstract syntax trees instead. Thus, text becomes just one possible representation of the software, among other possibilities. But the rest of the talk concentrated on two different tools for creating DSLs: An Eclipse based tool called Xtext, and a tool created by JetBrains, the company behind the IntelliJ IDE, called MPS. Both tools enabled the user to create DSLs and the tools to work efficiently with the DSLs. Xtext, for example, will automatically generate a new Eclipse editor plug-in for the language, complete with syntax-aware colour coding and context-sensitive help.

Conclusion
Domain Specific Languages was hot topic this year. I think almost every speaker at JAOO mentioned them in some form or another. The most obvious use of DSLs I’ve seen is as a build language (Gant being an example of an internal DSL inside Groovy). But I would have liked to see some more (and more diverse) examples of using DSLs in real life projects.

Other hot topics included functional programming (emerging into the mainstream, both in the form of new languages such as F# and Scala, and as a heavy influence on the evolution of existing mainstream languages); dynamic languages (pretty well established in the mainstream by now, with representatives such as Ruby, Groovy and Python); parallel computing (mostly as a threat hanging over our heads, waiting to be overcome one way or another) and how best to utilize the internet in our applications (cloud-computing and rich internet applications).

In conclusion JAOO 2008 has been a wonderful conference. I’ve learned a lot, talked to a lot of very interesting persons and gotten a load of inspiration that will properly take me days, if not weeks or months, to process. I hope I’ll be able to attend next year too.

Today’s keynote was about Google Chrome and their V8 JavaScript engine. It’s as nifty piece of technology, but wasn’t a very interesting subject for me. I can’t help but to doubt that JavaScript will be any kind of long-term solution for developing web applications, no matter how much Google optimizes their engine. The browser is a perfect distributing platform, but a lousy execution platform. I believe more in RIA technologies such as Flex, Silverlight and JavaFx.

Session 1: Of Code and Change: Beautiful Software by Michele Lanza
One word: Amazing! The first thing Michele showed us was a first generation visualization tool running in an Eclipse plug-in. It visualized code as a 2D graph where classes where represented by simple squares. Different metrics was used to control the width, height and colours of the squares. It was impressive what could be seen at a glance from such a relative simple figure. But the second thing Michele demonstrated was really fantastic. It’s a tool developed by one of his PhD student and it’s called CodeCity. It draws an entire software system as a full colour-coded 3D model of a city. Packages appear as districts and classes as buildings in the districts. It gives a whole new way of visualizing the overall architecture of system, spot areas ripe for refactoring, identify areas of frequent change or stale code, and much more. Take a look at .

Conclusion
For me, this day was all about Rich Internet Applications. I think Chrome is a good looking browser (I like the slick interface) but, as I said, I’m doubtful if JavaScript will continue to be the preferred language for web application in the face of the competition. Media codex’es aren’t build into the browsers but played through dedicated media players and plug-ins. I think we will see a similar trend for web application: They will use the browser as a distribution platform, but will run in dedicated ‘application players’ and/or ‘application player’ plug-ins. Whether these players will be build by Microsoft (Silverlight/.NET), Adobe (Air/Flex) or Sun Microsystems (JavaFX) I don’t know. Time will tell, I guess.

But first the opening talk and the keynote: It was looong. The initial speaker, for some reason, decided to walk us through the complete program for today. The keynote itself was held by Anders Hejlsberg and the subject was “Where Are Programming Languages Going?” It was very interesting but, unfortunately, also felt kind of protracted. He did at least three demos along the way (of LINQ and F#) and used a lot of time to convey a rather simple message: Future programming languages will blend traits from imperative, functional and parallel languages into one.

Session 1: End User Programming – Glenn Vanderburg
Excel, Lemmings and The Incredible machine as examples of successful user programming tools? Not something I would have considered on my own. But it made sense nevertheless. It was a bit of an eye opener, actually. All in all a very cool talk that nevertheless was a bit thick on the examples and a bit thin on the actual theorising and drawing of conclusions.

Session 2: Gant - Andrew Glover
This talk was part of a dedicated build track at JAOO. It almost made me sorry to miss the rest of the talk. The talk itself was about using Groovy as a DSL to replace Ant as a build tool. Gant has tight integration with Ant so it’s easy to call all the existing Ant tasks from within Gant. It also has integration with Ivy (an Ant version of Mavens dependency handling). It was very interesting. I could definitely see potential in replacing some monster Ant script with a DSL. But I was not quite convinced that Groovy was the best tool for the job – too much Java-like syntax left in Groovy to make it very elegant. Or perhaps a Java-like syntax would only be an advantage for building Java projects?

Lunch
Um, not the greatest variety ever. But nice with a break. I got to talk with a couple of interesting persons too.

Session 3: Aesthetic programming with Ruby by Sam Aaron
I admit I was late for this session. I missed the first 20 minutes. Perhaps that’s why I didn’t get what the h… the guy was talking about. I didn’t see much Ruby and about the only thing I did catch was that we programmers shouldn’t call code ‘code’ anymore because code equals secrecy and it should be all about communication instead. He ended up by suggesting that we build systems in three layers, as a bottom-up pyramid: A stable layer build in Java at the bottom, a dynamic layer build in Ruby in the middle and a business layer build using DSL’s at the top. But I wonder… how are we supposed to know which part of the system should go where? If we already know which part of the system will be stable forever and we know all the areas of potential change then it should be easy to build the system practically no matter which technology we use.

Session 4: Fortress by Guy L. Steele, Jr.
Fortress is a Sun sponsored open source project aimed at developing a next generation programming language for parallel computing on multi-core CPU’s. Basically, what Guy told us was that everything we know (about programming) is WRONG! Or control structures and even our data structures are inherently sequential and must be re-though for parallel computing. A rather depressing message! And still, also one that opened up new perspectives. I seriously doubt that Fortress will ever become a mainstream language but some of the techniques in Fortress will probably find their way to other languages given time. It was a very interesting and very insightful talk.

Session 5: Scala by Bill Venners
Another session, another new programming language. This was the last session of the day. Scala is a programming language that merges OO (Java-style) with functional programming. It seems like a very nice language that shares some characteristics with the leaner dynamical languages such as Ruby, but without giving up on statistical type checking. It also seems like a very nice and ‘safe’ way for a Java developer to experiment with functional programming techniques.

Conclusion
It was a very exciting and interesting day with some really good sessions. There’s not much Java in JAOO anymore it seems. The trends are all about DSL’s, functional programming and parallel computing. I don’t think a single speaker failed to mention those three today.

I’m looking forward to tomorrow.

1. does this class have just one responsibility?

• Description: If your class has more than one responsibility, then responsibilities can become coupled. If responsibilities are coupled, changes to one responsibility may affect the other responsibility. This can lead to fragile design, more complex UnitTests and your code may break in unexpected ways, especially if different clients depend on this class for different reasons or responsibilities. Also, the more responsibilities your class has, the harder it becomes to comprehend your class.
• Possible indications: Lots of import declarations, long classes, long methods, one client depends on this class for one reason and another client depends on this class for another reason.
• Possible solutions: Extract a class that has its own responsibility and delegate from the original class to the extracted class.
• What do you achieve: Simpler class design, testability and robustness improves.

2. is this method side-effects free?

• Description: If your method has side-effects, it does more than its intended purpose. For example it also changes the state by modifying a global or static variable. Or for example, it validates some data and updates the database as well. Methods with side effects make the behavior more difficult to predict, are more difficult to test and are harder to comprehend.
• Possible indications: long methods, it’s hard to write UnitTests for this method, arguments are assigned inside the method body, static or global variables are modified.
• Possible solutions: break method into smaller methods, find alternatives for argument assignments
• What do you achieve: Simpler methods, easier to create UnitTests, possible indications for different responsibilities, more readable code, robustness improves

3. is my code readable for someone unfamiliar with this code?

• Description: If your code is unreadable, it takes more time to understand your code. It is also harder to change your code and it can be risky to change your code, because you may not be sure if your change is correct. Most of your colleagues will probably become frustrated if your code is unreadable, and changing your code takes longer than neccesary.
• Possible indications: long methods, long classes, magical numbers (numbers you don’t know what they stand for), use of uncommon abbreviations, it doesn’t look nice
• Possible solutions: rename methods and variables to something that is understandable, declare variables as close to where they are first used as possible, make it look nice (consistent and correct spacing, indentiation, white lines, etc.), introduce constants for magical numbers, use consistent naming
• What do you achieve: simpler code that’s easy to understand, easy to change, and changing your code takes less time. Also your colleagues won’t be frustrated

These are 3 of the many important questions I ask myself when writing code. They help me evaluating the quality of my work, and thus assist me improving the code I’m working on when necessary. You will notice that when you ask yourself these kind of questions a lot, it becomes a second nature to think about important principles and guidelines.

Then I stumbled upon some blog posts about Netbeans 6.5 and their scripting support for python, php, ruby(rails),groovy(grails). This reminded me about how much better Ruby, Ruby on Rails and JavaFX support was in Netbeans compared to Eclipse. Sure Eclipse has plugins for these platforms, but Netbeans support is better.

Now I started wondering, would Netbeans be better suited for all these scripting languages ? I gave it a try with the Grails framework, since I was interested in having a look at Grails anyway.
The following screenshot shows the app I ended up with. I know nothing fancy, just a few simple entities (movie, director) but still it’s a result (be it very small )

After working with the new Netbeans editor I must say I’m impressed with how easy it was to create this Grails app, without any experience with Grails or Groovy. I can see why people like groovy and Grails, although for a real comparison with RoR I should give it a bigger test-drive some day.

The conclusion of this story is that I’m impressed with groovy and grails now that I finally took the time for some minimal hands on experience. And Netbeans seems like the default editor for scripting; I now have postive experiences with JavaFX , Ruby and Groovy with Netbeans (so I guess it also will be just fine for Php and Python etc.)

note: netbeans 6.5 seems pretty stable for a beta, but the resources usage seems a bit high

Some links:
Blogpost:Netbeans with groovy & python
Blogpost: Netbeans with php, python, scala
Blogpost: Netbeans with javascript
Blogpost:Netbeans and Grails
Article: introduction to groovy + grails

One possibility is to create Characterization Tests. Characterization Tests are tests that describe (characterize) the behavior of existing code. It’s important to realize that characterization tests therefore do not verify the correct behavior of your code, but only the existing behavior. So the purpose of Characterization Tests is to make sure that if you make a change, your change doesn’t affect the existing behavior of your application.

So basically when you create a Characterization Test, you observe the output for a certain input of a method, and then you write a test to assert this. For example, if you observe that the output of the method sum(2, 3) is 5, then a test can be created that asserts 5 is the output for the input 2, 3. When you make a change to the code, the result of your test should still be the same. Now the fun thing is, since Characterization Tests are based on existing code, you could generate some Characterization Tests from your existing code. JUnitFactory seems to be such a tool, but at this time the website seems to be down.

A best practice for writing Characterization Tests is only to write Characterization Tests for code that may be affected by your change. If methods are very long, have lots of side effects, and if the object or the method has lots of dependencies, then it may not be very easy to create a Characterization Test. Two factors that influence the testability of your code are:

• how easy is it to construct the Object Under Test
• how easy is it to execute the method to be tested in order to assert something

You can start writing Unit Tests now, even for existing code. And Characterization Tests really reduce the risk and make it safer to change existing code. Writing Tests also gives you more insight into existing code, and your tests will make your colleague developers happy for sure: they feel safer to make changes as well if you wrote a test.

To read more about Characterization Tests, see:

• Working Effectively With Legacy Code
• Working Effectively With Characterization Tests
• Working Effectively With Characterization Tests - Part 2
• Working Effectively With Characterization Tests - Part 3
• Fun With Automated Characterization Test Generation