This is a small story, that happened with me this weekend and I will post it bellow so you can also see the worst, in my opinion, type of failure of a website.
Yesterday I was set to change my current cable provider to Comcast. The reason was simple, prices. Compared to my current cable provider, Advanced Cable, they have a lower price for the same features.
Anyway, I have checked for my address, started a chat with a representative and selected a product to go on. After a long talk with the representative and correctly setting all the points that I needed to go on with the order my checkout was blocked with a message: Please call the Xfinity customer support to finish this checkout. Your address could not be found on the database.
That immediately issued a red flag for me. Calling about my address not being on the database? Ok. I’m not a client so that might be it, but still that can’t be good.
Called customer support and I heard the bad news: We cant provide service in City. You will have to go with Advanced Cable (witch is my current provider).
Until I have got to this point I have spent at least 2 hours planning, talking with reps, setting everything online and everything was pointing out to be good. The address checked, I had a good product option, prices were good. I was even considering to accept a contract, but it failed.
Why does the Comcast website says that you can provide service to my address and the customer support on the phone says that it cant?
Regardless of the reason that is a horrible mistake. A potential client went through a very long process to checkout, could not checkout and even if he wanted to, he would not be able to checkout. This is a horrible logic error because that information should have been validated on the beginning of the process.
The “bug” here is simple. If this was a shopping cart, it would be the same as letting a shopper to purchase a specialty product in USA that can only be sold in Europe. If the validation of the shopping cart was done in the begging of the process there is a good chance that, if possible, the client would still keep shopping for other products. In the case of Comcast and me, I couldn’t go further even if I wanted to, but I would consider them if I ever changed of address.
It’s not like you can’t uppercase characters from Japanese, Chinese, Korean, etc languages, but certainly using strtoupper is not the proper method.
I have passed the last 48 hours trying to find an error that was dying one of my view scripts. No exception has been set or displayed and no error or warning what-so-ever was being displayed. Chasing a bug like this is one of the hardest things you can do.
After a lot of slashhamer debugging (echo mktime(); die;) and help from co-workers and friends I finally could find where the bug was.
The problem was that I was trying to display a Japanese encoded page and simply trying to strtoupper the title was failing and dying the whole script.
After this was found out, then the logical exit was using mb_strtoupper to uppercase it, but it also failed. This time it was fully my fault. Mb_strtoupper uses mb_internal_encoding to get (and set) the internal encoding to be used with that function. If you don’t specify the encoding it will simply get the default therefore failing on the function call creating the origin of my whole ghost bug.
The simple and complete solution for this was setting the encoding to UTF-8 while calling the mb_strtoupper function.
Point is, if you are using a multi-language system and is most likely to be under LATIM1, then whenever using the mb_* functions you must set them to UTF-8, otherwise you will be chasing a ghost bug (and it’s not fun).
Setting the mb_* functions is easy, one of the parameters is always the enconding, so, for example, for the mb_strtoupper function, the function call would be:
echo mb_strtoupper(‘大文字mcloide wordpressのドットドットコム’, ‘utf-8’);
Have fun …
I have done a lot of applications and some of them had to be released in a Beta Version and as you probably know, beta is the first stable version that you can work with, but it might have a bug or two.
Most of the times I have just asked the users to submit an email with the feedback of what it’s going on. Most ot the times I have lost that email and had no reference about the bug.
I had two ways to work this out, one create a ticketing system or simply create a class that get’s the user information about the bug, saves and send an email.
Both have it’s pros and cons, but in this case I will release the bug class only. It’s simple, easy to adapt and it will store the bug information that is all that we need right now.
You can download the class here and inside the class you will see (at top) the information about creating the table.
P.S. This class uses my MySQLiHandler class that is available in my older posts.
Important update: I have added more fields in the bug reporter and I have changed the way that the insert method works in the MySQLiHandler class. Please get the latest versions.
Consider that you have a profile page, tabbed, and in one of the tabs you have a Google Map with the pinpoint of the user. When the page loads, it will load the map aplication, but the map div will not be visible at that point.
When you hit the map tab, you will see the map loaded, but, with some areas missing or acting really weird.
What is happening is when the tab loads, the map is not fully loaded and the main document finishs to load before the map loads, so, it understands that the map area is smaller than really is and shows it like that, funny.
How to fix it? Simplier than you think. If you search around you are going to find some stuff like map force redraw, but there’s a simplier way to do it.
Add a setTimeout to load the map.
That’s all you need and your map will have more than enought time to load all info and display correctly.