Můžete si přečíst český překlad. There is Czech translation available.
Michael speaking at JSConf 2010 (from Flicker)
You studied Psychology in addition to Software Engineering. How do these subjects go together?
In many ways. Artificial intelligence has always been the obvious intersection and remains a fascinating topic. But over the past couple of decades, User Experience, has come to the fore and emerged from a rather academic niche into a key sub-discipline of modern software development. You see product reviews now which include User-Friendliness as a factor; people expect products to be intuitive. You can only do that with an appreciation of human psychology, which means more than just speculation; psychology is an evidence-based discipline.
You wrote book Ajax Design Pattern. How you got to writing book from blogging and programming?
The book was the product of a blog post on the same topic, where I got inspired to collect ideas after seeing the Ajax term coined. People got excited, it hit a few of the right sites (Delicious Popular, etc.), and O'Reilly approached me about writing a book. I continued blogging excerpts as well as writing the entire book on a wiki. If I write another book, I would probably avoid the wiki approach and concentrate more effort on the blog, or at least a wiki with comments. It's a better way to solicit community feedback as people will rarely make edits to a long article that is mostly one man's voice. (And when they do, it's spam half the time!)
Michael speaking at JSConf 2010 (from Flicker)
You spent some time working with TiddlyWiki. It is a little bit strange project,isn't it? What do you like on it?
You like hackathons. What do you see as the biggest benefit of hackathons?
Loves me some hackathon. As a discipline, software has strengths and weaknesses, and a major strength is that you can produce something completely awesome in a single day. Or of course, many people won't do exactly that, but they'll still build something and learn a lot in the process. So hackathons are a celebration of this amazing thing we do, where we can start the day with a seed of an idea and end up with a concrete manifestation of the idea. It's going with the flow, fitting in with the nature of software development. There's also a social aspect as well, people making connections, working with each other, learning from each other. And it can be as much or as little as the attendees want - some prefer flying solo, and that's fine too. Something else about software is that you can't just learn by reading or listening. We can debate the reasons, but most developers would agree you can only grasp the concepts by rolling up your sleeves and hacking out real code. Hackathons are an ideal environment to do that, a safe place where the output is not critical and there are plenty of opportunities to get feedback and assistance.
What was the longest hackathon you participated in?
At BT, we had an agile hothouse concept where the events went for three intense days.The idea was to pull together all the project stakeholders and put real users at the centre of attention, so we could work with them and ask them to test our emerging work. We could spike ideas and come out with a plan for the next iteration. It wasn't perfect. I felt like we sometimes needed more coders to get the balance right, in an event that was heavily oriented around building real products and presenting them at the end of each day. Some also argued that it's how software should work every day, not just an occasional big bang, but I think in a complex multinational corporation, such "big bang" events are the best thing realistically. I felt the principle was sound and found most of these events to be good value for the company.
So in Osmosoft there were hackathons inside the company? Why should companies try out their own hackathons?
Yes, they were incredibly effective and we ended up running them about one a month, as Osmosoft had a wide range of internal customers and external partners. Fond memories! We'd meet the customer in the morning, usually several of them present. We'd agree on user stories and prioritise them, and then we'd get hacking. Typically an hour or two per sprint, running from 10am and presenting our work at 7pm. Between sprints, a standup meeting to sync up and plan the next sprint. Ideally, we'd be checking into GitHub or similar repo the whole time, and tweeting the event. The ultimate plan was to not only present our work, but also host the resulting web app publicly by end of play (not that it always happened in practice).
There are two important points here. Firstly, we could move very quickly, in a way that often surprised our customer. The reason was our emphasis on reuse - every new project was an opportunity to build not just a new app, but a series of components that could be used on other projects. Not grand enterprisey whitepaper visions, but a 50-line TiddlyWiki plugin that actually does something useful, today. It could be a comments plugin, a graphical editor, or a word counter. Secondly, the openness may be striking in the context of a company building new products. We could do this because we were building a plugin-based framework. Osmosoft, as an open source provider, would make the open source components and an app which is mostly just a composition of those components. BT could then come along and customise it to their own needs, just as any other enterprise (such as our external partners) could pick it up and use it too. Of course, in practice, we were part of BT and we would offer them direct support in customising and deploying the apps. But we showed open source can work for a big company, and we showed the benefits of a hackathon.
You started working for Google in spring this year as a Chrome Developer Advocate. How do you got this job? Was it your idea or have you been asked by Google?
I was invited to apply for the role by someone in Google and I then went through a standard interview process.
Chrome has support for extensions as many other browsers today. But every browser has different implementation. Doesn't make sense to create some cross-browser interface for browser extensions? To make possible for developers to write extension once and run everywhere?
The obvious upside is write once, run many; which is a huge benefit of web development in general. The downside is the risk of stifling innovation too early. While Firefox's extension mechanism has led to wonderful things like Firebug, it's also been difficult for everyday web developers to jump into and left opportunities for improvement, so it was too early to standardise on something like that. Now that Chrome has an extension framework that's easy for web developers to pick up and use, and Mozilla has JetPack, and Safari and Opera also have extension mechanisms, hopefully people will start to draw Venn diagrams and work out where we have common ground. But only if it doesn't stop browsers from continuing to innovate in this area. Chrome has recently introduced the ability for extension commands to appear in the context menu; that's one example of the kind of ongoing improvement that shouldn't be hindered by a standardisation process.
How many GDD do you visit this year as a speaker?
I will speak at the three European GDDs (Munich, Moscow, Prague), in two sessions at each: Google Chrome Extensions and HTML or Native for Mobile Development. The latter will be me alongside Android advocate Reto Meier, so it should be a lot of fun.
Have you ever been to Prague or is it your first visit? What are you most looking for?
I've not been to Prague, but looking forward to it. The best thing for me will be the pre-GDD GTUG event. Czech Republic clearly has a strong web development community, so I'm looking forward to meeting the local developers and seeing what they come up with.
Martin Hassman was interviewing Michael Mahemoff before his visit to Prague.
If you want to meet Michael at hackathon on 15th November, please register.