Category Archives: Uncategorized

Brownfield IoT in manufacturing – new blog post

Following on from Thingmonk last week, I’ve just published a blog post on the IBM Watson IoT blog about one of the growing focus areas within the manufacturing industry.

Let me know what you think.

Advertisements

Thingmonk 2016

I had great fun at Thingmonk 2016 yesterday over in Shoreditch. Even better, I had the chance to present a talk, so if you’re interested, I’ve put it up on Slideshare.

Enjoy!

 

Been a little while…but then not!

I realised the other day that it’s been a little while since I wrote here on this, my personal blog. Regular readers will remember my  last post was a personal one, about the sad demise of my running mojo. That story is long overdue an update, and I will write one (in case anyone’s interested how that ended up).

I haven’t, however, stopped putting my thoughts out there and whilst this blog has been relatively quiet recently, I’ve been quoted and writing elsewhere. It felt a bit grandiose creating a Press page, but I thought it’d be a good way of not losing what I’d been doing, and sharing for anyone who is interested.

Wearable Technology Show 2015

I was pleased to be asked to attend the Wearable Technology Show 2015 in London last week as both a panellist and as a speaker.

I used the occasion to share a point of view on the importance of design and human factors in the adoption of wearable applications. If you’re interested, I’ve posted the slides on Slideshare, and you can read a longhand version of the paper on the Crunchwear blog.

Simple database operations via HTTP with Node JS, MongoDB and Bluemix

In my previous posting I mentioned how I’d planned to harvest some of the useful fragments from a home project that might be useful to others. This time I thought I’d capture the simple mechanism I created to keep an audit database for my application using MongoDB running on Bluemix.

I opted for Mongo due to its simplicity and close integration with JavaScript — a perfect option for creating something quickly and easily to run in a Node JS environment. Mongo is a NoSQL database, meaning that you don’t have to define a specific schema for data, you simply store what you need as a JSON object in the form of key/value pairs. This means you can store and retrieve a wide variety of different data objects in the same database, and aren’t constrained by decisions made early on in the project if your needs change. Whilst it wasn’t a design point of mine, Mongo also is designed to scale too.

As described previously, I’m using the Node JS Web Starter boilerplate as my starting point. I’ve previously added the Twilio service, now to add Mongo, I simply select the MongoLab service from the Data Management set of services on Bluemix console, and add it to my application.

Screen Shot 2014-08-06 at 15.55.50When you create the MongoLab service for the app, Bluemix provides a link to the MongoLab admin page. The nice thing about MongoLab as a service provider is that it gives you nice user friendly tools for creating Collections, reviewing documents etc. I created a collection in there called easyFiddle using the web console.

Screen Shot 2014-08-06 at 16.01.55

Having configured the Mongo Collection, the next step is to make sure that the Mongo libraries are available to the Node JS environment. As with Twilio before, we simply make sure we have an entry in the package.json file.

{
   "name": "NodejsStarterApp",
   "version": "0.0.1",
   "description": "A sample nodejs app for BlueMix",
   "dependencies": {
      "mongodb": "1.4.6",
      "express": "3.4.7",
      "twilio": "^1.6.0",
      "jade": "1.1.4"
   },
   "engines": {
      "node": "0.10.26"
   },
   "repository": {}
}

Just as before, Bluemix will handle the installation of the packages for us when we push the updates to the server.

Within our code, we now need to instantiate the Mongo driver objects with the credentials generated by Bluemix for the MongoDB instance running in MongoLabs. Bluemix supplies the credentials for connection via the VCAP_SERVICES environment variable.

var services = JSON.parse(process.env.VCAP_SERVICES || "{}");
...
var mongo = services['mongolab'][0].credentials;

We will reference the mongo object to retrieve the credentials when we connect to the database.

As I did with Twilio, I am using a simple HTTP-based service that will in this case create an audit record in a database. I’m using Express again (as described previously), together with the same basic authentication scheme. My service works on HTTP GET requests to /audit with two query parameters device and event.

