In order to save a few bucks on a domain name and a hosting service (blackholelogic.com) and to show support for one of my favorite web services I’m moving my blog, in earnest, over to Github pages.

It isn’t really about the money, seriously. Mephisto, the framework that BHL sits on is dating, rapidly and I will not use WordPress, or any of the blog hosts like Blogger. I’d used Github pages to host a professional blog for a bit, and that’s now past. It came down to using Github or a simple site at Heroku. Since I’m also a brewing Git fan I figure why no the former. Having the blog hosted was also starting to make me nervous as I wasn’t really sure how it was backed up, if at all. By using Git/Github the archive is naturally built-in.

There’s a few things that are missing from the Jekyll-based environment at Github – which I hope to leech from someone else, or dev myself pretty soon. Tag/category support will be pretty high on the list. We’ll see.

So long Black:Hole:Logic – hello http://kitplummer.github.com – see you on the other side.

Well, my holiday-break project took a bit longer than I thought. As usual, it was a bit more involved that I really expected. Here’s the list of players:

• Pachube – a catalog of sensors and their data with an nice RESTful API
• Gumstix Verdex Pro – very small 600MHz XScale computer modules
• Go!Temp – USB temp probe

A couple of caveats to this story. First, I’ve already been working with Ruby on my Gumstix so knew going in I was going to have to due some yak shaving. But, I already have Rubygems installed and a slew of required gems. Second, I am normally working with Phidgets connected to the Gumstix. But, I wanted to get the Go!Temp sensor working for a few different projects.

I already had a Ruby script that could get the temp from the Go!Temp on Linux:

So, first was getting the temp from the Go!Temp on the Gumstix. Big problem, stock system build doesn’t include the ldusb driver. So, I had get an OpenEmbedded build environment setup, and the kernel to compile the ldusb driver. Ugh. Too many details so if you want the driver here ya go – just insmod it to install. With the ldusb driver installed, I was able to successfully test the gotemp.rb ruby script above.

Now on to the Pachube API. I had to send an email to get an invite code. Once received it was only a few minutes before I could start hitting the RESTful API with curl.

There’s two basic options for getting data to your sensor data feed. You can either submit data by using HTTP PUTs to your feed. Or, you can setup Pachube to get the data from the device itself. Because my device is sitting behind my firewall, and connected to my wifi network I’ll push up my info.

I figured this was a great opportunity to create a spiffy Ruby library for access the Pachube API as there really wasn’t anything complete for the RESTful interfaces. I also was looking for an opportunity to dig into HTTParty a bit. Since Pachube expects either CSV or EEML, their chosen schema. Since EEML comes with a nice XSD I could use Ruby’s xsd2ruby tool to convert the schema to Ruby objects and use the built-in marshalling capabilities. It didn’t take very long before I’d had my fill of that mess. I did have a fall-back plan in the eeml-ruby library.

I did spend a bit of time in the middle of this project updating the eeml-ruby to be a bit more complete in its ability to generate EEML objects from EEML XML. The resulting Pachube library, pachuber, is still in a rough state, but works for getting a feed, or updating one.

Here’s my simple posting script:

I just added a simple cron job to update the temp reading once an hour.

The feed is here at Pachube

Here’s the recent history:

It is also possible to get a simple Flash graph, or set triggers on various conditions, from the feed’s web UI.

So now what? I haven’t quite figured out how to consume other Pachube feeds for a nice mashup. But, I’m planning on adding more sensors. Perhaps an anemometer?

Well, it’s that time of the year ago…my home automation spirit kicks in, and the robot pieces come out of the closet.

It started with a rebuild of my dev environment. Said to say that the Gumstix docs still suck. I was able to get my dev enviro, based on Ubuntu 9.10, with the help of the mailing list.

Then it was installing the Linux drivers for the Phidget SDK. They installed no problem, but I couldn’t get the drivers to actually load when I installed a device. I figured something was missing around udev. Sure enough…just needed to set udev up.

