Get Tinder v3.0.0 working with ART

Since the latest update, Tinder has supposedly stopped working with ART runtime.


However, it seems to still work anyway.

Simply tap ‘Got It’ to close the dialog box and then tap the ‘i’ in the bottom-right corner.


Update (07/06/14):
As of the latest update (v3.0.1) this issue is now fixed.

Leave the first comment

Are the number of IE8 users likely to drop after Microsoft drops support for Windows XP?

The latest version of the dreaded Internet Explorer that Windows XP supports is IE8.

As we have all heard, Microsoft dropped support for XP, and with that, IE8,  on 8th April 2014.

As web developers, this is an important step away from those delightful conditional statements and towards a more unified browser experience.

The 20-25% of users, especially businesses, are expected to upgrade their systems from XP to Windows 7, and that also means upgrading their IE version!

Here are the statistics for Operating Systems this month:


To my disappointment, XP has not seen the sudden drop that I was maybe too naively expecting after the 8th.

I can only hope, on behalf of the web development community, that these users and businesses pull their socks up and upgrade their systems so we can finally see the decline of IE8.

Leave the first comment

Square Thumbnail Solution

Since JaL Productions v3, I’ve been experimenting with different solutions to square thumbnails.

My ideal solution is that all the thumbnails are automatically generated from the source images, perfectly aligned at all screen sizes and do not hinder browser performance.

The problems

The initial problem with square thumbnails is that the majority of the source content I am pulling in is not of a 1:1 width/height ratio. This means I have to have some way of aligning the images into a square container without letter-boxing, pillar-boxing or the thumbnail being misaligned or cropped.

letter-boxing | pillar-boxing | misalignment

letter-boxing | pillar-boxing | misalignment/cropped

The second issue to take into account is browser performance. There are plenty of ways to generate and lay out square thumbnails using Javascript or PHP, however I am placing a lot of emphasis on how they will effect browser performance and page load times.

The last issue is that of browser compatibility, and which solutions will hinder certain browsers.

The solutions

1. JaL Productions v3

I used CSS3′s background-size: cover; to crop and align my thumbnails inside a wrapper <div>. This was the solution for perfectly presented thumbnails, however it came with problems.

Firstly, the obvious CSS3 browser support. This was especially relevant for v3 as I built that in 2012, when CSS3 support wasn’t as great as it is now.

Secondly, this solution was semantically bad. I was presenting a bunch of images in <div> tags. This meant there was no support for image-specific context menu items such as Save Image As. It also meant that crawlers would not pick up these images, such as if I shared a link to that page on Facebook, it would not find any of the thumbnails. So when I started building v4, one of my requirements was that the thumbnails had to be <img> tags.

Thirdly, through my lack of knowledge, I was setting the width of my thumbnails using % in the CSS, and calculating the height in Javascript every time the browser was resized. This was a massive performance hit (especially for IE) and was before I knew how to create responsive squares in pure CSS.

2. JaL Productions v4 – The current solution

After working in the responsive team at the BBC, I became very aware of support for non-Javascript devices, and decided to rebuild my site to be completely mobile first, with support for devices without Javascript.

In order to provide properly cropped and aligned thumbnails for all devices, I looked into using PHP to determine the orientation of the thumbnail and settings its width and height accordingly.

I created a function called getOrientation() which uses PHP’s getimagesize() function to determine the image’s width and height, and from that its orientation. A class of either landscape or portrait is then applied to each image and then CSS is used to set the height or width respectively to 100%. This ensures the image completely fills the wrapper div without letter- or pillar-boxing.

The problem with this solution is that the getimagesize() function is too slow, and means that the initial page load time, before anything is drawn to the screen, is very long. This is not specifically the function being slow, it’s the roundtrip time for PHP to request all the images from the server. I am also requesting all the images one-by-one, meaning that each request also has the request header overhead. Not good!

Once the page has loaded, although the images fill their wrappers, they are still misaligned to the default left positioning. I’d much rather the centre of the image be shown in the thumbnail. So I use Javascript to calculate the width/height of the wrapper and the image (depending on the orientation) and re-position the image inside the wrapper accordingly using negative margin. I also use Ben Alman’s debounce plugin to limit the alignment recalculation to only when the browser has stopped changing size. This greatly improves the performance on older browsers.

