Archive for the ‘opinion’ Category
The Hobbit, in IMAX, was fantastic. Drain all bladders before taking your seat: there is something like 166 minutes of film, preceded by 30 minutes or more of trailer, ads, and the usually turgid mush about the mind-splittingly good technology that is going to make your experience unparalleled.
Before we get into a brief description of the thing, I’d like to note that the Hobbit probably represents the only new estate in big budget blockbusters – all the trailers here were for reboots: Superman (again), Wizard of Oz (a sequel), Star Trek (OMFG again).
This Hobbit screening was not only IMAX, it was 3D, which is generally of gimmicky quality. This, however, was very good – I couldn’t suppress a flinch at an incoming spear during the Star Trek trailer, and there were times when it appeared you were looking through a hole in the wall of the cinema rather than at a screen. No doubt, the 48fps had something to do with this. Pan shots were very smooth and there definitely was a parallax-scrolling effect going on during the wide travel shots.
Top tips: Do not sit near the front. You will be too close to the screen and you won’t be able to see the edges. Do not move your head around, the 3D effect appears to be delicate and even a moderate tilt will blur out parts of the picture. Do not bring excessively small humans, they have tiny internal waste storage spaces and may cause you to miss chunks of the movie when they need emptying. Do not bring a picky perfect recall of the book, loads of original material has been packed in to make a solid movie from what is really a short book constructed for the appreciation of young readers.
About twenty minutes from the end, the sound and picture streams de-synched at our showing, but by giving us free IMAX tickets for another show, the management of the cinema forestalled the impending torches and pitchforks mob.
Take the top tips above and go see it.
Thank you for a exemplary conference experience at Monki Gras during a chilly and bright London January. You went deep on the craft theme and I think that resonated strongly with everyone there, because those people who were there loved and cared so much about what they do. That was the first thing that set it apart from ‘regular’ conferences.
Also there was beer, but not a surreptitious beer, not a beer that was pale and fizzy and gullished without pleasure by braying middle managers with grotesquely tumescent bellies and swollen man-boobs. This was a first-class beer that was knitted into the fabric of the conference and reflected the craft theme, that an attendee could openly savour in company in the noonday without fear of a judgement of functional alcoholism (to borrow a phrase from @jasonh). This was another welcome distancing from the mainstream, albeit I thought I had been mugged after checking my wallet post the Craft Beer Co. experience – though is the welcome price we pay for quality.
At this moment, in an echo of the event itself, I am writing this letter, drinking a craft pale ale in a craft beer pub that has newly opened across the road from my office, a whole 45 metres away from my desk. I feel that these echoes will continue to reverberate, perhaps to the detriment of my deadlines.
Let us return to the conference.
The food, made fresh in front of our eyes, the specially roasted coffee, the baskets of fucking fruit, all spoke to a care of consumption that really is usually ignored in favour of cost in our modern lives. Care and attention, @monkchips, care and attention to the smallest detail makes the picture whole and perfect.
In your carefully crafted environment, who could not be in a positive frame of mind, content and happy to be open and honest with their neighbor, even though they may be a temporary stranger? This brought the best out in the already well-qualified and excellent speakers, brought out the humour, brought out the honest expression normally present among a group of friends rather than between a conference speaker and conference attendees. I cannot speak for others – but forty minutes into the first day I was in the front row wishing I was up there giving a talk. What a crowd!
And your conference was filled with wonders – the .gov.uk affair was heart-stopping in its implications and amazing in the fact that it actually happened; – the data pretties entranced us and were in a second breath laid bare as shams if presented without context; – kittehs masqueraded, unchecked, as chikins; – the bombshell that companies get the UX they deserve was dropped; – machines with software that killed people were wheeled out; – the dysfunctions of technology executives were outed without ceremony; – the list could go on, if it weren’t for the line drawn under it by that 9.5 ABV beer, the name of which escapes me entirely.
This letter has just about reached its limit. Let me finish by mentioning that most important aspect of conference-going – personal relevance. I’m a technical co-founder, and my work life is trisected equally into states of euphoria, all-consuming flow and cold panic. At your conference, listening to the experiences and the judgements of those who have treaded this route before, I experienced an enormous feeling of validation – that I haven’t chosen the wrong technology stack; – that I’m not totally crazy for attempting to do what I am doing; – that these people have tried and succeeded and are not that different to me after all: and for that, especially that, I thank you and your team.
all the best
p.s also – phone is teh awesome 🙂
There’s been some buzz about CoderDojo in the news recently. The CoderDojo was founded by James Whelton in 2011 to introduce kids to coding at an age when they are still in school, in an environment that supports learning. With support from Bill Liao, CoderDojos have sprung up in nine locations around Ireland.
This is relevant to my interests, and I wanted to see what the whole thing was about. To get in, you need a kid, so I brought the ten year old rugby fanatic that hangs around my house and eats the food. He chose the Programming Games with Python session – no doubt wanting to fulfill his dream of getting a decent rugby game on his iPod touch at some point.
Let me digress briefly on the subject of teaching kids how to manipulate computers with software code. We use physical tools to supplement our physical selves – pushing a nail into a piece of timber with your thumb is rarely successful. We need to use computational tools to supplement our own mental computing capabilities and allow us to enhance our reasoning processes. We are already equipped to pick up a hammer, see a nail and get a fair idea what to do next, but pick up an iPod Touch and put a rugby game on it? It’s not obvious how to get there, so instruction is required. And instruction needs to be imparted early, not because we want to make more developers, not because we want kids choosing a career in coding, but because we want to give them the tools they need in the 21st century to allow them to take advantage of every opportunity that comes their way.
Back to the dojo. Our host Eugene had his work cut out for him: 25 or more young humans, with vastly different capabilities in the area, short attention spans and different laptops all around. I decided take Mr. Rugby ahead with a copy of a simple Python text game involving choosing a cave and hoping the dragon therein doesn’t eat you, taken from the syllabus book.
The programming journey went like this – at each stage we thought of a goal and massaged the existing code and added new code to get to it. The kid did all the typing, saving, running, copying, pasting. I just pointed out now and then similar chunks of code that he could reuse and got him through any blocks.
- I say – let’s extend the game from a choice between two caves, to a choice between three.
- Kid says – let’s print out which cave was which at the end of the game, so you can see which was the right one.
- We discover that strings and integers were different 🙂
- We discover that when one chooses three random numbers in the range 1..3, there’s a good chance two will be the same, and it doesn’t make sense to have a bad dragon and a good dragon in the one cave – they are territorial.
- Kid surprises me by coming up with a simple but effective way to make sure that the numbers wouldn’t clash, and we implement it – without using the modulo operator
Then we were done with where we wanted to go. Eugene was taking the kids along, helping each individually if he need to do so, and going down the same path initially, making an extra cave in the game.
But our local journey hadn’t finished after all. The kid had decided that now it was time to do some visuals and had sketched out a picture with three caves with numbers over them. Here’s where having a software savvy dad and the internet is a win: we grabbed a free pixel art program, muddled out how to use it, and while he drew the screen, I frantically researched free Python game libraries.
Aside – before we got onto the visuals, I spotted a few areas in the code to put in a couple of for loops, and suggested we ‘tidy up’ the code a bit so that I could show these and explain them. Why? was the response, the thing worked didn’t it? The important thing at this point is to shrug and agree – the lad is not a professional coder, he doesn’t need to refactor, he just needs results. In fact the whole thing needs to be results-driven. This is why you use a tool – not because it’s lovely or elegant or makes you feel special, but because you have a job to sort out. Then you put the tool down. It’s only when you get trained in how tools work can you start making your own tools. cf. lightsabre etc
Eventually I stumbled over pygame, which turned out to be just the tool we needed. We made a plan to write a small programme to try it out, and there was palpable excitement when our extremely amateurish drawing of caves popped up, surmounted by a hand-scrawled Danger!! sign.
On the way home on the train, we designed an rugby-themed 8-bit scroller for the iPod Touch and set up the kid’s github account. When we arrived home the kid insisted, with uncharacteristic determination, that we finish the Dragon game – adding keyboard control, putting in dragon graphics, conveying the result visually. Next challenge: the rugby game. Yikes!
Very little of this article has been on the details of the CoderDojo, but you may have already realized how the CoderDojo was instrumental in making this tiny but important success work. It provided us (and I write ‘us’ deliberately) a place in which learning was the norm; it provided a place where myself and himself were on the same team working towards an external goal; it provided a place that wasn’t dominated by adults. And that last one is the key one I think.
Many thanks to Eugene and the team behind CoderDojo Dublin for their commitment and patience in putting the series together, they are providing an really valuable service, on their own time.
Backstory: I’m spending some time trying to find 10 spare gigs on my laptop to house the monster Xcode 4 install. During the cleanup, I’ve unearthed several dozen bog bodies from my previous software and employment versions. Some are embarrassing, but they are like eccentric relatives, I cannot bring myself to deny them, plus I enjoy seeing the effect they have on other people. So, rather than throwing them out, I thought I might share them here so that we can all have a laugh.
This one was from when I worked in an Open Source organization embedded in a Closed Source organization – when OSS suddenly became trendy in Enterprise Software. It was a draft of a primer of how to do Open Source When You Have No Idea How It Works, meaning how to take part in projects and run a stable of OSS developers successfully. I don’t think it got beyond a second draft. I still think OSS is a better way to do most things, however it does have its own pathologies, which at least are fairly visible.
Committing to Open Source
So, you want to try out this OSS thing. It’s the new hotness in the press, and your competitors are all about competing only on the 20% and contributing to and using Open Source for 80% of their delivery. You could get fired if you don’t jump on the bandwagon. Measuring your success is crucial. Your old metric of revenue linked to products won’t really work with Open Source. You will need to build a force of highly-competent developers that can consistently deliver value to customers.
OSS is a services engagement in most cases. Customers must be kept happy – you need capable and competent developers and you got to have a plan to keep them coming on-stream. This is vital when you are dealing with potentially the most mobile workforce in the world.
Key Aspects of Open Source (OSS) vs. Secret Source (SSS)
- SSS is about chain-of-command
- OSS is about tribal pressures
- SSS is about running a factory
- OSS is about being a patron
- SSS is about being regulated and policed
- OSS is about self regulation by application of taboo
- SSS success is about moving up the hierarchy
- OSS success is about moving out into the world
Patronage in OSS
You are a patron. Think about how that model works – those receiving patronage want to practice their craft. Those giving patronage want to enhance their standing amongst their industry peers. By enhancing their standing the patron can build a reputation and upon that, a dominance.
Those receiving patronage will brook some interference in the execution of their tasks, but not much, so you need to maintain a loosely-coupled connection to the body corporate. This can be difficult. You need someone who has trust from the stable of developers, and also can communicate the corporate messages in a way that makes sense – really this is not about spouting corporate goals, but being able to construct competitive challenges like – “We want to kill XYZ, how do we do it?”, or “That QRPX repository looks good, but we can do better”. Basic, tribal goals, not code-speak for corporates, no mission statements.
OSS developer is a highly mobile position. If you are a good patron, your reputation will spread. You build the reputation for a year or two, then you can start trying to poach names from the other projects that you are up against, poach the bloggers, do this by word-of-mouth. Every single one you persuade will give you PR you can’t manufacture. You are also hitting those projects where it hurts, by taking their staff directly.
How to be a Good Patron
What you do is strengthen each developer’s community immersion. One of the big winners is to increase their physical presence in the OSS milieu. Allow each developer to attend two conferences per year, more if they are speaking. Profile the conferences, and make places available, limit them to encourage submissions. Review your guys’ blogs and suggest topics to them, keep feeding them competitive nuggets. You also need to let them investigate stuff that is new and interesting. Some small-scale and locally-constrained brownian motion is fine, as long as the general trend is moving forward. Make sure you send them to competitors’ conferences, even things like Microsoft conferences. These people are your eyes and ears, developers are mostly honest, and they will give you a level of relevant information you have never had before.
Making Good OSS Developers
Firstly, keep the ones you have. If you are a Good Patron, your attrition should be tiny. However, you need to educate developers to turn them into OSS developers, it is not an instinctive thing. Programs for committership must be established. A mentoring system must be present. Committers must be regularly assessed on their contributions in the areas of Code, Documentation, Bugfixing, Customer Queries, Outreach (blogs/speaking/etc). Developers must have training and committership in more than one project, and may move on to project-centric, or customer engagement-centric majors. Competencies need to be tracked, and gating system put in place for customer engagements, based on using this competency system. This will help keep a strong reputation for technical and product capability in field assignments.
Some of the Roles/Structures You Need
Much of what follows is stating the obvious. There is a strong bias toward the developer satisfaction theme here, since that is the element that is the most different in approach to the SSS method.
- The Project Selection Group – a small group that discusses and decides what projects to be involved in, what to pull out from, what projects to start and promote, etc. Meets quarterly and produces auditable decision trail. Revisit decisions on substantive grounds only after a test period to ensure commitment.
- The Community Manager – one committer in a project has the role of Community Manager. They have a number of responsibilities. One is as the eyes and ears of the project selection group as to the state of the project, community health, diversity, etc. Another is to help to ensure the smooth running of the project and its delivery to users, so community manager role should be strongly biased towards repeatable builds, good website material, strong demos, blogging about the project, outreach at conferences and the like. Also this person is responsible for gauging developer performance in the project (doc, code, marketing, customers). One per project. All project leads and community manager folks must blog about the project and aggregate any blogs that regularly mention it. Everyone needs to read these.
- The Doc Team – if one thing adds value to OSS, it’s the documentation. The Doc Team gets close with the community manager to see where the docs are missing, what needs to be done, etc. An enhancement to documentation on the OSS project website is a big plus to the project, but excellent comprehensive documentation is something that people will pay for.
- The Tools team – another value add is pain reduction. Hard-core developers will have no issues working directly with the OSS project elements as downloaded from the website. The great majority of developers will need tools. A dedicated team is required to produce tools and shortcuts to help customers in certain places to increase productivity. Act on feedback from the services guys, other field reps and the community.
- The Distro team – there’s a group of individuals that are responsible for keeping the distributions ticking over and building – they are responsible for nightlies, weeklies, integration builds and the eventual distribution. They make the distros.
- The Test team – team that builds integration tests that are used as smoke tests for distro quality. They also design the tests.
- Web team – don’t have one of these – outsource it, but make sure the developers can update at any time.
- Marketing Support – primary marketers in the OSS community are the developers – they are the reputation enhancers. However more advertizing-style marketing is required that is full-time. Competition is rife in these communities and it goes to the deepest level. Every now and then stir the pot with some controversy. People can’t help but respond. Don’t be destructive – keep the bridges uncharred.
- Administrative Support – office management, expenses, travel arrangements, etc are all things that developers are not so good at.
- Training/Services – competency-based tracking of developers employed to stream capabilities to customers. It is important that every developer takes some time every year to be in front of a customer.
- Legal – maximally important when engaging with enterprise customers. Consider paralegel education for developers, or at least support them where feasible. Employ lawyers who have provenance in this area.
Dealing with the Mud-Slinging
When operating (‘competing’) in the OSS arena, attacks from others can be directed towards the software, or to the organization. Challenges to the software are easily met – if they are untrue, show that is the case; if they are true, then address the issue, and make a show that you have addressed it and that your detractor will have to think of something else to complain about. Attacks on the organization are generally harder to grasp.
The top four muddy missiles are usually the following (where for X insert company name):
- X has not acted in the best interest of the community
- X has been divisive in the community
- X has been spreading FUD (fear, uncertainty, doubt)
- Our software has displaced X in every account we went into
These kinds of accusations are reputation-tarnishers and need to be addressed. Accusers need to explain their assertion, and it needs to be dealt with in the open. They will need to cite examples for any challenge. Be sure to track every single engagement with them at the customer level. Build competencies in competitor product so that you can keep ahead – delegate a team to track and build small systems with the competitor product. Competition needs to be strong and you need to be up to date all the time, and be ready with insight or analysis, indeed produce these regularly.
If you come across failures in competitive products in real-world scenarios, you need to record them and save them for deployment when necessary – for example when you get attacked or when the opponent is in a weak position. Keep references to your own successes.
Google has come up with some kind of a like-a-like called +1. For those who may have not been part of an open source development community, ever, you need to know that this convention has been in place since the internet was a child, and Google’s arse was the size of a button. The full remit of of the taxonomy goes thusly
- +1 – I agree, and thanks for saving me the typing
- +0 – I don’t really care, to be honest, but slight preference on it happening rather than not, i.e. I’m emotionally content to be part of the majority here.
- -0 – I’ve no argument one way or the other, but I dislike change, and if there’s an issue I’ll veto this bastard.
- -1 – THIS IS THE DUMBEST IDEA I HAVE EVER HEARD. I CANNOT BELIEVE THAT YOU HAVE THE BALLS TO BRING THIS UP WHEN YOU KNOW THAT EVERYONE THINKS IT IS STUPID. Divers alarums, lying down in the road and Godwin’s Law ensue (exeunt omnes)
EclipseCon 2011 started today, with an awesome program of events going on over the week. I’ve attended the previous four instances of the conference, and had the signal honour to have been the Program Chair for EclipseCon 2010. Now, alas, I’ve lapsed. Instead of getting a nice easy job after my release from Progress last year, I’ve foolishly decided to startup a software business with a couple of guys. I hope this adequately explains my somatic non-presence at this years showcase of what’s wonderful in the Eclipse world. For example – if I was in California today, I would not have been able to load the mobile part of our product on the phone of a friend-of-a-friend who just happens to be attending a concert with the CEO of a division of a large cellphone company, with instructions to show it to this CEO and get a meeting for us. But if I was in California today, I would be enjoying beers with lots of people that are much smarter and much more dedicated than me.
It’s always a tradeoff.
Now that I have a brand new ‘user’ perspective, and am on the outside looking in, there are a few items within the Eclipse Ecosystem that are particularly interesting.
- EGit – I’m using git exclusively now for source code control, and having good support is very important. I think that the real decision-maker on using git all the time are hosting services like Heroku and Nodester adopting git push workflows for application deployment.
- DSL-based mobile device project scaffolding – projects like Applause and Applitude, both based on Xtext and mobl, based on Spoofax, can give you a chunk of starting point code to get your mobile application up and running on the cheap. I haven’t taken as much time to study these as I want to – a future blog entry I think.
- Orion – when I first saw the Bespin project, which then merged with Ace and is now the development-as-a-service Cloud9 IDE, it failed to stir me. However, when I started doing some node.js project experiments, then the option of being able to edit your JS code through the browser suddenly had more appeal, precisely because now you can edit server code. It will be worth a blog entry in its own right at some point (aside – Mr. Orion, @bokowski, just linked to another one, Akshell, a minute ago)
I just realized the other day that the last piece of Java/Eclipse a programming I did was in July 2010. Since then I’ve been in this dual world of the mobile app developer – programming
native code on iOS devices, programming Rails 3 and node.js on the server end of things, pushing data into PostGIS and Redis. I didn’t think I would end up here, but it’s been fun so far 🙂 As to the future, I’ve refused to plan anything beyond world domination for the moment. But maybe I can get an Orion talk accepted for EclipseCon Europe…
I really try to steer clear of blogging about individual pieces of non-developer-oriented software, but I’m making an exception for Sparrow, a new Mac-based frontend application for Gmail. Screenshot with privacy-enhancing blurs below.
I guess the first question is, why don’t I just use the browser of my choice to read email? Well, it’s because I don’t like using the browser to read email, thanks. And since I have a number of Gmail accounts, Sparrow makes it much easier to switch, with its Tweetie-like interface.
It’s very early days for this client, so there are some glitches and sometimes the UI feels a little slow during sync. I can forgive that for a work in progress. It’s now up to the developers not to screw it by adding in piles of unnecessary features. Watch the Sparrow blog for details.