There’s nothing more frustrating than reading an article that disparages online advocacy as “slacktivism” or “clicktivism.” Both terms derogatorily define online petitions, tweets and web messages as nothing more than feel-good measures that purport to support some kind of issue or social cause but really have little practical effect.

The ”slacker-activists as armchair do-gooders who don’t make a difference” argument has been made by the Guardian and Malcolm Gladwell, among others. Social movements with strong online interactions rarely are granted any credence compared to offline actions.

However, a few thought leaders have been recently rethinking online advocacy. In a New York Times piece last month, “Hashtag Activism, and Its Limits,” David Carr made the case that online advocacy can indeed affect real-world decisions. Carr offered several recent examples (the defeat of the SOPA bill and the Susan G. Komen incident to name a few) of how online pressure and awareness-building can create change. A Public Radio International piece on slacktivism also evaluated recent online social movements favorably. And Sortable.com’s recent infographic, “The Rise of the Slacktivist,” embraces the term and cites several examples of how slacktivism can actually lead to more real-world engagement. Check out their fantastic infographic below.

Online activism is — and has always been — a means to an end, just like phone calls, handwritten letters, and in-district meetings. Online petitions can have extraordinary reach to alert and activate tens of thousands of people around the world (or in the case of our current Thrive campaign, hundreds of thousands). A petition alone — as with any action by itself — cannot sustain a campaign or is unlikely to create change. But coupled with offline actions, media and grassroots activism, a petition can bring new voices into a campaign and help push direct action. And they are incredibly easy to share with others, so they can get passed around quickly and efficiently.

In the next two weeks leading up to the G8 summit, ONE will roll out some fantastic online actions to push global leaders to fund solutions to hunger and malnutrition. These actions, along with the postcards, petitions, #DearG8 hashtags, photos, and events are just part of a multifaceted campaign that pushes decision-makers to act. So, don’t think a click won’t count. That Facebook share graphic or the iPhone app petition has an overall affect for a campaign. To quote a trusted ONE staffer when discussing how to move US legislators, “A tweet by itself is just a tweet, but a thousand tweets are a song.”

Photo credit: Geek.com and Sortable.com

Garth Moore is US deputy director of new media for ONE and is a social media junkie. Catch him on Twitter at @garthmoore.

A friend of mine is working on a complicated publishing app; the data is
XML, perfectly appropriate when your objects are documents. She
told me they were thinking about automating some of the work by running XSLT
transformations out there in the client with
libxslt. I said “Well yeah, as long as
the client’s a PC not a tablet”. The category of “things you can do on a PC
but not a tablet” is interesting.

Anyone remember
AJAX? Now we just talk about Web apps, with towers
of JavaScript code (CoffeeScript for the
ultra-hip) built on an ever-growing library substrate (yes, there is
more than jQuery) making the browser look interesting.

It’s a good architecture! People like using browsers, JavaScript is growing up,
the Web Standards Project of yore has sort of won, and
REST keeps things nicely decoupled.

I dropped AJAX into that narrative for a reason. The ”X“ stood for
XML, which these days feels kind of heavyweight for use in Web apps,
unless you’re working with real actual documents. But when AJAX was a bright
shiny new idea, we didn’t care, because we had near-infinite power at our
disposal.

At the center of our world was a poor overtaxed Web server trying to take
care of a kazillion users’ requests. It was usually running in maxed-out mode,
while the computers it was serving were, in aggregate,
infinitely powerful, had hundreds of meg of lightly-used memory,
and typically ran with idle times averaging over 90%.

So all those other architectural advantages aside, the computer-resource
macroeconomics weren’t subtle; any piece of work you could offload from server
to client was a win.

It might still be. But there are clients and clients and clients.
Like I said at the top, you can’t run an XSLT transform on a phone.

In fact, there are lots of things you can’t do on a phone. I’m privileged
to work in close contact with platform engineers, and I’ve learned how
close mobile frameworks live to the edge of the possible. There’s no spare
memory and, since there’s no spare battery, there’s no spare CPU either.
I’m not just talking about Android, either.

