Sunday, March 28, 2010

SQL_BUFFER_RESULT may return stale result

Careful with SQL_BUFFER_RESULT in your mysql SELECT statement
While this may speed up the selects (sometimes by a lot), it will also get you the cached result, in some cases the result may be stale, not reflecting the changes that took place after the previous result was cached.

This was probably not intended to be like that, may be just a weird behavior when using PDO and somehow temporary table that was created for that BUFFER_RESULT was not removed. I don't know why, I am not a mysql developer, I just know what I see - when using SELECT HIGH_PRIORITY SQL_BUFFER_RESULT .... with php PDO class, the result may be stale.

Thursday, March 25, 2010

MySQL table locks up

Another day, another total lockup of MySQL, when it locks up, it locks up and stays locked like a dead cunt - forewer.

Saturday, March 20, 2010

Looks like memcached was freezing Apache 2.2

Very bad idea to have both php extensions - memcache and memcached to be loaded at the same time.

I think this was causing the unexplained freezing of Apache 2.2

It was very difficult to track down the cause of Apache just freezing - no timeout error, no errors at all, just sitting there waiting forever for page to load.

After trying everything else, I decided to comment out loading memcached php extension and only load and use the good old reliable memcache extension.

Some tests claim that memcached is faster than memcache, but the difference is basically in single milliseconds, like who cares.... Not important when you usually saving couple of seconds worth of complex sql selects (some long sql selects that have several LEFT JOINS sometimes take 15 seconds when mysql has to create temporary table).

Anyway, I don't know if the problem was that some of the sites on the server were using memcache and some were using memcached, so I needed to load both extensions in php.ini

After ditching the memcached and only using memcache, the problems with Apache seemed to go away. Keeping my fingers crossed, so far so good.

Wednesday, March 17, 2010

Eclipse PDT freezes like a cunt

The eclipse PDT freezes on my brand new Windows 7 PC the same way it used to freeze on XP, just like a good old CUNT it is.

Google friend connect integration thoughts

When you have value of fcauth cookie from Google Friend Connect
but user has unjoined your site, then when you
request the data from gfc server you get the 401 error status with this message:

Anonymous requests are not allowed to fetch data
Error 401

This is an easy way to know that the fcauth cookie is not good anymore and you should delete it from the table in case you are storing that value in a table.

It also indicates that user is not a member of your site via his GFC thingy.

What is the best way to auto-login GFC user to your site? The oblivious choice is via fcauth cookie, get data from GFC server and login/create oViewer object.
But this can slow down the page load in case the GFC server is slow to respond.

A faster choice is to log him in via your own uid cookie, then add some DIV tag to your page and then have JavaScript on your page to make ajax call back to your server, on your server check with GFC server and upon success return a couple of links to the browser. The links will be to 'Friend connect settings' and 'invite friends', then have your JavaScript callback to add these links to the page

If GFC auth in unsuccessful then remove fcauth cookie from user record, indicating that user in not subscribed to your site anymore. In this case have your http response to delete the fcauth cookie so you don't have to go through this again.

The downside to this is that you have to make an extra request to server right after the page renders (via ajax this time)

Tuesday, March 16, 2010

php setcookie for array of cookie

On the php manual page for setcookie() function
is says you can use setcookie() to set array of cookies

http://us2.php.net/manual/en/function.setcookie.php

This is convenient, but also a bit misleading. It leads you to believe that you are setting just one cookie with the array of values, but in fact the browser actually setting new cookie for each new array element.

So you may be setting 10 different cookies and not even knowing about it. A better solution is to set just one cookie with the name/value pairs like
userid=12331&name=john&group=admins&firstvisit=20091010

You can use http_build_query() to build a string that will then become your cookie value.

See, it looks similar to url.

To get values from the cookie, just get the cookie using the
$val = $_COOKIE['cookiename'];
and then:
parse_str($val, $aVars);
now the $aVars contains the name => value pairs
Just treat the values with caution just like any other user-passed variables. Validate, sanitize, whatever you normally do with values passed by user.

Friday, March 12, 2010

username-less paradigm

Just found out that on Facebook the username is optional
Everyone is known by their real first and last name. So Facebook API in most cases does not return value for username because it's optional and most people never set it up.
I just find this unusual but at the same time they may be on to something.
This makes it so much easier to integrate the Facebook Connect into your existing login system - because there could not be any name collisions with existing users in your database

Wednesday, March 10, 2010

Php can only count to 10 (sort of)

Careful when casting large number to integer in php
You probably used to do this $val = (int)$val;
in php as a way to be sure that $val is an integer.

Some people do this for added security, since integers cannot contain any type of
script or html tags, so it's an easy way to sort-of sanitize the string.

But.. but... but ..... but....

Php like a child that can only count to 10, can only count to 2147483647
That's right, I did not expect this either.

Any number larger than 2147483647 php just does not know!
This means when you try to case any number larger than 2147483647 to integer using (int)$val, php will just return 2147483647

This is terribly wrong, certainly should be considered a bug!

If php does not know any integers larger than 2147483647, then it should raise error when you try to convert a larger number, not return the largest number it knows!

This can cause some weird problems in your code.
In my case I discovered this bug when working with Twitter API
The Twitter has billions of status messages, so all the latest status_ids are larger than 2147483647, so I was doing what I thought was a good practice and casting these status ids to integer with (int), but php was quietly replacing all the actual values with the 2147483647

By the way, it was php version 5.2.9, which is fairly new version. I mean, I would not be surprised to see this bug in php prior to 5, but in 5.2.9?!

That's crazy.

Monday, March 8, 2010

Some near-term todos for qod site

Some feature to add to qod soon:
use javascript api to see if logged in user is following question owner and if not, then add "Follow " button which will point to user server and we can follow the user of behalf of the logged in user.

Add 'Other questions by this member'

Add 'Invite friends to join' but not sure how this will work - show a list of friends or just tweet about the link?

Sunday, March 7, 2010

Normalizing utf-8 string for Twitter API

In order to send Unicode (utf-8 to be exact) text to Twitter via Twitter app, you must first run the string through the php Normalizer class

This class comes with php 5.3 but before the 5.3 you need to build the lib yourself and then install extension from pecl

Then, once you have the Normalizer class, just do this:
Normalize::normalize($string,Normalizer::FORM_C)

This is not always necessary as most utf-8 strings and chars are already "just fine", it's just that some fairly rare chars can be considered 'not normalized'.

This means that Twitter will still accept them, they will even be rendered by the end user browser in most cases, it's just that Twitter may count such chars as 2 chars instead of just one, and you know in Twitter every char counts.

Basically you really want to make sure that utf-8 strings are normalized before you send then to Twitter from your API because otherwise you may run into situation that your message unexpectedely exceeds 140 chars and will be rejected by Twitter API.

Normalize::normalize($string,Normalizer::FORM_C)

And here is the info from php
http://www.php.net/manual/en/book.intl.php

http://php.net/manual/en/class.normalizer.php