It’s all about dynamics, really. When software becomes so dynamic that you see the data, then all that complex code will vanish into the background:
This is the transformation we saw a long time ago when going from teletype-based interaction to direct manipulation with the mouse, and the same is happening here: if the link between physical devices and the page shown on the web browser is immediate, then the checkboxes and indicators on the web page become essentially the same as the buttons and the LED’s. The software becomes invisible – as it should be!
That demo from a few days back really has that effect. And of course then networking kicks in to make this work anywhere, including tablets and mobile phones.
But why stop there? With Tcl, I have always enjoyed the fact that I can develop inside a running process, i.e. modify code on a live system – by simply reloading source files.
With JavaScript, although the mechanism works very differently, you can get similar benefits. When launching the Node.js based server, I use this command:
nodemon app.coffee
This not only launches a web server on port 3000 for use with a browser, it also starts watching the files in the current directory for changes. In combination with the logic of SocketStream, this leads to the following behavior during development:
- when I change a file such as
app.coffeeor any file inside theserver/directory, nodemon will stop and relaunch the server app, thus picking up all the changes – and SocketStream is smart enough to make all clients re-connect automatically - when changing a file anywhere inside the
clients/area, the server sends a special request via WebSockets for the clients, i.e. the web browser(s), to refresh themselves – again, this causes all client-side changes to be picked up - when changing CSS files (or rather, the Stylus files that generate it), the same happens, but in this case the browser state does not get lost – so you can instantly view the effects of twiddling with CSS
Let me stress that: the browser updates on each save, even if it’s not the front window!
The benefits for the development workflow are hard to overstate – it means that you can really build a full client-server application in small steps and immediately see what’s going on. If there is a problem, just insert some “console.log()” calls and watch the server-side (stdout) or client-side (browser console window).
There is one issue, in that browser state gets lost with client-side code changes (current contents of input boxes, button state, etc), but this can be overcome by moving more of this state into Redis, since the Redis “store” can just stay running in the background.
All in all, I’m totally blown away by what’s possible and within reach today, and by the way this type of software development can be done. Anywhere and by anyone.
Onwards!
Merry Christmas to all! And yep, I’m also blown away by this paradigm, and trying to keep up with learning all of this.
Given this environment, would json not be a better mechanism for encoding data once it leaves the little devices (in Bencode)?
I have a Jeenode like RFM12B receiver, with the LaCrosse IT+ changes added to the RF library, receiving data from a bunch of Jeenode and Conrad temperature sensors. This is connected (serially) to a little Linux board which receives that data and has a store and forward buffer where the data is kept if the real server (my web/mail etc server running on a larger linux box) is not available. Otherwise the data is inserted in the database where I have a Contao based application which allows me to add sensors, define them, graph the output etc.
I recently bought a Nodo (http://www.nodo-domotica.nl, Arduino based KAKU and IR receiver / transmitter) which is hooked up to a Raspberry Pi. On that I want to also get state info from the sensor network, and from the KAKU devices in a Redis store. On that I’d like to implement a Node.js user interface and rules / scripts for controlling the KAKU devices (e.g. if light low, and motion detected in the room, switch on lights).
What scares me most in those RADs is the security POV: all is beautiful and easy for “public” things. But think like if you’re hooking it to act as a “master switch” so you can turn off your whole house remotely… You wouldn’t like it if someone else would be able to turn it off when you’re working… Or that anybody could edit your databases. But maybe (well, really likely) it’s just me being ignorant… Still using PHP and C :)