The Unintended Benefit of AI Bias in Educating People About Social Biases

 I gave Bard the following command:

Write an article that talks about the fact that the biases we see coming out of AIs have an unintended benefit of educating people about social biases and is garnering more conversation around bias and in turn addressing the negative aspects of bias.

And this is mostly what Bard responded with. Some minor tweaks from me.

One of the unintended benefits of AI bias is that it is raising awareness of social biases. When people see AI systems making biased decisions, it can help them to understand how these biases exist in the real world. This can lead to more conversations about bias and how to address it.

For example, in 2019, a facial recognition algorithm was found to be more accurate at identifying white people than black people. This revelation sparked a lot of discussion about the role of race in facial recognition technology.

Another example is the case of COMPAS, a risk assessment tool used by judges to determine whether defendants should be released from jail before their trial. COMPAS was found to be biased against black defendants, who were more likely to be classified as high-risk and denied bail. This led to calls for reforms to the criminal justice system.

The unintended benefit of AI bias is not always positive. In some cases, it can reinforce existing biases and make it more difficult to address them. However, overall, it is clear that AI bias is having a positive impact on raising awareness of social biases. This is an important step towards addressing these biases and creating a more just and equitable society.

Here are some ways to address the negative aspects of AI bias:

Use more diverse data sets: AI systems are trained on data, so it is important to use data that is as diverse as possible. This will help to reduce the likelihood that AI systems will learn to reflect biases that are present in the data.

Use fairer algorithms: There are a number of algorithms that are designed to be fairer than traditional algorithms. These algorithms can be used to reduce the impact of bias in AI systems.

Be transparent about the data and algorithms: It is important to be transparent about the data and algorithms that are used to train AI systems. This will help to make it easier to identify and address any biases that may be present.

Encourage human oversight: AI systems should not be used to make decisions without human oversight. This will help to ensure that any biases that are present in the AI system are not allowed to have a negative impact on people's lives.

By taking these steps, we can help to ensure that AI is used for good and that it does not perpetuate the negative aspects of social bias.

The Parallels between the evolution of self driving cars and generative AI

Generative AI and driver-less cars are two technologies that are rapidly evolving and have the potential to change the world in a major way. Both technologies rely on artificial intelligence (AI) to perform complex tasks, but they do so in very different ways.

Generative AI is a type of AI that can create new content, such as images, text, and music. It does this by learning from existing data and then using that data to generate new variations.

Self driving cars are vehicles that can navigate roads and highways without the need for a human driver. They use a variety of sensors, such as cameras, radar, and lidar, to collect data about their surroundings. This data is then used by AI algorithms to make decisions about where to go and how to avoid obstacles.

The generative AI industry and the driver-less car industry have both been growing rapidly in recent years. Here is a timeline of some of the key milestones in each industry:

Generative AI

• 2012: Generative adversarial networks (GANs) are first introduced. GANs are a type of generative AI that have been used to generate realistic images, text, and music.
• 2014: DeepDream is released. DeepDream is a software program that uses neural networks to generate psychedelic images from regular photos.
• 2017: OpenAI Five defeats a team of professional Dota 2 players. This is a major milestone for generative AI, as it shows that AI can be used to create systems that can outperform humans in complex tasks.
• 2020: Nvidia releases StyleGAN2. StyleGAN2 is a generative AI model that can generate photorealistic images of people, animals, and objects.
• 2023: Google AI releases Imagen. Imagen is a generative AI model that can generate images that are indistinguishable from real photos.

Driver-less Cars

• 2004: The first self-driving car is built by Stanford University. This car is able to navigate a small course without human input.
• 2010: Google begins testing self-driving cars on public roads.
• 2014: Uber launches a self-driving car pilot program in Pittsburgh.
• 2016: Tesla releases its Autopilot feature, which allows cars to drive themselves on highways.
• 2020: Waymo launches a commercial self-driving car service in Phoenix, Arizona.
• 2023: Several major automakers announce plans to release self-driving cars in the next few years.

Both the generative AI industry and the driverless car industry are rapidly evolving. It is still too early to say when either technology will become mainstream. It is clear that they have the potential to change the world in a major way.

One of the most exciting things about generative AI is its potential to be used to create realistic simulations of driving situations. This could be used to train driver-less cars to be more safe and efficient. For example, a generative AI model could be used to create a simulation of a busy intersection, and then driver-less cars could be trained to navigate this intersection safely and efficiently.