So using this method, non-Javascript devices get a reasonably sized thumbnail that just isn’t perfectly aligned, and devices that do have Javascript will receive perfectly sized and aligned thumbnails even when the browser is resized, however the cost of this is a longer page load before anything is shown on the screen.


I am now in the process of revisiting my square thumbnail solution and I feel that I was blinded by the mobile-first approach that I was aiming for.

For every website that a developer builds, we should be considering the potential users who will be visiting our site. Now, although mobile-first seemed like a nice idea to showcase my skills as a developer, I think that it is hindering the performance of my site for a set of users that I simply don’t have or shouldn’t really be catering for. 99% of visitors to my site are going to have Javascript enabled, so why am I still trying to support them, especially if it hindering page load performance that much? Time for a change I think!

3. Speed up the PHP

The first thing I thought of was to run some benchmarks on the PHP side of things and see if there was a faster way of getting the image’s orientation. I found that PHP’s imagesx() and imagesy() would be slightly faster than getimagesize() for getting the image’s width and height, however the roundtrip request time is the factor that is really killing the page load time. I also found that using getimagesize() in a loop doesn’t do me any favours either, and that using something like curl-multi-init to do multiple requests simultaneously would be much more beneficial.

4. Imagick

The next solution I thought of would be to automatically generate all my square thumbnails. This would remove the need for getOrientation() and for any Javascript realignment after page load and on browser resize.

I am using Imagick to automatically generate the square thumbnails using cropThumbnailImage(). I then write the generated thumbnails into a thumbnail directory on my server and serve them to the user.

The advantage to this is that when a new image is added, the thumbnail for that image only has to be created once by the first person who visits the page (which is most likely going to be me anyway). My script checks whether the thumbnail already exists before generating one, kinda like a cache, so the Imagick function won’t run if it doesn’t need to.

The only disadvantage is that the current script I have saves all the images into a sub-directory on the same server. The previous solution loaded all the thumbnails directly from DeviantArt’s multiple subdomains, meaning I’ve lost download parallelisation.

At the time of writing, this seems like the best solution as long as I can develop into my script a way of storing the generated thumbnails into different subdomains.

5. Pure Javascript solution

A lot of posts I have read advise against using PHP for image manipulation and recommend doing it all in the front-end. This would be in favour of progressive enhancement but would go against my original requirements of making v4 mobile-first.

The real question is: How much should I really care about non-Javascript devices?

If I built a pure Javascript solution, calculating the orientation on page load instead of in the PHP, the page would load a lot quicker, but non-Javascript devices would get a shoddy thumbnail experience. That’s not to say they can’t still click through to the original image, but the thumbnails will be indistinguishable.

For devices that do have Javascript, once the page has finished loading, the Javascript will kick in, calculate the orientation and resize and realign accordingly.

I think this will be a very “jumpy” experience for the user and I am feeling more and more against this solution the more I think about it.

Which solution is the best?

Fast load times vs. shoddy thumbnails

Perfect, square thumbnails vs. loss of parallelisation

Leave the first comment

How to add a reblog and like button to every post on Artur Kim’s Lightweight Theme on Tumblr

This is an update from my previous post in response to Annie’s comment.

The previous post showed you how to add a reblog button to every post.

This version adds both a reblog and a like button.

The positioning of these buttons is also moved.

The code you need is:

<div class="reblog_like" style="position: absolute; top: 76px; left: 14px;">
    <div style="width: 20px; height: 20px; margin-bottom: 8px;">{ReblogButton}</div>
    <div style="width: 20px; height: 20px;">{LikeButton}</div>

Place this within the .post-type and .post-content blocks.

If you’re having trouble finding the right place, just Ctrl+F for class="post-content".

So you’re final code will look like this:

</div><!-- .type -->
<div class="reblog_like" style="position: absolute; top: 76px; left: 14px;">
    <div style="width: 20px; height: 20px; margin-bottom: 8px;">{ReblogButton}</div>
    <div style="width: 20px; height: 20px;">{LikeButton}</div>
<div class="post-content">

Note: If you followed my previous post, you’ll want to remove that code.

8 comments so far, add yours

Font Compression for the Web

