R.I.P. Nexus 7

Beginning of this month I received my Nexus 7 Tablet. I really like the form factor, the performance and how handsome this device feels in my hands. We had a great time.

Last Wednesday, without any further warning and totally surprising, the Nexus 7 died in my hands. I'm really sad about this loss, since I had no chance to properly say goodbye.

What happened? The screen started to show a lot of horizontal lines dancing from left to right and back. After a couple of seconds, the tablet shut itself down. There was no way to switch it on again. I tried everything. Finally I attached the tablet to my computer and it started to show signs of life again. I was so lucky. The battery charging symbol appeared and it seemed I was able to save the life of it. After some hours of continuous charging, it seemed that everything turned back to normal, but after some minutes using it, the same symptoms came back. This time, the tablet shutdown much more quickly. I was unable to switch it back on again. I declared the tablet dead at 3:21pm, Wednesday, 22nd of August 2012.

I called the undertaker (Google Support) how to proceed with this dead patient now. They offered me a replacement Nexus 7 tablet that will be send to me in the next couple of days (nothing can replace my beloved original Nexus 7 tablet).
Once arrived, I have to send the dead one back to them and they hopefully will give it the appropriate final treatment in it's short life.

Rest in peace.

New Job: ActionScript VM Performance Engineer

A couple of weeks ago I started to work for a new team within Adobe. The team: Performance Engineering for the ActionScript VM (AVM). What am I doing there? Build the infrastructure to track the performance data, analyze performance issues and develop performance workloads for the AVM.

For all reader not familiar with the AVM, it's the virtual machine that is used by the Flash Player to run Flash content. Wait, did I say Flash Player? Yes, the piece of well known software that so many people use and so many believe it's dead (or about to die). I can tell you, that at least from Adobes perspective, that the opposite is the truth (even if the perception out there might be different). Adobe is investing in ActionScript and Flash Player to make it the best language and execution environment for modern web enabled applications. There will be changes to the ActionScript language, which will improve the overall execution performance. The roadmap is available here.

One of the improvements already in place are Workers. Workers help the developer to execute code in a separate thread to create a smooth user experience. Think of some heavy computation that doesn't have to happen in the UI thread anymore. Have a look at the Worker example.


To better keep track of the upcoming performance improvements, this new team was build and I'm happy to be part of it. I'm going to work on a lot of different things over the next few months: automation, webapp/database development, analyzing performance issues, developing the relevant workloads to measure the performance, etc. This sounds exciting.
Riding a dead horse looks different.

Grape: adding a repo to the ivy configuration

Grape is a great thing. It’s one of my favorite features in groovy. It makes groovy script distribution so easy and painless. You want to use your groovy script on a new machine? Install groovy (if not already done) on the other machine and copy the script to the new machine. The script and all declared dependencies will be downloaded for you and the script is ready to run. What a timesaver.

@Grab(group='mycompany.com', module='awesome-lib', version='1.2')

This statement specifies a dependency to a library that your groovy script depends on. No need to copy this jar and all transitive dependencies manually to your machine. No need to make it manually available in the classpath. You know maven, gradle and ivy. They do the same job during build time. Grape provides the same dependency resolving functionality in the runtime scenario. No worries about missing dependencies anymore.

What happens if a required dependency is part of a not-so-famous or a company internal repository? Grape has a solution for it! You specify the repository with a Grape annotation and tell the dependency resolver to consult your company repository in order to resolve dependencies.

The following statement will add a repository named ‘my_unknown_repository’ and a root URL ‘http://repo.mycompany.com’ to the list of resolvers.

@GrabResolver(name='my_unknown_repository', root='http://repo.mycompany.com')

In case that you have a company internal repository (which also acts as a proxy to the outside world) and you always want to consult this repository without always remembering the GrabResolver annotation for every script you write, there is another way of specifying the repository. This option is less flexible, but it saves this one line in every script and probably makes more sense in a larger context like companies. To add your repository permanently to the resolver list, I recommend to obtain a copy of the configuration file that Grape uses to configure the underlying ivy to perform the heavy-lifting.

Grape uses a specific configuration that can be found in the groovy-x.y.z.jar. In order to customize the configuration, we need to create a grapeConfig.xml and add our repository there. But how does the content of the file look like? To preserve the existing configuration, we get a copy of the original config file from the groovy.jar.

Let’s jump to the command line (I assume that java’s jar is in the search path and /path/to/groovy exists):

jar -xf /path/to/groovy/lib/groovy-1.8.6.jar groovy/grape/defaultGrapeConfig.xml

This command extracts the defaultGrapeConfig.xml to the current directory. Open this file with your favorite editor and you will probably see something like this:

<ivysettings>
  <settings defaultResolver="downloadGrapes"/>
  <resolvers>
    <chain name="downloadGrapes">
      <filesystem name="cachedGrapes">
        <ivy pattern="${user.home}/.groovy/grapes/[organisation]/[module]/ivy-[revision].xml"/>
        <artifact pattern="${user.home}/.groovy/grapes/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
      </filesystem>
        <!-- todo add 'endorsed groovy extensions' resolver here -->
      <ibiblio name="codehaus" root="http://repository.codehaus.org/"   m2compatible="true"/>
      <ibiblio name="ibiblio" m2compatible="true"/>
      <ibiblio name="java.net2" root="http://download.java.net/maven/2/" m2compatible="true"/>
    </chain>
  </resolvers>
</ivysettings>

Now go ahead and copy one of the <ibiblio… /> lines and add your repository configuration. Finished with editing? Save the file as grapeConfig.xml in ~/.groovy/. From now on Grape will search your repository every time there is a dependency to resolve. If you want Grape to use only your repository, because it’s caching downloaded dependencies, you should remove all <ibiblio… /> lines, except the one for your repository.

Additional documentation about Grape can be found here.