Do we really need another browser?

Tuesday, 23 December 2008

View Comments

For those of you that spend a large amount of your day adjusting your styles (and occasionally javascript) to work on a variety of browsers you may be moaning over the thought of IE releasing another browser.

It's great that they are trying to improve things over at Microsoft, but I'd like to point out a few things as to why this could cause more pain than joy.

Looking at the stats over at w3schools which gives us a rough indicator of the break down between IE6 and IE7, they both have pretty close market share. Although IE7 is now in front it has taken some time to get there and IE6 is still refusing to die. With the introduction of IE8 we may be looking at three browsers in existence all with a reasonable amount of market share. Enough for those people who you are designing for to ask that there flashy new web site still renders well in all three browsers.

A couple of years back we were developing for IE6, IE7, Opera (and then Safari) and Firefox. We now have Chrome and IE8 now thrown into the mix. The biggest problem is that all these browsers render a page differently. Meaning more work with each new addition.

I don't want to go into detail about why it is good to have standards; it just seems with each release each of the majors does most things right, but it's the little things (except for IE6) that make life so hard.

I read this blog today on zdnet about which "big" sites had not yet prepared for IE8. I thought it was an interesting point of view that it was expected that these sites should be ready for another browser that has not yet been released. The other thing that the article mentions is the new 'Compatability View' button. This will allow (from what I have heard) sites to be rendered according to the way they would in IE6 or 7.

So... it has taken almost two years for half of the IE users to come on board with IE7. Why would they bother going to IE8 when it won't render pages the same unless you click on a button and then it will just be the same as the browser they just gave up.

It seems they still haven't got it right, with IE8 not passing the ACID3 test although according to Microsoft it apparently passes ACID2.

The past couple of years have been quite interesting with XP still refusing to die and IE6 refusing to die. When the guys at Microsoft come out with something that's nice and does great tricks (ala Office 2007) people flock to it. It would be better if they took the same approach with IE and come out with something that is the best in the field and not something that is playing catch-up with a backwards compat. button.

As they keep delaying, let's hope they're listening and come out with something that is worthwhile for the end-user. Otherwise we will continue to see Firefox eat away at their market share. Also we live in hope in one day IE6 will go away.

Large sized mysql dump

Tuesday, 9 December 2008

View Comments

As mentioned previously I have been working recently converting over some old classic asp pages into php. It has also been a company decision for them to continue to run mssql in conjunction with php. This hasn't caused too many dramas and isn't really what this post is about, but just to give you some background.

Recently my manager supplied me with a CD with a 350+ meg sql dump from mysql and asked me to verify the data. I thought the nicest way to do this would be to have phpmyadmin up and running so that they could quickly browse through the results once the data had been imported. Especially as they are used to using mssql's SQL Server Management Studio.

After trying to import several times through the command line to import the dump back into the new database I had no success. I had tried increasing the max_allowed_packet in the my.ini file, but with no success. I kept getting MySQL Server has gone away errors.

After getting in contact with the person who did the dump I asked a few questions about how they had gone about verifying the dump and if they had any success importing the data back in. It turns out that I was on the right track. In order to get this file to import they had increased the max_allowed_packet size to a wopping 10000000M. I tried this and the import worked straight away.

Here is the entry for the my.ini for those who want to know:

I suggest switching it back to something more sensible after the import. If you want more idea about what the packet size relates to and how to change settings have a look here:

Classic ASP.. what a headache

Friday, 5 December 2008

View Comments

The company I'm working for currently is going through the process of transferring all their old classic asp sites over to php and adding new functionality at the same time.

In order to meet deadlines some of the new functionality is being added in classic asp and being converted over at a later date which is not the best way to do things but keeps things moving (please note: I wouldn't recommend this to anyone as an exercise).

One of the biggest troubles I've had is getting values out of arrays. With php if you have a variable and want to know what the hell is inside it you can just call var_dump or print_r and if it's an array it's quite easy to see that it's an array.

In classic asp it's not that easy.

One of the pages had a series of checkboxes as follows:

<input type="checkbox" value="1" name="selectioncriteria[]"/>
<input type="checkbox" value="2" name="selectioncriteria[]"/>
<input type="checkbox" value="3" name="selectioncriteria[]"/>
<input type="checkbox" value="4" name="selectioncriteria[]"/>

Which is a quite neat way to do things as you get all your selected values inside a single POST variable.

For php we can do the following: (Please remember to sanitise your data first folks)

foreach ($_POST['selectioncriteria'] as $criteria) {

For asp it's almost exactly the same: (It just takes half an hour of Googling to find out)

for each criteria in request("selectioncriteria[]")

Hope that helps someone from half an hour of frustration!