We all need a change

I’ve made a career change! I have been a consumer of “enabling technology” my entire career. I am now stepping behind that line as I want to be able to influence and shape the technology that enables designers and developers to deliver the best imaginable experience.

I have joined the product management team for Flash runtimes at Adobe, which allows me maintain my focus on the best imaginable, and uncompromising, experience for the user. Flash has enabled this mission more than any other technology on the web and has allowed me to build some tremendous experiences. When user experience was considered a unique differentiator, the Flash/Flex partnership was there to enable.

The landscape has evolved. Thankfully user experience is no longer a differentiator, it’s an essential. To succeed we must put the user first.

The tech community has responded admirably and the expressiveness associated with Flash is moving in to the open-standards that are being defined by HTML5, which will enable a new wave of uncompromising experiences across the web. Adobe gave meaning to expressiveness and continues to innovate through contributes to HTML5 standards, such as CSS regions and CSS shaders. I am sure there is even more goodness to come as we will undoubtedly see more innovation through ongoing contributions to standards and our active participation in open-source projects such as Webkit.

So what’s next for Flash? As outlined in the recent roadmap for Flash runtimes we will be focusing on gaming and premium video. This week Adobe launched a new site specifically around gaming. There are already some tremendous games that showcase the unique capabilities of Flash, which are built on Stage3D to leverage the hardware acceleration afforded by the GPU. The AIR 3.2 release candidate brings the power of Stage3D to mobile in conjunction with the Flash Player 11.2 release candidate. Already some of the top games on the Apple App Store, such as Machinarium, have been brought to you by Flash and Adobe AIR. The Flash runtimes are alive and kicking on iOS!

I also care a lot about the experience of the designer and developer and making our technology accessible. I want to make the experience of using our technology a good one. I want to make it easy to design-develop-deliver incredible experiences.

Your thoughts are welcome.

Advertisement

Speak to your users in 3D

I care a lot about Software Craftsmanship.

I care a lot about User Experience.

I care a lot about designer-developer workflow.

I care a lot about continuous deployment (although I will opt for continuous delivery).

I care a lot about the lean startup movement (if you haven’t already done so buy, and read, Eric Reis’s book The Lean Startup).

I am firm believer in innovate or die and the need to conduct validated learning, and as such you should become intimately familiar with the build-measure-learn feedback loop.

I have spent a lot of time recently absorbing the technology landscape, whether that be HTML5, Flash, PaaS (Heroku, Windows Azure, …), BIG DATA, real-time, blah, blah, blah…

More than ever I feel technology doesn’t really matter. It’s an enabler. The difference between the choices that we have are closer than ever. Make the right choice for the job at hand. Practice Software Craftsmanship and you will have the confidence to adapt.

Software Craftsmanship in isolation is not enough. User Experience in isolation is not enough. Build-measure-learn on its own is not enough.

It’s a question of how we bring these methodologies and practices together and how an organisation molds itself around them. They need to be absorbed in to the corporate DNA and used to weave the fabric of innovation.

Going forward I feel our innovation mantra should be Design-Develop-Deliver. Like the build-measure-learn feedback loop advocates we need to rapidly move around this loop.

We need to shift our horizons to fully encompass the user. We start with the user and we end with the user. In his book Eric provides an anecdote about a feature not being complete until it has been validated by the users. I love this. It’s seems obvious and a subtle shift from the product owner or QA saying a feature is done, but its a big leap in terms of mindset. Imagine having the confidence to remove a feature (and deleting all the code) if users don’t actually get value from the feature? The focus this would bring to an organization would be immense.

We can destroy the traditional mindset and reject the dogma that software follows a fixed release cycle (regardless of how short it is). When the feature has been coded, give it to the user, it not done until the user says it is done.

I believe the Design-Develop-Deliver philosophy will allow us to innovate faster and deliver experiences that users want. It also creates opportunity for tech companies to enable this workflow. I would love to have a seamless set of tools and services that enable me to design-develop-deliver, this is far more powerful than getting caught up in the underlying technology debates and teams practicing their principles in isolation. We need to blend it all together.

Speak to your users in 3D.

Building organic software

I’ve been thinking a lot recently about how I can build “organic software” that permits services to transparently join the network and leave again. I want to know when a service joins the network and for it to advertise itself. I want to know when a service leaves the network so its consumers can gracefully adapt. I want a service to browse the network for the services it requires. I don’t want worry about configuration.

This is not new. If I cast my memory back to the big days of JavaOne I remember Jini (now Apache River) being the “big thing”.

