Start downloading books now!
Launch ShelfServer
E-Book reader for iPhone & iPod Touch

Archive for the ‘Articles’ Category

Paul Graham on the AppStore (Apple’s Mistake)

Sunday, November 22nd, 2009

Paul perfectly covers the bases and pretty much describes my feelings to a tee.

Apple’s Mistake

My experience with the AppStore has definitely tarnished my opinion of Apple.  Before working on the iPhone, I could (and frequently did) with no reservations whatsoever rave about how wonderful Apple was and how great they treated their developers.

While my iPhone development has been (in my consideration) highly successful (thank you, loyal users, one and all!) there have definitely been days I wonder why I spend a third or more of my life lately working on BookShelf.  The money’s nice, no doubt (again, thanks!), and I’m currently typing this from my new home, the down payment on which was paid entirely from AppStore proceeds.

Money notwithstanding, I have trouble summoning the same rave reviews that once so freely came for Apple and their development ecosystem.  Often is the time where during lunch at $DAY_JOB, I find myself ranting about some recent roadblock.  My co-workers (mostly Linux & a few Windows heads) occasionally call me on it.  I still have the Apple fanboi gene that makes me want to backpedal and make apologies; but they’re hollow, and lately I don’t even bother.  Apple’s second biggest strength to me was always how well put together the development environment was and how easy it was to build compelling apps using it.  (The biggest strength was of course the well-integrated, JustWorks™ platform they provide.)

Working within the restrictions of the AppStore is outright frustrating, and nobody benefits from it.  Crap apps still infest the AppStore. Several high-profile security related issues in less-than-legit apps have hit the media and even the courts lately.  I spend inordinate amounts of time tip-toeing around functionality that I *know* the phone has (Apple’s apps do it, and class-dump tells me so), but I can’t touch them because it’s “undocumented.”  And worst of all, buggy, outdated versions of BookShelf sit in the AppStore for weeks or months at a time, in part because the review process takes so long, and in part because I find myself rolling one development cycle into another without even bothering to submit since it’s such a pain.  I’m honestly not prepared to run branched development while waiting for an approval, but neither can I sit on my hands and do nothing for the month it typically takes to get BookShelf approved.  I’ve had cycles where the app was rejected, and I end up just ignoring it and continuing on for the next cycle since I’m already too far in to unroll my changes.  Yes, I should learn not to fear branching, but still…

Paul sums up nicely the change in attitude towards Apple describing his feelings on buying the latest iMac recently:

I felt the way I’d feel buying something made in a country with a
bad human rights record. That was new. In the past when I bought
things from Apple it was an unalloyed pleasure. Oh boy! They make
such great stuff. This time it felt like a Faustian bargain. They
make such great stuff, but they’re such assholes. Do I really want
to support this company?

The last few weeks have seen several high profile developers call “I quit!” over various AppStore frustrations.  Now don’t worry, because I’m not quite ready to throw my towel on the pile yet.  Still, the platform can only suffer when hugely talented, highly dedicated, long-time Mac developers decide that Apple’s phone is just too much trouble to work with. 

There’ss no shortage of good, easy to implement suggestions out there that could fix many of the AppStore’s problems.  One of my personal favorites is the idea of building a “reputation” with a series of good releases and simplifying or omitting entirely the approval process for those apps, subject to strong sanctions for abusing that trust.  BookShelf’s been in the store since day one, and as far as I know, it hasn’t ruined anyone’s phone…

Espresso Live Preview with Chrome, hold the Copypasta

Wednesday, April 29th, 2009

It seems like ages now that I’ve sought the “perfect” website design tool. Ever since the dark days of FrontPage, I’ve loathed HTML generators with their bloated markup and non-standards compliance. Still, while hand-coding XHTML is clearly the One True Path to Enlightenment, I’m no Buddha; and being able to do things WYSIWYG from time to time is a nice crutch. At the very least, I need a quick at hand live preview so that while I walk the Eight (below the) Fold Path, I can get a feel for what my page looks like as I’m writing it.
I spent a few weeks not long ago searching out Mac web design tools and putting them through their paces. I looked at full WYSIWYG tools like Sandvox and Rapidweaver, but both were a bit too invasive in terms of site layout, and neither allowed mixing rich text editing with manual markup creation while still providing a constant live preview.
I’ve always got my beloved TextMate to fall back on for markup editing, but Apple-Tabbing and hitting refresh in a browser isn’t exactly what I have in mind for live preview.
I tried out Coda for a while, but decided to Refrain from that. Nice enough, but not quite. Finally I settled on Espresso, in part because it finally unlocked in the last MacHeist, but more because I already fell in love with MacRabit’s CSSEdit which I still use extensively for editing pages that haven’t quite turned into “sites” of their own yet.
Espresso’s not bad, all told. It’s got live preview which you can tear off into its own window. It would be nice if you could dock the preview window to the top or bottom of the editor, but so be it. Espresso doesn’t have any kind of rich text editing, but with the rapidly updating live preview, I can pretty much live without that. I still write better markup than any generator I’ve ever run into.
Still, I was left with the problem of chrome. Espresso does make some valiant effort to preview script files like PHP, but it took one look at my pages and curled up in a ball whimpering in the corner. So I write complicated PHP pages…. It was about that point I decided to scrap PHP for the content pages in the site anyways, so no biggie. But the last thing I wanted to do was end up with all the chrome on every single page. What a maintenance nightmare…

