Google Maps – “hello world” with RequireJS and jQuery

I’ve been looking at the Google Maps “hello world” tutorial in conjunction with HTML5 Boilerplate, RequireJS, and jQuery.

When you download and extract the boilerplate it already gives you jQuery. Given I am using RequireJS with Node (see node-reference-app) I also wanted to use on the client-side to modularize my code. It’s no big deal in itself, but I ran in to a few issues when I dropped in the Google Maps API. A search on Google soon revealed it was due to the async nature that the Google Maps API (and other Google APIs) loads its own code.

There are a number of posted solutions. The one I liked was the async plugin for RequireJS from Miller Medeiros.

Jump over to GitHub to look at the complete solution.

The basic map code is exactly as it appears in the Google Maps tutorial, however here’s a breakdown of how it fits in to HTML5 Boilerplate and RequireJS:

• index.html – has the div for map_canvas, there is also a script tag with a data-main attribute that tells RequireJS the script to run, main.js, when the document is ready (read more here)
• style.css – specifies the width and height for map_canvas
• main.js – this is where the real work begins, we grab map_canvas from the DOM with the help of jQuery and call addMapToCanvas() on the google module
• google.js – this is the heart of the solution to the async problem, if you look at the top you will see the URL is prefixed with async!, which causes the async plugin to be called

Note: to use the example make sure to obtain your own api key and add it to the URL in google.js where it says YOUR_KEY.

Advertisement

Node.js reference app

I’ll keep this post short and sweet. I’ve spent the last week working on a reference app for Node.js. I’m not going to elaborate on it in this post, but rather ask you to jump across to GitHub and take a look at the project. It’s got a comprehensive README file that will hopefully explain my motivations and the app in full.

I’ll happily accept your feedback and encourage you to fork my code and adapt it to your own needs or to showcase the principles that you feel are important.

Enjoy!

TDD with Node

The last few days I’ve been looking at how TDD with Node. This blog provides an example project that uses RequireJS.

My requirements were kinda simple (and obvious):

• I want to easily write clear and articulate tests
• I want to use an expressive framework for writing test spies, stubs, and mocks
• I want a simple to use test runner so I can run my tests from a CI server (and ideally support for headless browser testing for when it comes to my client-side testing)

What I wasn’t expecting was an overwhelming choice of frameworks. That’s good…isn’t it? There were a few frameworks that initially jumped out, such as Vows. However, I struggled to get my tests working when it came to RequireJS. A lot of the examples I found out there were kinda of trivial and I didn’t find any good examples that showed RequireJS.

I have grown fond of RequireJS. I like that I can use it on both the client-side and the server-side, and I like the separation of concerns it affords in my code. So I was determined to find something that worked!

I came across Sinon.JS, which led me to Buster.JS (they both share the same author, Christian Johansen). Although Buster is still in Beta is made an immediate impression on me. It supports Node, it has Sinon embedded, it’s headless, the architecture is robust,…and the list goes on.

I soon got a simple test working and then struggled a bit with Require, but I eventually got it working!

My example app is intended to demonstrate the structure of a more complex app and how testing works. I’ve got a more comprehensive reference app coming soon. So enough said, jump over to GitHub for a closer look, the README provides more context.

Below is the documentation that I think you will find most useful:

• Node testing
• Sinon integration
• Sinon documentation

The Node Beginner Book

On my Node.js journey I came across The Node Beginner Book (which you can also buy bundled with Hands-on Node.js).

As the name suggests The Node Beginner Book is targeted at beginners and the goal of the author is to take you from novice to advanced novice, which it achieves well. The book is structured as a tutorial. It starts with the basics and then works towards a more structure codebase that demonstrates how to use modules for separation of concerns. There are also a bunch of links to other good resources that help you understand Node. As I go through my learning curve I am aggregating these and other resources I have found useful, I’ll share them soon.What I really like about the tutorial is it doesn’t just tell you what is bad, it shows you in code so you can see first hand. There are some really important lessons to be learned here in terms of “blocking” operations and the Node.js event loop.

I am currently expanding the MongoDB example I did with Mongoose in an earlier post. I want to build upon what The Node Beginner Book teaches to provide a more robust reference for a production Node application. I hope to share it soon in a future post.

