Say you had an important fix on your develop branch that needed to merged to master, but you did not want to merge everything.  They way to get the change to master is a cherry-pick merge.  If you look at the commit in github:

One commint into git

All you need is the commit number there and you run the cherry pick command:


git checkout master
git cherry-pick 4a2108c414
[master 18faa81] update to 1.6.0
1 file changed, 4 insertions(+), 4 deletions(-)
git push origin master


If you don’t have administrative access to HipChat, it is difficult, but not impossible to determine your room identifer.  For some reason, the REST API to HipChat requires administrative privileges to view or list rooms.  The WUI and GUI for HipChat don’t seem to reveal the room identifier as near as I can tell.  You need this room identifier to give to Jenkins so it can post notifications.  The one place you can see this identifier is the last part of the URL to the Chat History.

I’ve been having all sorts of problems off and on with the Juniper Network VPN connection.  I don’t have the exact pattern of what causes the problem, but I think I’ve seen it both with the machine hangs and when I disconnect the VPN normally.  Also, keep in mind, I’m using the Mad Scientists JNC script.  Anyway, what I see when I use the web interface is the GUI comes up for a couple seconds and fails.  I don’t see anything conclusive in the logs other than a most likely harmless “ncui.error Got signal 17″ (a user signal).  When I run the jnc script, it claims the VPN is up, but no packets are sent or received.

The problem always boils down to a problem with the /etc/resolv.conf file.  It normally has stale information in it and I edit it and get some things working. What I think I really need to do is delete it and recreate a link to /run/resolvconf/resolv.conf.  This last time, I had to make an empty file there.  Once I had that file, I got get the VPN to start and work.

It may be related that the files /etc/jnpr-nc-hosts.bak and /etc/jnpr-nc-resolv.conf should (or perhaps should not) exist. Last time I was working on this, I recreated an empty /etc/jnpr-nc-resolv.conf file just before things started working. I had a copy of the hosts.bak lying around. I think the main problem is the Juniper scripts moves the symbolic link out of the way and creates a regular file. Next time you start up, the file is not updated and you get the stale resolv.conf file.

I also reverted the VPN changes to the hosts file, which didn’t make any difference. The thing that may be key is removing all the log files from ~/.juniper/network_connect directory.

I recently had to reload the operating system and managed to lose all my ssh keys.  After finding a copy around, I scratched my head for an hour wondering why they weren’t working.  The permissions were all right on the client and server.  It turns out I neglected to run the ssh-add command to add the keys to the authentication agent.

So, I’ve been running AdBlock Plus for a long time now and recently it stopped blocking some facebook ads. After being ad free for so long, this was kind of annoying. It turns out my ABP filter was out of date. I’m running Chrome on Ubuntu although I doubt the OS matters. I just clicked on the wrench in the top right corner and selected Tools/Extensions. On the extensions page, select “Options” under ABP. I think the key filter is Fan Boy’s filter. Anyway, there is a big “Update Now” button which I clicked and the ads are now gone.

I think this is mostly on intermediate versions of Excon, but exporting and setting EXCON_DEBUG on Excon 0.14.3 is completely useless.  The environment variable to set is EXCON_STANDARD_INSTRUMENTOR which can be set to anything other than 0 as I understand it.  It is a useful feature to see what Excon requests are being made.  It looks like future releases of Excon will use the EXCON_DEBUG environment variable which is a lot more intuitive name.

export EXCON_STANDARD_INSTRUMENTOR=1

Back in the day on various Unix distributions we used to use the timex command to get real, user and system time used when a command run.  On recent Linux distributions, the timex command has been replaced with the time command with the -p option.

terry@brat:~/hp/unix_cli$ time -p hpcloud snapshots >out 2>err
real 14.72
user 0.63
sys 0.04
terry@brat:~/hp/unix_cli$

The DRY principle or “Don’t repeat yourself” states that ”Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”   Great principle, but I have been known to take this too far.  Sometimes you need to balance your KISS with you DRY to keep it simple stupid.  Just repeat the code if it avoids unnecessary complexity.

The YAGNI or “You ain’t gonna need it” principle is one principle I have fully embraced.  The reasons for YAGNI are:

• The time spent is taken from adding, testing or improving necessary functionality.
• The new features must be debugged, documented, and supported.
• It may lead to code bloat.
• The requirement for the feature has not be clearly defined, so it may be incorrect.

The reluctance to remove dead code that you ain’t gonna need also mystifies me.  Normally, you are using a perfectly good source code control system and in the unlikely event you ever wanted to see a piece of dead code you removed, look at the history.

The SOLID principles of object oriented design are single responsibility principle, open/closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle.  I went over these a bunch of years back when I think it was Matt Ozvatt started a discussion on the topic.  At the time I was busy with work and life and probably didn’t give them the focus they deserved.  Today, I’d like to review.

The single responsibility principle is the notion that each object should have a single responsibility.  This sounds insanely simple and intuitive, but in practice it is not and part of the reason is evolution of the code.  For example, it may make sense to have a car object early in a project and that object does everything a car does.  As things progress and get more complex, there may be a time when you need an engine object, a transmission object, etc.  As long as you are open to constant refactoring, you will create these objects when needed.

The open/closed principle is the notion that software entities should be open for extension, but closed for modification.  The principle sounds simple enough, but in practice it doesn’t make too much sense to me.  The idea that I would ever be done with any class is hard to fathom.

The Liskov substitution principle states that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.  The interesting covariant argument example for this principle is say you have a Person class and Child is a subclass of Person.  Person has a see(Doctor) method and Pediatrician is a Doctor.  The see method does not enforce that the Child must see the Pediatrician.

Interface segregation principle status that many client specific interfaces are better than one general purpose interface.  Basically, this means once a interface becomes “fat” you should split it up.    Just about every project has some interface that because bloated and everyone is afraid to change.  The longer you wait, the worse it gets.

The dependency inversion principle is the notion that one should depend upon abstractions, not concretions.  The idea is that if higher level objects are not dependent on lower level objects, there may be more reuse.

The SOLID principles are in some ways academic discussions of how code should be rather than how it is most of the time.  Am I going to write a service locator to find a logging object or just deal with the fact that my class is dependent on log4j?  Chances are I’m going to just use log4j.