Game on for Fabric Composer


Earlier in the week I was pondering some blockchain gamification with @howard_is, inspired by a recent GameOn challenge for early professionals in IBM. After helping out with a run through of the IBM InterConnect Fabric Composer lab this morning, it seemed like a good opportunity to make a start.

BlueBlockAlone

Instead of running yet another car auction, I think it could be fun to have a demo based on a ‘business’ network for playing games. To keep some similar elements to the more common trading examples, I’m currently wondering if keeping tabs on multi-player adventure games would work. This is the model I’ve come up with so far, and it seems like something that could be hooked up to a simple text based (powered by Watson Conversation of course!) or graphical game interface.

If you’re interested in playing with your own blockchain network, fire up the Fabric Composer Playground and have a go. If you want to know more @danielselman will be at InterConnect next week, or get in touch with the community. Better yet, join in!

Advertisements

Watson Conversation System Entities


The Watson Conversation service now includes built-in support for a few new entities. These system entities make it much simpler to identify numbers, currency values or percentages in a conversation.

The only slight gotcha is that system entities are not enabled by default. I would definitely recommend enabling all the system entities when you create a new workspace- there’s no downside and you’ll start seeing what system entities will be matched in the try out panel. (It’s also worth checking for new system entities when you make any changes to an existing workspace!)

system-entities-screen

I’ve recorded a quick demo on YouTube if you want to see system entities in action, and there’s a demo workspace in the conversation-starter project on GitHub.

A little more conversation


More than a year seems to have vanished somewhere since I left MDM for new adventures with Watson. It’s even been a few months since the new Conversation service first appeared on Bluemix, along with the tools I’ve been helping to build.

If you’re interested in Watson Conversation, or just curious about what I’ve been up to for the last year, these are a few blog posts which I’ve come across which explain everything better than I could:

This thing seems pretty popular, so there are videos too!

 

There are even a few GitHub repositories:

And of course, tweets

If that’s not enough, you can ask questions on Stack Overflow and dw Answers, or join the Watson Developer Community.

If you’re building something with Watson Conversation, I’d love to hear about it! And finally, if you have any tips or tricks that you could share, I’m trying to collect some for a conversation-starter project on GitHub.

Updated: lots more links!

 

Build it and they will come


sarflondondunc-battery-brick

Somehow I have spent way too much of my time over the last year on efforts to replace the build tools on projects that already have working builds.

Photo © Duncan Rimmer (CC BY-NC-ND 2.0)

Granted the builds had/have problems, as most do, but for some reason the ‘solution’ always seems to be to move to the new shinny build technology of the week, without really focusing on what that’s meant to improve even at a technical level, yet alone from an end user/business perspective. You may as well be arguing about tabs vs 2/4 spaces.

The latest fun build technology adventure has been to switch from Grunt to Gulp. (If you’re fortunate enough not to have heard of either, you may think I’ve changed the names to protect the innocent but no, Grunt and Gulp are both real tools to help automate build tasks.)

If it was up to me, I would probably avoid using Grunt or Gulp completely:

It’s not up to me though, so here are a few early observations about Gulp:

  • It seems to have a few issues with error handling, although gulp-plumber has helped
  • More worryingly, Gulp appears to have a tendency to hang, which doesn’t seem ideal from an integration point of view
  • A lot of the examples I found did things ‘the wrong way’
    (There’s a plugin blacklist and I’ve found a few strongish views on how not to do things in Gulp, just less concrete examples on what the right way is so far)
  • There are some useful recipes to get you started
  • It’s not really any better or worse than Grunt, just different
    (Not that I’ve spent that much time with Grunt)

Given there’s almost no chance of making everyone happy with the choice of build tools, I would just leave the decision to whoever creates a new project, hopefully taking in to account ease of development and continuous delivery, and then leave it alone.

If you really think you want to change from Grunt to Gulp, or between any other build technologies, don’t do it. No, really, it’s a waste of time. You’re thinking about trying Broccoli now aren’t you? Or Brunch? (Really, I’m not making these names up!) Why don’t you switch off your computer and go out and do something less pointless instead? If you really can’t stop yourself, at least buy everyone on the team lunch first.

Why doesn’t Eclipse/Installation Manager work on Linux?


