I send emails through Google Apps for Domains, so I had the following in my configuration.yml (previously email.yml):

delivery_method: :smtp
smtp_settings:
  address: smtp.gmail.com
  port: 587
  domain: substancelab.com
  authentication: login
  user_name: "foobar@example.net"
  password: passw0rd
  tls: true

I am pretty sure it used to work before the upgrade, now; not so much.

Alas, when I ran rake redmine:email:test I kept getting a

An error occurred while sending mail (SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol)

What is TLS even?

I knew this has something to do with the TLS settings, but Google didn’t reveal any concrete, working advice. Adding enable_starttls_auto: true, which seems to be most prevalent solution didn’t change anything for me.

One or the other, but not both

Only after digging deep into ActionMailer and the Mail gem did I discover my problem.

Having tls: true in the settings was messing things up even if starttls_auto is enabled. Changing my settings to

delivery_method: :smtp
smtp_settings:
  address: smtp.gmail.com
  port: 587
  domain: substancelab.com
  authentication: login
  user_name: "foobar@example.net"
  password: passw0rd
  enable_starttls_auto: true

made my email delivery work again.

File this under “blogged so you don’t have to suffer as I did”.

I'm no fan of bullshit NDAs, so I'm just sending this and I trust you that this'll not end up on Twitter or anything

I know quality has its price. [...] I don't like the wheeling and dealing either. If you say it's your rate, it's your rate

We would certainly not be against contributing back to the [open source] community

I must close this deal.

No problem, I thought, that’s doable using CSS3. Behold, it was (non-interesting styles like font color and size are removed for clarity):

HTML

<a class="button" href="#">
  Styled with CSS <small>(no extra markup)</small>
</a>

CSS

.button {
  background-color: #f98221;
  background: linear-gradient(top, #fec848, #f87d1a); /* Add vendor prefixes as needed */
  border-radius: 4px;
  border: 1px solid #eca253;
  box-shadow: rgba(0,0,0,0.2) 1px 2px 3px, inset rgba(255,255,255,0.7) 0 0 4px;
  display: inline-block;
  padding-left: 1em 36px 1em 18px;
  position: relative; /* Allows for absolute positioning relative to this element */
  text-decoration: none;
  text-shadow: rgba(0,0,0,0.3) 0.1em 0.1em 0.1em;
}
.button:before {
  background: url('icon_arrow_green.png') 50% 50% no-repeat;
  display: block;
  content: '';
  height: 100%;
  left: -2px;
  position: absolute;
  top: 0;
  width: 31px;
}

There was much rejoicing until the big blue elephant in the room reared its ugly head and pooped all over my nice and clean markup. Thank you, IE.

While IE9 does support most the CSS that’s needed for this button style, it notably doesn’t support CSS gradients. However, you can apply a proprietary Microsoft.gradient filter, which does basically the same thing. Perfect!

CSS

.button {
  filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#fec848', endColorstr='#f87d1a');
}

Unfortunately, the IE filter doesn’t work with border radius, thus the gradient isn’t rounded as it should be (note the square corners above). IE will not even clip the background gradient if we add overflow: hidden.

Introducing a clipping element

The solution is to create a wrapping element with overflow: hidden and border-radius that masks out the parts where the gradient shows through. Our markup now looks somewhat like

HTML

<a class="clipper" href="#">
  <span class="button">
    CSS, filter, and extra markup
  </span>
</a>

CSS

.clipper {
  overflow: hidden
}

This brings us really close to where we want to be. Unfortunately - although not unexpected - the arrow icon also gets clipped by the wrapping element.

Moar markup!

To work around that, we add more markup. First, we have our a element that simply works as a container for the visible elements inside it.

Inside the link, we generate an absolutely position element with the arrow icon (like in the first attempt).

In addition to that, we have our clipper element from before and inside that is a span with the text, to which we apply our actual button styles.

And boom, Internet Explorer now finally knows how to play nicely.

Internet Explorer, it is always you…

Unfortunately, Internet Explorer 8 doesn’t play nice with the above. While it doesn’t support border-radius at all, thus the corners aren’t rounded, it has a bug related to generated content and z-indexes, making our icon render beneath the button:

To work around that, we can make our clipping element a relatively positioned element with a negative z-index:

.button span {
    position: relative;
    z-index: -1;
}

This makes our button render well in Internet Explorer 8 and 9, Chrome, Safari, and Firefox with final markup and styles looking like this:

HTML

<a class="button" href="#">
  <span>
    <span>
      CSS, IE filter, and 2 spans<br>
      <small>It aint pretty, but it works</small>
    </span>
  </span>
</a>

CSS

.button {
  display: inline-block;
  position: relative;
}
.button:before {
  background: url('icon_arrow_green.png') 50% 50% no-repeat;
  display: block;
  content: '';
  height: 100%;
  left: -2px;
  position: absolute;
  top: 0;
  width: 31px;
  z-index: 1; /* Make sure the ico overlays the button */
}
.button > span {
  border-radius: 4px;
  box-shadow: rgba(0,0,0,0.2) 1px 2px 3px;
  display: inline-block;
  overflow: hidden;
  position: relative;
  z-index: -1;
}
.button > span > span {
  background-color: #f98221;
  background: linear-gradient(top, #fec848, #f87d1a);
  border-radius: 4px;
  border: 1px solid #eca253;
  box-shadow: inset rgba(255,255,255,0.7) 0 0 4px;
  color: #ffffff;
  display: inline-block;
  filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#fec848', endColorstr='#f87d1a');
  padding: 1em 18px 1em 36px;
  text-decoration: none;
  text-shadow: rgba(0,0,0,0.3) 0.1em 0.1em 0.1em;
}

The above renders like this in Internet Explorer 9:

Voila

There you go, a fully scalable link button styled primarily with CSS, using gradients and rounded corners and nearly pixel perfect rendered across browsers - even in Internet Explorer, at the cost of a little bit of markup pollution.

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.