They compared that number to 40%, which is supposedly the amount of web browsers that “HTML5 is supported by”.

Oh really, now?

First of all, the phrase “support HTML5” is terrible - what does that even mean? To the best of my knowledge there isn’t any browser (of the big ones) that doesn’t support at least some part of HTML5 in some way. Yes, even IE6.

The problem is, HTML5 is a complex thing composed of many different parts. Some browsers support some parts better than others - some, not so much.

It’s all about games

So let’s focus.

The infographic purports that Flash is better than HTML5 for games. The HTML5 canvas is what you’d use for drawing 2D shapes and whatnot for games, so I am going out on limb here and guess that what they’re looking at is support for canvas.

Thankfully, it’s fairly easy to get statistics on the market penetration for browsers supporting the HTML5 canvas element. caniuse.com has a nifty table showing exactly that.

According to that table, 69% of browsers support the canvas element.

40 != 69 && 99 != 96 && 69 < 96

The claimed 40% is a long shot from the actual 69%. Sure, it’s way less than the 96% potential market penetration Flash can achieve.

As I wrote in my last post, I don’t really care whether Flash is better than HTML5 for whatever you want to use it for. All the more power to you - as long as you don’t claim to be making websites with Flash.

But I do care about people being mislead with made uppoorly researched numbers and claims. Unfortunately, the infographic from OneMoreLevel.com seems to have plenty of those.

I don’t care much for whether Flash is the bees knees for games, but I do care about people misleading people with data. And some of the data points depicted in the graphic didn’t quite sit right with me, so here’s an attempt at figuring at least one of them out.

Flash is supported by 99% of web browsers

Taken literally, the statement that 99% of web browsers support Flash is flat out wrong. Fact is no browser supports Flash - at least not natively.

So that 99% figure should really be a flat 0%…

1 in 5 is 20%

Okay, fine, most browsers do support a method of displaying Flash content, namely the Flash Player plugin which is available as an optional download. However, only one of the major browsers - Chrome - actually ships with the plugin installed.

If we accept third party extensions as part of what a browser supports, the correct number here then becomes 20% - ie 1 of the 5 major browsers (Internet Explorer, Firefox, Chrome, Safari, and Opera) support Flash out of the box.

25% market share

There’s still some way before we reach 99%, though. And honestly, using the number of browsers as a base is pointless (but it serves as a nice illustration that statistics should rarely be taken at face value). It is more interesting to look at browser market shares in this case.

According to the numbers from W3Counter, Chromes market share was 24.6% in January 2012. This in turn means the market share of browsers able to display Flash content out of the box is roughly 25%.

Still not quite 99%.

They do statistics differently in Flashland

Let’s assume their wording is not entirely accurate. What they probably really meant to say is that 99% of internet requests come from a web browser that has Flash Player installed. Really, that’s the interesting figure if you plan on putting out Flash content.

However, that statements doesn’t seem quite right either.

Primarily because iOS famously doesn’t support Flash. In other words, no iPad, iPhone, or iPod Touch is able to display Flash content - at least not as part of the browser experience.

According to the numbers from W3Counter, iOS devices accounted for 4.5% of internet traffic in January 2012. Thus, there is no chance that the market share of Flash-supporting browsers can be higher than 95.5%.

96%, and that’s my final offer

So there we have it, this must be the number they’re thinking of. If we assume that every internet user actually installs the optional Flash Player - and I suspect this is a stretch, but I am not sure where to get reliable numbers on this - 96% of all internet traffic could come from a browser that is able to display Flash content.

That’s a huge, potential user base.

However, seeing that the 99% figure of the infographic is incorrect, I wonder which of the other numbers are misleading as well.

For example, if we extend the above definition to the HTML5 column, I am fairly sure that the number of internet requests coming from a browser able to display HTML5 content is vastly higher than 40% - but that’s a topic for another post.

Unfortunately I kept getting

SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (OpenSSL::SSL::SSLError)

when I tried deploying. There’s nothing quite like starting the year with SSL issues…

According to this article the problem

… comes from the fact that the new Ruby 1.9 installation doesn’t find the certification authority certificates (CA Certs) used to verify the authenticity of secured web servers.

