Jaimini: August 2007 Archives

The Chinese Google (seems so lame to say it this way), BAIDU, has decided to do video ads. I think its a bad idea. Reason is simple. Ads in there own right are quite annoying to the end user if they start taking over the content. Google ads don't fall in this category because 1) they are the most unassuming ads you will ever see on the internet 2) they are just plain text. It is very easy for the users to ignore them, if they want to. Also, the level of customization Google ads words, coz is plain HTML, provides the content publisher to really mesh the ads and content together in a unobtrusive way. This all is just not possible in video, hell, not even in those annoying flash and gif ads. Suddenly you start worrying about the color formatting of your page and the non-matching color used by your advertiser. Video is even worse, they can run any content without your control. Also, genuinely people, video ads are a pain for the end user. Some site have this videos ads which start playing as soon as the page is loaded. So the alarmed user has to start looking for this video player to turn it off. And if the site is running a video ad on most of the pages, on every page click a user does he/she has to stop the video from playing. That is annoying. Video ads just doesn't make sense. Lots of people have done it before and failed. I don't understand why would baidu is doing it. Is it because, well its becoming a big bully in china. Mind you, it has a very coveted position, Number One search engine in china. As per the Shanghai Daily, Baidu is planning to run this ads on sites of Baidu union members. Baidu union members are :

There are around 150,000 sites which have already formed a partnership with Baidu through cooperation on search-related ads. These sites, called Baidu Union members, are mostly small ones with stable traffic and rich content ranging from vertical industry portals to entertainment sites, but it is difficult for them to attract advertisers on their own due to their size.

Neways, I think this search engine war is starting to enter the "desperate territories". On the other side of the globe, Google has started to put ads in some of the youtube videos. I don't like but I can see why. Youtube videos are just not running on www.youtube.com anymore. They are everywhere. Phone, Home media center, other electronic stuff (like i dont know..). And for all these place there is no way to put in ads around the content (or at least Google hasn't figured it out yet). So next logical step is put the ads in the content itself (duh !). Which for the online user (i.e. youtube.com users) wouldn't make sense but for people watching youtube videos on there home tv, well its just commercial break. Same old, same old. We are all now immune to commercial breaks. Same would happen to ads embedded in youtube videos. Come to think of it, I am sure all video site will follow in on this one. But, there are a few things to watch out for: 1) How Google decides which videos get the ads 2) what if the content uploader doesn't want the ads 3) what if someone actually wants the ads in the video. Keep watching.

I came across this really amazing podcast streamed mainly by two desi guys.  Based in india, this site provides a good one stop shop for india masala, news and technology developments. Its called The Indicast. I think the main differentiator for this site compared  to loads of india portals out there is the "amateurish and informal" way these guys carry out the podcast. Good work guys.

I was working on a RSS to JSON XSL transform for some work related stuff. For reasons not to be disclosed, the updated timestamp of the item was to be parsed and serialized into JSON as an array of integers. There were bunch of problems to that. XSL or EXSL, for that matter, does not have support for parsing RFC822 dates. This can be solved by writing my own template for parse the date or even better write a static java method and use that in the transformation. I took the later approach (coz its easier) because its easier and having a our code base could use a utility method to parse RFC822 dates. Even better I wrote it so that it will take in a RFC822 date string and return a Atom date (ISO whatever same as XSD date). So now my transformation can parse the date and give me the individual bits i needed and also our codebase has a nice utility method(this such a lame reason...). Parsing a RFC822 date (for that any matter any standard format date) is a bit tricky thing in java. Well, its not all that tricky now that I have figured it. We have the DateFormat class we can use to parse the date string to date. But as RFC822 date though a single format has there are parts of the dates which are optional e.g. second, Day of the Week. so we need multiple DateFormat instances (actually SimpleDateFormat) to support the format fully ( I realized this only after my transform started failing for feed which were not providing "seconds" values in the timestamp). Below is the code snippet to parse the date string.
public static final SimpleDateFormat rfc822DateFormats[] = new SimpleDateFormat[] { new SimpleDateFormat("EEE, d MMM yy HH:mm:ss z"), new SimpleDateFormat("EEE, d MMM yy HH:mm z"), new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss z"), new SimpleDateFormat("EEE, d MMM yyyy HH:mm z"), new SimpleDateFormat("d MMM yy HH:mm z"), new SimpleDateFormat("d MMM yy HH:mm:ss z"), new SimpleDateFormat("d MMM yyyy HH:mm z"), new SimpleDateFormat("d MMM yyyy HH:mm:ss z"), };
I want to note that the order in which this objects are applied is important. Mainly because of the effect of using "yy" and "yyyy". You can lookup the javadocs for the pattern to see what I am saying. Closing note: I like the fact that Atom has adopted the ISO date standard, I think its more widely supported.