Sunday, November 1, 2015

I've been doing this for 20 years!

Ha!  And to think that I'm now old enough to say that about a few things.  In times past (not recently for anyone that I know who may be reading this), I've had occasion where men with pride assured me something wouldn't work because it wasn't something they did in an area where they had 20 years of experience.

The first time I encountered this in my life was in 2005.  At the time I was working as a framer.  I didn't have a lot of experience and was still considered green.  My foreman at the time was a great teacher and would often pull me aside from my tasks to show me parts of the house that he never understood.  For instance, how to get the exact angles on fascia board on the corners of a hip roof where the rafter ends are cut at 90 degrees.

The main reason I consider him to be a great teacher: he openly shared with me gaps in his knowledge in the hopes that I would fill them in.  Fill them in I did to the best I could.  I would spend my evenings with geometry books, construction paper, sometimes I would even go to Home Depot, purchase lumber and figure out the problems he'd shown me on job sites earlier that day in my back yard at night.  I did build a small roof once or twice to accomplish this :)

To get back to the issue at hand, there was one experience involving conical roofs.  My foreman and lead man had been working together for 14 years building custom homes.  Many custom homes have conical shaped roofs.  They always assumed the best way to cut the plywood was to use triangular pieces.  After thinking about the problem for weeks, I finally read in the dictionary the definition of a cone, and it had a picture that basically showed me the answer: measure from the peak of your conical roof down to it's bottom and you'll have the radius to cut your plywood!

The answer was so simple.  So simple it caused an argument during our lunch break.  "Joe," said my foreman, " there is no way that is going to work.  How can that be?"  Years of doing something a certain way had forged in the minds of these men that there was only one way to do it.  I cut a circle out of some construction paper and brought it with me that day.  I slit the circle along it's radius, and used it to show them.  As I slid one side of the circle over the other, a cone formed.  The house we were working on had 2 conical sections on the roof.  I begged my foreman to let me give the one in the back a go.  He let me!  My lead man took the one up front.

Not only was my hypothesis correct, but the result was an even stronger more structurally sound roof than the one built by my lead man!  I also knocked it out in half the time.

Before my lead man started on his portion of the roof, I overheard my foreman say to him "Why don't you try doing it the way Joe did?  Did you see how little waste there was and how quickly he completed it?"  I'll never forget the response "I'm good.  I've got this the way I've been doing it."

Why do we allow the way we've done things in the past to determine our outlook on the way they should be done in the future?  I speak of a time when others were guilty of this, but I know I've been equally so.  I believe some of the contributing factors are these:
  • We naturally want to be successful.  If we've been successful in the past doing something a certain way, reason states that we'll continue being successful at doing it the same way we have in the past.
  • I believe sometimes we become content and would rather not bother with something new when our current results satisfy us, even though the potential satisfaction from doing something a different way could be far greater than what we currently experience.
  • Fear.  It's natural for us to fear failure or wasting our time.
All of this is of course my current way of thinking about the matter.  In 20 years I'm surely going to have different thoughts about it.  Perhaps I'll use my time to write another blog about it then :P

Tuesday, October 27, 2015

How to: NPM in the Enterprise with Nexus

Using NPM in the enterprise without a private registry is a non starter for scaling reusable logic across teams.  Node modules shine at their ability to be small and shareable.

A google search for "private npm" will yield the following solutions:

  • Pay for private modules through npm.
  • Use hosted git repositories.
  • Mirror the public registry with couch db.

A co-worker of mine recently turned me on to an alternative that hasn't hit the main stream yet and I thought I'd share how to set it up.  What is the solution?  Use sonatype nexus!

  • Easy and fast setup
  • Private npm registry with public registry proxying
  • Minimal setup and maintenance for developers
  • Finer access control
  • Hosted solution for PCI sensitive applications.

Pre requisites

Java JRE available on your $PATH.

Setting up nexus

  1. Visit the nexus oss download page.
  2. Download the appropriate archive (.tgz or .zip).
  3. Unpack the archive and cd into the unpacked directory.
  4. Execute the nexus script in the bin directory ./bin/nexus start
  5. View http://localhost:8081/nexus in your browser.
  6. Login as the administrator using admin/admin123.
  7. Create a new(you should obviously change this).
At this point you should have nexus up and running with administrative access.  I will not cover everything involved in administering the server.  For that you should read the nexus book.  This is the free version.  You'll want to get a license for your organization, but this will do for example purposes.

Configuring nexus for enterprise npm

Now that we have nexus setup, we need to configure it to support a scalable npm workflow that consists of:

  1. npm install pulling down both private and public npm modules. With this setup, private modules will take precedence over public modules so be careful! If you have dependencies that depend on a module that you've overridden in your private repository, then it will receive your private module and not the one it depends on.
  2. npm publish publishing to the private repository that we'll configure in nexus.

Setup a proxy repository in nexus

