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.

If managing your to-do lists is taking up more time and effort than you spend actually getting things done, a new iPhone app coming from developers Phill Ryu and Milen Dzhumerov, designer David Lanham, and publisher Realmac Software might be the perfect solution. Tossing most iPhone UI conventions out the window along with any religious adherence to GTD principles, the upcoming Clear app is designed to eliminate the friction and complexity of adhering to systems like GTD and be as easy to use as a paper list. We were able to meet up with the team at the 2012 Macworld|iWorld to check out the offerings.

Clear has no standard navigation bar at the top or tab bar at the bottom—common iPhone UI elements. Instead, the app is stripped down to the bare minimum, with a rectangular strip for each list item. Pull the list down from the top to add another item. Swipe right to mark the item completed. Swipe left to delete the item from your list. Pinch to access a list of lists—you could keep a shopping list, a list of errands, and a list of projects, for example.






Read the comments on this post

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.

Although its copyright settlement with publishers is still in legal limbo, Google has announced that it will be starting to sell e-books through an online storefront early this summer. Like Apple and Amazon, Google's store would see it offer up in-print books obtained from publishers, which will retain their ability to set the prices for these works. But there's every reason to expect that the same storefront will be awash with out-of-print books the minute that Google can get a settlement for its ongoing lawsuit approved.

Google apparently dropped the news at a publishing industry event, sponsored by the Book Industry Study Group, and held in New York City. It has since been picked up by, well, just about everyone (many reports seem to be crediting a Wall Street Journal story for the announcement).






Read the comments on this post

Fans of Red Sweater Software's blog publishing tool MarsEdit got a surprise Tuesday morning with the release of MarsEdit 3. The most significant update to the software is the addition of a rich text editor, though those who fiddle with the HTML for their blog posts got an updated syntax highlighter. A new media manager rounds out this solid update, one that the company hopes will attract new users and get old ones writing again. 

According to Red Sweater founder and developer Daniel Jalkut, some of the features in MarsEdit 3 have been in the works for roughly 2.5 years—basically since MarsEdit 2 was released. Many of the enhancements in the new version respond to long-standing requests from users, Jalkut told Ars, particularly rich text editing. "Most of the [blog] Web interfaces and desktop competitors have a rich mode but, until now, MarsEdit has focused exclusively on HTML/markdown source," Jalkut said.





Read the comments on this post

Bento is the consumer version of popular database software FileMaker Pro. The new iPad version of the software joins the Mac version, currently at version 3, as well as the iPhone version in the growing stable of Bento implementations. At $4.99, the iPad application is 10 percent of the price of its desktop sibling, but the desktop software isn't necessary in order to make use of it.

Creating a database from scratch in Bento for iPad is simple thanks to the 25 different templates included with the software. These templates are made for people who are looking to track things like recipes, expenses, customers, and inventory. Each template can be edited to meet the needs of a specific user and can be helpful starting points. For those who want to start from scratch, there is also an option to start from a blank slate.





Read the comments on this post

One day has passed since Apple gave developers a sneak preview of iPhone OS 4.0, and already there's new (NDA-breaking) information floating around about the other 90-some features that Steve Jobs didn't discuss at Apple's media event. 
In addition to renewed evidence that Apple may add a front-facing camera and other camera-related features, developers with access to the beta have told Ars about even more tidbits buried within, essentially making OS 4.0 a piñata of API goodies for devs to beat on.

Thursday's announcement immediately turned up evidence that Apple might be adding a flash to the iPhone's camera, thanks to functions named VCaptureDevice.hasFlash, AVCaptureDevice.flashMode, and AVCaptureDevice.hasTorch. Apple is allegedly investigating LED flash options, which would make such a feature very BlackBerry-like. Additionally, the latest iPhone SDK continues to contain hints about a front-facing camera as well as iChat support.





Read the comments on this post