Introduction

In my previous project we decided to separate our single monolithic application into a main app, an app for auth and an app to handle content delivery.

The content in this case were the questions that made up online tests. The main app would allow the test taker to view their tests and results and to begin a test, and they would be redirected to the content delivery server to do each question that made up the test. When the test was complete they would be redirected back to the main app.

The auth server handled all authentication – the user would visit the auth server directly to provide their credentials and then be redirected to their homepage on the main app.

The architecture was based on the CAS single-sign on approach (please enjoy reading the protocol).

Our vision was multiple applications that shared a single auth server and a single (at least initially) content delivery server.

Introduction

Yes, this is a Ruby versus PHP post.

And my conclusion up front: while I don’t hate PHP, I just don’t enjoy programming with it compared to how much I enjoy programming with Ruby. Given the choice I would always choose to develop in Ruby over PHP.

However that doesn’t mean I’m a great Ruby programmer. I regularly fail to do things according to the Ruby Way. michaeltwofish clearly gets a lot of satisfaction from suggesting how to improve my code and make it less PHP-like.

But how fair is it to compare the two languages? You could easily class PHP as a High Level Language and Ruby as a Very High Level Language and say comparison isn’t fair, it’s comparing “apples with oranges”. Except this isn’t an intellectual exercise, it’s about selecting a tool to effectively build high quality software for the web. And from where I’m sitting, it’s Ruby every time (Rails often too, but not all the time).

Interview

I’ve been doing a lot more Ruby and Rails recently because I want to (and I don’t have an job, so I have plenty of time to do so) and because of an interview I had a couple of months ago.

The interview was for a Ruby on Rails position. Until recently most of my experience was with PHP. I’ve built a couple of small things with Sinatra (very satisfying), and a timetracker in Rails 2.1 or thereabouts some years ago (which was only recently retired, also satisfying that it worked almost flawlessy for this long). But since the interview I’ve now built a fully (unit and acceptance) tested factory production (literally a manufacturing factory) application in Rails 3.2, and I certainly learnt a lot (in a short space of time).

Introduction

The original favicon was a 16x16 pixel file named favicon.ico that lived in the top directory of your public web files but with “retina” displays becoming more common, and with favicons used in many places other than browser tabs, the approach now is to provide a much larger image, at least 64x64 pixels.

Retina Displays

The Apple retina displays works by redefining the pixel. On the Macbook Pro Retina 15 inch there’s 2880x1800 physical pixels available, but they give you 1440x900 CSS pixels. That is, a CSS pixel on this display is actually 2x2 physical pixels. On non-retina displays the mapping is 1-to-1 and you didn’t have to talk about physical vs CSS pixels, just pixels. So instead of a larger canvas (with everything on it being much smaller) they give you the same size canvas but with much more detail.

Towards a Retina Web is an excellent and in-depth article about CSS for retina displays.

There is also an interesting article on anandtech discussing how the Macbook Pro Retina handles scaling.