Yesterday I started looking at Multicast DNS (and Zeroconf), which is used by Apple’s Bonjour. Once again the Node community has not disappointed, I quickly discovered node_mdns.

I decided to do a quick spike around MQTT, which I have also been looking at. Again, the Node community delivers with MQTT.js.

I have a service that provides an MQTT broker. When the broker is ready it advertises itself on the network.

My client browses the network for an MQTT broker, when it finds one it connects to the broker and starts publishing messages. If the broker leaves the network it stops publishing. When the broker rejoins the network, it is again discovered, and the client resumes publishing again.

Take a look at my Gist.

Although my exploration has been limited I have found it to be simple and robust. As we shift our mindset from the monolithic deployment of software to one where we build, deploy, and scale processes independently I feel this offers some really interesting and exciting possibilities. This is especially true as we look more and more at how we bridge in to the physical world to build real time experiences that consume large amounts of data and tap in to sensor networks. The end solutions are broad, it can be digital marketing, gaming, home automation (or automation anything). I came across Pachube the other day, which folds in to this and opens the door to some really interesting possibilities.

node-messaging

I’ve spent some time recently looking at AMQP. I’ve been using it with RabbitMQ and Node. The de facto library for Node is node-amqp, which is powerful, but I have found it to be too low-level for my every day needs of pub/sub.

I wanted a more succinct syntax for publish and subscribe so I created node-messaging.

Below are some code snippets, for complete examples and further documentation jump over to node-messaging.

Publish

messaging.createMessenger( url, function( messenger ) {
    messenger.openForPublish( exchangeName, exchangeOptions, function() {
        messenger.publish( exchangeName, routingKey, { body: "hello world" }, messageOptions );
    });
});

Subscribe

messaging.createMessenger( url, function( messenger ) {
    messenger.openAndSubscribe( exchangeName, exchangeOptions, queueName, queueOptions, bindingKey, subscribeOptions, function( message ) {
        console.log( "Received message '%s'", message.body );
    });
});

Google Maps – “hello world” with RequireJS and jQuery

I’ve been looking at the Google Maps “hello world” tutorial in conjunction with HTML5 Boilerplate, RequireJS, and jQuery.

When you download and extract the boilerplate it already gives you jQuery. Given I am using RequireJS with Node (see node-reference-app) I also wanted to use on the client-side to modularize my code. It’s no big deal in itself, but I ran in to a few issues when I dropped in the Google Maps API. A search on Google soon revealed it was due to the async nature that the Google Maps API (and other Google APIs) loads its own code.

There are a number of posted solutions. The one I liked was the async plugin for RequireJS from Miller Medeiros.

Jump over to GitHub to look at the complete solution.

The basic map code is exactly as it appears in the Google Maps tutorial, however here’s a breakdown of how it fits in to HTML5 Boilerplate and RequireJS:

• index.html – has the div for map_canvas, there is also a script tag with a data-main attribute that tells RequireJS the script to run, main.js, when the document is ready (read more here)
• style.css – specifies the width and height for map_canvas
• main.js – this is where the real work begins, we grab map_canvas from the DOM with the help of jQuery and call addMapToCanvas() on the google module
• google.js – this is the heart of the solution to the async problem, if you look at the top you will see the URL is prefixed with async!, which causes the async plugin to be called

Note: to use the example make sure to obtain your own api key and add it to the URL in google.js where it says YOUR_KEY.

Node.js reference app

I’ll keep this post short and sweet. I’ve spent the last week working on a reference app for Node.js. I’m not going to elaborate on it in this post, but rather ask you to jump across to GitHub and take a look at the project. It’s got a comprehensive README file that will hopefully explain my motivations and the app in full.

I’ll happily accept your feedback and encourage you to fork my code and adapt it to your own needs or to showcase the principles that you feel are important.

Enjoy!

TDD with Node

The last few days I’ve been looking at how TDD with Node. This blog provides an example project that uses RequireJS.

My requirements were kinda simple (and obvious):

• I want to easily write clear and articulate tests
• I want to use an expressive framework for writing test spies, stubs, and mocks
• I want a simple to use test runner so I can run my tests from a CI server (and ideally support for headless browser testing for when it comes to my client-side testing)

What I wasn’t expecting was an overwhelming choice of frameworks. That’s good…isn’t it? There were a few frameworks that initially jumped out, such as Vows. However, I struggled to get my tests working when it came to RequireJS. A lot of the examples I found out there were kinda of trivial and I didn’t find any good examples that showed RequireJS.

