Full stack JavaScript is not about sharing code front to back

I'm watching a panel discussion at Node Summit and noticed one of the panelists saying that they found that there was very little benefit to sharing code between the front and back end when developing in a JavaScript full stack environment.

Recently I was touting the virtues of NodeJS and the person I was speaking to said "in reality how much code can you share across the stack?" I had to point out that this was not a virtue that I extolled and I've never thought of this to be a benefit of JS full stack.

In my opinion, shared code across the stack is a bonus and not a benefit. The primary benefit comes from the synergies and efficiencies in working in a single language through the stack. This means that if someone who traditionally worked on the front end has to dive in and do some work on the back end they are not going to be shocked by a different syntax and instead will be somewhat comfortable with what they see.

Parsing text for a Credit Card Number

A while back I wrote some code that parses text and looks for credit card numbers embedded in the text and then optionally masks all or some of the credit card in the text. This code is open source and available on GitHub: Credit Card Parsing

The main use case for this code was to remove credit card numbers that customers would email in to customer support when they were trying to buy something. The Payment Cards Industry (PCI) standards require the credit card data be stored under more secure conditions than most default standard storage configurations.

If customers' support tickets are being stored in a regular unencrypted database and they are sending you their credit card numbers then you are not PCI compliant. You have two choices. Make the support ticket database PCI compliant or remove the credit card numbers from the text that you're storing in this database.

The code in this library provides a mechanism to find and then optionally mask the credit card numbers in any block of text.

While I was developing this code I learned something interesting. 0.6% of all UUIDs/GUIDs have a valid credit card number in them. When I say valid I mean that it passes the Luhn Algorithm. I discovered this because our support emails had a lot of UUIDs that were part of URLs and other keys that the customers needed to communicate to us.

The first time I saw this false positive I thought that it was a one in a million chance. Not wanting to rely on that (bad) luck I used Monte Carlo Simulation to determine the probability of this happening and it came out at 0.6%. I had to adjust the credit card finding algorithm to ensure that what it thought was a credit card was not part of a UUID.

Development of this library was an unusual experience in that unit tests were immediately useful and protective. Each time a defect came back from production (i.e. a missed credit card or a false positive) I added that block of text* to a unit test and confirmed that it failed. I then fixed the code to ensure that the unit test passed and every time I did that it broke one of the other unit tests. My adherence to strictly unit test everything I wrote in this project ensured that it never had any regression bugs.

* If it was a missed credit card then that credit card would be replaced by a fake one before it was inserted into the unit test. I used Graham King's Credit Card Number Generator to create these fake credit cards.

Facebook should introduce a clothes tagging feature

The next big feature that Facebook should bring out is clothes tagging. This will allow parents to tag clothes that they've given to friends' kids and track how many times they've been passed on. Recipients of clothes can give clothe-tag-thanks to those who gave the clothes as a gift or a hand-me-down.

The data collected from the clothes lineage (assuming you can identify the label) could be used to calculate the hardiness of the clothes and manufacturing quality. The more kids that were able to wear the same t-shirt or shorts will be the ultimate vote in quality. You could also determine which kid treats their clothes the roughest if there's no lineage from them onwards.

This will also help track when friends and siblings don't return clothes they borrowed. Tag that blouse in a photo of you on Facebook and then link-tag it in your your sister's photo. The public humiliation will ensure that she returns it to you.

NodeJS Express Automatic Content Type

Try this in a NodeJS Express application. Add a route as shown below and take a look at what the web page shows:

app.get('/mytest', function(req,res){
    var testdata = {
        segment: 'Five',
        value: '42',
        environment: 'development'
    };
    res.send(testdata);
});

Before you go to this page in your browser, probably something like http://localhost:3000/mytest you should bring up the Developer Tools, on Chrome you can do this by hitting F12 or Ctrl+Shift+i.

In the browser you will see:

{
  "segment": "Five",
  "value": "42",
  "environment": "development"
}

In the Developer Tools take a look at the Response Headers in the Headers section. You will see that Content-Type is set to application/json; charset=utf-8

Now let's change the mytest function to the following:

app.get('/mytest', function(req,res){
    res.send('this is my data');
});

The browser will now show you:

this is my data

If you look at the developer tools you'll see that the Content-Type is now text/html; charset=utf-8

NodeJS/Express detected the type of data that you're sending back to the browsers and adjusted the Content-Type appropriately.

Audit Controls or People

In my senior year at college I took Auditing along with a number of other accounting majors. I was on track to become an accountant, and in fact became an accountant, until I mainlined some source code and was unable to turn back.

The only thing that I really remember from that auditing class was our professor telling us about controls and people. His comment was: "You can put in as many controls as you want to enforce or prevent something from happening and someone will always find a way around them. At the end of the day you need to hire the right people who don't need those controls in place."

When I heard this it made absolute sense and have always sought to surround myself with the right people and by default trust everyone. There have been occasions when I've been let down which is what you'd expect with a large enough sample size. As I mature and become better at accessing people the disappointments have dropped.

This ties in nicely with the Agile Manifesto and the autonomy that you give to teams to self form and determine what they can get done in a sprint. If you have the right developers on the team the controls can be minimal or none. Trust is the key. Awesome results are the end products.

A Dozen JavaScript Libraries

Just spent a couple of hours this evening listening to Rob Richardson give an awesome presentation on A Dozen JavaScript Libraries.

He covered:

1. jQuery
2. Lo-Dash
3. Handlebars
4. Modernizr
5. Moment
6. Normalize.css
7. Twitter Bootstrap
8. jQuery UI
9. Backbone
10. Angular
11. JSHint
12. Jasmine
13. RequireJS
14. Rafael

in enough detail to arm you with the ability to select one of them for a future project. It also looks like he's extended the Baker's Dozen (13) metaphor to a JavaScript Dozen (14). I'm guessing that JavaScript has the math library to do that.

Also love that he's using reveal.js for his presentations.

Good work Rob!

MongoDB for Node.js Developers

mongoDB.org, the makers of MongoDB, run an great online course called M101JS: MongoDB for Node.js Developers.

The course is 7 weeks long. Each week will take you about 5 to 12 hours to complete and they deal with:

1. Introduction
2. CRUD
3. Schema Design
4. Performance
5. Aggregation
6. Application Engineering
7. Mongoose/Final Exam

Overall I scored 90% for the course. Each concept is well presented in bite sized chunks with a good video clip of 2 to 10 minutes long and usually followed by a quiz to help solidify the concept. They build on each other from easy to difficult.

If you want to get credit for the course you have to keep up and do it as each week becomes available as the homework credits only stay active for one week. This, in my opinion is a good thing as it focuses you to dedicate time every week to getting this done.

The course has great explanations on replication and sharding, makes it seem obvious and simple.

The final exam covers everything you've done in 10 moderate to difficult questions. You'll get a great sense of accomplishment once it's complete.

MongoDB Education provide you with a database of 120,000+ emails from the Enron Corpus which makes for an entertaining set of questions (about 3 of them) that use this database to test your query and update skills.

Of the 7,599 students enrolled, 1,482 students completed the course successfully, a completion rate of 20%.