I my case, I was using Ruby 1.8 (well, REE) on OS X Snow Leopard, but the problem - and solution - was the same nevertheless.

The super easy solution is found on Stack Overflow (as always):

sudo curl http://curl.haxx.se/ca/cacert.pem -o /opt/local/etc/openssl/cert.pem

This installs Mozillas CS Root Certificates Bundle at /opt/local/etc/openssl/cert.pem, where the certificates can be found by Rubys HTTP library without any extra configuration.

Using MacPorts

As an alternative to the above, you can use MacPorts to get the bundles (as mentioned in this article):

$ sudo port install curl-ca-bundle

This installs the certificates bundle in /opt/local/etc/openssl/cert.pem.

You can then configure Ruby to use them:

https.ca_file = '/opt/local/share/curl/curl-ca-bundle.crt'

or if that isn’t feasible, simply link them up from the default location:

$ sudo ln -s /opt/local/share/curl/curl-ca-bundle.crt /opt/local/etc/openssl/cert.pem

I don’t think I have ever written you before, but there is something I wanted to get off my chest.

I just wanted to let you know, that you rock! Just the other day, you saved my customer a bunch of money - and made me look like a hero.

Okay, I realize you only did so because I had done part of the work already. And I am probably giving you credit for something you didn’t really do, but thanks to you a team of strangers had implemented features I needed and given them back to me.

Also, the way you enable people I have never heard about to take something I have created and transform into something they can use, is mind boggling.

Thanks.

Yours, Jakob

PS: I know, I know… I don’t contribute often enough, and I will some day, I promise. Soon.

Real deadlines are those necessitated by some external, unchangeable event. For example legislation, the company running out of money, the CEO having to get up in front of the world press and announce the product, or a marketing campaign kicking off.

And then there are the much more common deadlines; The Arbitrary Deadline. They are recognizable by their basis in nothing at all - other than a decision that it would be nice to have X done by this or that date.

They are often employed in a naive attempt to speed up production. The thinking seems to be “give the wizkids a tight deadline, and they’ll really dig in and program the heck out of this”.

Deadlines don’t change anything

But here’s the thing about deadlines; they don’t make things any easier or faster to implement. No matter the deadline, you still have the same amount of work to do.

If your deadline is fixed, something else has to give; either quality or number of features. The Project Triangle sayeth so.

Give up on features and the product might not be what you imagined. Give up quality and you’ll pay for it later - with interests.

I have yet to meet an arbitrary deadline that couldn’t be budged in the face of realities. Challenge the deadline before you lose your sleep over it.

psql my_database -c "COPY (SELECT stuff FROM my_table) TO STDOUT CSV" > my_file.csv

Works in at least PostgreSQL 8.4.

Facebook fetches the actual application, Chargify notifies you of subscription changes, payment gateways tell you the transaction has been accepted.

That’s fine in production where you have a public facing webserver running, but when you’re developing locally you have to jump through a few hoops.

The common approach is to setup a SSH tunnel on a remote server and use that as endpoint for the third party service. This is pretty standard business and can be handled by a service like Showoff. Personally I just use basic SSH:

ssh -vN koppen@example.com -R 3000:localhost:3000

As long as the above is running, all requests to port 3000 on example.com is received on localhost:3000.

If you’re developing Facebook apps, you can stop here. However, some third party services like Chargify and Quickpay refuse to use anything but port 80 (and 443) for their communication.

While it is possible to setup the tunnel on port 80 remotely, my servers tend to already occupy port 80, so that’s a no go.

Proxy passing

The next piece of the puzzle then becomes routing to the SSH tunnel at port 3000 from port 80.

Since my development server is already running Apache, this is painfully easy. I just created a new site, using mod_proxy to forward requests to the given port:

<VirtualHost *:80>
  ServerName tunnel.example.com
  ProxyPass / http://0.0.0.0:3000/ retry=0
</VirtualHost>

(The retry=0 option to ProxyPass prevents the endpoint from being marked as bad for a period of time if it receives a request without my tunnel being active)

With this in place, any request to tunnel.example.com is passed to 0.0.0.0:3000 on the same server, where the SSH tunnel receives it and passes it to my local development server.

Success! And the best part is, this totally makes me feel like I am bouncing connections around in Uplink.