In the mean time, if you are starting out with Node, even as an accomplished programmer, I would recommend taking a couple of hours to go work through the book. It’s a good investment of time.

St Francis de Assisi the patron saint of Software Craftsmanship

We live in a world of YAGNI (“you ain’t gonna need it”), DTSTTCPW (“do the simplest thing that could possibly work”), MVP (“minimum viable product”), and MCR (“minimum credible release”).

We bow to the philosophy of keeping our software simple (the code and the experience) and doing the minimum amount of work required to put the software in the hands of our users so we can inspect-and-adapt, or in the words of The Lean Startup the Build-Measure-Learn feedback loop (if you are thinking in this direction then I also encourage you to immerse yourself in continuous delivery).

Recently I was visiting with a customer who had a “war room”, and judging by the amount of material on the wall, there’s was a culture of collaboration, which I love. Written across the top of the wall was the following quote:

start by doing what is necessary, then do what is possible, and suddenly you’re doing the impossible

St Francis de Assisi, (Patron Saint of San Francisco)

This really struck a cord with me. I feel in our world of acronyms, it is a more elegant way of expressing the sentiment of simplicity and minimalism. May be we should herald St Francis de Assisi as our patron saint, after all he does have a connection to Silicon Valley.

Heroku + Node.js + MongoDB (featuring mongoose)

This is the next post in my series around Heroku + Node.js + MongoDB. In my original post I explored the node-mongodb-native driver, which I then followed with Mongoskin. In this post I’ll provide an example for Mongoose.

Again I won’t reiterate the steps to deploy the code. They are the same as the original post, only this time clone the code from this repository:

git@github.com:p15martin/BlogMongoDbMongoose.git

Comments on the code

So up-front I will say Mongoose gives me that warm old-school feeling from my JEE days. There is that sense of coming home and being snuggled up in the data access layer with my separation of concerns, and using my object relational mapping tool.

In contrast to Mongoskin you certainly need to write some additional code, but the intent is clear and the code readable.

The documentation is also great for Mongoose. Keep up the great work!

Conclusion

All three libraries are fantastic, as is Heroku + Node.js + MongoLab + MongoDB. Everything just works, I didn’t encounter any issues. With all three libraries I was able to quickly write my code and see it running in the cloud.

I think the choice of library is very much one of style, with a bias towards either Mongoskin or Mongoose, which I believe are both built on the node-mongodb-native driver.

With that said my examples are simple. I am only demonstrating that it can work and my code does no more than insert a document in the database. I’ve not thought about how these libraries would fit within a much larger codebase, nor have I looked at the robustness of the code or considered error handling. I am working on an extended example around Mongoose to show a more complex application. I will share it once it is complete.

I am encouraged by the fact that it just works and at how accessible the cloud has made technology. Now I can focus on just writing code. How cool is it that I can add a database to my app by simply saying: heroku addons:add mongolab:starter

Heroku + Node.js + MongoDB (featuring mongoskin)

This is the next post in my series around Heroku + Node.js + MongoDB. In my last post I explored the node-mongodb-native driver. In this post I’ll provide an example for Mongoskin.

I won’t reiterate the steps to deploy the code again. They are the same as the last post, only this time clone the code from this repository:

git@github.com:p15martin/BlogMongoDbMongoskin.git

Comments on the code

The code is certainly simpler, and with less code the readability is much improved. Like node-mongodb-native the documentation is weak, but again the tests provide a useful reference.

I’m not going to say anything more at stage, but wait until my next post on Mongoose to draw more of a conclusion.

Heroku + Node.js + MongoDB (featuring the native driver)

Following on from my previous post where I explored Heroku + Node.js + Pusher I thought I would explore MongoDB.

Heroku currently supports two add-ons for MongoDB, there is MongoHQ and MongoLab. I choose MongoLab for no other reason than first impressions (and it worked first time).

There are bunch of good blog posts out there that provide examples of Heroku + Node.js + MongoDB, which helped me get started. What I discovered was a bunch of different Node.js libraries for working with MongoDB. Specifically:

• node-mongodb-native
• Mongoskin
• Mongoose