This sort of sucks. There was a time when every client was a browser running
on a PC, and most PCs were in the big picture like most other PCs, and that’s
how the world was. But now, we’re in a position where client memory is very
nearly as scarce and precious as server memory. Which changes lots of things.

I’m not sure how this plays out. Right now, on Android or iOS, you can get
more out of that candybar in your pocket with a native app than with Web code.
But who knows how long that will last? We’ve got
Chrome on
Android now, and some of the phones they’re rolling out at MWC 2012 in
Barcelona constitute pretty big iron. On the other hand, you’d maybe like
your app to be available on a minimal developing-world phone too.

The one thing in the big picture that I don’t see changing any time soon is
the basic JSON-over-HTTP architecture of more or less every interesting
business app. That at least insulates the moving target running on the server
(NodeJS? Go?) from the moving target running on the client (Dart?
B2G?), and that has to
be a good thing.

Starting some time around 2005, under the influence of Perl, Python,
Erlang, and Ruby, I became convinced that application programs should
be written in dynamically-typed languages. You get it built faster, there’s
less code to maintain, and the bugs are no worse.
I’ve felt negative not just about statically-typed tools in general,
but about the Java programming language in particular. Living in the Android
world has forced me to think about this more.

The Old Argument
It’s remarkable that, fifty or so years after “Software Engineering”
joined the mainstream, we have so little consensus on these
issues. There are many people, including some here at Google, who think that
doing large-scale software engineering without recourse to static typing is
unprofessional, verging on malpractice. There are others, particularly in the
community of Web builders, who think that static typing in general and
Java in particular are evidence of old thinking and low skill.

Millions of words have been spent on this debate, but here are
a few of the highlights as bullet points; I’ll use “dynamic” and “static” as a
shorthand.

Dynamic gets systems built faster.

Static gives you a richer toolset for specifying interfaces, which
encourages modularity, particularly in large systems.

Dynamic produces less code. Less code is better.

Static programmers use more advanced IDEs with strong
refactoring support; this eases maintenance and reduces the burden of the
extra code.

Dynamic developers have a strong unit-testing culture, partly because
they lack the static-typing crutch; this supports fearless
refactoring.

The Java language in particular suffers from excessive ceremony and
boilerplate. Also it lacks important constructs such as closures, first-class
functions, and functional-programming support.

Static software supports optimizations that allow faster
performance.

Static software typically exposes shared-mutable-state threads, and
experience shows that application developers have difficulty understanding and
using these correctly.

Recent News
All that aside, I kept noticing that while I was working on Android apps,
the fact that I was writing Java code wasn’t bothering me that much. But I
couldn’t work out why.

Then, in the last few months, I’ve been working on a
revision of
LifeSaver, which involves Android code (in Java of course) and App
Engine code, which is in Ruby (Sinatra-based, via JRuby). The contrast
between the two couldn’t be sharper. And somehow I’m comfortable on both
sides.

This had been rattling around in the back of my mind like a poorly packed
object in the trunk of your car. Then
last September a gentleman named Ricardo
Bánffy, whom I haven’t met,
tweeted
It’s really interesting how writing Java for Android is not painful like
writing Java for web apps.... Which dragged it into the spotlight where I
couldn’t not think about it.

These days I’d never consider using
Java for a significant Web-dev project; but it seems a comfy fit for my
Android app code.

What’s the Difference?
I mean between mobile-device and Web-side
programming. Let’s start with API surfaces.
In a Web app, at a minimum you have to deal with:

The low-level OS interfaces: files, processes, memory, sockets, and so
on.

A persistence layer; files or SQL or postrelational distributed hashes
or some combination.

The Web machinery itself: HTTP and cookies and ETags and
authentication.

Here’s a picture:

Now you can, if you choose, load up on tangled towers of ORM and
dependency-injection abstraction and FactoryFactoryFactory joy, but these are
often part of the problem not the solution, and you can do anything
the Web can do without going near them.

On the mobile side, things are different. In order to use the device’s
facilities fully, you have to deal with those same three basic things and a
lot more besides:

