Month: November 2013

My credo

I was recently asked to describe my development credo.  At first, the question seemed odd to me.  My “credo”?  When I asked for clarification, my interviewer said, “Yes, those core beliefs or concepts that you apply to every project despite the actual methodologies or technologies used.”    After some thought, I realized it wasn’t really a bad question after all.   As technologists, our environment and tools we choose to interact with that environment are constantly changing and evolving.  Yet, there are touchstones that we carry with us from project to project, formed from past experience that we use to gauge and ensure a project’s success.    So here are some of mine:

1. Think small.   Over the years I’ve seen far too many important and well-funded projects fail because the team was too focused on analyzing, documenting and designing every detail up front.  Wanting to make a big splash by delivering at scale, they thought too big.  In the end, they ended up just being all wet and after many months of work all they had to show for their efforts were a stack of diagrams and a long list of requirements.  Meanwhile, the landscape had changed and those core business needs that the development team had spent so many months analyzing were no longer relevant.  I take the opposite approach because I strongly believe it is better to get something small deployed quickly, know that it won’t be perfect, solicit feedback, be prepared to change everything, and then iterate, iterate, iterate.  It’s the only way to ensure that what you are building remains relevant and will meet the needs of your users.

2. Don’t fall in love.  I’ve seen projects fail simply because the client, architect, or development lead was a fanboy of some new technology that, although great for some things, was the wrong match for that project.  No matter how great you think an idea, a technology, a thousand lines of code is, you have to be emotionally detached enough to recognize that and throw it to the curb if it isn’t meeting your needs.  The hardest part of my job isn’t writing code, it is deleting it.  Don’t get smitten.

3. Be lazy.   When I was a junior-level developer I spent time working on projects where success was measure by how many lines of code were written per day.  Being young and lazy, I never scored very high on those metrics.   But the great thing about laziness is that it demands that you find shortcuts.  Why waste time writing thousands of lines of boilerplate code if you can more quickly automate the process and take a long lunch?  Today, I encourage this behavior in my developers because it is through these time-saving discoveries that the entire team becomes more productive.

4.  Steal.  I currently work for a large multiunit, multinational corporation.  The way it operates you’d think the various units were warring countries.  One unit in particular has adopted a “not invented here” attitude when it comes to new technology or even sharing code.   Their projects are always late and typically suffer from a lack of innovation.   Again, I take a different approach.  I know that my chances of being the first person who needed to solve my problem are pretty low and it’s likely that there is already a library, framework or snippet of code out there that will solve most of my problem for me.  I can’t afford to waste time reinventing, I’d rather be innovating.  So, I encourage my team to adapt and reuse whenever possible…but abide by the license.

5. Be inefficient.  I know developers who get a perverse satisfaction out of squeezing as much function into a single line of code as possible.  The problem with this approach is that it makes their code nearly impossible to read for anyone else.  Modern compilers are going to do a pretty efficient job optimizing your code so there isn’t a need to be so terse.  You should instead adopt a coding style that allows others on your team to quickly discern what you wrote.  If it takes 2 lines of code to make your intent crystal clearer, write two lines of code.  And comment.

6.  Say no.  The first project I was worked on after college was a disaster.  It was a year behind schedule with no end in sight because they adopted a waterfall methodology and their client and corporate management keep changing the requirements.  The leadership on the development team would not say NO to even the most inane requests.  It’s a simple word, two-letters, easy to pronounce yet it rarely comes out to the mouths of architects and project managers.  I think it is far more important, especially in the early stages of a project, to clearly define a very limited scope and then deliver that on time.   No one likes to fail and a small victory is still a victory.  Don’t commit to the impossible.  Say No.

Creating and installing a SSL certificate on Amazon EC2.

In my previous posts I showed you how to setup HTTPS on Amazon’s EC2/Elastic Beanstalk.  In those posts I used a self-signed certificate.  This is a fine approach for the early stages of development or prototypes, but if you’re launching a real site you have to buy a real certificate from one of the certifying agencies otherwise your users may be scared off by  warnings about accessing an untrusted site.   Getting a SSL certificate is a fairly easy process but not always cheap,  you can do a search on the web for “cheap ssl” to try to find the best deal for your needs.  I chose GoDaddy because I had a coupon from them.  It pays to shop around as prices vary dramatically.

