Wednesday, 5 November 2014

Asynchronous JavaScript programming in Node

I want to be able to read an atom feed!! This is NodeJS, so of course there is this great library for doing just that (feed-read), the feed function is asynchronous. I also want to use a Node abstraction in the form using Express modules.
Ok, no problem, I thought. I tried putting the feed directly in my server.js file. There was a simple problem - I don't have the blog data because feed-read has made an asynchronous call to gather the feed information leaving me with nothing.
Once I understood the problem I started searching for solutions. What generally comes up are yet more helpful libraries to help you 'deal with' the async 'problem'.
I am sure there are more complicated problems which may merit a complex library but I happen to know that this is something that JavaScript is great at. JQuery introduced the idea of a promise in version 1.5 and this is basically the same problem, with a similar solution. So the answer?

In my case chain callbacks. Yes, if you are using a function from an abstracted module, pass in a function which will then pass a function etc... When the function at the bottom of the chain passes us some data back we will be ready!! Use an API call to do this perhaps so we can give our users a spinner while they are waiting.
     var blogReader = { 
      GetMostRecentBlog : function(callback) {  
        feed('http://bloglocation.com/feeds', function(articles) {  
         var mostRecentBlogPost = articles[0];  
         var blog = {  
            Title: mostRecentBlogPost.title,  
            Content: mostRecentBlogPost.content  
         };  
         callback(blog);  
       }); 
    };  
    module.exports = blogReader;
    
    You then can use it like :
     blogReader.GetMostRecentBlog(function(blog) {  
       //use Blog object here for display  
     });  
    
I found this exact pattern in Mixu's Node book chapter 7 - http://book.mixu.net/node/ch7.html. He also talks about two other useful patterns to deal with asynchronous calls which may be useful on larger scale projects - Parallel and Limited Parallel patterns.

 As always, the code for my solution can be found on github.

Sunday, 14 September 2014

NodeJS progress and the mighty Bootstrap

Since writing my last post I have spent some more time with NodeJS.
Things I have done:

  • I created an API using Express using this article to create some bears - http://scotch.io/tutorials/javascript/build-a-restful-api-using-node-and-express-4) 
  • I added a favicon using this - https://github.com/expressjs/serve-favicon
  • I pondered Jade as my view engine and then quickly decided that Handlebars would be much easier as I was already very familiar - https://github.com/ericf/express-handlebars
As you can see progress is good. 

Unfortunately, next came the bit I always dread, trying to set out an effective design for the website. I struggle as a designer. At university I got familiar Photoshop and Illustrator, and while I really liked doing it at the time, sadly I have not kept up with the evolution of the software since. Luckily I can just prototype and see where it...

...Mild panic began to build.... oh god what about phones and tablets! As if deciding on a design isn't hard enough, I have to think responsive! Anyway - thank god for the kind people/companies of open source. Luckily we have Zurb Foundation and Bootstrap. Zurb Foundation is fantastic, but as I am already familiar with Zurb I thought I would use Bootstrap.

I am not going to bore you with all the details but provide you with my gotcha's list:

  • By default Node does not permit the public directory to be accessed. I wanted to do this so I could access the bootstrap files which were stored in public/libs. If you would like to store your bower packages in a custom directory rather than the default like me, create a .bowerrc file in your route directory with no file name, if unsure check this. Then add the following: 
    {
          "directory": "public/libs"
    }
  • To access the public directory for styles and scripts:
    app.use(express.static(__dirname + '/public'));
  • To use in your views:
    <script src="libs/bootstrap/dist/js/bootstrap.min.js"></script>
  • Use navbar-static-top rather than navbar-fixed-top. This is a new class as of Bootstrap 3.0, it addresses the problem wherein the navbar sits over the content of the page.

Monday, 25 August 2014

Pondering a RESTful API in Node

Hello!

I am planning to utilise a NodeJS API for my website (gfentimen.com). Before I do this I thought I would try two different API frameworks to see which I prefer.

Loopback vs Express 4
After doing some research into the easiest way to create a RESTful API in node there seem to be a number of challengers. Loopback by StrongLoop seemed to have all the answers, it will connect through to Mongo without an issue, it creates an API framework in next to no time at all, but is it too abstracted?

I downloaded and installed it too see what would happen. Yes - it looks like I am going to have to buy into all of StrongLoops technologies but.... Fair play to them - it was very easy - before I knew I had a screens like these:




So what about Express 4?
Interestingly, since I started writing this blog post Express has had its IP bought by StrongLoop. I hope this will mean more corporate money earmarked for the project. I can't help feeling cynical and suspect that Express will be incorporated into their overcomplicated but admittedly simple to use suite. I can't help feeling that StrongLoop may have missed the point and should instead concentrate on their more evangelical/training pursuits.

I found this article which explains everything extremely well. It feels satisfying because you have such control over every aspect without having to write a colossal amount of code. It was also a relief to find MongoLab and Modulus, I used MongoLab to create my mongo database instance in a matter of minutes.

It gives you the URI e.g. mongodb://<dbuser>:<dbpassword>@ds045087.mongolab.com:45087/gfentimencom

There is an option to create users, however your user account already counts as a user. In other words dbuser and dbpassword are the username and password that you use to set up the MongoLab account NOT a user that you may add through the GUI users option. This had me a little confused for a while and caused some complications connecting to the db.

Another gotcha I has when going through the article it specifies port 8080. The chances are that if you run IIS frequently using this port then you will run into problems like this: events.js 72 throw er eacces.

I took this guys advise and changed my port to 3000 which fixed it. 

I don't think it will come as a surprise to you dear reader that I have gone for Express over Loopback. I found the added sense of control much more satisfying!

Sunday, 6 July 2014

Getting started with NodeJS and pushing it to the cloud using Git and Azure

Yes I know, getting started with NodeJS has been covered many times by far brighter people. However, there are not too many posts written by stubborn PC users (yeah that's right, turn in your grave Steve) and don't make me put another grumpy cat here! I also want to write this as a lead in for a more exciting post later on! If you are new to NodeJS like I am and you are excited at the thought of writing your next API in JavaScript then this is the place for you!

Pre-requisites:
  • NodeJS (this includes the npm package manager as well)
  • A Github account and therefore Git DVCS (Distribruted Version Control System)

To begin with lets make a new directory for the project. I am using  C:\code\nodestart

Create a file called package.json :

   "name": "nodestart" , 
   "version": "0.0.1" , 
   "dependencies": 
        { 
            "express": "latest" 
        } 
}

Then change directory to the location of your project in Command Prompt, and run npm install  
to install the express module.
cd C:\code\nodestart
npm install


So at this point we have everything we need to add further packages in the future. Lets add a new server.js file in our directory as well.


console.log("Hello World");

To run this, go back to the command line and type:

node server.js

You are treated with a "server running at http://127.0.0.1:1337/" message, paste this into your browser and voilà! Basic node achieved! Hazzah!

Now what if, for some strange reason, we wanted to publish our fine work? I mean everyone needs a useless site. No, well lets do it anyway!

First we need to use some slightly more sophisticated code:
var http = require('http')
   var port = process.env.PORT || 1337;
   http.createServer(function(req,res){
   res.writeHead(200, {'Content-Type':'text/plain'});
   res.end("hello world");
}).listen(port);

Now we need to initialise git to make our nodestart project a working git repository. Go to Git Bash (downloaded from git hub) or the command line, cd to the project directory and type:


git init

Notice that this will add a .git folder to the root of your project. We must also add a new file in the root called .gitignore. Add the following lines:


npm-debug.log
node_modules

This is so that you do not add all the node library files to the solution. Now it is safe to type:


git add .
git commit -m 'Initial commit'

It would be nice to setup ourselves properly in terms of our credentials and user names - (https://help.github.com/articles/set-up-git). Nobody likes annonymous commits... there is no-one to blame! 

Also rather than keep typing in your credentials you may want to setup an SSH key. This is very much optional and takes a little time but it makes pushing to source control far less tedious. If you do decide to do this remember to change the clone URL to the SSH one in github! 

Now all we need to do is set the origin and push to our github repository.


git remote set-url origin git@github.com/username/nodestart
git push -u origin master

I am going to use Windows Azure to host this application. You can sign up to get an account with a free trial. Afterwards you can keep the server in free mode and keep auto scale off to guarantee that it will not cost you any money.

Azure has the ability to "integrate source control". This can be done from the UI as shown below or you can use the Azure command line tools through Windows PowerShell.



It's really neat and means that you can push directly to Azure without using a web based repository host like Github or Bitbucket. For more information on this method check out Scott Hanselmans post on the subject

Now back in the Azure console I am going to choose integrate source code as before but this time choose "github" rather than "local git repository".

Select your repository and treat master as your CI branch and there you go! Success!



Additional: Windows Azure can cope with npm but what about bower? I found a solution for this problem here: http://gregtrowbridge.com/deploying-a-bower-dependent-node-app-on-windows-azure/

The only problem was that it relies on a deploy.sh file being produced when running "azure site deploymentscript --node". Instead my solution produced a batch file with Kudu code. To cut a long painful story short I was able to resolve this with the following code:
:: 4. Install bower packages
if EXIST "%DEPLOYMENT_TARGET%\bower.json" (
  pushd "%DEPLOYMENT_TARGET%"
  call :ExecuteCmd !NPM_CMD! install -g bower
  pushd "%DEPLOYMENT_TARGET%\public\libs"
  call :ExecuteCmd bower install
  IF !ERRORLEVEL! NEQ 0 goto error
  popd
)

Sources and references: http://www.nodebeginner.org/#javascript-and-you, http://kunkle.org/nodejs-explained-pres/#/example-http-server, http://howtonode.org/, http://nodejs.org/api/http.html#http_http

Sunday, 29 June 2014

Things that I wish I had known when I started out in the industry

I think there are some interesting things which I have learnt from my time as a developer. Some of them are nothing to do with code and some are very general but anyway, in no particular order this is my brief survival guide:

  • Ask, ask, ask - until everyone is sick of you, until your manager wants to gauge out you eyes with a blunt spoon. Its the only way. Especially when you join a company, sure they want you to contribute... but mostly they want you to learn without destroying their clients confidence in the software! The bottom line is: managers actually prefer to be hassled all the time even if they don't realise it yet!
  • Always, especially when you are very confident in code, add in try catches in appropriate places so that errors can be easily traced by you or other members of the team. In all fairness, I often find myself getting lazy with this sort of thing from day to day. When I have been away from back-end code and have had my head in CSS for sometime or I am deep in a large re-factor. But seriously, don't make your life difficult when code is released into the wild! Code which is silently failing is much more dangerous than code which is obviously broken.
  • When writing complicated business logic always unit test. It will save your bacon later down the line. When you find a bug, write a new unit test.
  • When writing unit tests always test from the lowest possible level up. If you are mocking loads and loads of objects, your code is probably too tightly coupled.
  • Communication with other team members. Lets face it we all say things on our CV like "I am a great communicator" and "I won the first prize in spelling when I was 12", OK less the second one, but the point is, we all think we can talk to other people when necessary and get our point across. However, what about all the extra things? such as an estimation on time or a report on a technical challenge that was overcome? As a major technical resource for your company, they need you to speak up on what is going on. Sure, you should have a manager that does this for you, but why not help him out a bit and do it yourself?

Sunday, 22 June 2014

Taking the plunge and starting a technology blog

I have finally got around to writing a blog, woop go me. I have joined the thousands of other technology geeks blogging about stuff that only other technology geeks care about. To be honest as a web developer in my professional life I can't help feeling a little grumpy when it comes to this kind of shameless self promotion.



However I am going to take the plunge anyway, in truth I am mostly going to use this blog to shame myself into writing more code. We can all learn from Jennifer Dewalt.