So what I thought I would do here is write a series of blog posts that take the same example and show the different styles of the above libraries so you can compare and contrast. In this blog post I’ll start with the node-mongodb-native driver.

I’ll start with a disclaimer, this is not intended to demonstrate well crafted code, it is a spike, which is intended to prove the technology works. Use it as a reference example, but don’t use it as production code.

Deploying the app

• Clone the code from GitHub.

git@github.com:p15martin/BlogMongoDbNativeDriver.git

• If you don’t already have an account on Heroku then create one and install the command line client (CLI)
• Move to your command prompt and change directory to where you cloned the code
• Create a new app on Heroku:

heroku create --stack cedar

• Take a note of the app that was created (e.g. hollow-autumn-6787) and the remote repository (e.g. git@heroku.com:hollow-autumn-6787.git)
• Add your Heroku app as a remote repository (remember to change it to your remote repository):

git remote add heroku git@heroku.com:hollow-autumn-6787.git

• Install the MongoLab add-on:

heroku addons:add mongolab:starter

• Push your code to Heroku:

git push heroku master

• Now test your app (assuming you have curl installed), remember to change the url to your Heroku app:

curl -H "Content-Type: application/json" -d '{ "jsonrpc": "2.0", "method": "add", "params": ["Peter", "Martin"], "id":2 }' http://hollow-autumn-6787.herokuapp.com

• If it worked then you should receive this response (if not jump down to the troubleshooting section): {“result”:”success”,”id”:2,”jsonrpc”:”2.0″}

Verify it worked

• In your browser, log on to Heroku and select your app (e.g. hollow-autumn-6787)
• From the add-ons menu select MongoLab

• You should see a screen similar to the following, under collections, there should be a collection called contacts and to its right the number of documents

• If you run curl again and refresh the page then the number of documents should be incremented
• You can also click the collection to view the documents

Comments on the code

I didn’t really like the examples I saw for the node-mongodb-native driver due to the deep callback structures. It hinders readability of the code. The documentation was also poor, although the tests are a good source of documentation.

I did some refactoring as I wanted to see how I could improve readability, as a result you will find two versions. There is web.js that uses top-level functions, and deep.js that uses closures. They both work so you can alternative between them by updating the Procfile.

On my list of things to do is to think more about writing well crafted code for Node.js. What are your experiences with writing clean and efficient code?

Troubleshooting

If you run in to trouble then check the logs. You can configure the logging level from the command line as follows:

heroku config:add LOG_LEVEL=DEBUG

To check the logs use:

heroku logs

Predictive Analytics for eCom

Recently I worked as part of a multi-disciplined team of User Experience designers, Software Craftsmen, and business domain experts to deliver a SaaS-based solution for Predictive Analytics.

It is targeted at existing customers of Adobe SiteCatalyst. The premise is relatively simple. We take historic web analytics data and run it through forecast models, which are typically associated with the investment world.

In the context of an e-commerce site and revenue we are looking to predict revenue and to identify problems ahead of time i.e. a shortfall in revenue. Think of it as an “early warning system”. This is where it gets interesting. The question we then want to answer is what actions can be taken to counter the shortfall? By knowing the correlation between site metrics and revenue the user can then model a % percentage in a metric and what impact it has on the revenue, which may be positive or negative. This level of foresight can then be used to make up the shortfall.

The experience is delivered on an iPad and leverages a statistical analysis engine on the server.

This was truly a fun project to work on and showcased the tight interlock between User Experience and Software Craftsmanship to deliver the “best imaginable experience” that meets the needs of the user – Experience Craftsmanship.

innovation-motivation

I am a big believer in building a team culture that fosters innovation. It inspires us. It motivates us. It drives thought-leadership. It leads to better product, and it leads to new product.

Regardless of where your role sits within the organization there is an opportunity to innovate.

The freedom to innovate enables us to build morale and evolve hyper-performing teams.

It also keeps our business healthy, if we are innovating then we are we are fostering good people, we are remaining competitive in the marketplace, and we are investing in longevity.

Innovation is an incredible tool and should be woven in to the fabric of all our teams. We shouldn’t expect innovation to just happen or rely on good will. It requires investment and it requires commitment from leadership. I’ll talk more about an innovation pilot I ran with my team last year, but first watch this video. It inspired me.