Chrome Boilerplate

Chrome Boilerplate at GitHub

I made a boilerplate for Chrome extension and app development this morning. Although the Chrome docs are great, one of the pain points is you need certain fields to be filled out in the manifest, and you also must provide icons, even in development mode. And it’s not really documented which size icons are mandatory, or whether it will resize. So to kickstart Chrome extensions/apps, you can use this boilerplate.


This is a boilerplate for Chrome app, extension, and theme development. It
should be easy enough to get started even if you've never built a Chrome
extension before by following the INSTALLATION notes.

Most of the boilerplate is scribbed together from the docs at
http://code.google.com/chrome/extensions and the icons auto-generated at
http://faviconist.com. It's all MIT-licensed.

INSTALLATION

  The boilerplate works out of the box, so start by installing it in Chrome:

  - git clone https://github.com/mahemoff/chrome-boilerplate.git my-project-name
  - Visit chrome://extensions and expand "Development mode" (top right).
  - Choose "Load unpacked extension ..." and point to the new project directory.
  - It's installed! You should see a new button in your address bar. Click it!

CUSTOMIZATION

  By default, most things are commented out - uncomment them to make them active.

  UI Exposure:

    Your extension can be an app, an action (address bar popup), or a theme,
    but it can only be one of these. Or if it does other stuff, maybe it won't
    do any at all. So at most only one of these can be uncommented.

  Permissions:
  
    For convenience, these are mostly selected by default (except "experimental",
    as it requires you run Chrome wiht a special flag). Be sure to comment out
    what you don't need - i.e., most of them - before distributing your extension.

  Locales: 

    A basic locale setup is included, with English declared as the default
    language. This won't do any harm even if you're not planning to localize your app.

