Frohe Weihnachten/Merry Christmas

Frohe Weihnachten/Merry Christmas

San Francisco City Hall 2012

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.

How do machines learn?

I already thought that I know the answer, until I met someone at a Party who told me about Machine Learning. That was the point when I realized that I only know a small fraction of this topic. Luckily, I found this free online class from Stanford University. The class runs for 10 weeks and I hope to learn the basics about Machine Learning, the tools and how to develop great algorithms for large datasets. The class started last Monday, so I already watched some of the videos and installed Octave. Now I need to learn how to use it.

git and why I sometimes feel lost

Yes, I had an affair with cvs, svn and Perforce the last couple of years! But most of the time I'm using Perforce, since this is used by my employer. Last year I started to look closer at git and mercurial. For some open source projects that I'm contributing to, I had to use git (Jenkins and homebrew) and mercurial (tamarin) to keep track of my changes. Having used Version Control Systems (VCS) for a long time, I thought that git and mercurial (hg) are just another new system that couldn't be too difficult to deal with. The start wasn't that bad: clone a repo, work locally, submitting changes locally without connection to the repository server is really a very productive feature.

How does it work if you meet somebody new and you try to build a relationship? You look for similarities and things that make it easier to find common ground. I my case I was still thinking: hey, they are all VCS's (Version Control Systems). That's true, they have a lot in common, but I also think they are more different than everybody thinks. I had to learn new concepts (which I always consider good) because of the centralized/decentralized nature of the different systems. The different terminology that all the systems use, is one of the issues that makes working not as smooth as I was used to it. Why? Every time I run into issues with branches, merges, resolving and I had to search for the "thing or situation" that described my situation best. But always in the language of the VCS that I was currently using. The longer I use the system, the better I should get to find the appropriate information quickly next time. I found numerous community driven site with tips and tricks and work flows for git and mercurial. There is the git and the mercurial handbook which will provide enough information to manage the most complex work- flows one can think of. But sometimes I'm looking for the simple tasks and how to manage them.

I'm getting better. I like git and hg. I don't love them yet, but we are working on our relationship. Even if they sometimes give me a hard time solving simple tasks, like this one: I wanted to delete a branch in one of my github repositories. As an example: in Perforce GUI tool I select the branch and delete it. Done. With git I had to do this in order to delete the branch:
git push git@github:ingorichter/homebrew.git :update-libzip
A push really deleted the branch. Perfect!? I hope I remember the command for the next time if I need to do it again.

Don't get me wrong: git and hg are very powerful, but it takes some time until your brain embraces the massive power of these VCS's. Until then, I assume that I will feel lost from time to time.

An IMHO very interesting podcast about VCS's can be found here.

Jenkins: OSX installer now supports the creation of it's own jenkins user

Okay, this doesn't sound like big thing, but there were some valid complaints from users that used jenkins to run their iOS and maven builds. Some of them had trouble with ssh. See https://ljnelson.posterous.com/getting-jenkins-running-on-a-mac and http://colonelpanic.net/2011/06/jenkins-on-mac-os-x-git-w-ssh-public-key.

Since jenkins version 1.449, the OSX installer provides an option to run the jenkins service no longer as daemon user. The installer is able to create a new jenkins user with it's own home directory (maven and ssh, here we come!). It should be easier to grant the jenkins user access to the keychain to allow codesigning of iOS deliverables.

Some facts about the new jenkins user:

• uid will be determined automatically to avoid any collisions with existing users
• guid of jenkins group is determined automatically to avoid collisions with existing groups
• home directory of the jenkins user will be /Users/Shared/Jenkins

Installer options

How to get rid of the jenkins installation?

I heard people talking about issues with the installer updating an existing installation (how can this be?). Some of them asked for way to get rid of the installed files. Since OSX doesn't have a mechanism to un-install files, there are only the options to remove the files manually or use some 3rd party tool (TrashMe) to get rid of the files. Since these tools use some heuristic methods to determine the files to remove, I created a simple shell script to remove all files installed by the installer. The script can be found here.
Warning: I used the script for testing purpose when experimenting with the installer. The are no error checks and it's far from being perfect. So, please use at your own risk!

red, red, red

Jenkins: Change Workspaces and Build Directory Locations

Have you ever wanted to change the location of the workspace directory of a Jenkins job? Not enough space on your hard drive or your hard drive is too slow? Whatever the reason might have been for your wish, there is a simple solution. Every job in Jenkins has a well “hidden”, I mean really not so obvious, setting to modify the Workspace root location of the job. To change this location, you need to configure your job and click on the Advanced… button in the “Advanced Project Options” section.

Advanced Project Options

Once you opened the settings, you will find some more configuration options for your job. Look for the “Use custom workspace” option on the right hand side and check the box.

Specify custom workspace for job

Here is some information that you should consider reading, prior to change the workspace.

Information about custom workspace

Important: The next build will use the new location, but you have to manually relocate all the existing content from the previous location.

Globally Changing the workspace location for all Jobs

In order of changing the workspace for a single job, there is another option in the Jenkins system settings that allows for changing the workspace for every job.
Navigate to Jenkins->Manage Jenkins->Configure System and click on the Advanced Button on the right hand side.

Specify custom workspace and builds directory location

Voilà! This opens up the following options section

Custom workspace and builds directory location

 
Now you can change your workspace and build directory to any other location on your machine. Jenkins provides 3 predefined variables that can be used to specify the new location:

• ${JENKINS_HOME} — Jenkins home directory
• ${ITEM_ROOTDIR} — Root directory of a job for which the workspace is allocated
• ${ITEM_FULLNAME} — ‘/’-separated job name, like “foo/bar”

The default value for the “Workspace Root Directory” is ${ITEM_ROOTDIR}/workspace and for the “Build Record Root Directory” it’s ${ITEM_ROOTDIR}/builds.

Some Notes

Please be aware, that if you change your workspace to a different location, the contents of the “old” workspace directory are not copied over to the new workspace.
Doing this on OSX could require to change the owner of the newly created workspace. So, if you encounter permission issues during your next build, then have a look at the new location.

my neck hurts

From Fun

Upcoming Jenkins OSX installer changes

I was too busy with other things that prevented me from working on the Jenkins OSX installer recently. Since there are some reported issues with the installer, I'm going to address them in the next couple of days. First of all I'm going to provide a solution for the "data loss" situation that happened several times. This "data loss" situation I'm referring to, is the deletion of a modified jenkins preference file. It's never funny to loose data, even if it's preference data and there were changes specific to your machine.
The other issue is to move from a daemon user for the jenkins execution to a 'real' user. The issue with the daemon user is best described here. I already started to work on this feature and I'm currently testing the feature. Currently I don't have a good solution for migrating from daemon to real jenkins user. This is something I have to find a solution for.

Kohsuke Kawaguchi provided some good documentation for the usage of the Jenkins OSX installer. The document helps to find the available configuration settings, how to display and modify the configuration settings and how to start/stop the jenkins process manually.

So, stay tuned for the upcoming, live easing changes.
Thanks