$ sudo cp udev/99-phidgets.rules /etc/udev/rules.d/

and

$ sudo /etc/init.d/udev restart

The I ran both the example manager and the Servo Test that comes with the standardC examples SDK.

I was also able to get a version of the Phidgets SDK to compile against my OpenEmbedded Gumstix enviro. The Bitbake recipe is here – maybe somebody will find it and run.

I’ve recently been toying with Semantic stuff and MediaWiki. Unfortunately, due to a few constraints I probably won’t have the luxury of sitting on top of an Ubuntu server platform – requiring a more “approved” OS. RHEL 5.x currently meets the my requirements. So, after creating a new VMware can with the RHEL 5.2 Server install I begun the process.

Fortunately, and somewhat to my surprise it was quite easy, and yet Google revealed very little to let me think otherwise. In fact the only recent docs/posts I found would’ve had me building and installing from source – the xAMP pieces. Ugh.

The good news is that Yum support prevents all of that. But, better yet the ‘Add Software’ menu option made it even easier/intuitive. With the “Package Manager” opened you can browse the Servers section – and select MySQL Database and Web Server. That’ll get the xAMx part. I did have to hit “Apply” here.

Once those are set up and in place I then did a search for ‘php mysql’ and installed the latest of both the ‘php’ and ‘php-mysql’ packages. Clicked “Apply” and that’s good.

I did configure both Apache (httpd) and MySQL to start automatically using ‘chkconfig’.

To get MediaWiki install I simple downloaded the latest tarball and exploded it in the /var/www directory structure. Then it was a simple edit of the httpd.conf setting the DocumentRoot to /var/www/mediawiki (which is what I exploded the tarball as).

I did have to set MySQL’s root password manually too.

That’s it. Not quite ‘sudo apt-get install mediawiki’ – but who cares, and I’m on the latest MediaWiki not 1.13.x.

Here’s the snippet. I’m sure if you’re interested you can follow the ‘require’ statements to the source. Questions? Fire away? Or, fork the gist and go.

The debate as to the relativity of “Community” of Open Source is a continuum, ad nauseum. From early ‘06 this article addresses many of intricacies – especially the relationship(s) between open-source and proprietary systems. More recently the “issues” associated with freeloading have raised another level of questions. Freeloading is nothing new. We all do it is some way or another. Matt Asay, confirms “John Mark Walker’s beliefs on community and Zen.

But, do you need a practical example of why community is so very necessary? First, one very keen data point here: inevitably almost ALL software will have some relationship to Open Source, but most likely a direct one, via an embedded dependency. Open Source is about abstractions and reuse, a sort of pyramind compounding. Open Source projects innovate by freely aggregating other’s innovation. This isn’t a linear progression. It is very similar to the power of social networking and crowdsourcing if not a direct relationship itself (GitHub knows this). So, here’s the revelation. There’s a inherent NEED for community…and the Grails crew have realized that it is virtually impossible to manage the embedded stream of dependencies on one side of the fence – as Marc Palmer very well points out – and asks for help. If there’s one way to “seduce” a community – it is to ask for help. The ’’‘Real Power’’’ of the OSS community is how we respond to these pleas.

Going to try and keep this one brief, and it is going to be difficult. So…I have to instantly break a few things up. But, let me start with a teaser.

Innovation, in the Kit Plummer dictionary, is defined as the collection of ideas which aggregate and compound to solve problems, inherently, without necessary a priori knowledge of the problem. Ok, so given my not-so profound definition here it is easy to arrive at the idea, each individual idea, as the catalyst for innovation. Almost needless to say, without ideas – no innovation. (Here’s Princeton’s definition of innovation too.)