WHO MADE THIS?

  Michael Mahemoff (http://mahemoff.com). I was previously working in Google's
  Chrome team, but am no longer at Google and this is not an official
  Google/Chrome project.

KISS Principle Applies to Users *and* Developers

This week, Netflix re-branded its DVD-by-mail business into a separate division, “Qwikster”. The announcement isn’t too direct, but it’s clear they see these as different businesses with different constraints, there are different licensing issues involved, and will probably spin off Qwikster at some point.

Keep It Simple, Stupid is certainly a vital way for large companies to ensure they continue innovating. I’ve seen this in more traditional industries. When everyone in sales fights nail and tooth to retain every weird component and configuration, you get short-term wins at the expense of long-term innovation.

But there’s a challenge applying “KISS”: Keep It Simple, sure. But Simple for whom?

Qwikster keeps it simple for Netflix. Bully for you, Netflix. It doesn’t keep it simple for the customer. In fact, it makes it dramatically more complicated for the customer, doubling the number of places they need to manage movie queues and payments. From a customer’s perspective, Netflix was a place to keep a list of movies they want to see, regardless of the medium. If anything, it would make sense to add media, e.g. TV and cinemas.

So the simplicity of KISS is masking the important question of perspective. We need to separate “simple from user’s perspective” from “simple from developer’s (or company’s) perspective”:

(where UX===User Experience and DX===#devexp===Developer Experience)

My own story is this. WebWait and ListOfTweets started life as a single file, and even when they went live, they were just static content. “Single Page Apps” with no server at all. That’s wonderfully simple for me as the developer – I can develop on any computer without even setting up a server.

But this is KISS for the developer, not the user. The user is oblivious to the server’s architecture, and they could receive precisely the same experience if the server was running PHP or anything else. In fact, the static-ness actually inhibited features, because it ruled out any server-side smarts. Specifically, server-less web apps can’t store anything permanently (they can only use client-side storage) and can’t communicate with the rest of the world (something which is less important thanks to JSONP and CORS, but still necessary for many applications).

At some point, I realised WebWait should capture snapshots, so I refactored the server to a Ruby Sinatra app, and added data persistence, which happily lets people link directly to a recording:

[blackbirdpie id="116743589337378816"]

A server with a database is more work for the developer, but still keeps things simple for the user, and because of the more complex framework, enables more useful features for the user. We could say the same about Netflix: If they’d been willing to deal with the extra complexity of the two business lines internally, they could continue to make things seamless for users.

Comparing CoffeeScript and Kaffeine

I’ve recently been Node web programming and as a long-time proponent of DRY, I’m more than happy about the Alt-JS movement that has taken the webdev community by storm over the past six months, along with alt-HTML and alt-CSS.

We used CoffeeScript and Less for HN Reader. Faviconist is built on Jade for HTML, Stylus for CSS, and Kaffeine for JavaScript. I’m now doing a project in CoffeeScript for comparison, and because I found Kaffeine wasn’t as much of a finger-typing saver as I’d hoped for. Also, CoffeeScript has a huge ecosystem at this point. There are definitely great things about both, and indeed they are more similar to each other than either is to JavaScript, and they both make JavaScript a lot more DRY and pleasant to deal with. But let’s look at the differences:

Kaffeine pros:

  • Kaffeine has the major benefit of maintaining line numbers. With CoffeeScript, any error messages require a little thinking in order to track down the bug. Sometimes I even have to manually compile the CoffeeScript to track down the errant code (some of the various ways I’m using CoffeeScript only ever serve the JS, or keep it in memory, rather than ever saving it).
  • Retains ternaries, which, being symbolic, are more to my liking than the “if then else” CoffeeScript idioms. (I like symbols for code structures because what words remain are those that matter, i.e. those related to business and application concepts.)
  • Has a number of nice “coding in the small” idioms which aren’t present in CoffeeScript, especially the pipe and async. The latter lets you create a traditional “sleep 1000″ on its own line, giving the illusion of synchrony.
  • Doesn’t impose Python-like significant whitespace. Actually, I’ve come to like this about CoffeeScript (see below), but there’s certainly a learning curve until you get how to handle the various situations, which doesn’t need to happen with Kaffeine.
  • Truly JS++. The Kaffeine compiler will compile a regular JavaScript file just fine. With CoffeeScript, although the language aspires to be “it’s just JavaScript”, standard features like “function” keyword are simply not part of the syntax.

CoffeeScript pros:

  • There’s one extremely compelling reason to choose CoffeeScript right now, above all other dialects: The ecosystem. There’s exponentially more docs (the core docs themselves are great), more existing code, and more tools in CoffeeScript, than any other dialect. (Just as the ecosystem of JavaScript is in turn exponentially bigger than that of CoffeeScript.) Don’t get me wrong. It’s great that other dialects like Kaffeine are out there pushing the barrier, and even the less JavaScripty tools like ClojureScript and Dart which treat JavaScript more like a virtual machine. And because they all compile down to JavaScript, you can use them today. But if you want to ship code fast, CoffeeScript is the sweet spot right now: The benefits you’d want in a “JavaScript++”, with best support and minimal effort to integrate it into projects. There are already several CoffeeScript books in the making, for example. StackOverflow registers 600+ questions about CoffeeScript, while other dialects are in the single or low double digits. (And 130K questions about JavaScript, to prove my point about CoffeeScript still being a minnow in the big JS sea!) There are also an increasing array of tools where CoffeeScript support comes out of the box, e.g. connect-assets.
  • For a related reason, CoffeeScript may be the most future-proof dialect out there. Though we can expect JS.Next to learn from all the dialects, it’s clear Brendan Eich is paying close attention to CS:

  • The syntax is best described as relaxing! (With apololgies to CouchDB.) I initially balked at the significant whitespace, but now I appreciate its ability to wipe out curly braces and parentheses. It’s just nice to define hash literals without commas and braces, for example.
  • Operators like “isnt” and “unless” make the code much more literate. Why add extra baggage? Because to a computer “5==count” is the same as “count==5″, but to a human, there’s always a context which makes one more natural. See Yoda Conditions. These kinds of expressions help avoid double negatives too.
  • Class construct, which like everything, “de-sugars” to regular JavaScript.
  • There’s a reverse compiler. Nice if you want to fork an existing JS library or code example.

I’m still not done yet. While these are “just” dialects of JavaScript, each has a sufficiently large feature set that it takes a while to get the hang of everything, when you’re using them in real-world projects. So I’m still jumping back and forth between my code and the doco to make sure I’m getting full benefit of both.

A few caveats about JavaScript dialects:

  • As I’ve already pointed out, JavaScript is still vastly more standard than any dialect. While Dart may come to Chrome in the future, and various features will morph into JS.Next, you’re always going to be doing more tool integration and working with less docs. If releasing open source, you’ll want to distribute the JS or at least make it easy for someone to generate it. What’s good though is you don’t have to learn something completely different, so it doesn’t become a maintenance issue. You could easily hire a JS developer to maintain a CS app, they’ll be up and running in a few.
  • All create extra overhead in terms of tooling. Whether you’re dealing with a browser or Node, both of those deal in the currency of JavaScript, and some conversion must take place.
  • There are many situations where you still have to use plain old JavaScript. For example, working with legacy code or other people’s JavaScript. Writing inline script tags or dynamic code which will be eval’d in the browser (unless you also want users to download the CS compiler). You’ll need to get used to switching between the two, and that’s painful because once you start working with them, trust me, you WILL NOT want to go back. (This has been true for Jade vs HTML and Stylus vs CSS as well.) So I’m often having to consciously ask myself what I’m coding in right now.

Three New IT Job Titles at Tipping Point

Matrix Architect ftw

Says Tim O’Reilly:

I was in a meeting with the CIO of large financial firm a few years ago, and he made an important comment. He said something like “We don’t need to know about new technology. We need to know how to change the company organization to take advantage of new technology.” The organizational impact of new technology involves new skills, new job descriptions, and new ways of thinking about old problems. The job of “data scientist” didn’t even exist a few years ago. Now it’s one of the most important roles in a cutting edge organization.

The New IT Jobs

#SeedCamp Product Day finished up with a master class on community management from SoundCloud’s @David. David is a community manager, and another I know is GroupSpace’s @shevski, who first explained the role to me. Here are people working daily in roles which really didn’t exist a few years ago. Sure, there were related ancestor roles, but these new-breed community managers spend every working minute dealing with tools and experiences foreign to someone a few years ago.

There are new job titles which are creating competitive advantages for startups over their enterprisey counterparts. They are not postmodern titles from 1998 (“comptroller of nerfball”), nor are they stand-in titles (“director of e-marketing who is still reporting to the same boss in just marketing”). They aren’t wannabe-important titles (“local social media expert”) and nor are they zombie consultant talk (“lean theatre mouthpiece”). These new job titles are significant because they represent new areas of resource allocation in the industry.

1. Data Scientist

Combines skills from statistics, mathematics, computer science, business analysis, econometrics, product development

Data science has been explored in the following places:

ReadWriteWeb: Jobs for Data Scientists Explode Across The Market

Data Scientists Turn Information into Gold

Conferences. There’s O’Reilly’s Making Data Work conference, and O’Reilly have also been busy exploring data science. a Data Science Summit, GigaOm’s Structure Data .

Data science is about dealing with “big data”. Recording all the info, because it’s so cheap to do so, and mining it later on to gain insights. There’s a big component of technical know-how involved in scaling operations, taking advantage of elastic scaling, NOSQL data stores, and optimal algorithms like map-reduce. It’s also about interpreting the data to a useful end. A great example is Google Flu Trends, where Google discovered its search data could predict an outbreak of influenza 1-2 weeks before authorities detected it!

Big data doesn’t have to mean big company. Lately, I’ve been focusing on the world of lean startups, where optimisation and validation is the name of the game. In particular, a obsession with data-based experiments, often in the form of a-b tests. Any entrepeneur worth their salt can have a crack at it, but for serious optimisation, an expert is needed. A data scientist. Even 37Signals, the flagship brand of the lean Software-As-A-Service model, now has a data scientist on board. And look at the results of their recent A-B tests. The data scientist role has certainly paid for itself.

2. Developer Relations (Developer Advocate, Technical Evangelist, Platforms Manager)

Combines skills from programming, marketing, technical support, and public relations

Using its related name, “Developer Evangelist”, you can see how this has risen over time:

This would be the role I know best, being that which I worked in at Google, and also at Osmosoft although it wasn’t my job title and I didn’t think of it that way at the time.

There’s a big fat head and a very long tail of platforms out there, which developers can tap into. At the top end, they are 800 ton platforms from 800 ton players. Microsoft’s .Net platform, Google’s Android, Apple’s iOS, Amazon’s elastic cloud, Facebook’s Connect, Twitter’s OAuth. These guys pump {m,b}illions into their platforms and are betting on adoption. In the middle, a boatload of APIs where you can access news, send text messages, and stream music. As well, there are developer-facing tools like IDEs and hosting. And in the glorious long tail, there are open source libraries, novelty widgets, even ahem RESTful random number generators.

The reasons for wanting adoption certainly vary. Some companies charge developers a fee, so the effect on bottom line is very direct. Other companies receive indirect benefits, by way of improved adoption of their core services. Apple and Google both want adoption of their mobile platform because – for all the talk about screen sizes and home screen capabilities – apps are arguably the no. 1 decision factor when customers choose a smartphone. People will buy a phone on the basis of it having a single app. Conversely, try selling a modern smartphone without a Facebook app. Good luck with that.

Whatever the business model, one thing is certain: Where there’s a major platform, there’s a company who wants people to use it. And this is where developer relations comes in. Developer relations has several components to it. Evangelism is the most obvious – “sell” the platform’s benefits. This can be done with great demos, especially those from third parties. Also with captivating data about the benefits developers will derive – promoting the market size, ease of implementation, etc.

But evangelism is a blunt instrument. These days at least, you have to treat partners and customers as intelligent entities, so developer relations is much more than evangelism. It’s also about advocacy, which means advocating for the developer, not just the boss man. This means partnering up with developers to produce demos which will not only excite other developers and users, but will also inform and evolve the product. That is, it’s a two-way relationship, and a solid developer relations programme pumps as much information into the organisation as it pumps out. It doesn’t happen much today, but devrels should ultimately be owning And there’s also a straight-out technical support component – supporting the long tail development community online and at events. For this reason, sourcing developer relations folks is a challenge.

“Developer Experience” is where this is headed in my view. Overall, DX is User Experience applied to developers. A holistic way for platforms to say to their developers, “what do you want to do and how can I help you kick major butt?”. The future of this role is “Developer Experience Manager”. To quote someone who knows devrel inside-out:

I have learned to not take a job with dev advocacy unless you *own* the developer experience: in ref to http://t.co/ZTO22d2 by @ade_oshineyeless than a minute ago via Twitter for iPhone Favorite Retweet Reply

It’s true that a fertile market will always drive developers to it, even if the developer experience is poor. This logic is backed up empirically; Facebook recently won the dubious “Worst API” award, and we know that didn’t stop a gazillion agencies and farmville wannabees jumping on board. Even so, they have a big push on to improve developer relations, as evidenced by 9 (at present) job postings under “developer relations”, increased presence at developer events, and their very cool new integration with StackOverflow.

I’ll close this section with an expert opinion from a leading software company about the importance of developer experience. No, really. MS may have pissed off a dev or two, but back in the day, they worked tirelessly to make the platform developer-friendly, and a giant universe of applications was a key ingredient in their rise to the top.

3. Community Manager (Customer Relations, cringeSocial Media Expert)

Combines skills from product development, public relations, and tech support

This is a new role for most companies, but actually a very obvious one when you consider the enormous amount of user-generated content and conversations surrounding any popular product or service. You could draw its roots in the Cluetrain Manifesto. Markets are converastions, whether companies like it or not, and they need to take part in the conversation.

@David’s done a great job explaining the role in his talks, and a few key points are: being authentic (acknowledge problems), help the user community be part of the growth story, go where the conversation is (Twitter, offline, wherever…not just the corporate sandbox). It’s somewhat paradoxical that this role exists at a time when individuals inside a company are more transparent than ever (another Cluetrain phenomenon). But the reality is that the sheer volume of conversation is overwhelming for people who have a job to do.

A lot of this applies to developer relations too.

Are We There Yet?

Of course not. Part of the fun of this industry is the dynamic nature of roles and processes. These roles will be old hat in 5 years and there will be a ton of new ones for companies to take advantage of. Just for fun, some speculation: * Code Mixer: A “developer” who doesn’t build fresh code, but patches together products by mediating between open source products (GitHub) outsourcing websites (eLance), contest websites (99Designs), and component distributors (themeforest). * Software Archeologist: An investigator of corporate and open-sources code corpuses, with the aim of discovering principles, patterns, and metrics. Not a new concept, but one that will gain momentum thanks to the “big data” movement described earlier. Listen to this StackExchange podcast about the topic, and read this book. “Joel requires that you read this book, because its the first one to take a scientific approach to making software as opposed to the subjective and anecdotal way that most have in the past”. * Information Visualiser: There’s a proliferation of data about how a company is performing, be it a/b test results, continuous integration builds, or real-time social conversations. Tools are starting to emerge which can deal with this complexity, but these tools need to be combined and configured in ways to meet the companies needs. Sure, there can be individual tweaking, but someone needs to take responsibility for the overall platform and provide sensitive defaults and guidance. Developers will certainly want different dashboards from CEOs, and don’t get me started about the information needs of Data Scientists, Developer Advocates, and Community Managers!

What other weird and wonderful jobs are you seeing, or you think we’ll see in the future?

Amazon Tablet: Apps or Not?

Was just listening to B&A covering the new Amazon tablet. According to their speculation, it will be a different kind of Android for several reasons:

  • It will not present itself as Android any more than OSX presents itself as Unix. Androidness is abstracted away.
  • For this reason, it may be a fork, not a customisation. If that’s so, we’ll get the usual divergence over time and devs will have to choose which to target.
  • Amazon will benefit from a massive collection of pay-ready user accounts. No signup wall. This was the same for Apple when it built the App Store after 4 years of gathering accounts via iTunes store.
  • Amazon wants to have a hand in app descriptions and pricing. While Marco says this “crosses a line”, he’s coming from a very different place than most developers, who would probably benefit from Amazon’s experience in this area.
  • Amazon’s record of developer experience on Kindle has not been sterling. Very low level and few apps. However, e-ink is not ideal for apps, and their ambivalence may be because they’re gearing up for the tablet instead.

The big question is binary: Does Amazon see the tablet as an app machine or not? If so, history (books, every other physical product, global expansion, Kindle, EC2 AWS) indicates they will do what it takes to make it a success.

Mentoring and Judging

I’ve been blogging about some of my own projects lately, but wanted to capture/announce/disclose/link a few other things I’m please to be involved in:

  • I’m now a technical advisor to MinuteBox. I’ve been singing these guys praise since I discovered the product at SeedCamp last year. The concept is so damn useful and the founders are capable of delivering on it, so I’m proud to be associated with it.
  • Judged for Node Knockout. Did so in its inaugural year in 2010, and again this year, now from the perspective of someone who’s Noding daily. My votes.
  • Judged for HTML5 Open Call, for GDD Russia. HTML5 Canvas and SVG galore! Actually, it was great to see an upswing in SVG use…really, it has a lot of benefits over canvas in some cases, and it seems people are beginning to see it.
  • Mentoring at SeedCamp next week, as I did last year. Looking forward to seeing what’s new, and I’m pleased to have made lasting connections at the last event (MinuteBox being one of them).
  • Mentoring at GammaRebels next week (remotely). Looking forward to this event too. Polish startup community is thriving right now.

Make Your Own Google Plus Feed

Plus Feed

Background

I recently mentioned why I like feeds as a developer:

I know RSS has been dead since 1982, but I’m still finding it very useful for powering status updates on my homepage (http://mahemoff.com). Whether Twitter, WordPress, Posterous, Lanyrd, Plancast, I know I can always scrape the most recent item with a one-liner.

It’s not clear if and when Google will release RSS feeds for Plus, though the comments there certainly indicate they’ve given it a lot of thought. There’s really too many variables to make speculation anything more than a fun discussion in the pub.

Fortunately, Russell Beattie has stepped up to make a third-party feed service, PlusFeed. but it seems to have been hammered in 2 waves: first, by an army of hungry feed bots; and second, by an increase in App Engine pricing. Even at this early stage, it’s costing $35/day, though there are probably optimisations possible as referenced in the comments. (UPDATE: Russell’s service is now offline due to the price whack, but the open-source project lives on. Follow the instructions here to roll your own for free.)

In any event, since I’m using PlusFeed for my homepage, I want to be sure it’s running, so I wondered about writing my own feed service. But in a second stroke of awesome, I don’t have to, as Plus Feed is actually open source.

Install A Feed Server on Google App Engine

It’s very easy to fork and deploy PlusFeed, even if you’ve not used App Engine before …

  1. Sign up for an App Engine account if you don’t already have one, and install the Python SDK. I recommend running the GUI for ease of use.
  2. From your App Engine dashboard, hit “Create Application” and give your feed a unique name. Let’s say “whataplusfeed”.
  3. Download Russell’s project: git clone https://github.com/russellbeattie/plusfeed.git. (You may wish to fork it on GitHub so you can maintain your updates.)
  4. You only need to make two changes – here you can see what I did. Specifically, change the project name in app.yaml to “whataplusfeed”. Then in plusfeed.py, replace the “idurls” regular expression with your own plus ID (the big number you see in your profile URL, e.g. https://plus.google.com/106413090159067280619/posts).
  5. Import your project into the GUI, test it locally, and deploy it! Now your personal Plus feed is running at http://whataplusfeed.appspot.com/<your-plus-id>

You could easily whitelist a handful of IDs too, e.g. for all the staff in a company or a group of friends. Or you could just use the original project as is; it would make a nice public service, but unless a lot of others step up too, you’re going to be liable for big bucks once the feed bots find your server. In any event, you can choose which feeds are offered by providing an appropriate regular expression in plusfeed.py (step 3).