iPhone App Development Step 1: Hit a Brick Wall

This morning, I had an idea for a iPhone app. After drawing up a couple of sketches on paper – I dove into the internets to look for existing code, sample projects, or at least some tutorials that might get me started.

While I did find an extremely simple sample project that did something similar – the bulk of the research was:

Apple doesn’t allow that.

Just out of the gate and the answer is ‘No’.

So inspiring.

Combine this with all the stories of people struggling to get their application distributed by Apple – and there’s good reason for web apps were Apple’s first answer to iPhone development.

Garrick’s Web Technology History

Earlier this week – a message came through the web font mailing list referencing VRML. A painfully slow, barely usable, 3d modeling-for-the-web technology that I experimented with VRML during my time with Jeremy and da5d.

And I hadn’t heard of since.

Shortly after my adventures in VRML, CSS 2.0 supported custom web fonts as we know them today, and I did some early experiments with that technology.

These two memories made me wonder about the intervening years and the web technologies I’ve worked with since.

    Here’s what the journey looks like so far

  • 1996: HTML
  • 1997: VRML 2.0
  • 1998: Web Fonts in CSS2, more about designing with them, no tech development
  • 1999: —
  • 2000: Weblogs, more about the act of publishing with them, no tech development
  • 2001: WiFi & Tablet PCs, yes, these were some very hot Linux tablet PCs
  • 2002: —
  • 2003: RSS Feeds (more about reading them, no tech development)
  • 2004: Podcasting, First Crack Podcast, PodcastMN, etc
  • 2005: Weblogs – round 2, WordPress (WP-iCal, WP-GotLucky, WP-iPodCatter plugins)
  • 2006: RSS Feeds – round 2, Cullect
  • 2007: Twitter
  • 2008: URL Design & Shortened URLs
  • 2009: Web Fonts – round 2, Kernest

How to Make Safari Render Pre-GZipped Web Fonts

After too many sleepless nights, I’ve finally got Safari to render pre-gzipped fonts.

All the fonts in Kernest are pre-compressed on the server (in addition to saving a little bandwidth, it also saves a little disk space and a couple hairs of server performance).

I started with this post by Darren Rush on how to configure Apache to send pre-compressed files, rather than compress on the fly.

While most browsers don’t care if the server does the compressing or if the files are compressed ahead of time. Safari does. Particularly with front-end-oriented files like javascripts, stylesheets, and fonts.

If you take a look, Darren’s code – it ignores Safari (RewriteCond %{HTTP_USER_AGENT} !Safari ).

Turns out Safari just dislikes the idea of javascripts, stylesheets, and fonts using the ‘.gz’ extension.

Yep.

Pre-compress your files – just don’t name them ‘.gz’.

“you CAN’T use the ‘.gz’ extension when serving compressed CSS or JS files to Safari. It knows how to handle gziped files, as long as they don’t have the ‘.gz’ extension (it’s just that weird :)” – sopppas

The convention seems to be ‘.jgz’.

This change is fine – because all reasonable browsers look at the content-type and not the file extension. Unfortunately, the really fast Apache mod_sendfile module doesn’t pass content-type. Now those reasonable browsers now have no idea what they’re getting.

In my testing – the smaller file (~40% savings) and slower serving method is still faster than the larger file size and the faster serving method.

Ban Helvetica: The Brave New World of Web Fonts – MinneWebCon

I just received confirmation that my ‘Ban Helvetica: The Brave New World of Web Fonts’ presentation has been accepted into MinneWebCon on April 12, 2010 at the University of Minnesota.

I’ll be covering; optimizing fonts for web use, browser compatibility, licensing, and answering your questions.

Registration is a very reasonable $200.

Expertise is Declared by Others, Not Yourself

One of the ongoing undercurrents of my thinking is the concept of acknowledged expertise.

A concrete example – we’re the worst people to write our own résumé. Talking with people we’ve worked with is better.

Having others describe us and what we do is far more accurate – if only because there are more of them.

What shows up in my Aadrvark.com profile today? The request to declare what I think my friends are experts in.

trusted_friends

Talent recruiters are about to get pwned.

Big Economy by Any Measure

Too much of the popular economics news paints an economically adversarial picture between the US and other countries of the world.

Aside from the obvious issue that all economies are tied together because economic behavior doesn’t like to be restricted by arbitrary boundaries, the US economy is unbelievably larger than other countries.

3x bigger as measured by stock market capitalizations.

stocks

And by some measures, just US Exports are larger than the GDP of some countries.
exports2

It’s always nice to reset perspective.

Users are a Side Effect or Why Google’s Web Applications are Free

“I get the feeling that all of Google’s products were invented for Google to help streamline the way it does things.” – yellowbkpk

Exactly.

Just as I wrote about Google’s AppEngine last year, Google’s applications – whether Gmail, Wave, Maps, or the recently announced Buzz – are about reducing costs and streamlining their business.

In the long run – it’s significantly cheaper for Google to build the tools its employees use (especially if the same employees build them) than it is to negotiate licensing or usage feeds to someone else.

This is why the significant majority of Google’s applications are free to us non-Google employees – the cost of opening up their apps to the outside world is so close to zero, they treat it as zero. Google’s development costs were paid by their operating budget.

I feel the same way about all the products I build, Cullect, Kernest, etc – I use them and I’m building the same technology infrastructure whether 1 person uses it or a thousand.

The incremental cost of sharing it with the world at that point is, well, zero.

Importance Persists

I woke up a to an inspiring post from Michael Janssen, one of Cullect’s biggest supporters:

“Still, I hope Cullect can come back in some form in the future, as it was hands down the best reader that I had ever used.”

Wow. That means a great deal to me.

Cullect was originally built during a time of stagnation within feed readers. Since it went down, sites like Facebook and Twitter have increased the number of people comfortable with the noisy-ness of real-time publishing and processing. Simultaneously, the innovation those services once provided has also stagnated. Additionally, many of the services Cullect integrated with are also down for the count.

Though Cullect.com is down – the Cullect engine is still being actively worked on – it’s powering RealTimeAds.com

If you’re wondering – no, I haven’t used another feed reader since Cullect.