Follow the steps here.  For our purposes, create a repository named "npm-public".  Choose the proxy repository option as this will proxy requests to the public registry.  The configuration should look like this:

Setup a private repository in nexus

Now create a hosted repository with the name "npm-private":

The configuration should look like this:

Setup a combined npm repository group in nexus

The configuration should look like this:

Configuring npm locally

With the repositories created in nexus, it's time to configure npm to pull from the combined repository group, and to publish to the private repository.  Every developer will have to follow these steps.

Pulling from the combined repository group

To configure npm to pull from our combined repository group, add the following line in your ~/.npmrc file:

registry = http://localhost:8081/nexus/content/groups/npm-all
Obviously in an enterprise organization you'll have a slightly different URL.

Now when you run npm install, npm will download private modules from nexus before pulling modules from the public registry.

Publishing to the private repository

To configure npm to publish to the private repository you created, you'll need to store your auth credentials in ~/.npmrc, as well as add a publishConfig section in each project's package.json file that you intend to be private within your organization.

  1. Run echo -n 'admin:admin123' | openssl base64. This will output a base 64 encoded password.  You'll want to substitute the user:password with your login credentials once you've moved past this tutorial.
  2. Next, add the following entries in your ~/.npmrc:
    _auth = YWRtaW46YWRtaW4xMjM=
    email =
  3. Finally in each project you intend to be private add this to it's package.json:
      "publishConfig": {
        "registry": "http://localhost:8081/nexus/content/repositories/npm-private/"

That's it!

You now have a working example of how to setup nexus for proxying the public npm registry as well as  hosting your private npm modules.

Sunday, August 30, 2015

Opinion Paralysis

Disclaimer:  I've tended to be an extremely opinionated person in the past.  Opinionated has many connotations.  I use it here harshly as I'm somewhat hard on myself when trying to change.  This post is a work in progress, much like my efforts towards eliminating opinion paralysis in my life.

Edit 8/30/2015

Why blog about this?

Because I got a taste of my own medicine at the start of this year.  I was on a project with roughly 15 devs.  It was our first of 6 sprints where we killed it.  Absolutely killed it.  We accepted something like 245 points.  We were rocking!...  key word is were.

Then mister right came in.  Everything was wrong after that.  Open floor became his soap box, everything was on the table for discussion.  Everything!  Right down to the last semi-colon (angular/javascript project mind you).

So what happened?  Next sprint we only accepted something like 140 points.  In his attempts to completely change the way we were doing everything, he sent us back from the performing stage, to the storming stage.  Teams are never productive in this stage, hence the name.

This dev eventually left the company because we as a team didn't agree with everything he was preaching.  He couldn't handle it.  This project wasn't going to be his baby, and we weren't prepared to have another one.

Definitions (from

  • Opinion: a personal view, attitude, or appraisal.
  • Paralysis: inability to act or function in a person, organization, or place.

Why did this happen?

It's impossible to know for sure.  Some would say management hired the wrong guy.  Others would suggest that the developer didn't have a lot of team experience and was used to working by himself.  Oh he was a brilliant dev though; when he actually focused on getting work done.

The characteristics are usually the same:

  • Lack of team experience, especially on large teams
  • Unwillingness to change
  • Personal attachment to semi-colons and comment syntax (I'll call this passion, but in it's worst sense)
  • Lack of consideration
  • Immaturity
I'd like to dwell on that last characteristic for just a moment.


If you're a passionate developer, you'll realize at some point that there's more to life than code.  I ended up leaving the last project after being on it a year for just such a reason.

I had been spending most of my time at night (prior to this project) ignoring my family, locked up in my room, stargazing at the latest open source repository I was creating.  I believe this did many good things for my career, and helped me learn at a more rapid rate than many others around me; however, it also helped me be self-centered.  

Many events transpired on this project regarding opinions that I was able to see the folly in long drawn out debates around how to write code: nothing gets done.

Does that mean the way something is done means nothing?

Not at all.  It's merely an observation.  When developers meet and they attempt to write standards based off of their personal preferences they risk a lot:

  • Wasted company resources (time is money, developers are paid money for their time)
  • Customer satisfaction (arguing devs are unproductive devs which means defects and features remain unimplemented) 
How then are we to avoid opinion paralysis?

Simple.  Make it a point to forget about what your preferences are, and go with the most authoritative, popular opinion on the subject.  If you're looking for a style guide, google "Style Guide" and pick from the top 3 results.  If you're running for office, uphold the constitution.  If you're serving in a volunteer organization, follow it's policies, handbooks, and instructions.  Opinions are like the wind, everyone has them and they usually mean nothing when they're gone.

What about exceptions?

They exist.  Where it isn't a matter of morality or good and evil, just pick what is most in line with what you've already agreed on in your team.  If that isn't helping, then set the example by asking for a coin toss.  At that point, it likely doesn't matter very much.

Friday, August 28, 2015

Replacing a Rear Main Seal on a 1994 Volvo 940 Turbo Wagon

This is one of those projects I hope I don't have to do for a while.  I bought this volvo recently with the understanding that the rear main seal was leaking (it was advertised as such).  I googled many posts, and found some good information.  Here are some items I found to be missing from other posts.

Time Commitment
I spent roughly 14 hours on this project, spread out over the course of a week.  Couple hours here, couple hours there.  Tried not to rush anything.  This is definitely one of those jobs you do not want to re-do, so take your time.

Supporting the rear of the engine

Engine mounts on the B230 are closer to the front of the block.  The rear of the block is mostly supported by the Transmission Bell Housing.  The transmission comes off when replacing the rear main seal leaving the rear of the engine completely unsupported.  Not having my engine hoist at my house (it's at my dad's 1.5 hour drive), I decided to try this this:

Luckily I had some 2x4 blocks and some 2x3.  Used a strap in the middle and looped it through the rear engine hoist attachment.  This setup held the weight of the rear of the engine and the transmission just fine.  I was also able to slightly maneuver the engine by adjusting the strap which was nice.  I felt safe underneath this thing for 14 hours!

Removing the transmission

For this I used my Big Red (by Torin) Floor Jack with a strap and some plywood to prevent the transmission from falling off the Jack and to prevent the drain pain from getting dented.  I lowered the torque converter, tranny, and crossmember together as a single unit and had it off for several days on the jack.  I used some twine to hold the torque converter straight with the drive shaft so as to prevent the drive shaft seal from leaking.  Fixing the rear main seal only to have the drive shaft seal leak afterwards would suck!  Fortunately that didn't happen though ;)

Removing the driveplate

The drive plate is held on by 8 bolts.  Removing them wasn't too bad, but I knew re-installing them would be, so I sprayed the drive plate with WD-40, held a piece of metal behind it and sprayed the metal with black paint to create a toothed drive plate holder.  Here it is in action (worked great!):

Removing the old Rear Main Seal

I was able to carefully tap a screw into the center of the seal, and use a pry bar to pull it out.  I think next time I'll try just a flat head screwdriver to pry it out (no screw) as outlined in the Bentley Service Manual.

Installing the Rear Main Seal

I took a couple pieces of PVC pipe, and used some garden hose clamps to make the inner diameter the outer diameter of the crankshaft drive plate flange.  It worked out great.  Using a slightly larger end cap allowed me to tap on it with a rubber mallet.  You want to tap evenly and slowly.  It is important that the seal ends up in as perpendicular a position as possible.  Also, lube both sides of the Seal and the mating surfaces liberally with Assembly Lube (I used Lucas brand from Autozone).


After Installing the new Seal, installation was the reverse of the removal!  I've been driving the car for a week now with no leaks.

Fingers Crossed.

Thursday, August 27, 2015

Playing Basketball in the Stairwell

Ever get tired of dead space in your stair well?  I sure do.  Well I used to.  One day I decided to build this.  Where I once used to gaze and wonder, I know practice my jump shot!

How to avoid Hypocrisy

Disclaimer:  In no way am I completely free of hypocrisy, but I desire to be.  I also can't say that I've mastered any of this, or that I fully practice it.  Stating your beliefs publicly encourages one to live them more. This post is mainly to document my ideals around being less hypocritical as time moves on.

EDIT 8/27/2015

  • Make it a game to see how many times a week you can catch yourself doing something you would consider to be stupid.
  • Try to view yourself the way other people would.
  • Do not take yourself too seriously.
  • Join in with others when they make fun of you to keep spirits high!
  • Realize that every time you're annoyed at someone for whatever reason, you've done the exact same thing!

Sunday, April 19, 2015

PageObjects done right in node.js

Yesterday I blogged about how widgets written as mixins with default methods in Java make PageObjects easier to maintain.  Now I'd like to show how the same technique can be used in javascript with node.js.

We'll start with the widget. Here we're making some assumptions about the context of this. In order for this to work, PageObjects that mix in this widget will have to use .call(this) inside their constructors.

Let's see what this looks like now in a page:

Here's a common page that all our page objects will extend:

And here's what our tests look like:

Once again, treating widgets as mixins has made our PageObjects easier to maintain and our tests are far more succinct. What I like about the javascript approach is that the CSS selector in the SearchWidget is private. It would be nice if Java 8 interfaces allowed for private constants, now that default methods are possible, but it doesn't. I see this as a slight disadvantage, but not big enough to warrant a complete ship evacuation for.

The downside of the javascript approach though with our custom DSL, is that we're typically dealing with promises in most async libraries. return this works really well for a synchronous webdriver library like webdriver-sync; however, with a library like protractor or selenium-webdriver where promises are in play, our exapmles would likely get a lot busier real quick due to the fact that you can't return this in a promise world :P