For all my day to day development work, be it in php, html, js and even when I branch out into Java or C/C++, I use Netbeans as my IDE of choice. I first got into it when coding Java at university but since then I’ve moved into mainly working on PHP web apps and it has proved to be, in my opinion, the best PHP IDE available. In this post I’m going to highlight a couple of customisations I’ve made to make it’s use easier.
For the past couple of years I’ve used Netbeans on Ubuntu, previously I used Visual Studio on Windows but then I was developing C++ Applications. When I moved to Ubuntu I looked for a new IDE to patronise, I’ve never really got on with VIM or emacs.
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.
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.
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.
It seems finally we may be freed from the unstable shakiness which is embodied in PHP_SAM – the only PHP based MQTT client….until now.
Project SAM is a PHP library for several different pubsub messaging systems, one being MQTT. However it suffers from a very restrictive licence, a lack of maintenance and quite a few bugs. Previously there was no choice if you wished to use MQTT and PHP, now Andrew Milsted (@bluerhinos) has started to produce an alternative: phpMQTT
phpMQTT is only in infancy at the moment and currently only publishing is fully functional, with some bugs to be ironed out of subscriptions, however for anyone who has used PHP_SAM it provides a refreshingly easy way to start using MQTT – consisting of just one file and a handful of simple functions. An example of publishing a message (written by Andrew Milsted) is shown below:
In this post I will show the latest in a line of mini examples using html5 and websockets – an example of how future home monitoring dashboards should be created. At present they commonly use a combination of flash dials and JavaScript canvasy bits and pieces to create representations of data obtained via ajax. This has the inherent disadvantage that the browser polls the server rather than the server pushing values to the browser when available. Also there is very little in the way of accessibility as far as canvas and flash are concerned. In this post I will show a simple example of using data via a web socket and displays it via the meter.
While nothing demonstrated here is rocket science it’s something that’s not being focused on enough, developers seem to be getting lost in the shinyness of the canvas and forgetting the built in meter functionality along with it’s inbuilt accessibility. Having said all that it is only displayed by the more bleeding edge browsers and things may pick up as the html spec matures.
UPDATE: I have now isolated the problems to 64 bit linux, the setup described here does work without using the standalone web server and using apache…just not on my main system!
Following on from my experiences installing and testing pywebsocket I now move to the main reason why I bothered…to create a bridge to allow a user to view a web page showing a live stream of MQTT messages.
It should be noted that despite making the effort to setup pywebocket with Apache this time I will be using the standalone web/websocket server provided with pywebsocket (standalone.py) as I’m still trying to debug why this code doesn’t work with apache!
