Tag Archives: Technology

Signals, messages, clouds… pigeons?

… AKA, how a flock of pigeons ūüź¶ is connecting my past, present and future technology interests.

If I look back at the past 10 years or so of my career, I believe there’s a continuum of interest – from my passion for¬†/ community building around application messaging systems (MQ, MQTT, and others), to building lightweight cloud-based services (Cloud Foundry and API platforms), and now, to working on what you can choose to see as a large scale, cloud messaging platform (Twitter).

Twitter is far more than that, of course. It’s also a platform that humans interact with more so than any of the other systems I’ve worked on in the past. From¬†e-commerce to¬†core banking systems, I’m pretty sure that none of the things I’ve helped to build in the past have had the same scale and impact in the world every day that Twitter has done. It also reflects my passion for people and communities – hell, I’m a guy with a History degree playing at being a technologist, and jumped into social media before the term even really existed, what else would you think I care about? OK, OK, yes I’ve also always been an early adopter of shiny new technologies… but my excitement with technology is almost always about what it enables us to do as humans every day.

So what’s the point of this post, other than to muse on this?

Well, Twitter also represents a nice confluence of my passion for the Internet of Things, sitting between those messaging systems and those cloud apps that I mentioned, and people.

Twitter is real-time, and live. By creating and curating my Twitter timeline, I¬†follow the people (@), topics (#), and well – the things – that I care about most. I receive breaking news, follow along with what my friends and colleagues are up to, and learn about what is happening in the world in real-time. It’s a platform for both messages, and signals. The engineering and support efforts required to support¬†all of this happening, with rapid¬†response times and a solid user experience, are pretty impressive – hats off to my colleagues in those departments.

Twitter is also conversational, which means that it can make a great home for all those conversational interactions we’re hearing about with the resurgence of bots, helpers, and personal agents. In fact, we can think back to not too long¬†after the Twitter API came about, to the Tweeting plant asking for water when the soil was dry, to see that these kinds of applications are no strangers to the platform.

I’ve spoken about these topics a number¬†of times over the past couple of years, most notably at our first Flight conference in 2014, where I covered flood alerting, plants, ferries, sports events, houses, earthquakes, and more!

Soon after starting work at¬†Twitter, I ended up helping a project to connect river sensors online. Right now, you can find local river stations in the UK on an interactive map, and then (if you’re interested) you can follow the ones that matter to you. It’s pretty cool stuff, and can help with flood alerting and monitoring as well as local awareness.

Perhaps¬†you’re interested in the environment around the Dublin Bay Buoy?

Talking of the environment, last year we ran a conceptual contest out of Twitter UK, inviting organisations to think about new ways to use the platform and build applications #PoweredByTweets. One of the winning entries was the idea that pigeons in London could be instrumented with tiny backpacks measuring air quality. At the exhibition of the winning entries in September, there was a display that mocked up how this could work.

Yesterday, the @PigeonAir patrol took flight for real in London, and for another day or two will act as a temporary set of mobile beacons that can report back air quality via Twitter conversations.

I love this – and quite honestly, I remember telling people how barmy I thought it was when we first started looking at it!

Another interesting data point to add to all of is that social signals from Twitter may be more effective than some FEMA models, according to recent research

So what’s next? Who knows. My mind is constantly racing with ideas, and others come up with far, far more interesting ones!

This is not a story about Twitter.

This is the story of how humans used technology in creative ways, to improve their lives and their environments.



Getting inside Cloud Foundry for debug (and profit?)

I’ve recently started to play with some more of the internals of Cloud Foundry than I’ve been used to. This has been made much easier by the advent of bosh-lite, a system for deploying all of Cloud Foundry’s components using the bosh continuous deployment and configuration tool, into a single virtual machine. bosh-lite achieves this by using containers (Cloud Foundry’s own Warden container technology) to “emulate” the individual VMs where jobs would run in a full distributed topology.

bosh-lite has actually been around for a number of months now, but I’ve not had much of a chance to play with it until recently. This is partly due to other activities, and also that my earlier attempts to get an environment up-and-running were hampered by lack of memory. It should be possible to run bosh-lite with a Cloud Foundry deployment in 8Gb of RAM, but given my laptop’s configuration and the amount of other stuff I’m usually running, that was never comfortable – now I’m rocking 16Gb in a MacBook Pro, things are running more smoothly.

I don’t intend to spend this post documenting how to install bosh-lite and get a running single-node Cloud Foundry system. I followed the instructions in the README and things went well on this occasion. One suggestion that I’d make is if you can, to use VMware Fusion (assuming like me, you’re on OS X) and the Vagrant provider for Fusion, seems quite a lot better than Virtualbox. If you do, don’t forget to pass the --provider=vmware_fusion flag when you bring your Vagrant image up (that’s something I do usually forget). One other little thing to mention is that after I started the bosh deployment, the bosh CLI gem timed out and returned a REST error – but the deployment process itself continued without any issues, and I was able to use bosh tasks to check in on the progress. If you are interested, I used cf-release-157 this time around.

Once I had my minty-fresh Cloud Foundry running, I deployed Matt Stine’s handy, simple, Ruby scale demo app and pushed up the number of instances.

So what’s the point of this post? I want to mention two things…

Note: this is not about debugging applications on Cloud Foundry in general – a PaaS is an opinionated system and you generally shouldn’t need to poke around inside it like this. This is for debugging the Cloud Foundry runtime itself, or aspects that might run inside a container. Oh, and I’m sorry about the formatting of some of the shell output examples below!

Peeking at NATS traffic

NATS is the internal, lightweight message bus that Cloud Foundry components use to talk to one another. I’d read blog posts from Cornelia and from Dr Nic about digging into this before.

First of all, I used bosh ssh to access the NATS host:

$ bosh ssh
1. ha_proxy_z1/0
2. nats_z1/0
3. postgres_z1/0
4. uaa_z1/0
5. login_z1/0
6. api_z1/0
7. clock_global/0
8. api_worker_z1/0
9. etcd_leader_z1/0
10. hm9000_z1/0
11. runner_z1/0
12. loggregator_z1/0
13. loggregator_trafficcontroller_z1/0
14. router_z1/0
Choose an instance: 2
Enter password (use it to sudo on remote host): ***
Target deployment is `cf-warden'

Setting up ssh artifacts

Director task 9

Task 9 done
Starting interactive shell on job nats_z1/0

So now I’m on the NATS host – now what? well, strictly speaking I didn’t need to login to that host / container, since of course, as a messaging system, the other hosts can connect to it anyway. The reason I wanted to login to it was to find out how NATS was configured.

$ ps -ef | grep nats
root 1470 1 0 12:09 ? 00:00:12 /var/vcap/packages/gnatsd/bin/gnatsd -V -D -c /var/vcap/jobs/nats/config/nats.conf

$ more /var/vcap/jobs/nats/config/nats.conf

net: ""
port: 4222

pid_file: "/var/vcap/sys/run/nats/nats.pid"
log_file: "/var/vcap/sys/log/nats/nats.log"

authorization {
user: "nats"
password: "nats"
timeout: 15

cluster {
host: ""
port: 4223

authorization {
user: "nats"
password: "nats"
timeout: 15

routes = [


From this, I can see that NATS is listening on IP, port 4222 (the NATS default), and that it is configured for username/password authentication. Handy to know!

I borrowed a little script from Dr Nic, but needed to modify it slightly to talk to authenticated NATS (his original script assumed there was no auth in place):

[update – Dr Nic has provided a more convenient method to do this, in the comments below – check out nats-sub – but this works, as well]

$ ./nats-all.sh
Msg received on [router.register] : '{"host":"","port":8080,"uris":["login."],"tags":{"component":"login"},"index":0,"private_instance_id":"e6194fe8-4910-4cb1-9f7c-d5ee7ff3f36b"}'
Msg received on [router.register] : '{"host":"","port":8080,"uris":["uaa."],"tags":{"component":"uaa"},"index":0,"private_instance_id":"7713dd5b-3613-41a6-9c67-c48f22a769b4"}'
Msg received on [router.register] : '{"dea":"0-1ba3459ea4cd406db833c1d188a78c02","app":"b8550851-37a0-4bd5-bdce-1d787b087887","uris":["andyp."],"host":"","port":61021,"tags":{"component":"dea-0"},"private_instance_id":"b52dfd91d68144cabb14b6c7bae77daae8b493acf1354c99941d49772a1f61fb"}'
Msg received on [router.register] : '{"dea":"0-1ba3459ea4cd406db833c1d188a78c02","app":"b8550851-37a0-4bd5-bdce-1d787b087887","uris":["andyp."],"host":"","port":61025,"tags":{"component":"dea-0"},"private_instance_id":"090f5c5aeee94fdfb4a4e0f0afde2553480dcd97c018431db37b4dffdc80fde4"}'
Msg received on [router.register] : '{"dea":"0-1ba3459ea4cd406db833c1d188a78c02","app":"b8550851-37a0-4bd5-bdce-1d787b087887","uris":["andyp."],"host":"","port":61028,"tags":{"component":"dea-0"},"private_instance_id":"92e10af77b274836a3f54373c9b7feee025c5b72f41a4c4982bde97d241ebd5b"}'
Msg received on [router.register] : '{"dea":"0-1ba3459ea4cd406db833c1d188a78c02","app":"b8550851-37a0-4bd5-bdce-1d787b087887","uris":["andyp."],"host":"","port":61039,"tags":{"component":"dea-0"},"private_instance_id":"86edf0c0a7f84f04b52693b489ad93b7f857f77271b84d568d8f5600b34f7054"}'
Msg received on [router.register] : '{"host":"","port":34567,"uris":["8b24c0a7d28f4e03aa028a3dc89fb8c3."],"tags":{"component":"directory-server-0"}}'
Msg received on [dea.advertise] : '{"id":"0-1ba3459ea4cd406db833c1d188a78c02","stacks":["lucid64"],"available_memory":23296,"available_disk":22528,"app_id_to_count":{"b8550851-37a0-4bd5-bdce-1d787b087887":10},"placement_properties":{"zone":"default"}}'
Msg received on [staging.advertise] : '{"id":"0-1ba3459ea4cd406db833c1d188a78c02","stacks":["lucid64"],"available_memory":23296}'
Msg received on [dea.heartbeat] : '{"droplets":[{"cc_partition":"default","droplet":"b8550851-37a0-4bd5-bdce-1d787b087887","version":"a420d371-0816-4baf-9649-4e21255a66a4","instance":"d92d3c0c43ce4b6981e443e5c2064580","index":0,"state":"RUNNING","state_timestamp":1392639135.9526377},{"cc_partition":"default","droplet":"b8550851-37a0-4bd5-bdce-1d787b087887","version":"a420d371-0816-4baf-9649-4e21255a66a4","instance":"898e632697e246de9cf6b7330444227c","index":1,"state":"RUNNING","state_timestamp":1392639136.3117783},{"cc_partition":"default","droplet":"b8550851-37a0-4bd5-bdce-1d787b087887","version":"a420d371-0816-4baf-9649-4e21255a66a4","instance":"56d023e374aa49d88720daabac58e862","index":2,"state":"RUNNING","state_timestamp":1392639135.2225387},{"cc_partition":"default","droplet":"b8550851-37a0-4bd5-bdce-1d787b087887","version":"a420d371-0816-4baf-9649-4e21255a66a4","instance":"f11d86a7f4ad47f1ad554ae1b087d5f6","index":3,"state":"RUNNING","state_timestamp":1392639136.1042},{"cc_partition":"default","droplet":"b8550851-37a0-4bd5-bdce-1d787b087887","version":"a420d371-0816-4baf-9649-4e21255a66a4","instance":"c9e6de77f0484e6cae47f73ad6ca778a","index":4,"state":"RUNNING","state_timestamp":1392639135.9426212},{"cc_partition":"default","droplet":"b8550851-37a0-4bd5-bdce-1d787b087887","version":"a420d371-0816-4baf-9649-4e21255a66a4","instance":"924c387fc33444289b2db2762eefac42","index":5,"state":"RUNNING","state_timestamp":1392639135.940636},{"cc_partition":"default","droplet":"b8550851-37a0-4bd5-bdce-1d787b087887","version":"a420d371-0816-4baf-9649-4e21255a66a4","instance":"69866b260b1a49a09c03e178c4add2c5","index":6,"state":"RUNNING","state_timestamp":1392639135.944143},{"cc_partition":"default","droplet":"b8550851-37a0-4bd5-bdce-1d787b087887","version":"a420d371-0816-4baf-9649-4e21255a66a4","instance":"94bc605505d94dc1832e55bf2f671a99","index":7,"state":"RUNNING","state_timestamp":1392639135.4456258},{"cc_partition":"default","droplet":"b8550851-37a0-4bd5-bdce-1d787b087887","version":"a420d371-0816-4baf-9649-4e21255a66a4","instance":"8420df9bbe64456385dfa91285641ba4","index":8,"state":"RUNNING","state_timestamp":1392639135.9456131},{"cc_partition":"default","droplet":"b8550851-37a0-4bd5-bdce-1d787b087887","version":"a420d371-0816-4baf-9649-4e21255a66a4","instance":"ed9ad14f6599494c96f90296c59e6041","index":9,"state":"RUNNING","state_timestamp":1392639135.938359}],"dea":"0-1ba3459ea4cd406db833c1d188a78c02"}'
Msg received on [router.register] : '{"host":"","port":8080,"uris":["loggregator."]}'
Msg received on [router.register] : '{"host":"","port":9022,"uris":["api."],"tags":{"component":"CloudController"},"index":0,"private_instance_id":null}'
Msg received on [router.register] : '{"host":"","port":8080,"uris":["login."],"tags":{"component":"login"},"index":0,"private_instance_id":"e6194fe8-4910-4cb1-9f7c-d5ee7ff3f36b"}'

Warden containers and shells

Cloud Foundry’s native container technology is called Warden. When an application is deployed, Cloud Foundry starts up a Warden container based on the limits assigned in terms of memory etc, and the applications run inside that. How can you get “inside” the container to see what is going on?

Well, there are a couple of techniques. Cloud Foundry Loggregator provides streaming access to the standard application logs (stdout/stderr) via the cf logs command. Another option is James Bayer’s cool websocket-based method for getting access to the container. Yet another option is Warden’s own shell, wsh. This does assume you can access the DEA machine with ssh, however.

wsh doesn’t seem to be very well documented, although I knew Cornelia had played around with it – see her excellent blog post on troubleshooting CF and applications, including a great flowchart / graphic suggesting different techniques.

Here’s the secret sauce:

1. Login to the DEA VM (called “runner_z1/0” in the list provided by bosh ssh).

2. Identify your Warden container… there are a lot showing below, but I happen to know that these are several instances of the same app. The important part is the instance-17ij46hadt2 – the second part or that value maps to the location of the container’s private space on disk.

$ ps -ef | grep warden
root        49    42  1 11:41 ?        00:00:41 /var/vcap/bosh/bin/ruby /var/vcap/bosh/bin/bosh_agent -c -I warden -P ubuntu
root      5390 32634  0 12:12 ?        00:00:00 /var/vcap/data/packages/warden/38.1/warden/src/oom/oom /tmp/warden/cgroup/memory/instance-17ij46hadss
root      5503 32634  0 12:12 ?        00:00:00 /var/vcap/data/packages/warden/38.1/warden/src/oom/oom /tmp/warden/cgroup/memory/instance-17ij46hadsu
root      5697 32634  0 12:12 ?        00:00:00 /var/vcap/data/packages/warden/38.1/warden/src/oom/oom /tmp/warden/cgroup/memory/instance-17ij46hadt3
root      6779 32634  0 12:12 ?        00:00:00 /var/vcap/data/warden/depot/17ij46hadsu/bin/iomux-spawn /var/vcap/data/warden/depot/17ij46hadsu/jobs/58 /var/vcap/data/warden/depot/17ij46hadsu/bin/wsh --socket /var/vcap/data/warden/depot/17ij46hadsu/run/wshd.sock --user vcap /bin/bash
root      6780  6779  0 12:12 ?        00:00:00 /var/vcap/data/warden/depot/17ij46hadsu/bin/wsh --socket /var/vcap/data/warden/depot/17ij46hadsu/run/wshd.sock --user vcap /bin/bash
root      6784 32634  0 12:12 ?        00:00:00 /var/vcap/data/warden/depot/17ij46hadsu/bin/iomux-link -w /var/vcap/data/warden/depot/17ij46hadsu/jobs/58/cursors /var/vcap/data/warden/depot/17ij46hadsu/jobs/58
root      6930 32634  0 12:12 ?        00:00:00 /var/vcap/data/warden/depot/17ij46hadss/bin/iomux-spawn /var/vcap/data/warden/depot/17ij46hadss/jobs/59 /var/vcap/data/warden/depot/17ij46hadss/bin/wsh --socket /var/vcap/data/warden/depot/17ij46hadss/run/wshd.sock --user vcap /bin/bash
root      6931  6930  0 12:12 ?        00:00:00 /var/vcap/data/warden/depot/17ij46hadss/bin/wsh --socket /var/vcap/data/warden/depot/17ij46hadss/run/wshd.sock --user vcap /bin/bash
root      6934 32634  0 12:12 ?        00:00:00 /var/vcap/data/warden/depot/17ij46hadss/bin/iomux-link -w /var/vcap/data/warden/depot/17ij46hadss/jobs/59/cursors /var/vcap/data/warden/depot/17ij46hadss/jobs/59
root      6950 32634  0 12:12 ?        00:00:00 /var/vcap/data/warden/depot/17ij46hadt3/bin/iomux-spawn /var/vcap/data/warden/depot/17ij46hadt3/jobs/60 /var/vcap/data/warden/depot/17ij46hadt3/bin/wsh --socket /var/vcap/data/warden/depot/17ij46hadt3/run/wshd.sock --user vcap /bin/bash
root      6955  6950  0 12:12 ?        00:00:00 /var/vcap/data/warden/depot/17ij46hadt3/bin/wsh --socket /var/vcap/data/warden/depot/17ij46hadt3/run/wshd.sock --user vcap /bin/bash
root      6960 32634  0 12:12 ?        00:00:00 /var/vcap/data/warden/depot/17ij46hadt3/bin/iomux-link -w /var/vcap/data/warden/depot/17ij46hadt3/jobs/60/cursors /var/vcap/data/warden/depot/17ij46hadt3/jobs/60
vcap     23713 16807  0 12:26 pts/0    00:00:00 grep --color=auto warden
root     32634     1  0 11:52 ?        00:00:09 ruby /var/vcap/data/packages/warden/38.1/warden/vendor/bundle/ruby/1.9.1/bin/rake warden:start[/var/vcap/jobs/dea_next/config/warden.yml]

3. Head over to the directory for your chosen Warden instance:

$ cd /var/vcap/data/warden/depot/17ij46hadt2

4. Notice that the Warden containers are running as root. If you run wsh now as an unprivileged user, you’ll get a connect: Permission denied error. Time to switch to root, and then run wsh specifying the command to run inside the shell, as a parameter:

$ sudo su -
# cd /var/vcap/data/warden/depot/17ij46hadt2
# bin/wsh /bin/bash

5. At this point, we’re inside the Warden container with a bash shell, and all commands are scoped inside it. So, let’s take a look at what is running:

root@17ij46hadt2:~# ps -ef
root         1     0  0 12:12 ?        00:00:00 wshd: 17ij46hadt2
vcap        29     1  0 12:12 ?        00:00:00 /bin/bash
vcap        31    29  0 12:12 ?        00:00:00 ruby /home/vcap/app/vendor/bundle/ruby/1.9.1/bin/rackup config.ru -p 61031
vcap        32    31  0 12:12 ?        00:00:00 /bin/bash
vcap        33    31  0 12:12 ?        00:00:00 /bin/bash
vcap        34    32  0 12:12 ?        00:00:00 tee /home/vcap/logs/stdout.log
vcap        35    33  0 12:12 ?        00:00:00 tee /home/vcap/logs/stderr.log
root        39     1  0 12:27 pts/0    00:00:00 /bin/bash
root        52    39  0 12:27 pts/0    00:00:00 ps -ef

This is our Ruby app, running on port 61031, and we can see the logs being written as well.

Hopefully this is useful information for folks wanting to dig around inside bosh-lite and a running Cloud Foundry system!

Different Spokes

When Jeff Douglas from CloudSpokes contacted me last week to ask if I would be interested in being a guest on their Different Spokes show to talk about Cloud Foundry, help to review a book on node.js, and generally talk tech, I was delighted to be able to say “yes!”. I met Jeff back at Monktoberfest in October and I love the stuff the CloudSpokes team are doing around application challenges to build skills in different areas.

It turns out that these guys are spending a lot of time with Javascript lately and the brief was to review The Node Beginner Book. We did talk about it for a bit, but I probably talked too much earlier in the show because I was getting excited about all the cool stuff happening around Cloud Foundry lately ūüôā

This was my first use of the Google+ Hangouts On Air feature, which allows content producers to publically stream the group chat to a YouTube account. I have to say that I was extremely impressed. We used the lower thirds feature from the Hangouts Toolbox plugin to do titles, and I’m sure there were a bunch of other handy add-on features we could have used to enhance the experience too.

It was great to be able to respond to viewer questions coming in via Twitter, and I’d like to thank my colleague Raja for his cool node app examples (don’t forget to check out nodelogger which uses the Cloud Foundry authentication features too). A shout-out to Brian McClain for bailing me out when I forgot the features of my own product, too…!

All-in-all, a really enjoyable discussion, and I’d love to take part in that show again sometime – smart guys! They’ve posted a nice recap post if you’d like to check them out.

Looking back, looking forward

As I close in on my first year anniversary joining the Cloud Foundry team, we’ve passed the New Year marker and some things are in the process of changing, so I thought it was high time for a blog post – now there’s a thing!

Last year was one full of changes for me, not all of which are things I’ve posted about online¬†– those who know me well know that I had an “interesting” year! Like many folks, I’ve just gone through the corporate annual review cycle, and that was a good chance to think over what I got up to in 2012.

Looking back

I’m not going to quote word for word from what I submitted in my review, but pick out some of my personal highlights:

  • I’ve had a blast in the Cloud Foundry team, and particularly feel at home with my Developer Advocate colleagues. I was able to co-present sessions with Monica at MongoDB UK (she’s now moved on to more awesomeness), and Raja at our Cloud Foundry Open Tour event in London‚Ķ I co-wrote a Cloud Foundry and Spring article for JAX with the legendary Josh‚Ķ and in the past few weeks I’ve been working more with Raja and others on some new content that is coming soon. Teamwork and collaboration FTW ūüôā
  • I built a few simple samples for Cloud Foundry – not quite the uber-app that I had planned, that’s still in my head – and learned a bunch of new (to me) languages and technologies in a short period of time.
  • I’m very pleased with my “reach” in terms of audiences, talks, and the numbers of people referring to videos, screencasts and slidecasts I built in the past 12 months. Always room to improve!
  • I had an excellent time working with our Cloud Foundry ecosystem partners and friends in 2012, getting to know Diane, Adron, the Uhuru team, AppFog, etc. For me, the partners and community around Cloud Foundry are what make my role a real pleasure.

Beyond the day job, I did a bunch of other things last year, too:

  • Visited San Francisco for the first time… which sounds weird given my IT background and the tech concentration there. I love that city! Next time I might actually get to do the tourist thing, but I really enjoyed being over there with my colleagues.
  • Saw IBM’s MQTT code move into the Eclipse Paho project, where I became a Committer. I was able to represent the project at EclipseCon in the US and in Europe and at the Eclipse Day in Toulouse organised by my good friend Benjamin. There was some big growth in the MQTT community last year – lots of new software implementations, another significant use of the protocol in Facebook’s updated mobile apps, and increasing numbers of folks discovering the protocol.
  • Attended both of the Redmonk Brew events – the Monkigras and the Monktoberfest. Hands-down the best technology events that I’ve been too. Can’t wait for the Monkigras 2013 next week. Sell your own arm to buy a ticket. A leg too, if necessary.
  • Took part in the London Green Hackathon, the Field Studies Council Hackday, the IDEO Make-a-thon (gutted that I cannot go to the event this year), spoke at Digital Bristol, attended Horizons and the Raspberry Jam in London‚Ķ
  • Was on the crew at OggCamp, Hack to the Future, the Brighton Mini Maker Faire‚Ķ
  • Rediscovered my love of LEGO.

Looking forward

So that was last year, and it’s late January already – way past time to think about how 2013 will shape up. Despite my good buddy¬†James Governor not doing New Year’s Resolutions, I made myself a short list of things I want to focus on this year – and ignoring some of what he says, I am actually going to try to follow through‚Ķ

  • Be as awesome as possible in my role on the Cloud Foundry team. I work with great people and they deserve the best I can offer. Looking forward to seeing where the Pivotal Initiative takes us, and there are some great things happening!
  • Attend fewer events in one week / month. A couple of times last year, I definitely pushed myself too hard. In the London tech scene you can pretty much choose from 2 or 3 good developer meetups on any evening of the week, and I over-committed on several occasions. I’m also going to be more picky about exactly how I get involved in them‚Ķ I loved all of the events I crewed for last year, but I scheduled things poorly and need to cut back.
  • Blog more frequently. Yes, this is the obvious one‚Ķ but I really do want to, and have intended to for a long time. I have moments where I compose whole blog entries in my head while I sit on the train, and I wish they could just be transcribed in the moment. I do regret having let other social sites take over my online presence, particularly when it comes to the end of a year with the chance to look back. I should have been able to link every “big event” in the lists above, back to a blog post about what happened. So, I’m committing myself to writing more again this year.
  • Improve my Ruby and Javascript skills. I’ve started out well on this with a couple of projects I’ve been tinkering with lately.
  • Make cool things. LEGO things. Raspberry Pi things. Arduino things. I want to learn, hack, and make more. I talk about Maker culture, and I want to remind myself that I’m part of it.
  • Focus on improving my public speaking habits. I know I sometimes talk too quickly, get sidetracked, etc‚Ķ every time I listen back or watch a talk I gave, I spot another thing I want to adjust. I think this is one of those lifetime improvement resolutions more than it is something I can “fix” in a 12 month period, but it’s certainly an area I want to look at.
  • Take. Proper. Holidays. I nearly¬†managed to entirely detach from Twitter over the Christmas period, and definitely didn’t keep checking my work email, for the first time in many years. It felt good. I want to do that more often from now on.

Seven simple (?!) thoughts. I guess the only one that will easily be measurable by watching my blog will be the one about writing more, and this is my start on that one!

Happy 2013, friends – hope to see you soon!

My next steps – joining the Cloud Foundry team

I’m very excited to announce that, from April 10th, I will be joining the Developer Relations team for Cloud Foundry at VMware.

This is a thrilling opportunity for me for a number of reasons.

  • from a technology perspective:¬†Cloud Foundry is very, very,¬†very¬†cool. In my opinion, it really comes from a different set of thought processes than the other Platform-as-a-Service offerings out there, which make it unique and compelling.
    • the operating system stuff gets out of the way (why should it matter?), but multiple language runtimes and backend resources are available for easy scaling. Seriously, the first time I walked through¬†the command-line tutorial and scaled a Ruby app to 6 load balanced instances with a single command, I was instantly impressed.
    • it is Open Source. The code is on Github. You can run your own cloud if you like. You can add support for your own languages and frameworks, much as¬†AppFog have done for PHP, Tier 3 and Uhuru have done with¬†.NET in Iron Foundry, and so on. This provides a huge amount of flexibility. Oh, and of course mobile and cloud go hand-in-hand, so last week’s announcement of¬†FeedHenry providing tools to develop HTML5 apps to deploy on Cloud Foundry was really significant, too.
    • you can take your cloud with you using¬†Micro Cloud Foundry – so the development and deployment model remains the same whether you are online or offline. I love this idea.
  • for me, personally: it’s a natural evolution of much of the work I’ve been doing over the past few years – focusing on developer communities and promoting technology adoption, as much as top-down solution selling. As my good friend James Governor is fond of saying and as his colleague Steve O’Grady wrote, developers are the new kingmakers – and with trends like mobile, cloud, and devops, nurturing those communities is more important than ever. You don’t impose technology on a community – you explain it and earn your place and reputation.
  • I’m looking forward to more speaking, more writing, more mentoring, and more online community building. These are things I’ve grown to enjoy (and in the case of the latter, appear to do naturally).
  • I’ve followed Patrick Chanezon, the Senior Director of the team, since he was setting up the developer advocacy programme back at Google – I have a lot of respect for what he’s achieved and the way he operates, so I’m delighted to have the chance to work closely with him. I’m excited to join everyone in the team, of course – I have spoken with most of the group already and I’m really looking forward to learning from their diverse range of experiences and backgrounds.

Between now and April 10th, I have a few things planned including a vacation (!), heading to EclipseCon to talk about MQTT and M2M topics, and some other speaking engagements. After I start the new role, I expect I’ll join in on the Cloud Foundry Open Tour and start to meet folks. I’ll also be on the team for the GOTO conference in Aarhus in October – exciting times ahead!