Thursday, January 28, 2010
Google live search is shockingly stupid
Ok, I searched for "REST or RPC" which are the 2 technical terms for protocols, so I was looking for find the answer which one I should be using in my application.
So, Google added results from live twitter stream on the first page, some of them go like this "I should go get some rest"
or "the rest of the album is..."
Com'on Google, my son can write a smarter search engine - just filter out the VERY common words or at least don't show results for words that can have more than one meaning if you don't know which one of the meanings I am searching for.
What's the name for such words anyway, (words with more than one meaning)? I forgot, I better go Google it.
Thursday, January 21, 2010
Programming discussions tips
popular php and javascript projects is to keep an eye on the
mailing lists.
One good place to watch the latest lists is on this discussions site
It's updated in real time as soon as any new message arrives to any of the many programming lists they track.
There is also a way to reply, you just need to register and you good to go.
Friday, January 15, 2010
Enhances Search Results on Yahoo Serp pages
Just want to bookmark this page.
It contains valuable info on how to enhance the site markup to allow extra cool snippets on yahoo search results page - right on SERPS.
I especially like the Discussion, News and Video section, but Documents and Events and even Games look very promising too. The Games, however require them to be written in flash. I am not 100% sure but at least the example on Yahoo site is in flash.
It would be cool if Javascript games were also allowed.
Very interesting: at the bottom of the page there is a link to "Build a Custom App", so basically Yahoo also allows to build custom app and have it included in enhances SERP.
Yahoo allows microformats to hint discussion
Very interesting. Yahoo allows to add
a microsofmat or RDF to indicate that a blog with comments or a forum discussion takes place.
Yahoo will then include this data in the enhanced search results page.
http://developer.search.yahoo.
"Description Display blog or forum information directly in Yahoo! Search. Add code to indicate to Yahoo! that a discussion exists on your page, and when we next crawl your site, we'll take care of the rest. From your markup, we’ll be able to extract structured data from your site and render it automatically in an enhanced result in search results."
- SearchMonkey - Discussion (view on Google Sidewiki)
Wednesday, January 13, 2010
2 Interfaces cannot contain the same method names
implemented in the same class
For example:
interface LampcmsResourceInterface
{
/**
* Returnes id of user (USERS.id)
* who owns the resource
*
* @return int
*/
public function getOwnerId();
public function getResourceId();
}
and then a
interface Zend_Acl_Resource_Interface
{
/**
* Returns the string identifier of the Resource
*
* @return string
*/
public function getResourceId();
}
This is not a problem as long as you don't try to implement
both in the same class.
You may assume that if your class has a method
getResourceId() then you can safely say it implements both LampcmsResourceInterface and Zend_Acl_Resource_Interface
but this is not true
if you try to write a class like this
class MyResource implements LampcmsResourceInterface, Zend_Acl_Resource_Interface
{
protected $resourceID = 100;
public function getResourceId(){
return $this->resourceID;
}
}
You will get fatal error when you try to instantiate this class:
Fatal error: Can't inherit abstract function Zend_Acl_Resource_Interface::getResourceId() (previously declared abstract in LampcmsResourceInterface)
The best course of action now would be to
change the LampcmsResourceInterface to only have one required method getOwnerId();
Then if you need an object that MUST have getOwnerID() and getResourceId()
just make a class and declare it as implements LampcmsResourceInterface, Zend_Acl_Resource_Interface
Tuesday, January 12, 2010
Thursday, January 7, 2010
Correct way to handle deleted messages and posts
Sure, we can also delete a record from MESSAGE_BODY if we keep a separate table just for message bodies.
Don't just mark it as deleted, but actually use a timestamp value for the 'deleted_ts' column.
The reason for that is that we will them be able to spot that the message has been deleted and not just 'does not exist'.
One advantage of knowing that it has actually been deleted and not just 'not found' is that we will be able to return a 410 response code instead of the normal 404
The difference between 410 and 404 is that search engines will not attempt to retry getting the same page again and again. The 410 basically says 'gone permanently' instead of just 'not found'
It may actually cause Google to delete this page from Google cache very fast.
Actually we can even give Google another hint to remove such page from cache. When we catch the 410 exception we may add an extra meta tag NOCACHE or NOARCHIVE, whatever it is that Google understands as 'don't use cached version'
This can be very helpful. And of cause by marking message as deleted instead of actually deleting it, we are not breaking the 'next', 'previous' navigation.
The 'next'/'previous' nav is another story, and maybe we actually should not use the 'next'/'prev' links of deleted pages because if many messages have been deleted we don't want to point to 'prev' which has also been deleted, we want to point to the first non-deleted page, but that will require a different logic. Later...
Also when we know that timestamp of when the message has been deleted we can show it to the user on the 410 page. So, we not only sending 410 response code but we can also show 'message was deleted on Dec 12, 2009' for example
This is also extremely helpful to the user.