Touch-screen interactions.

Telephony.

More radio interfaces, potentially: WiFi, NFC, and
BlueTooth.

A GPS and compass and maybe altimeter.

Audio gear, including speakers and a microphone.

A camera, with a sensor and lots of controls.

An accelerometer.

Last but not least, a
vibrator.

Testing
Another observation that I think is partially but not entirely a
consequence of API scale is testing difficulty. In my experience it’s pretty
easy and straightforward to unit-test Web Apps. There aren’t that many APIs
to mock out, and at the end of the day, these things take data in off the wire
and emit other data down the wire and are thus tractable to black-box, in whole or
in part.

On the other hand, I’ve found that testing mobile apps is a major pain in
the ass. I think the big reason is all those APIs. Your average method in a
mobile app responds to an event and twiddles APIs in the mobile
framework. If you test at all completely you end up with this huge tangle of
mocks that pretty soon start getting in the way of seeing what’s actually
going on.

Criteria
Let’s call them the Bánffy-Bray criteria for selecting between static and
dynamic type systems.

Static typing’s attractiveness is a direct function (and dynamic
typing’s an inverse function) of API surface size.

Dynamic typing’s attractiveness is a direct function (and static
typing’s an inverse function) of unit testing workability.

“I finally cracked it.” is what Steve Jobs told to Walter Isaacson when talking about a way to revolutionize TV. Given the usual insanity, wild extrapolation and rumor-mongering that goes on regarding upcoming Apple products, it’s no surprise that this got a lot of people excited. Aside from the typical unfounded speculation, see for example Gruber’s excellent Apps are the new channels. I think everyone that works in tech and read that sentence is still wondering, exactly, what he meant.

This reminded me of Fermat’s Last Theorem. Pierre de Fermat, in his copy of Arithmetica wrote the following in one of the margins:

it is impossible to separate a cube into two cubes, or a fourth power into two fourth powers, or in general, any power higher than the second, into two like powers. I have discovered a truly marvelous proof of this, which this margin is too narrow to contain.

The proof took over 350 years to arrive, and obsessed many world-class mathematicians since it was first proposed. While it is certainly possible that Fermat had the proof in his head, he never published it or even wrote it down anywhere, and Occam’s Razor would dictate that he had the intuition, but not the proof, and he left that down there, to put it simply, as a prank — or, if you find that somehow offensive, think of it as a challenge.

Now, these two problems are as similar as oranges and toasters, but the result is not. Whether he had “cracked it” or not, Jobs knew that throwing down the gauntlet like this was something that would be analyzed, parsed, processed, and argued over for a long time.

He knew that, if Apple had a product in development in that area, he was setting the bar for its release high enough, in public, for all to see (and this is not a minor thing).

That, whether Apple actually had a product in play or not, he was planting the seed of something larger.

That someone, somewhere, would use it as a beacon to say “Steve cracked it, so can I,” and eventually, finally, really crack the problem.

Just a thought.

Do you agree with this?:

Entrepreneurship and inequality, by Joshua Gans: So I was reading Felix Salmon’s account of a debate here in Toronto between Paul Krugman and Larry Summers. ... I was struck by this passage.

Summers also tried to defend inequality, at least in part, by saying that “suppose the United States had 30 more people like Steve Jobs” — that, he said, would be a good thing even as it increased inequality. “So we do need to recognize that a component of this inequality is the other side of successful entrepreneurship; that is surely something we want to encourage.”
Now there is nothing new in this view. It is an argument for inequality that reminds me of Ted Baxter (from the Mary Tyler Moore Show) who intended to have six children in the hope that one of them grows up to solve the population problem. The inequality version is that we accept inequality in the hopes of getting the fruits of entrepreneurship.

So no one disagrees with encouraging entrepreneurship. ... But when we link it to inequality in this way we are asking ... whether the poor (or middle class) are happy outsourcing knowledge creation and are each willing to pay a bit to see that happen.

