Product passion is a result of product focus. You don’t have to be Musk or SpaceX to have crazy passion for your product, you just need the culture and mindset from top to bottom.
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.
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.
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:
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:
If the ‘default’ machine start without any problem then you are good to go!
Now check if all your images are still available using:
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
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…ASSISTS! I 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!
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!
Don’t be mislead by the title of this post, this is probably the most important video on Agile you have to watch, by Dave Thomas, one of the authors of the Agile Manifesto.
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.