Generative AI could also be used to create new features for driver-less cars. A generative AI model could be used to create new navigation apps that are more intuitive and easier to use. The future of generative AI and driver-less cars is very bright. These two technologies have the potential to revolutionize transportation and make our lives safer, easier, and more enjoyable. 

Developers procrastinating their way to better code

In The surprising habits of original thinkers Adam Grant describes the sweet spot between precrastinators and procrastinators for optimal original thought.

In short, completing your tasks far ahead of time or at the very last minute leads to less original thought.

Think of this in terms of a developer getting their tasks done.

Typically we're pulling tickets off job queue. If you're a developer then you've probably worked with GitHub Issues or Jira or some similar system. Tickets are usually prioritized from most important to least important.

If we've never seen the ticket or problem statement that we've just pulled to work on then our original thought process for solving this is the equivalent of an extreme procrastinator. We're learning about the problem at the same time as we're solving it. This leads to less original solutions and probably the first solution we think of instead of the best solution.

One way to mitigate this is to have grooming sessions. We meet as a team and go through the backlog of tickets and in addition to prioritizing them the ticket creator will explain the ticket in more detail so that we can estimate the effort in completing this. More details are also added to the ticket if needed. The team sometimes discusses possible approaches to solving this. Most important, in my opinion, is that this problem has been dropped into your subconscious and whether you like it or not your brain is noodling on a solution in the background.

Something that I feel we don't do often enough is "kick tickets down the road." In other words, there are tickets that we should procrastinate on that we don't.

Some tickets are critical and need to be done immediately. Major security vulnerabilities fall in this category.

If the ticket is not urgent and can be punted and you or the team are uncomfortable with the current array of possible solutions then do it. Kick that ticket down the road. And do it intentionally and without shame. Add a comment on the ticket stating exactly that:

The team discussed this issue on DD-MMM-YYYY and we were unable to come up with an idea for addressing this in way that we wanted so we're putting this back in the queue to mull on.

How do you measure the value of a PR Review?

How do you measure the value of a PR Review?

Thinking out aloud. You employ a developer whose sole job is to review PRs submitted by other developers. How do you measure the value that developer is providing?

The formula

The time saved by not having to (1) debug issues in production plus (2) the time taken to fix the code plus (3) the time taken to review and deploy the fixes multiplied by the cost of that time.

Plus...

The revenue generated by the customers who would have signed up if that bug did not exist.

Plus...

The revenue that would have been maintained if those customers had not canceled their subscriptions because of the bug that got through.

Plus...?

Minus...

The cost of the review-developer doing the PR.

Minus...

The other noise created by the review-developer trying to make the value look obvious by over-commenting on the PR. (A quick aside: If you are being measured or incentivized to do PRs then you will have a tendency to comment more frequently to show value. Sometimes that will be value but sometimes it will be costly noise.)

Minus...?

Review Feedback and Measurement

What if the PR submitter and added value markers to each comment that the reviewer made?

Given that the submitter has to read through all the comments anyway it should be very little effort to tag the comments with a marker. In Stash there's the "like" link and in GitHub you have a collection of emojis.

An automated scripts could aggregate the tags assigned to the reviewer.

What is a valuable comment on a PR?

This brings up the question on value in comments.

"I like that you used reduce() here instead of filter() and map()" - is that a valuable comment? I think that it is. Perhaps sometimes it needs more context. The value here is that your telling the PR submitter that you (1) read through it and understood it and (2) thought that a particular section was well written.

A comment like this has even more value if the submitter has not used an optimal pattern (that you like) in the past or in another section of the PR. I have seen this where a submitter may have used a "perfect" pattern in one file and then something "messy" to solve the same type of problem in another module. Highlighting the good code as well as the "needs improvement" code has as much value.

The Architectural Decision is Wrong

Every architectural decision we make today will be wrong at some point in the future.

It will be wrong for one of two reasons:

1. Information we didn't know at the time we made the decision.
2. Technology that's changed or become available since then.

This also goes for the technology stack that you choose.

When you make your decision, list all of the reasons why you're taking that path. Do it in your Jira or GitHub Issues (or Whatever tracking system) in the first post or description of the ticket.

Copy/paste the top of this blog post that includes the two numbered points into the bottom of the description and stop wasting anymore time on this. This is a reminder that it's going to be wrong one day.

Months later when you can't remember why you made this decision you can revisit this ticket and make notes about what you could have done at that time to make a different decision if needed. Or perhaps that was the best decision you could have made at that time.