For the next time I’m grumbling about yet more incompatibilities causing problems with Eclipse on Linux, adding the following properties to the bottom of the launcher configuration file seems to help:

-Dorg.eclipse.swt.internal.gtk.useCairo=false
-Dorg.eclipse.swt.internal.gtk.cairoGraphics=false

For example, edit the install.ini file for Installation Manager, which is where I first encountered problems after updating Red Hat Enterprise Linux last year. The problem appears to be due to incompatible GTK and Cairo versions, and there’s a related IBM technote for Installation Manager on RHEL 6.6.

Unfortunately, while that was enough to get Installation Manager working, the Eclipse IDE still seems somewhat unstable. I been exporting the following environment variable for a while but, based on the SDK Known Issues wiki page, maybe that doesn’t make any difference with recent versions:

export GDK_NATIVE_WINDOWS=true

Another suggestion I’ve seen recently, related to tooltips, is to export another environment variable, although so far I haven’t tried it:

export GRE_HOME=/dev/null

Need to experiment a bit more with those last two, and see if I can narrow down whether there are any other real problems.

Hadoop as a service


It’s been a fun year learning new stuff, and along the way Andy Piper helped out with a bite sized architectural debate while I was experimenting with a Hadoop service on Bluemix. Having a short lived/disposable memory I thought it would be worth posting the discussion here for future reference…

‏@jtonline: Still pondering how a hadoop buildpack might compare to a hadoop service

@andypiper: @jtonline why would you want a buildpack for Hadoop – surely data store = service (broadly) not runtime. #cloudfoundry

@jtonline: @andypiper hmm, maybe, but you want to bring the processing to the data don’t you? Currently seems like services will hold big data in silos

@jtonline: @andypiper for example, I might want to use one of the address verification services from my map reduce job. I’m probably missing something.

@andypiper: @jtonline multiple services can be bound to multiple apps. And you can call jobs in those services from those apps.

@andypiper: @jtonline PivotalHD ships as a service in PivotalCF – obviously you may need data access libraries in the buildpack for the app.

@jtonline: @andypiper not convinced hadoop is just a data store. Do I need apps on runtime to kick off oozie jobs with details of other services?

@andypiper: @jtonline the runtime/service debate on CF has been a long one but I think fairly clean/clear. I’d see Hadoop as a shared resource.

@andypiper: @jtonline bear in mind buildpack -> droplet -> runnable containerised app instance.

@jtonline: @andypiper agreed. Maybe what I’m missing is an easy way to wire services together?

@andypiper: @jtonline yeah maybe – you end up with apps acting as service coordinators I guess.

@andypiper: @jtonline coupled with the fact that apps are intentionally short-lived and best stateless… interesting architectural debate :-)

@andypiper: @jtonline (for “short-lived” read “disposable” my bad)

It should be an interesting 2015.

BigInsights Quicker Start


I’ve been taking a break from Liberty and JAX-RS recently to start tinkering with IBM’s BigInsights Hadoop distribution. To make things easier/more interesting my first attempts were using the Analytics for Hadoop service on BlueMix. In case it helps anyone, here’s what I ended up with before needing to install BigInsights myself:

And this is the script I used to upload data in the video (unfortunately I didn’t have any luck using the HttpFS API):

#!/bin/sh

BIUSER=biblumix
BIPASSWORD=password
BIURI=https://hostname:8443/data/controller/dfs

curl -iv –user ${BIUSER}:${BIPASSWORD} –insecure -X POST “${BIURI}/user/${BIUSER}/sample-data?isfile=false”

curl -iv –user ${BIUSER}:${BIPASSWORD} –insecure -X POST “${BIURI}/user/${BIUSER}/sample-data/orgdata.unl” –header “Content-Type:application/octet-stream” –header “Transfer-Encoding:chunked” -T “orgdata.unl”

curl -iv –user ${BIUSER}:${BIPASSWORD} –insecure -X POST “${BIURI}/user/${BIUSER}/sample-data/persondata.unl” –header “Content-Type:application/octet-stream” –header “Transfer-Encoding:chunked” -T “persondata.unl”

Notes:

  • since recording the demo Bluemix has added a United Kingdom region, however it looks like the Analytics for Hadoop service is currently only available on the US South region.
  • there is also now a BigInsights service on Bluemix which allows you to provision multi-node Hadoop clusters.