Seen in this light, the problem of inequality is a design problem. This is something that Jean Tirole and Glen Weyl have recently investigated. They ask a related question: when is it a good idea to confer entrepreneurs with market power (as a reward)? The answer turns out to be, when the government does not know much about the nature of demand for innovative products. In this world, by exposing entrepreneurial rewards to what they can get through monopoly pricing, we screen for innovations that maximize the gap between innovative benefits and innovative costs. The implication here is that if we outsourced innovation to creative geniuses, we would do it in a way that allows them to charge high prices.

But does that carry over when there is real inequality? Let’s face it, the actual products Steve Jobs produced were not priced for the poor. The best we can say is that when they were imitated the poor received some benefits (which may also be arguable). So is it really the case that poorer people would be willing to be taxed more (by government or through monopoly pricing) in order to bring out more people like Steve Jobs? Instead, the Steve Jobs argument is surely one for a lateral wealth transfer from those with wealth — innovators or not — to be more concentrated amongst those who innovate. It is inequality in talent and skill and its mismatch to wealth that drives the argument not inequality in wealth.

It takes a village to make an iPad.

First of all, I should announce my editorship (starting
today)
of another blog, the
Android Developers Blog.
But at Google there are stories behind the stories.

Android Dev Blog
It’s been around since November 2007, way before I’d ever heard of Android.
In recent times it’s been used
somewhat like a press-release channel; each of the pieces heavily group-edited
into just-the-facts mode. Perfectly OK (if a bit tedious) when that’s
the kind of channel you want.

It seemed obvious to me that there was scope for a real bloggy kind of
blog, since there are a ton of interesting stories inside Android crying to be
told. So I said that a few times and I suspect irritated a few people, and
the upshot was I got the whole thing dropped into my lap.

Let me drive a stake in the ground: If you want to
know the actual technical substance of what’s being built here, or to read
inside-Android stories,
that blog is the place
to come, or rather
subscribe
to if you really care.

Blogging at Google
It’s hard, way harder than I’d realized. There’s this thing in the company
culture where everyone is very free with information, internally, and
expected to be very close-mouthed, externally. Within a few days of arriving,
my brain was bulging with more Really Big Secrets than I’d picked up in years
at Sun.

In fact, I now know how much storage we’re dedicating to support... hold
on, even mentioning what it’s being used for would probably get my ass
appropriately fired. And so on. There are a million stories around here and
a person like me who can’t not write is dying to tell them; but it’s really
hard to keep track of which ones are fair game.

To make matters worse, Google is interesting. Since I’ve come to
work here, my blog readership and Twitter follower-count have both ballooned,
and I’ve noticed that more or less anything we say, whether or not I think it
matters, is news.

Twitter follower count; I started at Google on March
15th. Statistics courtesy of
twittercounter.com.

On top of which there are many out there who are kind of scared
and nervous about Google, for a variety of reasons some of which are
perfectly reasonable. And there are those, including some who write for
large audiences, looking to pounce with glee on any whiff of evil or
hypocrisy. Fair enough, I suppose, since Google presents what we in the trade
call a Large Attack Surface.

Which means that Google in general and the Android project in particular
are careful, verging on paranoid, about what gets said in public.

Since I’ve been here, I’ve argued repeatedly that there are a lot of people
who would like to like us, and that there are lot of stories here
that would be good to tell; that the rewards of open-ness greatly exceed the
risks. There are people here, including some very important ones, who
are unconvinced. But they’re still giving this a chance. Let’s hope I’m
right.

One of the nice things about this job is that I’m meeting lots of interesting
startups who are doing mobile apps. My fave so far is
Bump.

Bump World Headquarters

The idea is simple: I bump your phone with mine, and the result
is that I transfer something to you; say, a phone number, or a picture, or, of
course,
money.

A good place to start getting the picture would be their
FAQ.
This is the kind of technology I like; a simple effect, instantly
understandable, that requires rocket science under the
covers to pull off.

Ah, that startup ambience. You’ll note that I erased the
whiteboards, but I can reveal that one of them contained scraps of what
appeared to be [gasp!] Haskell code.

Bump and Android
There’s good news and bad news. The good news is that they’re running on
Android (very nicely) and shipping an Android API. You can bump an iPhone and
an Android together and it Just Works, no problemo.

