General, Subversion, Technology, Version Control Systems

Subversion Revert with Externals

Disclaimer: I know Git rocks, but people still use Subversion 🙂 !

Let’s say you have a Subversion checkout containing externals. Now you’ve made changes in many places within the folder structure and you want to get back to the original clean state.

So your typical approach would be to go to the top directory of the working copy and do a recursive revert using:

svn revert -R .

But unfortunately nothing happens! The reason is that the working copy is made up of sub folders containing externals and in order to revert them you need to go into each sub directory and then issue the svn revert command. This can be cumbersome if you have a working copy containing many subfolders corresponding to externals.

Well the solution is pretty simple if you have a bash shell (Windows users will require Cygwin or something similar)

for d in ./*/ ; do (cd "$d" && svn revert -R .); done

This little bash script will change (cd) into all sub folders using a loop and execute an svn revert within each ‘external’ folder recursively.

The solution was inspired by this thread on StackExchange.

Cloud, DevOps, General, Technology

How To Move your large VirtualBox VM disk created by Docker

So you’ve been using Docker Tool Box (DTB) on Windows and the ‘default’ docker host created by docker-machine is growing alarmingly large on your limited C: drive.

The super large disk.vmdk file for the “default” VM created by DTB is usually located at C:\Users\[username]\.docker\machine\machines\default

Now you want to move the existing disk.vmdk file to your much larger D: drive without having to recreate a docker machine/host from scratch and pulling all images on to it again.

The important thing to note here is that the vmdisk is an implementation detail of VirtualBox (VBox) not Docker. docker-machine just uses VBox as a provider to create a Docker host.

Therefore if you need to move the VM disk file to another location you should change VBox configuration for the VM instead of changing any Docker machine configurations (or using any docker commands)

So here  are the steps you need to follow.

1. Stop the running docker machine (i.e. VBox VM) like so:

                   docker-machine stop  

Note: This will effectively power off the VBox VM, named ‘default’. You can check this by opening the VBox GUI.


2. Copy the disk.vmdk file from C:\Users\[username]\.docker\machine\machines\default to a suitable folder in your bigger D: drive. I created D:\docker-machines\default for this.

Now the interesting part 🙂 We need to tell VBox about the new location of the disk.vmdk file.

3. The default.vbox file located at C:\Users\[username]\.docker\machine\machines\default\default  specifies the path to the vmdk file. This vbox file is an XML file, so just open it up in any editor and set the Machine/MediaRegistry/HardDisks/HardDisk/location attribute to the new location on your D: drive.


Note: Don’t worry about the “DO NOT EDIT THIS FILE..” statement on top since you have already stopped the VM, the file will not be overwritten. And I found this method easier than using the GUI 🙂

4. Now power up the docker machine using:

                docker-machine start

If the ‘default’ machine start without any problem then you are good to go!

Now check if all your images are still available using:

docker images

5.  You can verify that the vmdk file on D: is being used by firing up VBox and selecting the “default” VM and clicking on Settings/Storage/disk.vmdk as shown below.


6. Now you are done! Just go ahead and delete the huge disk.vmdk from your C: drive located at  C:\Users\[username]\.docker\machine\machines\default


Tip from Basketball for Software Firms

Many times a software developer’s performance is judged purely on the number of “tasks” that he or she has completed. This can be the number of bug fixes or user stories completed during a given period of time. This would typically co-relate to the amount of code contributed to the product by an engineer during this period. Now this can be an important performance metric no doubt.

But in my mind software firms need to pay more attention to another important  non-tangible metric when evaluating a developer’s performance…ASSISTSI got this idea when watching some highlights of this year’s NBA finals. In basketball, an assist is when a player makes a pass to a teammate that directly results in a goal and points for the team. The number of assists a player makes in basketball is considered an important stat in terms of his performance.

Similarly in software teams, some developers may contribute in many “non-tangible” ways to assist other developers in the team. These can be in the form of architecture/design tips, suggestions for new product features, code improvements or even pointing developers to look at similar implementations in other areas of the same product.

Contributing to the team in such ways is a key trait of a good software engineer and software firms should have mechanisms in place to “quantify” (at least to some degree) such “assists” made by team members. Project/Product managers and even architects can play a key role in helping software firms identify the amount of assists that a developer has contributed during a given period when evaluating her performance. This is by no means an exact science but a “ball park” rating can be very useful.

Software engineers should also realize that their value proposition is not just about writing code but also contributing to the team goal in other non-tangible ways as well.

Look at Steph Curry for example he is not only a huge points scorer but also brilliant in assists, that’s why he is MVP!


Warning: Bootstrap classpath not set in conjunction…

Java or JDKs in particular provide a way of writing your applications to work with older JVMs.

For example you can be using JDK8 for development but you also want to make sure that your code runs in an older Java 7 based JVM. This is done using the “-target” and “-source” switches sent to the Java compiler javac.

So if you want to compile your app using JDK8  but also want to ensure that it works in Java7 you would do something like this.

javac -target 1.7 -source 1.7

Now this will make sure that your application source is not using any Java8 specific language features. For example if your code had used Lambda Expressions the compilation will fail now since they were introduced in Java 8 and are not available in Java 7.

But the problem is although the compiler can check for language features it does not (and most likely cannot) check for the usage of newer API classes introduced in the new Java platform.

So in our example here, if the application code tries to use the new JDK8 specific Date Time API classes, compilation will not fail even though you sent in “target 1.7” and “source 1.7” to the compiler!

And this is why the Java compiler warns you and suggests to set the “bootstrap classpath” to the older JDK specified in your “target” and “source” switches. This ensures that you will not use classes introduced in the the newer JDK.

javac -Xbootclasspath:/path/to/jdk7/rt.jar -target 1.7 -source 1.7

Now if your application code tries to use classes that were introduced in the newer JDK compilation will fail!

Management, Mobile, Uncategorized

Mobile is to Desktops what Startups is to Enterprise

Something that caught my attention when trying to understand good Mobile UX was that many of it’s patterns can be applied to larger devices i.e. Desktops as well.

In other words if you start with a Mobile first UX approach you tend to remove the clutter and come up with a more “lean” UX that can be used on desktops as well.

But interestingly (or strangely) I see a similar relationship between how Startups are managed compared to larger enterprises.

Startups are managed in a very lean, less bureaucratic manner with a bias toward action. I think smaller organizational units (e.g. software project teams) within a large enterprise can also take a leaf out of the startup playbook.  This is similar to how Mobile forces a leaner UX design by removing “unnecessary” clutter.

Folks in the enterprise environment may call this Agile but I think having a “Startup mentality” at a large organization is going even more further by shedding as much clutter as possible and getting stuff done.

I guess SAP has already recognized this with it’s AppHaus concept.

Design Patterns, Java, Maven, Uncategorized

Missing ServiceProviders after Shading

Shading is a technique used in Maven to create a single”Uber” jar by merging the contents of  your app jar and all of it’s dependent jars. This makes it easier when distributing your application since there is only one big jar to deal with.

The Java Service Provider pattern is a cool way of building loosely coupled extensible applications.

When building a jar containing such implementations a text file per interface should be created listing all of it’s implementations and placed in META-INF/services. This is used by the JVM when the application needs to load (using ServiceLoader class) implementations of a particular interface without explicitly knowing about them.

The problem is when shading multiple jars containing service providers Maven does not merge the contents of META-INF/services by default.

The solution is to use the transformer ServicesResourceTransformer to tell the Shading plugin to merge the contents of META-INF/services in every jar it shades.

This can be specified in the pom.xml as shown below.

<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>