SSL Certificates

That little lock icon in your browser url bar is actually quite complicated.


SSL stands for secure sockets layer. The point of SSL is to prevent the tampering of data. Without SSL, everything is sent and received as plain text. If you are familiar with networking and specifically wireless networking, you know that the wireless data coming and going from a router (say in a coffee shop) is broadcast as far as the wireless signal can go, and if someone is sitting in their car with a repeater (signal extender), it can go further.

SSL is also for identification. If you go to, how do you know that you are actually seeing the website that google is hosting and not someone’s mockup of google. To go back to the coffeeshop scenario, if we did not have SSL, a patron in the coffeeshop could hack the router and tell all traffic bound for be redirect to his own fake website where he or she could do nefarious activities.

SSL = Identification and encryption.

Certificate Authorities

Every browser, when it comes across an SSL certificate, checks known certificate authorities (the people that can issue certificates) to ensure that the certificate is valid. Browsers these days come with internal lists of these authorities, so they can avoid round trips across the internet to verify the most common certificates.

Three types of certificates.

  • Self-Signed certificate – You or anyone can always sign your own certificates. However, since you did the signing, it means that no one else will trust your certificates (nor should they). Best for internal / your personal use.
  • Domain only validation – The cheapest and also less secure, since there are minimum checks. Great for encryption, not great for identity validation.
  • Organization only validation – More information about your company is verified by the issuer.
  • Extended validation – Take longer to issue, but most vetted certificates.

Now there are also;

  • Single site certificates –  I.e. has a certificate, but would also need its own certificate.
  • Wildcard certificates – I.e. and  would fall under a * wildcard certificate, but would not…
  • Subject Alternative Names (SAN) certificates – You can also take a single site certificate and (based on your provider) add additional subdomains to your certificate.

At the end of the day, if you own a domain, your certificate will be unique among all other certificates on the internet. Every https:// website has purchased ($$$) their own certificate which was originally issued by a certificate authority.

Browser and Server

When you browse a website with https, your browser and the server agree on an encryption level. By default, they choose the strongest encryption that is supported by both. With that being said, encryptions are always a moving target and a good reason to upgrade your browser (and server for ops) is to make sure you are able to use the best encryption available to secure your session.

The browser and server encrypt and decrypt messages back and forth using public and private keys. The key (pun unintended) is if you are running a server, you need to properly secure your private server key, because if someone gets a hold of that, they can setup their own server, which will be verified via SSL as being valid. All other certificates on your server are public and necessary for the user’s browser to know how to “talk” with your server in a secure manner.

“You get what you pay for.”

This saying holds true even for SSL certificates. If you buy a cheaper or free cert, it will be less trusted by browsers across the world. If you aren’t spending over $100/yr, you might want to make sure that your cert will work for people say in Australia at an enterprise.

Do research and try to get as close to a root certificate provider as you can. GeoTrust, Verisign, etc.

There is more to know…

The above is merely scratching the service.  We didn’t even his CSR, TLS, the NSA, Ciphers, etc. Certificates knowledge is far and wide. The best thing to do is go to a website with https and click on that little lock icon. Look at the certificate and see who issued their certificate and research prices and service levels. Most issuers have pretty decent service and will turn around questions promptly if you ask. After all, when you consider each website is paying $100 – $2,000 a year, it is a decent business for them.


Multi-tenant database angles

There are a few different ways you can go about supporting multi-tenancy within an application in regard to the database.

1. Add a column

The add a column approach simply means throwing another field on to your schema that is indexed. That is, every table has a ‘tenant’ field that is a string value that is required and is auto-attached to every save, find, delete query.

The benefits of this approach is that you can use one database for all of your tenants.

The downsides become attempting to scale beyond the one database and also a bit of annoyance with having an extra index on every table. And the other, it “feels” dangerous to have one tenant’s data sitting one row over from another tenant’s data.

2. Prefix table names

In the second approach, we can achieve multi-tenant separate by prefixing table names with the tenant name. I have not personally done this approach, but I know it is quite popular. The reason it is popular is that you get clean data separate (no row-by-row), no added indices, and still one database.

The downsides of this approach are more operations level. If you aren’t using a tool which filters table names, you could potentially have thousands of tables in one database when going to query something. That is quite daunting, of course, perhaps you don’t use a GUI, then maybe it isn’t so bad.

3. Separate databases

This approach creates a separate database for each tenant.


The benefits complete autonomy with your data. Yeah, you could screw up the connection switching in your application (if you aren’t deploying a version of your application for each tenant), but you could also screw up the query method or the prefixing a table name method. All have inherit flaws.

The downsides are the Ops around managing x databases with backups and making sure they are online and running smoothly.

Which do you choose?

All three of the above approaches are very valid in their own right. Which one you should choose comes down to the following.

1. How many tenants?

2. How much data per tenant?

3. Do you have ops resources now or later?

Let’s answer these questions with a few scenarios.

If you have very few tenants (ie under 12) and they could have a lot of data (and are paying you a lot of money), option 3 would probably be your best bet. And given the ability to easily and cheaply throw up new databases in the cloud these days where they will be fully managed for you, you shouldn’t feel bad about doing separate databases.

If you will have a lot of tenants (ie 1000s) and they have very low data requirements, option 1 would probably be ideal.

If you are in between those numbers, perhaps option 2 is the right fit.