In fact, there are a couple of things they can do in Android that are
harder on other platforms; for example, because of the Android
Intent
feature, you can register Bump to, for example, share pictures.

Of course, nothing’s perfect. The Bump guys had run
across a couple of issues which were causing them extra work at release time,
and really shouldn’t have.
So I visited them to look at the source code so we can figure out how to set
things up so that particular bug doesn’t bite anyone else.

Practical compatibility testing at the Bump World
HeadQuarters.

Any other startups reading this, I’d be happy to get pitches. But I probably
won’t write you up here unless I’m actually going to use your app myself.

Last week I wrote
Content
Provider Iterator, which simplifies the task of dealing with Android’s
Content Providers. Reto Meier, the author of what is currently the
best
Android developer book, got
all
nervous about my approach. He’s got a point, but so do I.

If you haven’t read Reto’s piece, please hop on over there and do so; I’ll
wait till you get back.

To recap; my
providerhelper package
lets you write the following code:

Reader<Call> calls =
new Reader<Call>(Call.class, activity, CallLog.Calls.CONTENT_URI);
for (Call call : calls)
String number = call.getnumber();
I claim that this is about as idiomatic as you can possibly get, if your
idiom is Java’s flavor of object-orientation.

But On the Other Hand
Reto, and others, point out that this creates a lot of objects (one per
Call, plus one for any field you choose to store in an Object field) and does
a lot of reflection (one method.invoke() for each field you want
to extract from the Cursor, for each Call). This, they argue, will have an
unacceptable cost and flies in the face of the official recommendations on
designing
for performance in Android.

Jerome Lacoste actually wrote
some
code to measure
the performance, and it suggested that the slowdown was as much as a
factor of ten. So this is not just a theoretical problem. I guess
those people who wrote the Design-for-performance guidelines knew what they
were talking about.

Well, for some applications, anyhow. The problem is,
for others it’s not going to make a damn bit of difference.
For example, in my own app code, the delay for reading a few hundred records
out of the phone-call log, and doing a bit more work with them than Jerome
did, isn’t even measurable. (I’m working to reconcile my result with his;
something funny is going on).

At a more general level, I’d like to appeal to Knuth’s
Premature
optimization is the root of all evil. What Knuth didn’t say, as far as I
know, was the reason why his statement is true: nobody is smart enough to
predict where the performance bottlenecks will occur in any reasonably complex
application. And let’s grant that some “premature” optimization is
common practice: as in, the selection of sensible algorithms and data structures.

So, my take-away is: Yes, you have to learn the lessons Reto’s teaching and
be nervous about the things he says you should be nervous about.

Having said
that, I still believe that the right way to build an application is to do
the Simplest Thing That Could Possibly Work, and maybe it’ll be fast
enough, and if it’s not, then don’t bloody guess where the problem is, measure
it until you know.

Other Gripes
Reto and my commenters also point out that:

Getters and setters are often bad practice, and

the code isn’t thread-safe, and

developers shouldn’t have to inherit from
Builder.

Those are all fair points, particularly the one about concurrency. I will
update the package docs to include warnings about the potential performance
problems and all these other gotchas.

What Next?
I’m not sure yet. On the one hand, Reto’s arguments and Jerome’s results
are certainly sobering.
On the other, I think the problem I was addressing is real: Having read quite
a lot of Android apps source, I do think I see quite a bit of tedious ugly code
concerned with pulling fields out of cursors; the kind of thing that has
me thinking
Don’t repeat
yourself.

Having said that, I have to observe that the Google-provided apps work
pretty well and run pretty fast, and the
source code is a lot easier to read
than that of a bunch of other open-source projects I could name. So maybe I’m
straining at gnats here.

Maybe I’ll end up plastering a big Never do things like
this all over that providerhelper code. Maybe I’ll find
a way to do away with some boilerplate at a more acceptable cost.
I’m quite positive that I’ll come away a deeper and better understanding of the
Android SDK; this is by way of sharing the lessons.