Turns out their camcorder stores its clips in MTS/AVCHD format, and I didn’t grab all the fluff^Wnecessary files. As a result iMovie ‘11 cannot import the MTS video clips.

After reading a bunch of threads and forum posts I finally found these settings to convert from MTS to MOV files that I could import into iMovie ‘11 without significant loss of quality:

ffmpeg -i input.mts -b 185M output.mov

That -b flag took me forever to find and I finally spotted it in this thread.

I am not a video buff, so I am sure the above can be optimized, but it worked, and I am posting it here primarily so I know I can find it again.

After writing my last post I realized that what I had thought to be the path of least resistance, wasn’t. And while I knew I’d run into resistance with XCode and Objective-C as well, at least I’d be doing things the “proper” way and learning new stuff.

So I fired up XCode once again and set out to write a Mac application. The following is a bunch of notes and stray thoughts I scribbled down during those first hours - my first (well, fourth) impressions of developing iApps coming from Ruby.

• Oh dear God, so many windows. I can see why Mac/iOS developers like to have multiple 30 inch screens.
• Inline error messages are kind of awesome.

The language

• Oh yeah, I remember why I’ve tried figuring this out on more than one occasion.
• Oh no, semicolons.
• Is there something like TryRuby for Objective-C? I think it would be easier getting started not having to worry about XCode and Interface Builder and outlets and other blah.

Interface Builder

• Not sure if I should hate it or love it.
• When I rename a file via Interface Builder why doesn’t it change the import statements or other references. I thought this was what an IDE should be doing.
• Finding good, up to date introductory articles is hard, and it seems Interface Builder changes quite a bit between versions making it hard to transfer instructions from another version.

Files and structure

• I miss something like Rails to force a structure on me. Where to I put this or that file? What’s my main application file called? ApplicationDelegate? AppController? Where do I put other things, what should I name them? Arg, best practice me, please!
• Seriously, do all files simply go in the same directory?
• Using git with XCode isn’t exactly a joy. Closing all files because git has changed them is annoying to say the least.

Debugging output

• I miss a consistent, robust way to log debug output. Object.to_s and .inspect of Ruby are awesome. NSLog() isn’t quite flexible enough, ie NSLog(@"%@") fails for certain types (integers).
• A visual debugger is nice, I remember that from my Delphi days.

Installing frameworks

• Download, run something, then copy something into a project, then add build phases, then import it. Damn, I miss gems.

I am sure I’ll laugh at the above as I get more experience. But this serves a nice reminder that starting anything new is a fragile situation and we should make sure newbies are welcomed and aided into our communities.

Getting MacRuby and HotCocoa running on Snow Leopard wasn’t entirely as easy as it should have been, though. Here are some of the hoops I jumped through.

I like RVM (go Wayne!) so I installed MacRuby that way. Fortunately - for me - that was only a matter of

rvm install macruby

BridgeSupport via downloaded installer

Supposedly this is only necessary if you’re still on Snow Leopard, but you need BridgeSupport.

You can grab it from the MacRuby site - at the time of writing Preview 3 is the most recent version. After downloading it, unzip it and run the installer.

HotCocoa via Bundler

HotCocoa is a Ruby-style interface to Cocoa, basically a way to create your user interface. Unfortunately, it seems the project is in a state of limbo and the official gem isn’t the one you want.

There is an active fork on GitHub that supports 64 bit architectures and actually works, so we want that.

After messing about with this for a while, struggling with making sure I got it installed as part of RVMs gems, not the system gems, and usable via rake, instead of macrake and what have you, I ended up using Bundler for bringing in the forked gem.

# Gemfile
gem 'rake'
gem 'hotcocoa', :git => 'https://github.com/ferrous26/hotcocoa.git'

Note that rake is also added to the Gemfile. Without it I was getting a bunch of seemingly unrelated errors, but this worked in the end. Just remember to do

bundle exec rake run

to run your application. Without it, you’ll be running RVMs macrake and you didn’t install the HotCocoa fork under that.

App away

With the above out of the way, I was able to happily code my way to a working Mac app using Ruby. That is pretty sweet.

I’ve not been able to really get along with Objective-C yet, so I’m hoping MacRuby can be a gateway drug for me.