My current project, so dubbed the Battle Command Innovation Platform (BCIP), is attempting to bring many of the commonly found innovation tools found in the software/IT world to the U.S. Army (CERDEC COBRA). The ultimate objective is to allow the warfighters to solve their problems and host their own solutions. Imagine Amazon Web Service + Google’s AppEngine + GitHub + domain-specific languages (DSLs) + management, training and support delivered to those with the information problems at hand. Imagine four levels of complexity: full OS-level virtual machines (EC2), language-specific application framework(s) (AppEngine), traditional LAMP site-level hosting, and DSL-based wizard-driven applications. Add in to the mix, web-based API data services to front traditional stove-piped systems of records – and Voila you get the concept that is BCIP.

There are a few key attributes of BCIP that drive the whole conceptual premise. First, is the notion of “composable” apps. Yes, that composable – the software holy grail where applications can be built from lego-like blocks of functionality. But, also (and at the risk of biting the buzzbar) mashable applications where pieces of data are aggregated visually to produce new data. And, to some degree the ability to tap into existing infrastructure apps, documents and data. Secondly, and not without debate, is the idea of community. Yes, the meritocratic behavior that is sought after by hackers, projects and commercial entities alike. But, not necessarily the same kind of community as in the Open Source world. Within BCIP’s ecosystem, the community is the really only scope by the problem domain. The only membership requirement is that one has identified a problem and also is empowered to resolve it.

The end result is emergent innovation. The kind of innovation that comes from the people closest to the problems solving their problems, and sharing the solution with everyone across the enterprise. It doesn’t end with the first solution. How often have you found that somebody else has a very similar problem? By remixing (a process of changing inputs, but not functionality) your solution they now solved their problem. Compound solutions. With a solid community infrastructure the potential for recycling (a process of changing a simple piece of functionality and creating a new app) enters the fray. More compound solutions.

Ok, how’s that for a scratch? Now consider things like my employer, Accenture National Security Services, Forge.mil, and a mad dash to demonstrate the concept. It should be fun, it has been so far. I’m currently a one-man show wearing the Solution Owner, Scrum Master, QA, Biz Dev and team hats – all at the same time (yes we’re Agile). I am getting some help from some very smart people – they’ll get their due in future posts. Right now I’m working with GeoServer, OpenLayers, Tomcat, Groovy and Grails, Openfire XMPP server, Ubuntu”:http://www.ubuntu.com, Eucalyptus, AppScale, Amazon Web Services, a little bit of that, a little bit of this and GitHub:FI (Thanks Milo and Chris for getting us going).

Some of you might just be asking – do warfighters really code? Yes, yes they do. More on Carlos Castillo and Paul Lin’s COIN and intentional emergence story to come too (though Jim, my boss, has pretty much nailed it).

Really just testing the gist ‘embed’ feature. But, figured I shared a couple of things here:

Unfortunately, it appears that gist doesn’t support syntax highlighting for Groovy (real bummer). Hidden in my Groovy script there is a closure-based Java Interface implementation. By declaring the closure “as PacketExtension” I’m able to really simply do some cool XML magic on XMPP messages.

More to come here…as I’ll need to consume that sucka via an ExtensionProvider (me thinks).

Was having problems getting GEOSERVER_DATA_DIR to take using the normal environment variable are WEB-INF/web.xml tricks for the Mac installer version of GeoServer. Ultimately had to set it using the JVM options in the GeoServer.app’s Info.plist. Works great now. Pretty cool, and the little window showing the server out is cool. All made possible by Jetty…very nice.

So, I recently created a new project based on Grails 1.1, which I needed wrap with Maven. Grails 1.1 IS ready for prime time. With the maven-grails-plugin I was able to simply call ‘mvn install’ from my Hudson CI environment – even with no Grails 1.1 installation on the CI server. Very, very cool. Great work from the Grails camp!

[Note: I had to backtrack on my previous post…sorry.]

As the Netbook market continues to evolve – so has the technical specifications that drive the smaller form-factors and architectures. I actually don’t believe that ARM has any place in the Netbook market.

