What a great EclipseCon!

As anyone on this planet knows, last week was EclipseCon time. As always, it was a great experience. Seriously... How many conferences can one discuss, during lunch, the double-checked locking pattern or how EMF could support facets? (thanks Eike and Kenn)

All talks I've attended were awesome. It's reinvigorating to see all the energy and technology happening behind Eclipse: from known technologies to hot topics like E4 and XText.

And it gets better! The people at the conference are simply fantastic. Just to name a few, it was great to chat with Nick, Chris, and Boris and to finally meet in person Tom, Kevin, Peter, and Paul Webster. There are many others that, although not listed here, have contributed to make last week a memory that will not fade away from my mind.

A bit more personal, I like to think that the EMF tutorial was well received. We chose to go deeper into several subjects instead of mechanically read all the slides. Unfortunately, because of that, we didn't cover all the material. The offer to be available to answer individual questions after the conference is still valid ;-)

I got some positive reviews for the modeled UI in e4 talk, which definitely doesn't seem to agree with the official numbers. I wonder if we were too "slide driven" while the folks attending were expecting to see more action. Or perhaps my delusional-self is correct and people did mistake the '+1' for the '-1' bucket. Oh well... I am sure we'll do better the next time.

Finally, a special thanks to Steve: I was peacefully seated at the closing event when he handed me a winning deck for Thursday's poker game. My son loved the RC boat and will enjoy playing with it on summer time.

Another finally... The EMF book was the first one to be sold out at EclipseCon! I had the pleasure to autograph a few copies. On the subject, EMF and modeling in general are everywhere. It is good to see something I helped built making others more productive ;-)

EMF tips and tricks: Don't save if it hasn't changed.

For a while I have been thinking about writing some EMF tips that may not be known by most of the users. What keeps me from doing it is the lack of inspiration to come up with a nice introduction and to explain the rationale behind a design. This is probably silly though. I am sure I would be way more useful if I simply focus on showing the "what" and "how", leaving the long discussions for the cases when someone is actually interested ;-)

So here we go...

We've added a few new options to the EMF Resource in EMF 2.3 (the one available in Europa). One of them is Resource.OPTION_SAVE_ONLY_IF_CHANGED. When this option is used, the save method writes out the bytes of the serialized objects only if these bytes are different from the existing persisted form of the resource. Behind the scenes, the objects in the resource are serialized to either a temporary file or memory buffer and then compared with the bytes read from the URI pointed to by the resource. Clearly this slows down the save operation, but it may be useful when, for example, the resource serializes to a file that is versioned by CVS, hence avoiding "zero delta" changes.

This snippet shows how to use this option:

Map<Object, Object> saveOptions = new HashMap<Object, Object>();
saveOptions.put(
  Resource.OPTION_SAVE_ONLY_IF_CHANGED,
  Resource.OPTION_SAVE_ONLY_IF_CHANGED_MEMORY_BUFFER);
resource.save(saveOptions);

Using OPTION_SAVE_ONLY_IF_CHANGED_FILE_BUFFER instead of OPTION_SAVE_ONLY_IF_CHANGED_MEMORY_BUFFER would serialize the objects to a temporary file instead of using a buffer in memory. This subtle difference is important when dealing with big resources.

An experienced EMF user may be asking how this relates to the Resource.setTrackingModification(boolean) method and to the "dirty" state of the editor generated by EMF. The main difference here is that the new option applies to the actual bytes of the serialized resource while the other two approaches are related to the state of the objects in memory. For example, the new option doesn't change the serialized resource when a "dummy" modification is made to an object (such as setting an attribute to its current value), but would do it if the serialization format changes (which could be caused by using a different value for the XMLResource.OPTION_LINE_WIDTH option, for instance). The other two approaches do the exact opposite in these examples.

From iterator-loop to foreach-loop with one regex.

Probably the most important feature we've worked on this release was to add Java 5.0 support to EMF. We've learned a lot during the process and actually had some fun trying to make sense out of Generics and Annotations. Of course there were also some very annoying tasks, such as converting Java 1.4 "Iterator loops" into the new "foreach loop" style. For example, this snippet