// Leave out the auth parameter if you're not using an 
// authentication scheme
app.get('/audit', auth, function(req, res) {
   var theDevice = req.param("device");
   var theEvent = req.param("event");

Now it’s a case of connecting to Mongo, and inserting a JSON object as a document to contain the two parameters.

   mongodb.MongoClient.connect(mongo.uri, function(err,db) {
      // We'd put error handling in here -- simply check if 
      // err is set to something
      var collection = db.collection('easyFiddle');
		
      var doc = {
         "device": theDevice, 
         "event": theEvent, 
         "date": new Date()
      };
		
      collection.insert(doc, {w:1}, function(err, result) {
         // Again, we'd put error handling in here
         res.json(doc);
      });			
   });
});

And that’s it. We can now create an audit entry using our browser if we choose, with a URL that looks like:

http://appname.mybluemix.net/audits?device=TEST&event=TESTING

I’ve added other services using the same method to variously query and delete all the records in the Collection. Whilst I’ll not include them all here, note that the syntax for deleting all the records in a collection is a bit non-obvious — the examples show you how to delete a record matching a given key/value pair, but are less clear on how to delete them all. You do so simply by supplying a null instead of a name/value pair the method call:

collection.remove(null, {w:1}, function(err, result) {
   // Error handling
   // ...
});

Note that the result variable will contain the number of records deleted.

Hopefully this posting has helped get you going anyway. A great resource to help you navigate your way around the Node JS API for Mongo can be found in the MongoDB documentation.

Tag cloud from Wordle

Over a cup of tea this morning I revisited wordle.net which an online resource for making tag clouds. One thing I noticed is you can supply a feed URL so in the interests of science, I pointed it at my current blog homepage. I was interested to compare the tag cloud created by tags with that generated from the free text itself.

You can find the full version on the wordle.net page, here’s the thumbnail:
Wordle: Martin Gale's Blog

Persisting custom attributes for an iWidget in IBM Mashup Center

In an earlier entry, I talked through a simple example of how to construct an iWidget for IBM Mashup Center. This afternoon I presented at the WebSphere User Group meeting at IBM Bedfont and was asked about the persistence of state in iWidgets, saving and loading and so on and so it seemed a sensible next step to augment the earlier sample to show how this is done.

ItemSets and attributes

As well as local instance variables inside the Dojo class, the iContext instance provides us with hooks into a standardised structure of instance-specific attributes. These attributes can be defined and set declaratively using the XML descriptor for the iWidget. To extend the earlier example, first modify the XML to contain the following element structure inside the <iw:iwidget> tag:

<iw:itemSet id="attributes" private="false" onItemSetChanged="itemSetChanged">
   <iw:item id="pollInterval" value="5" readOnly="false"/>
</iw:itemSet>

This will make the pollInterval property we coded earlier as an instance variable into a managed attribute inside an ItemSet. The iWidget specification defines the ItemSet data type (and ManagedItemSet sub-type) to describe a generic key-value pair data store for iWidgets. The iContext exposes to us the attributes as an ItemSet instance, with accompanying accessors to get, set and save changes to the values contained within it.

The next step, therefore, is to wire this logic into our existing Dojo class to exploit this feature. At the top of the onLoad method, add the following line:

this.pollInterval = this.iContext.getiWidgetAttributes().getItemValue("pollInterval");

This reads the currently saved (or indeed default) value for the given attribute, and populates our instance variable with the value.

Similarly, our routine to save changes to the iWidget now needs to update the attributes and save the changes so they can be persisted with this instance on the page. Add the following lines after the call to set the pollInterval instance variable in the saveParams method:

this.iContext.getiWidgetAttributes().setItemValue("pollInterval", this.pollInterval);
this.iContext.getiWidgetAttributes().save();

What you will now discover is when you modify the setting and save the page, when the page is reloaded, you will see the attribute load with the modified value.