As a bit of background I work in a small specialist printing company in Sheffield, UK. My projects have ranged from basic design and implementation of static html sites to eCommerce systems incorporating custom image generation and internal systems which integrate with production software. Most of my work is in PHP, Mysql and javascript, although I always try to use the best tools for the project at the time.
Me when I started
I don’t normally write posts about myself as usually they’d not be very profound, however I feel that after my one year anniversary of my getting my first real job as a web developer after leaving university (though not my first job) I have some worthwhile experiences to share. Some of them are just good practice that any decent developer will alredy follow and some are more general observations:
At this point there was going to be a paragraph for each…then half way through writing it I realised nobody would read it all so I’ve summarised it (even now I’ll be lucky!):
My previous example Node.js, MQTT and Websockets showed the use of a websocket to broadcast messages from a subscribed MQTT topic, however the topic was hard coded and the messages broadcast to all who connected. The example below uses the same client side script to connect but allows the MQTT topic to be specified in the URL and only broadcasts to the individual client. Now to subscribe to a topic “test” the websocket address would be ws://<ip>/test. Read more ▼
For a while I’ve been looking at how to bridge the MQTT protocol and websockets to make it easier to build web applications using data broadcast in MQTT streams. In the past I used python and mod_pywebsocket along with mosquitto python libraries however this was cumbersome and difficult to install. Here I present a simple solution using node.js to interact with mosquitto MQTT clients. Node.js lends itself to working well with messaging systems like MQTT and websockets due to its event driven nature. I’m also in love with node.js at the moment!
This is much simpler than previous attempts and I put the initial test together in less than ten minutes.
Prerequisites
Obviously you’ll need to have node.js and mosquitto installed and also the node library node-websocket-server (which can easily be installed using npm). All my work was tested under ubuntu but there is no reason why it wouldn’t work on OSX or even cygwin. To test you’ll need a websocket compatible browser such as recent versions of chrome.
System Structure
mosquitto_pub and mosquitto_sub are command line MQTT clients supplied with the mosquitto MQTT broker, here mosquitto_sub will be called using node.js as child processes, events are generated on output from the process. The data is then captured and broadcast over a websocket. In this case a simple jquery page is used to display the broadcast messages but in a real application there would be more client side processing to make a useful application.
Just over a year when the chromiumOS code was first released I spent a while compiling it and experimenting and posted my opinions
I made a few basic points:
Little wifi hardware support
Requires a DHCP network
Quick boot time (~10s)
It’s just like Google chrome and nothing else
A few weeks ago @popey mentioned on twitter he was compiling it and this inspired me to have another go with it. In this post I intend to see if things have moved on.
I did read others but they were mostly boring and I can’t remember specific things to say about them.
Since buying Introducing HTML5 by @brucel and @rem I’ve been promising myself I’d write some kind of opinion on it. Now, a few months later, I’ve got another two related books I have read and like so now’s probably the time to write this post before I forget.
This post has become a bit of a mammoth post, it’s been in my drafts folder for over two months, but I’ve finally found the time to finish it, so here we go:
Currently no browser I’ve come across on android has support for websockets. As an android user I found it a bit annoying that iOS now has support built in, so after a bit of hunting I found that this is an active area of development for fennec (firefox) – the code however hasn’t made it into the main repository and is still held as patch files in the bug report. I also have a project lined up that I need mobile websockets support for so I’ve very grateful to the developers working on this.
Now after much blood sweat and tears I managed to patch the current source pulled from the mozilla repository and compile a version of fennec for android. I’m not a fan of mixing patches and version control but I can see why they do it…However while I found this a great hassle, due to my relative unfamiliarity with patching and resolving merge conflicts, I did think to myself how much better it is to be able to quickly compile and deploy an app without having to pay or go through any arcane systems required for the iphone.
I’ve made the compiled binary available for download below and it’s completely without warranty or guarantees it will work. It works for me on my HTC Desire Z (G2 for Americans!) and should work on other ARM7 devices. I may try and compile a version for ARM5/6 tonight. This is a cutting edge development build and will crash, especially if you try to rotate the screen…but after my brief testing websockets appear to work.
The first thing that struck me was the burnt flux on the main chip:
Then I noticed staining on around the caps too, nothing that affects the functionality of the unit but it left me feeling disappointed. This arduino cost me £57 + shipping + a new ethernet shield to use with it (which is incidentally, absolutely perfectly manufactured and really shows up the mega). My board also had sharp bits on but I filed them off. I paid a premium price to get what I thought was a premium quality product, clearly I was wrong and will think twice before buying any official arduino hardware again.
And don’t even get me started on releasing the boards before there was linux support. At first I thought I had faulty hardware after seeing it and then it not working.
I should state that this post is only applicable to the arduino 0019 IDE version and later versions should solve issues here, however at the time of writing such versions have not been released.
Today I was happy to take delivery of one of the first new arduino megas which utilise the atmega2560 and replace the ftdi chip with a more versatile ATMEGA 8U2. The websocket server I’ve been writing is getting a bit heavy for the arduino duemilanove I used up to now at around 20kb so I decided it was time to upgrade. However I had failed to notice that a version of the arduino IDE (0020) had not been released for Linux at the same time as the hardware. This was a bit of an oversight on my part but I think it was a bit silly of the arduino team to release the hardware without mentioning it.
In this post I intend to briefly outline things I’ve tried that can make it work at least a bit…
After I had problems with my sheevaplug power supply I had lost faith in the device and didn’t trust it to survive being on 24/7 without exploding/setting on fire etc… so after NewIT kindly fixed it I sold it. This left me with no server to mess with so I decided to try and build a new one – the two primary requirements being that it used as little power as possible (ideally around 10W – the same as my sheevaplug with hd and usb hub) and was totally silent. In this post I’ll describe what I came up with.
After consultation with the original developer of the only existing Arduino (@razorbeans) websockets library I have forked the project to allow me to take over maintenance. Over the coming weeks and months I intend to:
Migrate the library to use the new bundled string library rather than the WString library (mostly done)
Tidy up the code
Add functions for onconnect, onmessage and allow sending of strings at a time determined by the Arduino, not just in response to a message from the client.
Update the library to allow recent browsers to connect. Currently the library supports the version 75 handshake protocol but most browsers have now moved to the more recent 76 protocol..
The project is available to download on Github currently this will only work with versions of Google chrome before 6.0.414.0 but this will hopefully change soon as the handshake is updated.