The first step is to generate a private key and the Certificate Signing Request needed for the certifying agency.  You can do this with openssl.  If you’re on a Mac like I am, openssl is already installed.  If you’re on another platform, here are some instructions on how to install it.   Ready? Let’s get started:

  1. Open a terminal window and create a directory for your certificate files.  Create this in a safe location and name it appropriately so you don’t accidentally delete it later.
    $ mkdir my-ssl-certifications
    $ cd my-ssl-certifications
  2. Create the private key according to GoDaddy’s requirements (other providers may have different requirement so be sure to check first).   Enter the following command.  You’ll be asked for a pass phrase.  Be sure you remember it, you’ll need it later.
    $ openssl genrsa -des3 -out host.key 2048
    Generating RSA private key, 2048 bit long modulus
    e is 65537 (0x10001)
    Enter pass phrase for host.key:
    Verifying - Enter pass phrase for host.key:
  3. Now lets use the private key to create the certificate signing request (CSR).
    $ openssl req -new -key host.key -out host.csr
  4. You’ll be asked for your pass phrase again followed by several questions.  It is vital that you answer these correctly and accurately otherwise your certificate will not be valid.  In particular, be sure that the Organizational Unit Name, and the Common Name match the URL for your website.  You can leave the last two ‘extra’ questions unanswered.
    Enter pass phrase for host.key:
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    Country Name (2 letter code) [AU]:US
    State or Province Name (full name) [Some-State]:Missouri
    Locality Name (eg, city) []:Saint Louis
    Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
    Organizational Unit Name (eg, section) []
    Common Name (e.g. server FQDN or YOUR name) []
    Email Address []
    Please enter the following 'extra' attributes
    to be sent with your certificate request
    A challenge password []:
    An optional company name []:
  5. Now that you have the host.csr file, you have to submit it to the certifying agency.  For GoDaddy I had to first purchase a standard single-domain SSL certificate on their website.  Upon checkout a  ‘SSL Get Started’ link appeared.  I clicked on that and finally got to a form that asked for the CSR.
  6. Open the hosts.csr file using a text editor and then copy and paste the entire contents (including the delimiters) into the GoDaddy CSR request form.
    [encoded text here]
  7. Submit the form.  The agency will then verify the information.  The process and the length of time this may take will differ depending on the certifying agency.  GoDaddy was able to verify my domain instantly because I purchased my domain through them so they knew the domain and had my contact information.
  8. Once you receive notice that the certificates are ready, download them into the directory you created earlier.  For GoDaddy, I received a zip file containing 2 files:  a [server].crt  (a randomly named file ending in .crt) and a gd_bundle.crt file
  9. Now we need to modify and upload these certs to Amazon.  So log into the Amazon EC2 Management Console.
  10. Click on Load Balancers in the left hand column
  11. Click on the checkbox next to Load Balancer for your instance (it may be the only one).
  12. Click on the Listeners tab that appears at the bottom of the page
  13. Click on the Change link in SSL Certificate column for the HTTPS row.
  14. Click on Upload a new SSL Certificate button in the popup window that appears
  15. For the Certificate Name, enter any name you want to identify this certificate.
  16. For Private key you need to get the text for the original host.key you created.  Type the following command in your terminal window and copy the results from the terminal window into the Private Key field on Amazon.

    $ openssl rsa -in host.key -text
  17. For the public key you need to convert the [server].crt file that you received into PEM format. Type the following command in your local terminal window  (replace server.crt with the actual name of the server cert file you received) and copy the results into the Public Key Certificate field on Amazon.
    $ openssl x509 -inform PEM -in server.crt
  18. Finally you need the certificate chain certification. The Amazon form says this is ‘optional’.  It isn’t.  Type this command in your local terminal window and copy the results into the Certificate Chain field on Amazon.
    $ openssl x509 -inform PEM -in gd_bundle.crt;
  19. Click Save.
  20. Give the instance a minute or two to recognize the changes and reboot. If you now visit your site using https you should no longer get a warning about accessing an untrusted site.

Integrating Mongo and Node

If you’ve followed the last two posts you should have Node.js and Express as well as Mongo DB installed.  The next step is to install the Mongo driver in your application’s dependencies and start using the database within your app.

Let’s go!

    1. First install the Mongo db driver for Node.  The easiest way it to add it to your app’s dependencies.   Navigate to the myApp directory you created earlier and open the ‘package.json’ file in a text editor.  Add the following:
        "name": "myApp",
        "version": "0.0.1",
        "private": true,
        "scripts": {
          "start": "node app.js"
        "dependencies": {
          "express": "3.4.4",
          "jade": "*",
          "mongodb": "*"
    2. Save the file.
    3. Now rebuild the app dependencies.  Open a terminal window and navigate to your myApp directory.  Type the following:
      $npm install
    4. You may see some warnings.  I did, but they were only warnings.   If you are concerned you can review the build logs in the myApp/node_modules/mongodb/node_modules/<bson or kerberos>/builderror.log files.   Happy?  Ok, now let’s modify the app to connect to the database. Open app.js in a text editor and add the following:
      app.get('/mongo', function(req, res){
          var MongoClient = require('mongodb').MongoClient, 
            format = require('util').format;
            function (err, db) {
              if (err) {
                  throw err;
              } else {
                  console.log("successfully connected to the database");
    5. Save the file. Ensure your Mongo DB is up and running using mongod command. Then start the Node server by typing:
      $ node app
      Express server listening on port 3000
    6. Now open a browser and enter the test url: localhost:3000/mongo. The terminal console should read:
      successfully connected to the database
    7. If so, great! If not, boo. Go back and see what you missed.
    8. At this point the basic structure is in place to start building our database app. We’ll do that in a future post.

How to install and setup Mongo DB in a minute or less

In my previous post I showed you how to install Node.js and Express.  Now we’re going to install Mongo DB.   If you’re unfamiliar with Mongo, it is a schema-less, JSON-based database that is leading the whole noSQL movement and will soon overtake DB2 in terms of popularity (sorry IBM).

Ready to go?

    1. If you followed my previous post to setup Node then your environment should be good to go. If not, go back and make sure you have Brew installed and it is up to date.  Open a terminal and type:
      $ brew install mongodb
    2. That’s it. Well except for some configuration.  Let’s do those steps now.  First create a default directory for your databases.  You’ll need root access to do this, in the terminal type:
      $ sudo mkdir -p /data/db
    3. And change permissions on the new directory:
      $ sudo chown 'id -u' /data/db
    4. Now start Mongo.
      $ mongod
      all output going to: /usr/local/var/log/mongodb/mongo.log
    5. Done, done and done.