for (Iterator i = Collections.singleton(new Integer(1)).iterator(); i.hasNext();)
{
  Integer integer = (Integer)i.next();
  System.out.println(integer);
}

should look like this after the modifications

for (Integer integer : Collections.singleton(new Integer(1)))
{
  System.out.println(integer);
}

Unfortunately Eclipse's "Source->Clean..." magic action doesn't do a good job here since it doesn't keep the names and types of the "each" variable. At least back in December, I would end up with Object object : instead of Integer integer : for the example above.

Either to boost my productivity or just to exercise the right to be lazy ;-), I've come up with a regular expression that does the conversion for me. It works flawless with Eclipse's Find dialog (ctrl+f):

Here's a clipboard friendly version:

Find:

(for\s*\(\s*)Iterator\s*\w*\s*=(.*)\.iterator\(\).*;\s*(\)\s*\{\s*)(.*)\s*=.*next\(\);\s*

Replace with:

$1$4:$2$3

I can't see the code I blog!

Today I was proudly showing my blog to Dave, a good friend from work. "Proudly" would be the perfect word if it also meant "embarrassed". While I consider myself an illiterate in multiple languages (after 7 years in Canada I haven't learned English yet and my Portuguese is starting to fade away), Dave is my "English hero". Not only he writes really well but also knows all the grammar rules that would explain "why one should use a comma here" for example. A typical case of knowing what to do and how to do it. Anyways, I am digressing...

When I was showing the blog to Dave, he pointed out that the chunks of code I wrote were not been properly displayed on his Windows box. After some digging, we found out that the culprit was the "fixed" font on my CSS. After changing it from

font-family: fixed, courier, courier new, times, times new, times new roman;

to

font-family: courier new, courier, fixed,  times, times new, times new roman;

everything worked just fine.

Perhaps I should show this to Nick, another good friend from work, from whom I've stolen... err... leveraged the CSS customizations.

What do I do with my passwords?

Have you noticed the incredible number of services, emails, accounts, logins and identities we have to manage on a daily basis? I am sure you already have a technique to handle your ids and passwords. The one I chose is... keep all my information in a text file.

Of course it is not that simple ;-)

I do have a text file with all my ids and passwords though. I write it in a very human legible format (== no xml). You would read something like this if you got your hands on it

www.pizzapizza.com
marcelop/mypass
marcelop@the.email.I.used.here.com

This file is stored on my server, where I make all the changes, and duplicated on the machines I use. Given the importance of the data (to me at least), I decided that it would be wise to encrypt it. Enters ccrypt. This package is available on both Linux and Windows (through Cygwin), and provides a command line application (ccrypt) to encrypt text files and another (ccdecrypt) to do the opposite operation. It also includes 'ccat' that displays the content of the file after decrypting it in memory.

So how do I put everything together? When I need to add a new entry to the file, I ssh to my server and run cad, defined this way:

alias cad='ccdecrypt ~/personal/ids.txt.cpt &&
          vi ~/personal/ids.txt &&
          ccrypt ~/personal/ids.txt'

This command (1) decrypts the file 'ids.txt.cpt', (2) opens the plain text file using vi, and, after I am done editing it, (3) encrypts the 'ids.txt' file.

After editing the ids file, I return to the machine I am working on (this has started with an ssh, remember?) and run the psync command defined by the following alias

alias psync='scp -p lh:/home/marcelop/personal/ids* ~/personal'

which copies the file located on my server (the alias stands for "personal sync" and actually copies other files that I only edit on the server). After that, whenever I want to check an specific information, I run this alias on the local machine

alias cad='ccat ~/personal/ids.txt.cpt | grep -i -B 2 -A 5 '

So something like cad pizza would display 2 lines above the "pizzapizza" entry and 5 below. Adding this to the .bashrc

export GREP_OPTIONS='--color=auto'

makes it even better, since the word "pizza" would appear in red.

There you are. Seems like a lot of work, but it is actually quite simple. After using this technique for 2 years, it feels absolutely natural.

PS: 'cad' stands for "cadeado" (locker in Portuguese).