Coaching and the PR Code Review

There is rarely a time when all the members of a team have a deep understanding of all the technologies being used on a project. On top of that the technologies that they're using are evolving and all team members need to keep up with the changes. Some members will learn new techniques and features earlier than the others.

An effective way of cross training team members is through the Pull Request (PR) Code Review.

Comments on a typical PR will be:

• This looks like a mistake because...
• This doesn't conform to our standard because... (This should rarely happen because a lint step should have caught this earlier. If it is happening then the lint rules should be reviewed.)
• This works. I would do it this other way because...
• Please add/modify a test for this.

In addition to that, as a reviewer, you should be asking:

• I'm new to this technology, what does that do?
• Please can you add a comment above this line explaining what this does?
• I haven't seen this syntax before, is it the same as?
• This is fantastic! I never knew you could... (Call it out when someone does something you haven't seen before or does something really well and you learned from it. Everyone loves positive feedback.)

If you submit a PR that has new features or techniques then consider immediately adding comments (in the PR) about them to help the reviewers if know that they will not understand what something does.

The question then arises, should I add a comment in the code or a comment in the PR? My take on this is that comments about how a language, framework or technology works, in isolation, should go in the PR comments. You don't want to clutter the code with information that can be found through a search on the web. The comments that go in the code are how the code works.

These are the advantages of learning through code reviews:

1. The reviewer is learning in the context of the project domain. You don't get more real world than that. Not only will the reviewer be learning new syntax/constructs but they will also be understanding the business domain and gain knowledge in part of the code base that they may need to maintain in the future. Compare this to learning contrived examples in a class.
2. The reviewer is learning a subset of the technology as it pertains to this domain. We would all love to learn all aspects of each technology we touch. Time constraints do not make this possible. Learning like this in situ provides the most time efficient way of learning the essentials. Again compare this to class learning where you may gain some super interesting knowledge and then not apply it.
3. The coach, the person who submitted the PR, is forced to look at and explain their code. When you ask your seemingly naive question you may see a comment like "This construct in this language does... Now that I look at it again I see a problem/way-that-I-could-improve-it."

Using this technique you get a better code review on the PR and a great contextual training session at the same time.

MomentJS Notes

Install

npm i moment --save
npm i moment-timezone --save

Use

var moment = require('moment-timezone');

Create moments in and out of DST:

var cdt = moment.tz("2015-07-23 08:30", "America/Chicago");
var cst = moment.tz("2015-11-23 08:30", "America/Chicago");

Check that offset from UTC is what you'd expect:

cdt.tz('America/New_York').format()
> '2015-07-23T09:30:00-04:00'
cst.tz('America/New_York').format()
> '2015-11-23T09:30:00-05:00'

Check that zone aware format output is what you'd expect:

cdt.tz('America/New_York').format('HH:mm:ss')
> '09:30:00'
cst.tz('America/New_York').format('HH:mm:ss')
> '09:30:00'

Node Foundation Membership Election

Mikeal Rogers recently posted Nominations for the 2016 Election for individual representation on the Node Foundation board.

I'm putting myself forward and answering the question "Why would you like to represent the individual membership of the foundation?"

Why?

I think that Node.js and the ecosystem around it plays a critical role in our current technology stack. This is going to become more important in the future.

I would like to be able to help shape the success of this platform. One way to do that is to understand what the membership wants and needs to get out of what we have today. More importantly what do they expect from the future. As part of the bridge between membership and the board I will be working to ensure that members' opinions are represented at the leadership level.

Qualifications

Leadership: In the past I've served as a director of engineering for a large IT company managing a team of 35+ managers and developers.

Technical: I have a few open source projects that I manage. I also contribute to open source projects I can improve through pull-requests. My day-to-day work is mostly writing JavaScript against the Node.js platform and system design and architecture.

Questions

I've intentionally kept this brief. I'll answer any questions. If you ask them as comments to this post then we can keep them in one place. Anyone else reading this will be informed.

Babel Cannot read property error of undefined

This is more a reminder to myself about how to solve this error that I've stumbled across a couple of times with Babel 5 & 6.

If you downgrade Babel from 6 to 5 and leave a .babelrc file in your project with a Babel 6 specific setting like:

{
  "presets": ["es2015"]
}

then you might get an error like this:

if (!option) this.log.error("Unknown option: " + alias + "." + key, ReferenceError);

TypeError: Cannot read property 'error' of undefined

The solution is to remove the .babelrc file or remove the Babel 6 specific settings.

Also, if you're using Babel 5 and you require a module from another project that has a .babelrc file which is using Babel 6 and has a Babel 6 setting in it then this will cause the same problem in your Babel 5 project.

Docker and GLIBC_2.14 not found

Hit a problem today when I was using Docker and Docker-compose to run a Node.js app in a CentOS container. I had done an "npm install" locally and then the docker-compose command had setup the container and copied everything over from my Ubuntu workstation.

Problem was that I was using a couple of Node.js modules that used native code. So the Ubuntu compile of those modules was getting copied to the CentOS container and when CentOS was trying to run them it was giving me an error about "GLIBC_2.14 not found" because it hadn't compiled those modules.

I feel that a good practise for almost any Docker setup is to have a .dockerignore file which excludes the "node_modules" folder.

This is what my .dockerignore file looks like:

node_modules/

My Ideal Full Stack JavaScript Team Environment

Here are some of the tools and practices that I'm currently in favor of when working in a team environment on a JavaScript Full Stack project. In no particular order.

Pull Requests

All code should have a second set of eyes on it at some point. This serves the following purposes:

1. Catch bugs or potential bugs.
2. Teach both the reviewer and reviewee.
3. Keeps the team members up-to-date with what other teams members are working on.
4. Introduces best practices, new features/techniques and new libraries.

PRs should almost always be assigned to someone. Others can be @mentioned. Almost anyone (senior enough) should be able to signed off with a Looks Good To Me (LGTM) in the comments and merge.

The developer submitting the PR should let the reviewer know the urgency of the PR.

1. Urgent. The submitter immediately accepts the PR. The review is done post-facto as a learning and review process. Can also catch bugs that are fixed in the next PR.
2. Normal: Someone is expected to review this within an hour.
3. Low: Review within the next day.

Linting

An automated linting tool should be part of the commit process. Locking in lint errors to a maximum value will allow the gradual introduction of linting to existing projects.

My default (and currently the mostly popular) linting tool for JavaScript projects is ESLint.

Developers should be encouraged to have a lint helper plugin in their editors so they rarely/never see lint errors on commit.

The team should have an evolving .eslintrc file that's shared across all projects. Some projects might have specific override .eslintrc rules if they are catching up with the standard or have exceptions.

Keep the master .eslintrc in a dot-files folder that's a sibling of all the other projects and reference it from there.

ES6

ES6 is here. There are very few reasons not to start using this. Babel is an excellent transpiler that will allow developers to start using those features.

Use code reviews to help teach other team members ES6.

If you're not using ES6 you'll start leaking developers to other teams and companies. More on this below...

Hot Loading

Most projects should have tooling setup so that they can quickly iterate on small changes to code that they are working on and see the results.

This rapidly accelerates both learning and development.

If, for example, you're working on a React/Node project then, in my opinion, you'd have the Webpack Hot Module Replacement transpiling your changes in memory and making them almost instantly available in the browser.

As developers we're always on a learning curve. We can never be expected to know everything. Using a fast responsive hot loader we can quickly try different techniques and see the results. This will speed our learning of how that corner of the world works.

Front End Framework

Most projects should be using a modern front-end framework for the UI component. The most popular over the last several years has been AngularJS. The current rising start is ReactJS.

I'm in favor of ReactJS. It looks like AngularJS and EmberJS are converging on what ReactJS has introduced.

Latest Versions

We should strive, as much as possible, to be using the latest versions of everything. It's perfectly acceptable to hold off on the brightest and shiniest until it's stable. That should be a conscious decision and not the default.

Npm has a great command npm outdated --depth 0 that will give us a summary of how our project looks compared to what's available. Use that command with the -g option to check your globally installed tooling.

The 3 main reasons usually given for keeping up with the latest version (1. Features 2. Performance 3. Bug Fixes) are completely irrelevant. The reason you want to stay current is to keep your developers happy and engaged. Nobody wants to work on yesterday's technology.

Keeping a buzz in the team about moving to the next version will keep everyone up-to-date on what's happening and engaged with the team. The grass-is-greener syndrome with other teams or companies won't exist on the technology front because you'll be using the latest. In fact I've successfully used this as a recruiting tool for developers who are stuck in other companies or teams on old technology.

Related:

Your tooling should automatically keep your project's dependencies up-to-date with what would be installed when someone initially installs the dependencies on the project. I use the npm-update-outdated module as part of my pre-commit hook to update my dependencies before the tests are run so I know that my tests have run against what the CI server will use.

Project Onboarding

If someone asks you to work on a project then you should be able to do the following pretty quickly.

1. git clone
2. npm install
2. npm test (should run clean)
4. npm start

And have a server up and running that the browser can hit and interact with.

There are lots of complexities that might stop something that simple from working.

The project's readme should have bullet proof (as good as possible) instructions on how to address that.

For example, most developers have Docker. If you have a dependency on a MongoDB then npm start or npm install should run Docker and pull down a MongoDB container and get it up-and-running.

A new-to-the-project developer who experiences problems with an out-of-date README.md and who then updates the README.md should be given the rest of the day off as a reward. (That might be a bit extreme. This almost never happens so it might also be okay.)

Testing

All projects should have tests. These should run during a pre-commit hook. Ideally these are run implicitly through the Code Coverage tool.

When bugs are fixed a test should usually be written demonstrating the bug before it's fixed. This test will prevent a regression on this bug later.

Tests are difficult to write. Do lots of cross-education with other team members during PRs with tests. Get to know and love all the tooling around tests. When you're using a tool for the first time ask for help and opinion in the PR.

Some of the tools I use for testing:

• Mocha
• Jasmine
• Istanbul
• Sinon
• Rewire
• Proxyquire

Code Coverage

Code coverage such as Istanbul can be automated as part of a pre-commit hook. It will help make sure that critical sections or sections that you're about to change have sanity tests. It has awesome "graphics"

Code Coverage Minimum Levels

It's easy for a developer to commit new code that doesn't have test coverage. In my enthusiasm to get my new code out there I often forget to write tests for it. Using a tool like Istanbul we can prevent code coverage from dropping from the previous level in a pre-commit hook. This will remind us that we need to add tests.

Update 11/2/15

Isomorphism

I didn't used to think that isomorphic JavaScript was that important. I believe that it is now becoming important.

Least of all you should never have duplicate code that's duplicated for the sake of using on both server and client. There is almost always a way to provide the same code block to both client and server to provide a DRY and isomorphic code-base.

ReactJS JSX gives us HTML in JavaScript

What I consider the main difference between ReactJS and its JSX syntax when compared to the other frameworks like AngularJS, EmberJS, and BackboneJS is that JSX is HTML in JavaScript. The others have JavaScript in the HTML.

HTML-in-Code instead of Code-in-HTML.

Here's a simple example:

React's JSX:

myCollection.map( (item) => {

  return render (

    <div>{item}</div> 

  );

});

AngularJS:

<div ng-repeat="item in myCollection">

  <div>{{item}}</div>

</div>

One of the things that we continuously struggle with is the ability to program markup. To do this we've been adding language to the markup.

JSX stands that paradigm on its head and adds the markup to the language.

As a developer I enjoy writing code more than writing markup. JSX means that I don't have to jump-out-of the markup to make things happen to it. The markup is encapsulated inside the logic that controls the flow of the application.

With AngularJS I'm consciously wiring language and markup together.

AngularJS appeals to the designer in me while JSX appeals to the developer in me.

I'm not against AngularJS or the other frameworks. I enjoy writing code and solving hard problems. I also hated the sight of JSX when I first saw it and before I wrote my first project in it. It didn't seem right to pollute JavaScript with markup.

For me the AHA moment was the productivity I felt that React gave me by keeping me in my area of expertise: JavaScript. I'm good at HTML and CSS. I'm an expert at JavaScript. More productivity happens in your area of expertise.

Long live ReactJS.
Long live AngularJS.

Thousands of Lint Warnings and Errors

You add linting to your project and suddenly you're faced with thousands of lint warnings and errors. What's the point? You're never going spend those hours upon hours fixing all of this. Or are you?

I use ESLint for linting on JavaScript projects.

If I start a project I add a set of linting rules (in the .eslintrc file) and an automated way of running them with tests or checkins and the project remains lint free. That's easy.

Adding lint rules to an established project is tough, especially if you have a set of predefined rules you want to use and they are generating more warnings and errors than you can address.

The best way, I've found, for adding a linter in this case is to:

1. Add all your lint rules using the .eslintrc file.
2. Run the linter and then disable each rule that is generating a warning or error until there are no more warnings or errors.

Now go back to coding on your project and when you hit the wall turn to enabling a lint rule as your stress relief.

We all have times when things are not going well in the code base and we need to take a break to refresh, regroup and take another approach at what we're doing.

These breaks are perfect times to see if we can switch one of those disabled lint rules to a warning or error level and improve the quality of the code. It's also a great opportunity to scan over the entire code-base and re-familiarize yourself with parts that you'd forgotten about or parts that might be dead and can be removed.

Consuming a JSON REST result in C# .NET

Yesterday I wrote about an Simple API server for IP Address Information Lookup that I had created in Node.js. This server produces a JSON result that looks like this for IP address 8.8.8.8:

{
   "city":{
      "geoname_id":5375480,
      "names":{
         "en":"Mountain View",
         ...
      }
   },
   "continent":{
      "code":"NA",
      "geoname_id":6255149,
      "names":{
         "de":"Nordamerika",
         "en":"North America",
         ...
      }
   },
   "country":{
      "geoname_id":6252001,
      "iso_code":"US",
      "names":{
         "en":"United States",
         ...
      }
   },
   "location":{
      "latitude":37.386,
      "longitude":-122.0838,
      "metro_code":807,
      "time_zone":"America/Los_Angeles"
   },
   "postal":{
      "code":"94040"
   },
   "registered_country":{
      "geoname_id":6252001,
      "iso_code":"US",
      "names":{
         "en":"United States",
         ...
      }
   },
   "subdivisions":[
      {
         "geoname_id":5332921,
         "iso_code":"CA",
         "names":{
            "en":"California",
            ...
         }
      }
   ]
}

I wanted to consume this end-point in a C# application. A quick search for solutions on how to consume a JSON result from a REST service showed some very complicated ways of doing this. This is a simple solution that I came up with:

// A simple C# class to get the details of an IP address
public class IpApi
{
    public IPInfo GetIPInfo(string ip)
    {
        // Create the URL for the REST endpoint
        string url = "http://localhost:3000/ip/" + ip;
        // Create a .Net WebClient object
        WebClient wc = new WebClient();
        // Get the string result from the REST endpoint
        string json = wc.DownloadString(url);
        // Use Newtonsoft JsonConvert class and its static
        // DeserializeObject method to parse the string into
        // a .Net object
        return JsonConvert.DeserializeObject<IPInfo>(json);
    }
}
// The following classes create the JSON object graph hierarchy
// in static classes. It's a bit tedious looking at the JSON
// object and typing these out. I'd imagine that if you're 
// doing this a lot you could write a tool to generate these
// classes using the JSON as input. Or perhaps there's already
// a tool that does this?
public class Names
{
    // I didn't need the pt-BR and zh-CN key/values from the
    // names so I didn't bother looking up how JsonCovert maps
    // those. 
    public string de, en, fr, ja, ru;
}
public class City
{
    public Names names;
    public int geoname_id;
}
public class Continent
{
    public string code;
    public Names names;
    public int geoname_id;
}
public class Country
{
    public string iso_code;
    public Names names;
    public int geoname_id;
}
public class Location
{
    public decimal latitude;
    public decimal longitude;
    public int metro_code;
    public string time_zone;
}
public class Postal
{
    public string code;
}

public class IPInfo
{
    public City city;
    public Continent continent;
    public Country country;
    public Location location;
    public Postal postal;
    public Country registered_country;
    public Country[] subdivisions;
}

Simple API server for IP Address Information Lookup

I find that I often have the need, in a web application, to lookup information about an IP address that a request comes from.

To serve this purpose I created IPAPI (GitHub), a simple server providing a single API endpoint that returns information about an IP address.

(You should try the server just because the name is a palindrome. Imagine the awe and respect you'll get when you say "I ran a Palindrome API server today.")

The server runs on Node.js and uses the GeoLite2 database from MaxMind.

You can install and run the server with:

git clone git@github.com:guyellis/ipapi.git
npm install
node index.js

or

npm install ipapi
node node_modules/ipapi/index.js

The server will download and unzip the IP database if it's not found locally.

Using the server is as simple as having your client call http://<your-domain/ip/<x.x.x.x> and getting back JSON with information about the IP.

There are plenty of improvements that can made to this simple server. Pull Requests gladly accepted.

Improving Security in Node.js

A collection of tips and ideas to improve the security of a Node.js application.

Don't let your app identify itself as a Node.js application

In the response header you might have:
X-Powered-By: Express
Set-Cookie: connect.sid: sJbhAJcKt1JVuCRZ5HwpYMhFBAKaXm0

The first item identifies that your application is using Express.js which identifies Node. The second in a similar manner identifies the Connect middleware for session management, again a Node module.

The fixes for these are very simple. To suppress the X-Powered-By header key/value you should do this:

app = express();
app.disable('x-powered-by');

For the connect.sid identifier you can change the default name by using the "key" key in the initialization object:

app.use(session({
  key: '<customize me>',
  ...

No Website Needed

I have a friend who's an architect. He does bespoke designs for shops and houses. He's never had a website and he says that's one of his unique-selling-points (USP) when talking to a customer.

Apparently the conversation goes something like this:

Customer: "I searched the web and I couldn't find your website or anything else about you."
Architect: "The only reason that we're talking now is because someone, probably an existing client, recommended me to you. I only do work through referrals and I find that I have more work than I can cope with."

In his response he's implying that he's that good that he doesn't have to advertise. According to him that's a very powerful sales pitch during the initial consultation with a future client. A website, he feels, would not allow him to use that line in closing a sale.

Moving your Team and Project to ES6

How do you safely move your team to using ES6?

1. Convince the team/boss/stakeholders that it's time to move to ES6

The points in this article might help.

2. Decide what you're going to use

Are you going to use a transpiler like Babel or a shim? If using Node.js are you going to use the --harmony flag? There are plenty of articles that discuss this.

3. Start using ES6

Most teams will have at least one person who wants to use the new syntax. This is how these developers should introduce ES6 to the rest of the team.

Training? That's one way. Another is to cross-train each other on a code base that you're already working on.

Let's say that you wrote some ES5 code like this:

handleChange(name, e) {
  var change = {};
  change[name] = e.target.value;
  this.setState(change);
}

and you decided that you'd rather use ES6 syntax like this:

handleChange(name, e) {
  var change = {
    [name]: e.target.value;
  }
  this.setState(change);
}

The better way to use the ES6 syntax is to tag it with the name of the new feature like this:

handleChange(name, e) {
  var change = {
    // ES6: Destructuring, computed property keys
    [name]: e.target.value;
  }
  this.setState(change);
}

A developer looking at the ES6 comment should be able to copy/paste the text into a search engine and find a reasonable list of articles that deal with the feature.

4. Teach in the Pull Request Review

Now when you do a Pull Request on your changes message the rest of the team that there are labeled ES6 features.

I've found that this has the extra bonus of having more developers want to review your code because they know that they're going to be learning something new about ES6 during the review process.

Your team are already contributing to and editing a code-base that they're familiar with so the ES6 usage that they're learning is not contrived. It's real world.

5. Remove the ES6 comments

The comments labeled ES6: are there for training purposes. After a period of time you may want to remove them. This is easy to do in a search and delete of this type of comment in the code base.

If you have a lot of non-ES6 developers continually joining the project then you might not want to do this. You can also tag the repository before removing the comments so others can checkout that tag and read the comments.

You might also elect to start dropping comments for the easy-to-understand and common ES6 features and keep them in for the more complex scenarios.

Should I use Extend or Assign in Lodash?

 

 

Use _.assign()

Justification

 

1. If you look at the lodash documentation for _.assign() you'll see that _.extend() is an alias for _.assign(), not the other way around. This would imply that _.assign() is the default and _.extend() is an alternative.
2. ECMAScript 6 will use assign() and not extend().

How does a covering index on a database work?

Today I was having a conversation with a co-worker who lives in Italy. He said that Christmas in Italy starts on December 8 which is a holiday in Italy but he didn't know the English name for the holiday.

I went to Google and typed in "december 8 holiday italy" and got back this result:

I didn't need to  click on the result of the first (or any) item that turned up in the search result because all the information that I needed was right there: The Feast of the Immaculate Conception.

This is a covering index. When the results from the index alone can satisfy the information that you seek then they are said to be "covered in the index" and no further lookup is required.

In my search analogy I only made one request to the Google index and never opened the page that it pointed to.

In a database I would pull back all the information that I needed from the table's index and not have to retrieve the record from the table to complete the information search.

Leaving the land of Google analogy you might have a table with an index on userId. Finding that ID in the index allows the database to quickly locate the record in the table from which it can pull the name, for example.

If you had an index on both userId and userName then only the index would need to be searched if all you are after is userName and the second lookup in the table would not be needed.