Here’s why. I spend a considerable amount of time developing for the Gumstix platform. The Gumstix runs OpenEmbedded, a cross-compile environment for many embedded processors – most notably, the ARM family. Without going into great detail ARM != x86 (Intel stuff). The cross-compile dance is required to build all the Linux pieces specifically for the ARM architecture on a (normally) x86-based machine. While OpenEmbedded supports many of the pieces, that normally doesn’t cut it. If it is not a supported package the process (project creation, make manipulation and cross-compiling) is just gross. Now, coming from an embedded background I’m used to that. The Linux community in general is not. I can’t speak for the Winders folks, but guessing not. :)

Sure, the ARM platform will get you lower power consumption/longer battery life. But, at the cost of CPU/RAM resources, and the above mentioned architecture mess.

To be honest I’m not sure the ARM even has a place is micro devices like the Gumstix.

The fit-PC2 shows just how close we could be from a form-factor perspective to the Gumstix with an Atom-based(x86) processor and 1GB of RAM. Shoot, just get rid of the connectors and we’re damn close.

The fit-PC2 runs a full-blown Ubuntu environment, which means no cross-compiling.

The downside is that the fit-PC2 requires 12V and consumes ~6W. For many applications that may just work…leaving the door open for the ARM platform. But, I just have to wonder how long before we see 1+GHz Atom-based platform running off of 3.3-5v at 1-2W. Lights out ARM.

But, the ARM fights back. The BeagleBoard an almost viral phenomenon parented by TI is proving that the ARM is a valid, general purpose platform.

Again, I’m waiting with intense curiosity…I have to believe Intel is hard at work (probably with Apple’s interest in mind) on a super low-power high-performance processor that will bridge the gap and extinguish the need for cross-compiling.

All this stuff said, I do understand the deltas between the truly embedded architectures. I’m just a software engineer who appreciates the OS and application side of things and really want to see a simpler means for eliminating the void between desktop and mobile platforms.

After way too much time spent by me and a PGP support guy I finally came to the conclusion that GoDaddy was mucking with the SMTP side of things – to the point where I couldn’t send an encrypted email. I’m already a tad bit disgusted with GoDaddy’s “Girls Gone Wild” marketing slant. So, this new revelation that there is some inherent need to not allow me to send encrypted emails is a bid awkward. Remember just because you may being using SSL to send mail, it is only SSL’ed/encrypted between you and their relay. (I could be wrong here, and it wouldn’t be the first time – but, I’m just too lazy to find out. Plus I’d like to think there is more to me wanting to leave GoDaddy besides their sleeziness.) The problem is that the PGP Desktop/email proxy wasn’t able to do its thing based on the email configuration. I happen to be on a Mac and using Apple Mail, which at first I was willing to drop the blame on. But, after switching to a new provider the PGP Desktop client configure everything transparently with no issues. It did do a number on my Gmail configuration – disabling TLS there. But, all I had to do was turn it back on, and disable the PGP auto-configure option.

So…if you are hoping you’ll be able to sign and encrypt emails for a domain hosted through GoDaddy – get ready for a battle, or a switch.

I’ve run in to many different issues trying to build OpenEmbedded or recipes on Ubuntu 8.10 Intrepid. The list kept getting longer, with fixes to some and workarounds to others. Just setup a new 8.04LTS (server) VM and all works clean, straight-out-of the box. Back to progress…and thanks to the Gumstix mailing list for not responding to my question, forcing me to give this a shot. ;)

I ran into a bit of an issue trying to connect a suite of Gumstix computers to my local Airport Extreme (WPA2) WAP. The fix is really simple; I just had to add a “proto” configuration in the /etc/wpa_supplicant.conf file:

network={
        ssid="yourSSID" 
        proto=WPA2
        #psk="your_passphrase" 
        psk=bf83f4c896110b115bee8ff77b372f844435108950476a51667dd1b4a97e5b98
}

The rest of the directions here are still good.