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.
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.
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:
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.
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.
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:
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!
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
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:
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.