I have grown fond of RequireJS. I like that I can use it on both the client-side and the server-side, and I like the separation of concerns it affords in my code. So I was determined to find something that worked!

I came across Sinon.JS, which led me to Buster.JS (they both share the same author, Christian Johansen). Although Buster is still in Beta is made an immediate impression on me. It supports Node, it has Sinon embedded, it’s headless, the architecture is robust,…and the list goes on.

I soon got a simple test working and then struggled a bit with Require, but I eventually got it working!

My example app is intended to demonstrate the structure of a more complex app and how testing works. I’ve got a more comprehensive reference app coming soon. So enough said, jump over to GitHub for a closer look, the README provides more context.

Below is the documentation that I think you will find most useful:

• Node testing
• Sinon integration
• Sinon documentation

The Node Beginner Book

On my Node.js journey I came across The Node Beginner Book (which you can also buy bundled with Hands-on Node.js).

As the name suggests The Node Beginner Book is targeted at beginners and the goal of the author is to take you from novice to advanced novice, which it achieves well. The book is structured as a tutorial. It starts with the basics and then works towards a more structure codebase that demonstrates how to use modules for separation of concerns. There are also a bunch of links to other good resources that help you understand Node. As I go through my learning curve I am aggregating these and other resources I have found useful, I’ll share them soon.What I really like about the tutorial is it doesn’t just tell you what is bad, it shows you in code so you can see first hand. There are some really important lessons to be learned here in terms of “blocking” operations and the Node.js event loop.

I am currently expanding the MongoDB example I did with Mongoose in an earlier post. I want to build upon what The Node Beginner Book teaches to provide a more robust reference for a production Node application. I hope to share it soon in a future post.

In the mean time, if you are starting out with Node, even as an accomplished programmer, I would recommend taking a couple of hours to go work through the book. It’s a good investment of time.

St Francis de Assisi the patron saint of Software Craftsmanship

We live in a world of YAGNI (“you ain’t gonna need it”), DTSTTCPW (“do the simplest thing that could possibly work”), MVP (“minimum viable product”), and MCR (“minimum credible release”).

We bow to the philosophy of keeping our software simple (the code and the experience) and doing the minimum amount of work required to put the software in the hands of our users so we can inspect-and-adapt, or in the words of The Lean Startup the Build-Measure-Learn feedback loop (if you are thinking in this direction then I also encourage you to immerse yourself in continuous delivery).

Recently I was visiting with a customer who had a “war room”, and judging by the amount of material on the wall, there’s was a culture of collaboration, which I love. Written across the top of the wall was the following quote:

start by doing what is necessary, then do what is possible, and suddenly you’re doing the impossible

St Francis de Assisi, (Patron Saint of San Francisco)

This really struck a cord with me. I feel in our world of acronyms, it is a more elegant way of expressing the sentiment of simplicity and minimalism. May be we should herald St Francis de Assisi as our patron saint, after all he does have a connection to Silicon Valley.

Heroku + Node.js + MongoDB (featuring mongoose)

This is the next post in my series around Heroku + Node.js + MongoDB. In my original post I explored the node-mongodb-native driver, which I then followed with Mongoskin. In this post I’ll provide an example for Mongoose.

Again I won’t reiterate the steps to deploy the code. They are the same as the original post, only this time clone the code from this repository:

git@github.com:p15martin/BlogMongoDbMongoose.git

Comments on the code

So up-front I will say Mongoose gives me that warm old-school feeling from my JEE days. There is that sense of coming home and being snuggled up in the data access layer with my separation of concerns, and using my object relational mapping tool.

In contrast to Mongoskin you certainly need to write some additional code, but the intent is clear and the code readable.

The documentation is also great for Mongoose. Keep up the great work!

Conclusion

All three libraries are fantastic, as is Heroku + Node.js + MongoLab + MongoDB. Everything just works, I didn’t encounter any issues. With all three libraries I was able to quickly write my code and see it running in the cloud.

I think the choice of library is very much one of style, with a bias towards either Mongoskin or Mongoose, which I believe are both built on the node-mongodb-native driver.

With that said my examples are simple. I am only demonstrating that it can work and my code does no more than insert a document in the database. I’ve not thought about how these libraries would fit within a much larger codebase, nor have I looked at the robustness of the code or considered error handling. I am working on an extended example around Mongoose to show a more complex application. I will share it once it is complete.

I am encouraged by the fact that it just works and at how accessible the cloud has made technology. Now I can focus on just writing code. How cool is it that I can add a database to my app by simply saying: heroku addons:add mongolab:starter