Exciting times for node.js and websockets.
The 1.0 release of socket.io is out and its looking good. I blogged back in 2013, wondering what was happening with socket.io as it was looking very quiet, but thats all in the past and socket.io is back with a vengeance.
Check it out on the socket.io site
I’ve just been setting up the blog for Big5 Boutique
I thought I’d share the useful sources of info I found to do this:
I set up the WordPress blog under the /blog/ subdirectory of the main Rails app and set up the rack-reverse-proxy to serve up the blog. Two issues to be aware of:
- Rack Deflater wasn’t able to serve up the WordPress css files.
- The WordPress visual editor gets disabled because WordPress tries to sniff the user agent but since the requests are reverse proxied, the browsers user agent isn’t coming through. Thankfully this blog article explains why this is happening and how to fix it.
Last Friday we pushed Big5 Boutique live. We want to make the whole process of booking safaris much simpler and we are very excited about everything we’re going to be building over the next few months. Please do check it out
Exciting days for the B5B team!
We’ve got the beta version of Big5 Boutique up at our staging url, http://big5boutique.herokuapp.com
We’re not quite ready to launch yet but we’re getting close. Next step to start learning about SEO.. Its quite the rabbit hole to go down.
Integration with Peach Payments has been going well but they still don’t have any code samples for integration using Node.js
In my previous post I showed how you can get the URL for an iFrame point at their Web Payment Frontend. You can use that to allow your customers to store their cards with Peach Payments. Once you’ve done that and got a unique id for the stored card its pretty easy to do single click transactions using their POST interface.
Heres a snippet showing how to do it from Node.Js
I’ve been writing some code to integrate to Peach Payments. They’re a great payment provider for developing markets. Unfortunately their API documentation is missing details on how to retrieve the url for their WPF integration using node.js
So here is a simple code snippet showing how you can retrieve a WPF url using Node.js. I find it a bit easier to grok than their PHP example.
I was recently reading this blog post about the dangers of using the bodyParser middleware in the Express server. This warning is actually echoed in the Express guide. The problem basically boils down to the fact that bodyParser creates a temp file on your server for every request leaving you wide open to a DDOS attack. Get the details from the article though.
I was interested to see that the getting started guide for Passportjs actually uses suggests the use of the bodyParser middleware. This is quite possibly the de-facto authentication solution for Node.js app which means there might be a lot of vulnerable apps out there.
Luckily for me the solution was easy. I’m using the local authentication strategy and was able to replace my call to app.use(express.bodyParser()); with app.use(express.urlencoded());
I’ve been trying to find information on whether nodejitsu supports PhantomJS or not.
The short answer as of 04/Oct/2013 is NO.😦
If you try to access phantomjs from your node app, you will find that it is not installed.
If you try to install it using the phantomjs npm module, then you get a 500 error when you try to deploy your app.
However, Modulus.io seem to support PhantomJS according to this article so I’ll give that a go.
I’m still getting to grips with MongoDB and Node.js.
Update: 25/07/2013 : The solution described below does not work with RC6 .. You will need to get ember-latest.
Are you finding that errors occurring in your promise handlers are being swallowed silently by Ember.js ? I had written some code that looked like this:
The problem was that I was calling this.getXXX while in the scope of the then() function, which is globally scoped. This was easily fixed by passing a reference to controller scope, but normally these kind of mistakes are logged to the console.
Turns out the then() callback function was being executed by Ember.js in a try/catch block, with the error being passed to the default reject handler which was swallowing the error.
Luckily @teddyzeenny was in the IRC channel to offer some advice. Heres a code snippet that you can add to your Ember.js application to make sure these errors get logged to the console.