Ian Lewis' Blog

I implemented tracking using Google Analytics for my company's mobile sites using a technique described by Peter van der Graff on his site. The technique involves performing a GET to to an image on Google's server and passing it a bunch of options. Incidentally this is because Javascript can perform gets of images but not gets for any other kinds of content (as an aside, this kind of protection seems usless since the server could return any kind of content in wants to the javascript even though the GET has an image in the url. Maybe someone could enlighten me).

Peter originally came up with the idea because he wanted to track hits to a RSS xml url (which also seemed strange to me since the rss aggregator could read it as many times as it wants and doesn't give much insight into the number of readers, but I digress), or to another type of file download (image, pdf, etc) which wouldn't trigger the javascript that Google uses for Analytics.

One important difference between his motives and mine were that I'm tracking hits to a mobile site. Doing analytics on the server side are important since most phones (in Japan at least) don't support javascript. I also, because of the differences in what I was doing, needed to make some changes to how his script worked. Since I'm not tracking downloads or rss hits, I care about things like sessions, language, and user agent (why Peter didn't also care about this I'm not sure).

So I modified his code as follows. I forward the language and user agent of the client to Google Analytics so that I can track these things properly. I also pass my own cookie number so that Google Analytics can aggregate page hits from the same user into a session. I also make use of the user var to track hits to different customer's web pages. The example is in PHP but it could be easily translated into another language.

Note that, because of the use of stream contexts, this code will require a version of PHP >= 4.3.0.

Gnucash 2.2.3 was released the other day and contains my first contribution to the project. Albiet, a pretty small and lame patch for a small bugfix, but a patch nonetheless!! I hope to do some more work particularly on the QIF import, eventually making it work with the generic importer, and then expand my contributions to include improvements for multi-currency and reporting.

So the last few days I've been playing around with MochiKit and working with Javascript. Until now I have done some Javascript here and there but not too much. MochiKit seems to make it a lot easier by providing you with lots of useful functions for things you do often. In fact it's so popular that I have a hard time explaining to myself why I hadn't tried to use it up until now. I'm certainly not on the bleeding edge here.

Anyway, like I said, MochiKit makes JavaScript less painful. I have a little mockup for a page that defers going to the server until the user has stopped entering data for 3 seconds. That cuts down on a lot of back and forth between the server and client. It's easy in MochiKit. Just use the callLater function.

In this example the callLater is used to call another function, deferredupdate, after 3 seconds. However, if the user enters data a second time before the three seconds are up then the deferred object will be cancelled and a new deferred object will be created. This has the effect of not calling the update function until a user is really done entering data.

The request object is created in the deferredupdate function.

The deferredupdate function calls loadJSONDoc which creates a deferred object as well however this deferred object doesn't wait for any time it simply does it's work in a separate thread and executes a callback when it's done. In this case I set the callback to be the pageupdate function. The pageupdate function does the work of putting the resulting data into a table and adding that table to the html DOM.

If you are wondering what the bind function does, it always ensures that the 'this' reference works. I'll leave the full explanation for another post.

Most people who program in JavaScript already know about MochiKit but if you are interested in it check out the screencast at http://www.mochikit.com/

In the same vein as my first post bashing Internet Explorer I wanted to point out a few CSS bugs/unsupported features that are notable in Internet Explorer. For those who are not familiar, CSS is a stylesheet language which helps you to layout your forms. It's used on basically every major website on the internet. But Internet Explorer, even though it is the most widely used browser, does not support many of the features of CSS and when it does, sometimes the layout appears differently than in other browsers because Internet Explorer doesn't follow the rules for how the CSS should work. This post will cover those issues where Internet Explorer simply doesn't work at all.

PNG Transparency

The first issue affects this website and actually causes the CSS used by this site at the time of this writing to be non-standard (shh!! don't tell anyone! I'll fix it sooner or later). That issue is that Internet Explorer doesn't support PNG transparency. PNG files have in them a transparency level which allows translucent images. When you click on an image on this site like below it pops up an image and the background is darkened by another translucent png image. This doesn't normally work in Internet Explorer.

Normally you should be able to just set the background image like the following and the png will be displayed with it's inherent transparency.

#overlay{ background-image: url(overlay.png); }

But Internet Explorer displays it as completely opaque.

Instead, for Internet Explorer's sake you have to do some wierd hack that is Internet Explorer friendly.

Notice the wierd call to some Microsoft method for displaying images with alpha. This is totally non-standard and broken but necessary in Internet Explorer to display a png with transparency (there are other ways to achieve the desired effect in javascript however).

Button Hover

The second issue is that Internet Explorer doesn't support the button:hover attribute in CSS. Normally you can make a particular piece of a page such as a link or button behave differently if you add the "hover" attribute to it in CSS. This has been used a lot with normal links. Indeed this site uses a:hover to show different color links when you hover over them. Try it. The link goes nowhere but you can see that it changes when you hover over it. The same should be true for buttons. You should be able to change a buttons properties when the user hovers over it using only CSS.

button:hover {
  /*Your CSS here */
}

In fact you can use this hover effect with pretty much anything, such as table cells and rows. However IE only recognises the hover for links so it requires javascript. Check out this test page. Hovering over the button does nothing in IE. In order replicate this functionality in Internet Explorer you have to write some wierd javascript that sets the behavior of the button when the page is loaded. There are a number of ways to do this but the most straitforward is to use the whatever:hover script so you can make use of the hover attribute in css. It has some important limitations however so be sure to read the limitations section. Essentially the scripts adds a onMouseOver and onMouseOut events to the button which change it's stylesheet class.

Both of these problems have added difficulty to my life. The first stemming from this website and the second stemming from work. While web browsers have become a quite complicated piece of software, time spent fixing bugs because of broken implementations of standards is a huge waste of time. This is somewhat true for Safari and Firefox but especially true for Internet Explorer. No argument could counter that it is a steaming pile of dung and that you shouldn't use it. PLEASE STOP. The world will be a better place if you do.

There is currently a bug in the current stable release of MDB2 (2.4.1) that breaks transaction support with MySQL databases. It seems to occur anytime the server cababilities are checked twice (This basically means that it occurs when creating multiple connections to the database).

After running into this bug I took a dive into the code for MDB2 and found that was caused by the use of a static variable that is used to determine if the capabilites were already checked or not, including whether transactions are supported or not. Basically you make one connection to the database and everything is fine, it checks the capabilities and finds that transactions are supported and sets a class member variable indicating this. However, when making the second connection, the server capabilities are checked in the new object. The member variable of the new object that specifies if transactions are supported defaults to false, but the function that actually checks the capabilities checks the static variable to see if they were already checked and skips checking again leaving the new connection object with transaction support set to false.

Seems like a silly oversight to me, but one that caused me a headache for a couple hours. I looked to see if I needed to submit a bug report and/or patch but it seems that someone has already done so. The change should be in the next stable version but I need to patch my currently running servers so that transaction support is enabled in the mean time.

Basically the title says it all. Since I started doing web development I've lost count of the number of bugs that I've found in Internet Explorer but I want to highlight a couple that were especially annoying to me.

1.) The <button> tag doesn't work. The button tag has a value attribute which is supposed to be sent as the value of the post when I submit a form but it's not. The display value of the button is sent instead. So if you have a form like so:

<button name='time' value='1030'>Click here</button>

and you submit the form that the button is contained in, the post value of time is set to "Click here" instead of "1030" like it's supposed to. Basically in IE you can't have a button submit a form and post a value different from the displayed value. This makes it very hard to have an array of buttons and post a different value based on what button you push.

2.) For e-mail links that contain Japanese characters you have to change the characters to the %0000; equivalent value. So if you have a mailto with a subject line in Japanese you can't write:

<a href='mailto:myperson@mymail.com?subject=おはようございます'>e-mail me</a>

and expect it to work. Internet Explorer simply does nothing. No error message. No e-mail client. You have to url encode the link to something look something like:

<a href='mailto:myperson@mymail.com?subject=%E3%81%8A%E3%81%AF%E3%82%88%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%26'>e-mail me</a>

which if you are using php is not so bad since you just call urlencode() but it's just plain annoying to get stuff like this to work when there isn't really a good reason why you need to encode it (at least I haven't heard one so far).

That's just the 2 most annoying bugs/issues. I can't imagine how the button bug got though the testing phase for IE but probably there are too many applications that depend on the bug working as is for Microsoft to ever change it to work the way it's supposed to.

I realize I shouldn't hold my breath, but the sooner everyone stops using IE the better.

This week I've been working on setting up several web service for a project I'm working on for work. Because we are creating these web services from scratch we had to start by creating a WSDL file to describe the web service and it's functions.

WSDL is a type of xml document that describes the inputs and outputs from a web service. This can be done using a number of ways but in my case I'm using SOAP so I described my inputs and outputs using XML Schema.

In learning about WSDL I found a number of documents helpful. Forthought Inc.'s Uche Ogbuji always seems to write good articles and Using WSDL in SOAP applications no exception. Also, examining existing documents that are publicly available was also a big help. Such as this example Stock Quote web service. Or the Google SOAP web service definition.

Though after reading all of those, while returning base types like int or string or even custom objects was easy to define, I had a hard time figuring out how to define how to return arrays of objects (Actually, Google's WSDL shows an example of what I'm about to describe).

I originally thought that returning a list of objects would simply involve returning more than one of the object. Like if I defined this in my types section:

for reference this is my message definition:

That's a perfectly fine piece of XML Schema but unfortunately web services clients and servers won't recognize it. Instead you need to put a restriction on your returned type to define the array you are returning as a http://schemas.xmlsoap.org/soap/encoding/:Array. Sounds hard but it is really just a matter of following the pattern below instead of what I did above.

The message definition doesn't need to change from above. After doing that your favorite web services client or server that supports WSDL should recognise that what you are returning is an array type properly.

One thing that is a bit annoying about Japan is that it has it's own system for counting years. Many observers note that the Christian year is widely used in Japan but this is a bit short-sighted. Most Japanese don't internalize Christian years but rather convert Japanese years into Christian years when necessary. A bit like how you would translate a word into a foreign language if you weren't terribly fluent. Also, most systems that aren't developed by western companies or people, use Japanese dates. Filling out my birthday on a form to apply for a commuter pass for the train is an example.

The system includes separating time into eras which represent an Emperer's reign. They start at the first year that a new Emperor comes to the throne, and ends with the year that he dies. The year that he dies, is also consequently, the first year of the next Emperor's reign so there is 1 year of overlap.

For example, this year is the year Heisei 19. It is the 19th year of the Emperor Akihito's reign. The previous Emperor Hirohito's (we should all know who he is), era was called Showa. The Showa era lasted from 1926–1989. 1989 was the year that Hirohito died, and Akihito became Emperor. Thus 1989 is the year Showa 64 but also Heisei 1.

This is particularly hard when calculating years in software. Since most software uses western dates you have to convert these somehow. Also, whenever an Emperor dies you have to change the software to reflect the change in era. Software will, of course, continue to work in spite of the Emperor's death, but it will not reflect Japanese dates accurately until it is updated.

Things also get complicated when you are born in the year of an Emperor's death, as technically, the new Emperor's era starts after he ascends to the throne. So if you were born in 1989 but before the Akihito ascended to the throne, technically you were born in Showa 64 and not Heisei 1. So you would need to know the exact date of ascention and not just the year to accurately reflect a particular date, however most software doesn't go that far to accurately present Japenese dates.