PID algorithm for Node

This is a PID algorithm I'm working on for beerNode:

I got beerNode connected to my 1Wire controller this weekend. Gauges by Steel Series.

Don't optimize the code until you've optimized the algorithm

A co-worker pointed out an article regarding performance tuning for the JQuery DataTables this morning. The author goes through a lot of effort to improve the performance of a JQuery DataTable when adding 1000 rows. It's a valiant effort, and some good code is in there, but, there's a better way.

P. J. Plauger once wrote "Don't optimize the code until you've optimized the algorithm".

Truer words have not been spoken. I spent way too much time (a long time ago in a galaxy far far away) "optimizing" interrupt service routines into 8086 ASM code. I was convinced that a C compiler could not produce code that was as good as I could write - and I was correct. However, I was so caught up in being "right" that I was wrong. Sure, I could write better asm code than a C compiler, but, my asm code was doing the job all the "wrong" ways. My algorithm was flawed. I modified the algorithm, converted the asm code to C and the result was better performance (and a lot less bleeding).

This poor fellow above has fallen into that trap - he's trying to find a better way to stuff 1000 rows into the DOM. Don't waste time and effort trying to find a better way to stuff 1000 rows into the DOM - find a better way to NOT send 1000 rows to the browser! What's that better way you ask? Server side pagination, and it's built into DataTables:

Server-side pagination with DataTables

Certainly, there are situations where you need or want all the data at once, but those situations are typically rare. Think long and hard before you go loading 1000 records into your browser. Server side paging is almost always a win-win-win for viewing large datasets: less impact on the server, less bandwidth used (the data gets there faster) and the page load is faster, improving the user experience - especially on mobile devices.

Socket.io and flash sockets

Having trouble with supporting flash sockets on port 843 in Socket.io? Are you doing this?

io.set('flash policy server', true);
io.set('flash policy port', 843);

That turns on flash socket support, but on port 10843! The call to

io.set('flash policy server', true);

actually starts the server - on the default port of 10843. The next line of code that sets the flash policy port to 843? It has no effect.

Do this instead:

io.set('flash policy port', 843);
io.set('flash policy server', true);

or better yet:

io.set('flash policy port', 843);

which will set the port and turn on the flash policy server.

Connecting Socket.io to Backbone.js

I've been messing around with Backbone.js recently, and as a learning project I started work on the beerNode client this past weekend. One of the problems that needed to be solved is how to "connect" socket.io events to the Backbone model for that device. Backbone has a very nice event mechanism that connects models to views, but there is no mechanism (that I know of) to send an event to all models in a collection.

I solved that problem as such:

• Create a global object that is extended from Backbone.Events
• Add that object to the Backbone.Model prototype
• During model init, listen to 'change' events from the global event object
• When a device status update comes in, trigger the global object with the device object. The models will get the event and will check if the event is for the device being controlled.

Create the global event aggregator, assign it to the Backbone.Model prototype and listen for io events:

A device status update has come in from our socket.io server - trigger the global object, passing the device object as the parameter:

Done. Socket.io events are are now distributed to the various Backbone models without any direct coupling. Perfect.