The fact that this isn’t posted on
developer.android.com is a bug,
I’d say. If you’re going to
be doing any Android programming, you really need to get Reto Meier’s
Professional Android 2 Application Development.
Yeah, he works for Google (same group as me) so I’m prejudiced. Whatever. For
the moment, Reto’s book is the Bible.

I want to be able to write apps for my phone in in something other than the
Java language; for example Ruby or Python.
This isn’t one of the things my group at Google has asked me to look at, but I
think it’s worth doing and worth some of my time.
I’m writing this today because I’m amused by the contrast with the current
hubbub over Apple having
tightened
the developer thumbscrews.

Why?
I like
the libraries, but I have to confess
that these days, I’ve slipped into the camp of those who find the Java
language verbose and rigid and overly ceremonious. It bothers me less on
Android than on general-purpose computers, because Android apps tend to have a
pretty thin layer of application code between calls out to the network and GPS
and accelerometer and so on.

But having said that, I’m pretty sure that in, for example, Ruby, I could
write less than half the number of lines of code to get any particular job
done. Also, I entirely loathe
Java generics.

What Google Thinks
As usual, I’m not speaking officially for Google here, but my impression is
that if there were an official reaction, it’d be along the lines of “Uh,
whatever, we’re focused on shipping this next release.” Which is likely
appropriate; The Androiders are so zoned-in on building a great SDK and runtime
and Market that my wild-eyed screw-the-semicolon ideas are not exactly likely
to become front-of-mind. Well, unless I can show that they work.

It may come as a surprise to regular readers here, but there are vast
expanses of our profession, including some of the best and brightest, who
haven’t got the dynlang bug yet.

And the Official Policy?
That’s a non-issue. An Android app has to be an
APK file, and if
you generate/sign one of those and are in the developer program, and it’s not
illegal or porn or something, you can drop it into the Android Market.
(If falls afoul of Market rules, you can post it on your own website or some
other market, and people can still install it, no jailbreaking required.)
How you build the APK is up to you.

In practical terms, if you want it to look-and-feel like an Android app,
you have to use the
Android
SDK; but what language you generate those bytecodes and method calls with,
and how you compile it, well, why should anyone care? I’m using Eclipse,
and while it Just Works with the library and emulators and other tools, it’s
failed to win my heart.
I’m seriously thinking of going to
Emacs and seeing if I could replace Ant with Rake. And, of course,
every piece of the toolchain is open-source and thus in
principle can be forked and improved and replaced.

If what you produce sucks, the word will get around quick; having used the
official Android toolchain won’t save you. And if it doesn’t suck, not having
used it won’t get in the way.

I’m actually a little puzzled by the Apple policy; the technical side I
mean, not the business issues, which Gruber
explains
with ruthless clarity. I can see Apple wanting to enforce the use of their
APIs, but the compulsory linkage to the Objective C programming
language makes me feel like I’m missing something; where is it carved in
stone that it provides the optimal, impossible-to-improve, way to use the
iPhone APIs? And if nobody’s allowed to try anything else, how will we find out?

Anyhow, the market will decide; the big small-m market, not the iPhone nor
Android Markets. But in the meantime, I’d say we’ve got more scope for fun
over here on the Android side.

Candidates
Right at the moment the Rubyists seem to be in the lead in this race, what
with
Ruboto and
Duby.
I can’t think of any architectural reasons why Jython shouldn’t be a
candidate, except for Sun let
Frank Wierzbicki go and I’m not
sure anyone’s working on it much, these days.

Also, in theory you ought to be able to use the
Android NDK to
get the native C versions of Ruby and/or Python going. It’d be a slog, but
the idea doesn’t seem insane.

There are lots of other languages, and maybe one of them is a better bet;
My focus on Python and Ruby reflects my own prejudices, but my
mind is open. And of course JavaScript is already a first-class
citizen pretty well everywhere.

In Conclusion
Got any good ideas for how to let me write serious, shippable Android code
without ever having to do this again?
HashMap<String, List<Person>> buf = new HashMap<String, List<Person>>();

If you do, get in touch. I might be able to help you help me.