Instead, I came up with a publishing process which applies the site chrome to bare XHTML pages as the site is uploaded. Each page is well-formed XHTML which has an html and mostly empty head tag (the title is set in each page), and a body tag with only the main (center) content of each page. All of the top/side navigation, colors, CSS, etc. is left off.
I wrote a bit of Ant script which prepares the XHTML pages before upload. I went with Ant mostly because it’s the devil I know very well, being a Java coder by day. Bash, Perl, or <insert scripting language> would surely have served just as well. The Ant script compiles and executes a few Java classes which connect to my MySQL server to get news and FAQ’s which are output to XHTML snippets using Freemarker templates (again, the devil I use every day). Finally the Ant script executes an XSLT transformation on all of the XHTML files to apply the chrome and output static HTML files which contain all of the chrome, ready to upload.
This way I only have to update the chrome in one place, but I still don’t need any scripting on the webserver to display everything. All of that’s great except that live preview only ever shows black text on a white background. Not too helpful that. Today I finally found the missing link.

It’s always been in the back of my mind that web browsers can apply XSLT transforms to XML files on the fly when they load them. The Daily WTF’s XSLT Mandlebrot reminded me of that this morning. As it turns out, the Safari-based live preview in Espresso honors XML processing directives as well, and so my prayers were finally (mostly) answered.
I had to tweak my XSLT a little bit to make it work. It appears that Safari only has an XSLT 1.0 parser whereas Firefox happily takes XSLT 2.0. Fortunately I didn’t have to change much to make 1.0. I had to default some of the xsl:param elements that are normally sent in from Ant to sensible values and also rename all of my source files from .html to .xhtml to get everything to work.
The final result is that I have plain XHTML files with no chrome and live preview WITH the chrome appearing in Espresso. I can edit the basic XHTML files; and in less than a second, the preview updates with all of its chrome-y goodness. The changes to make it all work are pretty minimal.
First, the web pages themselves: All pages must be well-formed valid XHTML. A minimum example looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
<?xml-stylesheet type="text/xsl" href="apply-style.xsl"?>
<html xmlns="">
<link href="style.css" rel="stylesheet" type="text/css"/>

<div>Put your main content here.</div>

The file starts with an xml declaration and the XHTML doctype followed by an xml-stylesheet processing directive. That’s where the real magic happens. That directive points to an XSL file in the same directory which can process this page’s XML to create the final page. Below that are the rest of a simple XHTML page. The link to the CSS fools Espresso into thinking that there’s a stylesheet that can be edited and overridden for this page. The link element is actually replaced by the XSLT, but it does the job of allowing the CSS to be edited. Finally inside the body is the main content of the page, no chrome required.
The XSLT file that brings the whole thing together looks something like this:

<?xml version="1.0" encoding="UTF-8" ?>
xsi:schemaLocation=" dtd/xhtml1-strict.xsd"

<xsl:strip-space elements="*"/>
doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
cdata-section-elements="html:style html:script"
<!-- Default is just copy everything. -->
<xsl:template match="@*|node()"><xsl:copy><xsl:apply-templates select="@*|node()"/></xsl:copy></xsl:template>

<xsl:template match="/">
<title><xsl:value-of select="/html:html/html:head/html:title"/></title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta name="description" content="EBook reader for iPhone or iPod Touch"/>
<meta name="keywords" content="iphone,ebook,e-book,reader,electronic,ipod"/>
<link href="{$httpRoot}style.css" rel="stylesheet" type="text/css"/>
<div id="header">
Header stuff goes here.

<div id="content">
<div id="maincontent">
<xsl:comment>=======Main Content Starts Here=======</xsl:comment>
<xsl:apply-templates select="/html:html/html:body/*"/>
<xsl:comment>========Main Content Ends Here========</xsl:comment>

<div id="sidecontent">
Side-nav content here

<div id="footer">
<div id="copyrightdesign">Copyright © 2008-2009 Zachary Bedell. All rights reserved.</div>

The above template is greatly simplified, but it gets the idea across. The real version has code to include the XML files containing site news & FAQ’s where appropriate, a template which calculates the correct value of {$httpRoot} based on the current sub-directory level, and some other BookShelf specific stuff. When I need to update the chrome for the site, the XSLT is the only file I need to touch (plus maybe the CSS if it’s a formatting change). Once the XSLT is updated, re-running the Ant script generates new HTML files and SCP’s them up to my Mac Mini webserver.
To make all of this work in Espresso, you need to … do nothing. Just open or create a project for your files, open an XHTML file and launch a live preview for it. Done!

Obligatory App Store Complaint

Tuesday, April 21st, 2009

And it’s not even my own rant.  Just a link to someone else’s:

[…] but when Apple ties my hands behind my back and lets users punch me publicly in the face without allowing me to at least respond back, it’s hard to get excited about building an app.

The desire to link that that post is actually what pushed me over the edge to finally setup WordPress on the site.  Mr. Murray rather tidily sums up most of my major frustrations with the app store.  The number of, “I couldn’t figure out how to do foo!  This app sucks!” reviews I’ve read is disgusting.  Of course none of them ever bother to email me or post in the forums…

If you’re reading this contemplating a review, please for the love of Steve, at least drop an email to support at iphone bookshelf dot com first.  If I can possibly help you I will.

Copyright © 2008-2009 Zachary Bedell. All rights reserved.