Now, I mentioned if you have the ops available to support your decision. A good ops team can make any of these approaches work and run smoothly. Salesforce, for example, does something like option 1. Now, given how big they are, they obviously run across multiple databases, but they have a fleet of dozens of engineers working around the clock optimizing the gears to make the approach work.

In my job, ops are done by me. Lower ops = happier me. We will only have 12 clients (big clients) for any particular application. After implementing 1 and being happy with it, our big clients were starting to right in their contract they 100% wanted clean data separation. Even though they would never know the difference, what the heck, give them their own database. The “nice” thing about 1 is that separating out the data and shoving it into a new database isn’t that bad and your code (save, find, remove tenantId attachment) doesn’t have to change.

The second approach is apparently the one the LearnBoost (mongoose guys use) and I’m sure other companies do as well. I haven’t tried because, as I said we are under a dozen tenants and it is so cheap to throw up a hosted database that sacrificing table names and potential ops hazards doesn’t seem worth it for my scenario.

Key thing to remember in programming, your scenario may require something different. There are tradeoffs to each approach. Yes, option 1 is the ideal. But, eventually you will have to shard and if your database doesn’t natively support sharding, you’re looking at a combination of option 1 and option 3, which isn’t such a bad thing, because it means you have a lot of people using your platform, right?


A run in with gliffy

The Gliffy chrome app has sat under-used in my chrome for quite some time. Since I am waiting to go to the vet, why not take it for a spin. After all, I do enjoy diagramming and while I have found many tools are very easy (I am not talking about you visio) I always find that their stock clipart is so junior… Gliffy is much like this. Very easy, awful clipart.

Here is a five minute diagram loosely based on the ops architecture I have implemented at my current job. There are obvious omissions, but putting everything on a diagram somewhat defeats the purpose of providing a high level view.



Granted the clipart graphics are pretty bad and even the cloud based shading and extra thick stroke look overbearing. However, I did only spend five minutes, so it isn’t too bad. I suppose I cannot expect just anyone can redesign their whole software platform in a year. And thus my search for a diagramming tool that does not rely so heavily on 90’s clipart continues.

Gliffy, being a free tool, is pretty cool though. Definitely check it out. It exports to PNG or JPG, which is good enough. There icon sizes between different diagram types can be jarring, but overall easy to get in and get out.

Adding harmony to nodemon

By default, nodemon will look at your package.json and execute whatever you had set to the “main” property. This is great for coffee, but what about harmony.

Turns out, you have to create a nodemon.json config file that looks something like…

{“execMap”: {“js”: “node –harmony”}}

Now, when you run your standard “nodemon” command it will still pick up your “main” property, but attach the –harmony flag on to it.

Debugging Node.js

I’m not sure it gets any easier than the following video.

Debugging node.js w/ node-inspector by Alex Ford

Run down of steps:

  1. “npm install -g node-inspector”
  2. Open a new terminal, run “node-inspector” and leave it running, info on port provided
  3. Start your app with “node –debug app.js”
  4. Refresh node-inspector browser window (i.e.
  5. Set breakpoints, use your app normally on localhost:3000

If you want to set breakpoints outside of a request, i.e. when setting up express. Then simple use “node –debug-brk app.js”

Good luck and don’t worry about saying goodbye to console.log().


Searching for a blogging platform

Not just any platform, but one specifically tailored toward developers, but while still maintaining the elegance of what everyone else expects from a blog. The goal being to go nerd, but not full on raging nerd.


  • The most popular, which means a plugin or theme exists for absolutely anything.
  • Has a downloadable version that will run in any LAMP setup; i.e. cheap, easy.
  • Speaking of popular and downloadable, people make livings off setting up wordpress sites. Why not (as a developer) at least be familiar with what you could make money off of.
  • Not at all developer / code centric. Though many, many plugins exist to fill that void.
  • Runs on “old” tech.
  • Just a bunch of unnecessary stuff thrown in if all you want to do is blog and remove distractions.


  • It feels a little more developer friendly.
  • Integration with google, which is probably the most popular analytics and adwords.
  • Annoying popups to integrate with google+ or other google services.
  • Not a fan of themes that let users rearrange the entire blog format with the click of a button. I will always prefer someone take their time to craft the best view for their median than let a user have to think.

What about others?


  • Haven’t tried.


  • It’s not really personal. Good for stories, but I just want to have something to show a small tutorial.


  • Like what they are doing, but still a ways off. Node.js hosting is becoming more prominent, but also having to tweak the source to make it work with heroku is too much for most people.
  • $5 / month is also a bit too much for people.

Jekyll / Octopress

  • I’m a huge fan of static generated sites, I just don’t want to take the time to set it up. I also want to blog remotely, so having to open my textpad / idea / commandline seems counterproductive. In other words, too nerd.

And all the others… IMO, not popular enough.

Which one is the best? At least for a developer looking to do a little writing about code… I would have to say… Github.


  • Already handles your code.
  • Free. Unlimited public repos.
  • Developers (your target audience) already use it, so checking in what you can do in a few sample projects will go further.
  • Github Pages / Markdown readme files makes it a snap to thru up something decent.
  • Your code is readible, cloneable, downloadable, etc.
  • The one thing is lacking, besides maybe some SEO, is upfront (or post article) discussions as those can be actually more helpful than the original blog post.