ZOMDir > Blog

Saturday, 20 June 2015

A bug in Safari?

Apple is more or less cheating about the Javascript* screensize of the iPhone 4s for a long time.

You might check this by using Browsersize at a Glance on an iPhone. This simple webpage will give you results like this:

Safari on iPhone 4s, iOS 7.1.2


Chrome on iPhone 4s, iOS 8.3
The browsersize returned isn't the real size of the iPhone 4s. According to the iPhone 4s Tech Specs  the iPhone 4s has a screen of  640 (width) by 960 (height) pixels. That Apple was "cheating" on the browsersize was never a problem for me. On the contrary I did understand that Apple pretended that the screensize is lower than the specs for backwards compatibility. After all previous models of the iPhones have a screen of 320 (width) by 480 (height) pixels.

However now I wonder why Apple states that the iPhone 4s has more pixels than in the specs. Today I got this result and I'm puzzled.


Safari on iPhone 4s, iOS 8.3

Why do I now get the default width? The only thing I have done is updating iOS, so I wonder what I have done wrong that the default width is shown. Perhaps this is a bug. 

I know this is a technical issue, so it is good to know that I have read Apple's Configuring the Viewport and I'm always using this code 

<meta name="viewport" content="width=device-width" />

in the head section of the webpage. 

Thanks,
Hans

By the way, I also wonder why there is a difference between Google's Chrome and Safari. I suppose that they are based on different versions of webkit.

* The screensize is based on the Javascript innerWidth property and the corresponding innerHeight property


--
ZOMDir.com is a dynamic directory and a wiki
Everyone is able to add a link in 10 seconds
To learn more view this Slideshare presentation

Sunday, 17 May 2015

The power of the Zero Width Space

Recently I discovered that besides the Non breaking Space, there is also a Zero Width Space

A Zero Width Space works similair to the Soft Hyphen. Instead of adding a visible hyphen where the string is broken across lines, the Zero Width Space adds virtualy nothing.  

The Soft Hyphen is useful when you want to control where normal words might be broken across lines. 

Use the Zero Width Space when you don't want extra visible hyphen in your string. Since I discovered the Zero Width Space I use it in URL's. This way, long URL's are shown perfectly fine on small screens too. 


Zero Width Space in URL's

In URL's I add a Zero Width Space:

  • After each ampersand '&';
  • After each sledge '/';
  • After each egual sign '=';
  • After each underscore '_';
  • After each plus signe '+';
  • Before each percentage sign '%';
  • Before each period '.'
This way an URL might be shown as follows:

http://example
.zomdir.com/
this_is_a_fake_
directory/and-
this-one-is-fake-
too/index.php?
inputfromuser=
wow%20this%20
is%20a%20handy
%20code
 
In my opinion is the Zero Width Space that useful that I wonder how I missed it before. Anyway from now on I'm a fan of the Zero Width Space.

Hans

By the way. The code for a Zero Width Space in HTML is: &#8203;

--
ZOMDir.com is a dynamic directory and a wiki
Everyone is able to add a link in 10 seconds

To learn more view this Slideshare presentation




Monday, 2 March 2015

Memcache to the rescue

ZOMDir was built on Google's App Engine. One of the reasons to choose for this platform was the excellent performance. Google's servers are really fast.

However, a fast platform is not enough. The software architecture should also be optimised for speed.

Google's recommendations 

Luckily Google has some suggestions for a good performance like:
I have taken all these recommendations where possible. Although I over optimised the last recommendation a bit. Let me explain.

Why use sharding counters

Writing to Google's datastore takes much longer than reading from the datastore and an update of any single entity or entity group is only possible about five times a second.

Therefor the solution Google suggests relies on the fact that reads from the App Engine datastore are extremely fast and cheap. The way to reduce the contention is to build a sharded counter – break the counter up into N different counters. When you want to increment the counter, you pick one of the shards at random and increment it. When you want to know the total count, you read all of the counter shards and sum up their individual counts. The more shards you have, the higher the throughput you will have for increments on your counter.

200 new links per second?

How much shards you should use depends on the number of updates you expect per second. I have chosen for 40 shards for the statistics, so ZOMDir should be able handle circa 200 new links per second without contention. Nice, isn't it.

However there is a disadvantage. To collect all these 40 shards takes time. More time than I expected. The reason is probably that I didn't code smart enough to save resources :-( 

Memcache to the rescue

Reducing the number of shards will ruin the statistics so to overcome this I fall back to memcache.

To improve the performance I decided to save the total number of links in memcache too. This way I was able to improve the performance with a factor 2. That is roughly from 1500ms to 750ms. 

That's what I call a nice improvement :-)
Hans

--
ZOMDir.com is a dynamic directory and a wiki
Everyone is able to add a link in 10 seconds

To learn more view this Slideshare presentation

N.B. Here are some pictures from the testresults based on the English page of hotels in Amsterdam

Before the I kept the total number of links in memcache: An endless list of shards I have to collect
The results after keeping the total number of links in memcache

The results according to tools.pingdom.com

The results according to GTMetrix

Monday, 26 January 2015

600 Days

A small surprise when I looked up the stats today. ZOMDir.com is 600 days!



--
ZOMDir.com is a dynamic directory and a wiki
Everyone is able to add a link in 10 seconds

To learn more view this Slideshare presentation