During a recent client project, I ran across the issue of really slow loading custom fonts.

The client wanted me to use a font called Nanum Gothic. The TTF for this font is a beefy 2.25MB! On desktop it took ~5 seconds to download on a ~5Mb connection. On my smartphone connected to WiFi, it took several minutes!

I knew that FontSquirrel had some compression options, but when I tried to upload the file it returned an error saying the font was too big – ironic.

Then I came across FontForge, a font editor which allowed me to individually select and remove the glyphs which I knew I didn’t need.

I then exported a TTF from FontForge and ran it through FontSquirrel (now that it was small enough) to create the other file types for my CSS3 @font-face rule.

Here are the file size comparisons:


File Size
NanumGothic-Regular.eot 2,510 KB
NanumGothic-Regular.svg 34 KB
NanumGothic-Regular.ttf 2,510 KB
NanumGothic-Regular.woff 2,576 KB


File Size
NanumGothic-Regular.eot 17 KB
NanumGothic-Regular.svg 43 KB
NanumGothic-Regular.ttf 29 KB
NanumGothic-Regular.woff 20 KB


I’m not sure why the SVG file is actually larger, but the rest have an extremely significant file size difference. The TTF had a 87% compression rate!

For JaL Productions, I am using the AngryBlue font for my logo. FontSquirrel allows you to specify exactly which characters to export, and as I know that the only characters I need are those in “JaL Productions” I managed to save 42KB (51KB before, 9KB after) on the TTF file.

Leave the first comment

How to clear 50% floats

Let’s say I have a bunch of floated elements which are all 50% width but are of varying heights.

I can use the CSS3 pseudo-selector to select every other element, clearing the float, displaying what appears to be rows of 2 elements.

To combat the white space I could change the background-color of #container to be a similar colour to the floated content.

See the Pen Clear 50% floats by James Alexander Lee (@jamesl1001) on CodePen

Leave the first comment

1 year today

Today is my 1 year work anniversary! Celebrated in true World Service tradition with cake!

What’s been happening recently:
- fixing embedded videos on story pages
- RN iteration 2
- lack of team

Leave the first comment

Off-piste work

Off-piste work has been occurring a bit lately.

This is where work is done that hasn’t been assigned or been accounted for by the project manager.

There can be genuine reasons why this might happen, for example:

  • General well-being/tidy up/refactoring of the codebase
  • Pre-work to another task
  • A new task that was raised from current task


The important thing to learn is that it best to make these unplanned tasks visible, for the project manager, the BA, and for the rest of the team. It can then be discussed and prioritised and properly accounted for.

Leave the first comment

All the teams of the rainbow

There are now 5 teams working on the same codebase, and we all have coloured codenames.

  • Blue/Green/Teal: News
  • Crimson: Local
  • Purple: World Service
  • Orange: Rapid Rollout


Essentially we are both purple and orange. But the idea is that we rotate between us onto the orange team to roll out new sites.

This pretty much started with Arabic, where Stefano and I were the core developers working on that. And now Bogdan has mainly been working on Newyddion.

It’s not quite as straightforward as that, as one developer can’t create the whole site. That developer might be more of a front-end dev for example, and therefore wouldn’t be the best person to do the back-end tasks. So everyone is essentially chipping in anyway.

Leave the first comment

How to fix bi-directional RTL brackets/parenthesis problem?

What is the problem?

So this is the markup:

<div dir="rtl">
    <a href="#">mp4 (21.9 ميغابايت)</a>

And this is what I see in the browser:


As you can see, there are problems with the text ordering and the direction* of the parenthesis.

The browser is detecting what is LTR script and RTL script and displaying the text in the correct direction accordingly.

So therefore, this is actually correct. “mp4 (21.9″ is being detected as LTR, and “ميغابايت)” is being detected as RTL.

* According to the unicode standard, parenthesis are actually neutral, but I’m using “direction” here as the best way to explain open and close parenthesis.

How to fix it?

If I add the HTML character entity &rlm; either before or after the first bracket, this will force the latin script to display RTL.

The markup now looks like this:

<div dir="rtl">
    <a href="#">mp4 &rlm;(21.9 ميغابايت)</a>

And the browser now displays the whole string correctly flipped:


One comment so far, add another