blog.rakeshpai.me

Announcing AceSeller.com

2011-06-07T12:33:00.002+05:30

It's been some time now that I've been working on solving an interesting problem, and I think it's time to start talking about it.

AceSeller.com is a cloud-hosted service that aims to make it real easy for businesses to start selling products on their websites. It is targeted at small and mid-sized businesses that want to start selling online, but don't know how to. It is, from what we've seen, already the simplest to use and cleanest application that does this.

I'm doing this together with Sandeep Shetty and Jinesh Mehta. Between the three of us, we've got a great deal of experience with almost every aspect of running ecommerce sites. We are good friends, have tremendous respect for each other, and share a common passion for technology, simplicity, great user experiences and online businesses. This passion has already started reflecting in AceSeller.

We're working very closely with some businesses who have agreed to use our platform for launching their web-stores, and we are very excited about the great feedback we've been getting. One of these stores has already gone live on the AceSeller platform and is already processing orders, while several more are in the pipeline.

AceSeller is currently not open for sign-ups. We are working fervently on getting the little details right. However, if you want early access to AceSeller, please leave your email address with us, and we'll get back to you as soon as possible.

Our plans with AceSeller are huge. We've barely scratched the surface of what we want to offer, and this post doesn't do justice to even that little bit that we've already accomplished.

The amount of things we've learnt over the last couple of weeks alone is tremendous; I can't wait to start sharing that knowledge. There's so much to talk about - everything from the challenges we've faced in getting businesses online, to the user experience we want to provide, to how our technology choices came about and how we managed to race ahead to get AceSeller live. I'll keep churning out more details as frequently as possible. Stay tuned.

Thoughts On Taking the Entrepreneurship Plunge

2011-05-10T19:56:00.005+05:30

tldr; Jump to the bottom ↓

I found myself at a time in my career when I had to look back and reflect, and decide what I want to do next. Remain an employee? Or leave it all and become an entrepreneur. It's hard to make purely logical decisions about these things, in part because your life and well-being might be affected, but mostly because you need to make projections into the future and the future presents itself as a hazy picture at best. A lot of this decision is based on gut feel. This post outlines my thoughts.

Financial aspects

This was obviously the most important thing that I was thinking about. Salaried jobs give you a decent amount of financial stability. This is in sharp contrast to starting up, which has near-zero financial security, at least at the outset.

However, financial growth in a salaried job is not in your control at all. Your salary increments depend on a lot of factors: What is the industry standard paycheck being given out, what's the salary of your peers and bosses, what's the revenue of the company, what's the funding status of the company, etc. Yes, your performance does matter, but even with excellent performance you have an abysmal salary increase every year. What's worse, no boss will ever tell you that your performance has constantly exceeded all set expectations. They'll always find some cop-out; things like: "Your performance has been good, but you should take on more responsibility."

That's an awfully bad deal — the factors that affect my financial growth are not in my control, good performance pays very little, and there are text-book methods to even reduce the payout for excellent performance! I've tried fighting this at all my past jobs, and I've always lost. It's a system designed to make you lose every time.

It's very easy to take this negatively. When you realize that your performance doesn't matter anymore, the quality of your work suffers. You start going to work simply because you are obliged to. You start hating Mondays, and look forward to Fridays.

I am not like that though. More than anything else, I have a strong primal urge to create stuff. I never let my obviously slow and completely-out-of-my-control financial growth affect my quality of work. Fortunately, this kept me in the good books of my bosses and my employers at all times. That makes everything fine, right? It does, except when you stop to think: Where is all this going?, and discover that you don't really know. You realize that if you could instead use your zeal, energy and passion elsewhere where the promise of financial growth is higher, you could maybe make a lot more money for the stuff you are doing.

May be, I should start up.

Of course, the promise of financial growth is just that — a promise. There's a huge possibility that it will not work at all, and I will have failed. But then I realized that if I fail, it'll be of my own doing. It will be my mistake that stalls (or negatively impacts) my financial growth. That's a lot more control than I've been used to! I only need to be able to learn from my mistakes and change what I'm doing wrong quickly enough. I should be very cognizant about what might be mistakes, and reduce possible risks from those mistakes. Easier said than done of course, but at least I would be in control.

Creating something

Let's now talk about that primal urge to create that I mentioned above. It's one of the reasons I work with technology — it's very easy to create things seemingly out of thin air, with very little effort at nearly no cost. It's an awesome feeling when you build something and watch the world use it. This, I now understand, is why programming is argued to be an art — you are always creating. I have that creative urge in me, and I intend to never let go of it. It's the single most important character trait that I will treasure and nurture.

So, how do you create stuff when you are an employee? Turns out, it's nearly impossible. Firstly, there are the business goals of the company, and you have to align personal goals with business goals. For most people, personal goals just means making money. But that's not the case when your biggest passion is to create things. What it means then is that you have to compromise. You end up doing things that might not be fun to do, because the business requires it. Like most other people, this is what I have been doing.

Secondly, on those occasions when you do get to create, you are not in control of the decisions taken. There are several stakeholders in practically anything you do. Their opinions have to be factored in as well. By itself, the idea rocks — creating stuff is a form of collaborative art in some sense. However, in practice it never ends up that way; people's egos, unclear vision, different motivations, etc. get in the way of the quality of the product. You end up creating something that is not as good as it could be.

So, creativity at work practically doesn't exist. As a creative person, how do you deal with this? What I used to do was wait to get back home, and then I'd work on my own little side projects. Most of these projects have never seen the light of day. There have been all kinds of projects I've worked on on the side over the last couple of years: creating protocols, implementing protocol clients, writing some funky server-modules, and building stuff on the bleeding-edge of web tech. These products were meant to be given out for free, and I could've built a business model around it in the future if I wanted to. Actually, it didn't even matter that I didn't get these live; I was happy enough to have satisfied my urge to create. On some days, I have found myself working on my side projects till the wee hours of the morning, getting very little sleep, spending time at work because I had to, only to come back home and continue having fun on my side projects till the morning. It was exhausting, but I enjoyed it because I could finally create.

Starting up

If I could channelize this energy, focus on something that can actually see the light of day, and get it to generate enough revenue for me, I could maybe survive on this. I'll be working just as hard, and will have more fun doing it.

It's an unsettling thought process that's been eating into me for several months now, and I've been meaning to act upon it. I've been discussing this with several people, and there's a lot I've learnt. There are several factors to be considered and risks involved. It hasn't been an easy decision. I would be leaving my cushy job to take on what would be my biggest risk ever. And then I realized something.

Starting up is not a risk at all.

What is the worst that will happen? Even if I fail, I'm only losing my financial security. That's a reasonably easy problem to fix. I could always take loans from friends and family. Or I could secure investment to buy me more time. I'd have to have a revenue model that will start generating money from get-go, and that in itself will reduce the risk significantly. There are several solutions, but the fact remains that it's an easy problem to fix. If all else fails, I'll still be at least as employable as I am right now. I'd end up doing a salaried job like I have been doing, as much as I wouldn't like it.

The worst that will happen is that I'll end up where I am right now. That's hardly a risk!

Last Friday was my last day as an employee. I've never been more anxious and excited. I've finally taken the first steps towards doing what I wanted to always: fully control my financial growth, create what I want the way I want to, and do this at minimal risk of my financial security. At the risk of sounding overly dramatic: last Friday was the first day of the rest of my life.

Watch this space for more announcements coming soon!

The Impact of HTML5^H: Feature Detection

2011-01-21T19:15:00.007+05:30

Ian Hickson posted a day or two ago that the WhatWG has decided to drop the version number from HTML. On the face of it, it seems like a knee jerk reaction to fight an old rival that just announced the HTML5 logo, but it's a lot more than that. In Hixie's words:

The WHATWG HTML spec can now be considered a "living standard". It's more mature than any version of the HTML specification to date, so it made no sense for us to keep referring to it as merely a draft. We will no longer be following the "snapshot" model of spec development, with the occasional "call for comments", "call for implementations", and so forth.

What does this mean for us developers? It means that the spec will never be finished — the living standard bit — so there's no point waiting for an announcement saying that HTML5 is ready or anything to that effect. But that's just on the surface.

For front-end developers it means one more very important thing. It means that feature detection is more important than ever before. It'll be the only reliable way for us to determine browser support for features. Of course, we always knew that but rarely did we ever practice it. You think you might have, but the libraries you have been using didn't actually do this. Until very recently that is. jQuery removed all browser sniffing in jQuery 1.3 and the guys from Dojo have launched a project called has.js meant for library authors to incorporate feature detection. Of course, Modernizr has been around for a long time now, and its list of detectable features keeps growing.

But detecting features alone isn't enough. You need a way to work around them. This is where polyfills come in the picture. As Remy Sharp describes it,

A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will.

That way, feature detection happens at a lower level than the developer, and the developer can continue coding to the WhatWG/W3C specs. If this works as well as it says on the can, I think we can all move forward, and not worry about little pains like IE6.

What are the factors to be considered when creating a way to download a polyfill? The first is that there has to be a way to declare a dependency on a browser feature. Depending on browser feature detection, one or more polyfills might be downloaded for that browser. Secondly, the download of the polyfill will necessarily be asynchronous and the coding paradigm will have to take that into account. Thirdly, ideally the download of the polyfill itself shouldn't slow down the experience. This is impossible to do, but at least we should employ whatever techniques we have to reduce the impact of the download.

How would such an API look? CommonJS has been doing some great work with the Asynchronous Module Definition spec to help solve the general problem of dependencies in JavaScript. Maybe we can look at their API for help. To define a module, you'd generally write code that looks like the following (from their own example):

define("alpha", ["require", "exports", "beta"], function (require, exports, beta) {
    exports.verb = function() {
        return beta.verb();
    }
});

That looks simple enough. The first parameter of define is the name of the module, the second is a list of external dependencies that the module has, and finally it's the declaration of the module itself. Using RequireJS, the way to use such a module would be, (again, from their own examples)

require(["helper/util"], function() {
    //This function is called when scripts/helper/util.js is loaded.
});

That's a simple enough API. Unfortunately, we can't use this directly for our polyfills, since we'll need to only download the dependencies if the browser doesn't already support them. So, maybe for our purposes, we'll need to have an API that looks like this:

require(["our/polyfill/helper"], function() {
    requirePolyfills(["localStorage", "geolocation"], function() {
        // Polyfills have been downloaded and applied now if necessary.
        // We can code straight to the WhatWG/W3C APIs without worrying about browser differences.
    });
})

The requirePolyfills function is responsible for downloading the polyfills necessary depending on browser support in an async manner, and then calling the function passed in to hand over control to the developer. The developer then doesn't have to worry about browser differences and can write simple code completely devoid of browser specific hacks. It gets me excited just to think of how awesome it will be to program once we've got browser differences out of the way.

Taking this a level further, this could be done by library authors itself, to ensure that the footprint of the library is as small as possible. This way Chrome users will have an excellent experience since there's no polyfill to be downloaded, while IE6 users will have the worst experience since many polyfills will have to be downloaded. If you think that's worse than the state of affairs today, consider that Chrome users currently have to download all the browser hacks for dealing with IE6 that exist in the library, and then the code-path never hits them. Wasted download, and the worst possible experience for all users thanks to IE6.

Libraries are slowly migrating towards the CommonJS AMD spec. Dojo just announced partial support for it in their latest version. The landscape is bound to get better. If polyfills were to be part of the library itself, it would be awesome. That way, we ensure that the library has the smallest footprint possible.

That leaves us with two more problems. First: we need to develop a public repo of polyfills that are very well tested. The quality of polyfills is not something that library developers should be fighting over. Also, there's no reason for a polyfill to be tied into a library's APIs. And there's no reason why one shouldn't be able to use a polyfill without a library. The second problem is slightly more tricky. The problem is that of network latency. You wouldn't want to download a bunch of polyfills over slow network connections. Ideally, it should be just one file containing all the polyfills required for that browser. This might necessitate a change the API I've mentioned above. Feature detection obviously happens on the client, but then the client issues only one request for the polyfills file. The request could look something like: http://example.com/polyfills?include=localStorage,geolocation. The server basically just concats the polyfills the client has requested, and sends them down in one file. Awesome.

Unfortunately here I've added a server component which suddenly makes this far less appealing to library authors, and for good reason. I don't know of a clean way to fix this, except saying that there should be publicly maintained servers that do this for everyone. Something like Google's CDN. This solution isn't ideal for several reasons, but it might be a good stop gap. Of course, there's also the possibility that open source implementations of such polyfill servers can be developed for several languages, maybe even just web servers — I'm thinking mod_polyfill or something similar.

The best solution is not clear yet, but we have an idea of what it might look like. We'll have to see how things evolve in the coming few months to get clarity on this. Meanwhile, what do you think about this? Do you think there might be a better way to solve this problem?

Practical CSS3 Media Queries and Mobile Browsers

2010-10-16T16:48:00.011+05:30

tl;dr: Jump to the end of this post ↓

I've been working on-and-off on a little project on the side, and have been trying to make it as buzzword-compliant as possible, because, you know, that's what all the cool kids are doing. Making it buzzword compliant meant that I had to use persistant connections to the server for real-time data exchange, use non-blocking I/O, I just had to use node.js, and throw in generous portions of NoSQL. So I did all of that, and now my server is worthy of a new starburst sticker.

Now that the server was mostly ready, I shifted attention to the client. Clearly, I had to use HTML5 and CSS3, think heavily about Web Performance Optimization, and ensure that the usability trolls don't get a chance to make me look bad. That was the easy part, since I have been doing these things for years. The fun started when I decided to flirt with an idea I had never played with before.

The Mobile Web

CC: -Tripp-

Mobile devices, it seems, have finally arrived. We have forever dreamt of an always-connected world, and mobile devices seem to be delivering on that dream. Indeed, we are on the verge of having more traffic from mobile devices to the web than from desktop browsers^{[citation needed]}. In such a scenario, it's impossible to ignore mobile devices.

The problem is that no one knows what the mobile web means. In such a case, it's absolutely fine to interpret it the way you want to, and that's what I did. So, here's what the mobile web means to me.

The mobile web is that part of the web that works well on mobile devices.

Pure genius of a definition, isn't it? I know. Thank you. There's an ambiguity in the definition there though — what does it mean to work well? Turns out, no one knows that either. But there are some hints:

It should work fine in the mobile browser — no native apps, no downloads.
Context is king. The site should provide the right amount of data that is needed in a mobile user's use-case at that time.
The site should be touch friendly, meaning take care about hit areas and stuff because some people have fat fingers. Not me — my fingers are beautiful. Just thought you'd like to know.
Lightweight and fast. Because I want my data quickly, and I'm paying by the byte. This is true of the desktop as well, but especially true of the mobile web, because network operators try to suck as much as possible out of the wallet by giving as little as possible.

So, how do we go about building such a site? Generally speaking, this necessitates building a separate version of the site just for mobile browsers. Trust me, this effort is worth it. Don't believe all those standardistas who say change your CSS file, and everything will be magically fine. Their latest mantra is use CSS3 media queries and everything will be magically fine. Like most other things in life, nothing is that simple.

But there are times when that actually works. And this post is about those times. This post is only useful if:

Your site is already light enough and tightly focussed enough that the markup for your desktop version is going to be the same as that of your mobile version.
There's not really too much contextual data you need to provide to your mobile users, so again the markup is the same.
Your site is styled primarily with CSS. You are doing that already, aren't you?
You are lazy, and don't want to create multiple versions of the same content, otherwise known as maintainability or code reuse.

CC: Edward L

I'm definitely lazy, and I'm proud of it. I'd rather not write any code at all. If I have to write any code whatsoever, I'd rather write it such that (a) I never have to look at it again, (b) I keep using the same thing over and over again so I don't write the same thing ever again, and (c) I should write as little as possible. Fortunately, these are all considered good practices — maintainability, reuse and conciseness. I bet whoever said these were good practices was lazy. But as long as the rest of the world doesn't find out, this can be our little secret.

There's a problem with being lazy though. You have to work hard to be lazy. How ironic is that! And hard work is, well, hard. So, there's where I was, wanting to be lazy, tinkering with the idea of the mobile web, and looking at CSS3 media queries from the corner of my eye. Being lazy, before I wrote a single line of code, I wanted to know everything about challenges for mobile phones and media queries. I'll cut a long story short, and tell you my findings.

There's no standard screen size for the mobile. If you plot a graph of mobile screen sizes, the graph is going to be all over the place. That basically means you have to design for all screen sizes! This is going to be fun. Not.
Media queries let you target styles to different ranges of screen sizes. Awesome. Seems like a right fit for the job. So, we can have a different CSS file targeted to small screens, a different ones for medium sized screens (like the iPad), and the full of crap ones for desktop browsers. Neat. Except...
CSS3 media queries don't work in most mobile browsers and IE! Bam! Just when we thought we had a solution. Well, to be fair, it does work in some mobile phones — the iPhone's and Android's WebKit browsers being good examples, but both these browsers put together are such a small percentage of mobile users, it's not even funny. Blackberry's horrid browser, Opera Mobile and Symbian's native browser have the largest market share of all mobile browsers. We can't just ignore them, can we! Just like we reluctantly show love to IE, we'll have to show some love to these browsers as well. It's that kind of a relationship. (BTW, I think Opera Mini does support CSS3 media queries. I haven't tested this.)

So, I was going to throw the idea of media queries completely out the door, you know, baby and bath water and all that. This is when I saw an excellent talk by Luke Wroblewski. What he is advocating is that we should build for mobile sites first, and for desktops later. His arguments are mostly non-technical and about usability, design and innovation, but he underscores the importance of designing for the mobile. I get that, but it doesn't help me be lazy. Well, it could, but I didn't know how. It still looked like double the effort. Except, he had planted an idea in my head. You know, much like Inception. Come to think of it, Luke does look a little bit like DiCaprio, doesn't he? Cool!

Mobile First

CC: Mrs Logic

So far, I was thinking of making separate CSS files for mobile and desktop, and doing so in parallel. That mostly meant I'd do the desktop version first, and the mobile version next. Then I'd target different screen sizes with media queries (which I discovered wouldn't fly) and voila it would work everywhere. Instead, Luke's talk got me thinking: what if I design for the mobile first, and then target desktop browsers with media queries. This would theoretically work, since most mobile browsers are old, and they get the vanilla CSS files. For newer mobile browsers and most desktop browsers since they are new as well, I'd serve the full css file targeting them with media queries. Newer mobile browsers will understand it's not for them, so they'll ignore it. Older mobile browsers won't understand it at all, and hence ignore it. Most desktop browsers would know that the CSS file is for them, and hence apply it. This leaves our old nemesis Internet Explorer, but we're used to that already. We'll solve that problem later.

Now, about actually pulling it off. I found this document at Dev.Opera that goes into a fair amount of detail about media query parsing differences between browsers, old and new. This doc would definitely help. Now, I needed to figure out how to structure the CSS. Remember my laziness? This meant that there should be as little repetition between the mobile version and the desktop version. What would generally be the things that remain common across the two types of browsers? There's actually quite a bit. There's color schemes, there's some type information, and possibly some CSS niceties like rounded corners, gradients and effects. What's going to be different? It's mostly going to be font-sizes and layout. Sounds good so far, let's start implementing it.

The code

Since we've decided to work only with mobile browsers first, and serve it CSS like it's the 1990s, the following markup should do it.

<link rel="stylesheet" type="text/css" href="narrow.css" />

I actually went ahead with this and built the whole mobile version of the site, and tested it in Mobile Webkit on Android and iPhone and in Opera Mini, which are the two browsers I had access to on a couple of devices. I kept the layout fluid, since I didn't know the screen size before hand, and didn't want the site to break in screen sizes I didn't have control over. I strongly recommend that you go with fluid width layouts for narrow screens as well. I even tried it in a couple of emulators and it all looked fine. Of course, some of the fancy CSS rules didn't work on some browsers, but that was ok — things still looked reasonably pretty and it looked mobile-web-optimized. Awesome. Now, I turned my attention to the desktop. This was when the Dev.Opera doc came in handy. This is what my markup looked like:

<link rel="stylesheet" type="text/css" href="narrow.css" />
<link rel="stylesheet" type="text/css" media="all and (min-width: 400px)" href="wide.css" />

See that media attribute there that says media="all and (min-width: 400px)"? That's the media query. It means target this CSS to all media that have a min-width of 400px. Why all media? Because I was being lazy and didn't want to work on a print version at the moment. Also, it seemed like the most reliable media type to target from Opera's documentation. Why base this on min-width? Because that's the best way to target different device sizes. Why 400px? Because in portrait mode it would apply the narrow.css (screen widths are generally 320px for devices that support orientation), but in landscape mode or for most desktop browsers, it would apply the wide.css file. This suited me, since I wanted to utilize the extra width in landscape mode better. YMMV, and you should play with this number to suit your tastes.

Also, since I was applying both the files and hence cascading their rules, I could already go with most of the stuff defined in narrow.css. wide.css only had to override some properties — mostly font sizes, block positioning and layout. Tested this, and it continued to work with all the mobile devices I was testing in as it was before, and worked on desktop browsers with the wide.css layout. I just had to add ~~a few extra divs~~ some HTML5 semantic markup to get some extra styling hooks. Success! And I'm continuing to be lazy since I'm reusing as much code as possible. There is a disadvantage to this technique though. It requires the download of two files. I could have combined them into one file, but that would've introduced some hacks as described in the Dev.Opera document. I am consoling myself by saying that wide.css is actually a very small file, and CSS files are downloaded in parallel anyway, so the impact shouldn't be huge. But that said, it is something to think about.

Wrapping it up

That just leaves us with one beast — the old nemesis — Internet Explorer. We've gone through all this trouble to support all sorts of crappy old mobile browsers, it only makes sense that we don't leave IE behind. Now, IE doesn't understand media queries, so how do we serve it wide.css? Turns out, we can use IE against IE, thanks to it's own conditional comments! The final markup looked like this:

<link rel="stylesheet" type="text/css" href="narrow.css" />
<!--[if lt IE 9 ]>
<link rel="stylesheet" type="text/css" href="wide.css">
<![endif]-->
<!--[if (gte IE 9)|!(IE)]><!-->
    <link rel="stylesheet" type="text/css" media="all and (min-width: 400px)" href="wide.css">
<!--<![endif]-->

CC: Simon Zirkunow

Let's dissect that. Firstly, serve the old narrow.css the way it was being served. No change there. Next, detect if the browser is IE and the version is less than 9. Why 9? Because MS is promising that IE9 has got media query support, so we'd rather use that over blindly serving the file to IE. If it is less than IE9, serve it wide.css no questions asked. If the IE version is 9 or greater, or if it's a non-IE browser, serve it wide.css with the media query.

This post is bound to be outdated before it's even out, since MS is launching Windows Mobile 7 or whatever it is called with a very uninteresting version of IE which is purportedly somewhere between 7 and 8. But I don't know yet how the browser is identifying itself, and hence can't exclude wide.css from it. If you find out, please leave me a comment, and I'll update my post with your findings.

In the end

We've successfully managed to:

Target mobile phones, new and old.
Match device orientation for newer phones.
Apply different CSS to desktop browsers.
Get it working even for the thing that is IE.
Keep Luke happy.
Done all of this without using any pesky JavaScript or server-side UA sniffing.
Continued to be lazy.

This has not been without drawbacks:

Two CSS files are downloaded to wide clients. To make things worse, some parts of narrow.css are overridden in wide.css, making the double-download even more painful.
Mobile IE gets the wide version, mostly because I don't know too much about it.

This works for me for the moment though. Would love to hear your thoughts.

Like this post? I blabber on a lot about this kind of stuff on the twitters. Follow me there if you like.

Section 3.3.1 of iPhone SDK License Agreement

2010-04-11T13:12:00.008+05:30

CC: William Hook

It has been an interesting week for iPhone developers. iPhone just released the developer preview of the iPhone OS 4, which has got features that are exciting to both developers and users. However, John Gruber discovered that Apple made a change to their iPhone SDK Licence Agreement with this release.

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This amendment has far-reaching effects. The effects are so powerful that the FUD surrounding it over-shadowed the excitement of the OS upgrade itself. There's no doubt that there's evilness in this amendment to the ToS. The question is what part of it is evil, and how should we react to it. Let's analyze this amendment, and see what it potentially means.

On APIs

Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

This seems reasonable to me. It's Apple's platform, and they expose a bunch of APIs, and they only want developers to use those APIs. However, it stinks of potential anti-trust cases. However, this is not what got people pissed off for, so let's skip past this statement.

On language of choice

Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs

CC: Shane Gorski

This is plain stupid, and only serves to push developers away. Everyone knows that the choice of programming language hardly matters in any meaningful way, and what the developer is comfortable with is what s/he should ultimately use. This clause doesn't allow for that, and there's no good reason why it shouldn't. Just plain stupid.

This kills the soon-to-be-released CS5 Flash-to-iPhone compiler, the MonoTouch project which compiles C# and .Net to the iPhone, and the Unity3D project that let you program 3D games in C#.

However, also consider that without asking you for your source code, how can Apple guess which programming language you used for development? It's all compiled anyway. It just doesn't make sense. I don't see how Apple can enforce this. We'll have to see how this develops.

On compatibility layers

(e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This is the big one, and is the reason most people are pissed off, because it's implications are far reaching.

Firstly, consider the case where I want to build an iPhone app using Ruby, and I use a library that has wrappers on top of the Objective-C APIs. This is like the point above, where I should be able to choose my language and program in it. And like I said above, there's no reason to restrict this, and it's stupid on Apple's part to do this.

The other case is that of compatibility layers, where I code to an API much like above, but the compiler is designed to cross-compile to multiple platforms, not just the iPhone. This is the big one, and is what makes the future of platforms like Titanium and PhoneGap unclear. This means that as a developer, I only need to write once and the environment let's me compile and run anywhere. As we all know the write-once-run-anywhere dream has eluded us all the time — Java, Air and Flash being great examples of it. A look at applications like Eclipse, Open Office, etc., and virtually anything developed using Flash, and you'll see that it feels nothing like a native application on all platforms. This is neither the fault of the language nor the compiler, but that of the platform APIs (like Swing in Java's case). The problem is that since the platform API, which serves as a compatibility layer in these cases, tries to expose APIs that can work everywhere, they are forced to do a bad job of it.

Let me illustrate this with an example, to drive the point home. The Mac doesn't have a UI for combo-boxes, whereas both Windows and Linux do. What would a compatibility layer do in such a case? There are four possibilities:

If the API makes it possible to use combo-boxes everywhere, it'll not feel native on the Mac, because the OS itself doesn't do these kinds of UIs. The platform will have to fake it.
If it doesn't let you use combo-boxes anywhere, it'll seem less powerful on Windows for developers, and will provide a bad UX for users.
It can choose to present completely custom UIs, which falls in neither camps, and hence fails.
They could also say that you can use combo-boxes in Windows and not on the Mac, but that'll only make the programming experience horrible for developers.

So which approach is the least bad? Swing decides to compromise on UX. Flash goes the route of custom UIs.

An interesting case to consider is that of Google Chrome, which has done the absolute right thing. The core engine is C/C++, and UIs are coded separately for different OSs. However, this is clearly expensive to do, and only someone with Google's resources can pull it off.

CC: Rohit Gowaikar

Of course, there's also the possibility that Apple just wants to make it hard for developers to build apps that can run anywhere, by creating a lock-in. However, I don't think this is the case, because they are still allowing JS to run, and their browser is one of the best browsers ever that a developer can work with. This browser itself can be looked at as a compatibility layer that works across platforms. I've actually tried it — fairly complex applications built for the iPhone work just fine in Android-based touch phones with zero effort to port it. This is because when you develop for the iPhone browser, you are actually developing for Mobile WebKit, and has nothing to do with the iPhone Objective-C APIs per-se.

Aside: I've just negated my own point. I've criticized cross-compilers, and then said that the browser is a great environment to code because you are platform independent. However, I think that you should think different (pun intended) about browsers. This is because the browser is a sandbox that runs the Internet from the user's perspective, and it's expected that the UIs on web pages will be platform independent. That's not the case with native applications. Besides, the browser doesn't just run applications — they are also content distribution channels.

From the point of view of the UX of applications built using a cross-compiler compatibility layer, I sympathize with what Apple's done. Do I think such apps should be banned completely? I'm sitting on the fence on this one. I think the best thing to do would be to let the application fail in the market, rather than disallowing such applications outright. But then, I can see why Apple would ban it as well. Apple has always been a stickler for the UX of applications on their platforms. On the other hand however, they enforced this on the Mac OS by giving guidelines, not by disallowing such applications. So this thought is full of contradictions.

CC: Natalie Manyor

Then there's the case of the app store. The idea of a market place is awesome, but Apple's moderation is just stupid. Other issues apart (and there are several), it's a model that simply doesn't scale. Maybe Apple did this 3.3.1 thing just to ensure that they can moderate lesser apps and make their moderation generally easier to do? If that's the case, Apple is just reducing their problems and moving it to all their developers. Just another reason why Apple's moderation is stupid. Why Apple moderates is beyond me. No other platform that I know of does this, including Apple's own desktop OSs.

History repeats itself, sort of

There's a bigger concern I've got. Let me put it this way. I used to be a VB developer back in the day. When the Internet started becoming interesting, I found out that I could take my VB knowledge and port it to the web to build ASP programs. It was awesome, and I loved how Microsoft had made it easy for devs to move to the web as a platform. However, when the .Net framework was released, MS told developers like me that ASP was not cool anymore, and that we should choose either C# or VB.Net. VB.Net, for those who don't know, is nothing like VB. It's an entirely new language. Besides, MS seemed to put it's weight behind C#. Most developers were convinced that they should move to C#.

Not me. I was filled with FUD. I couldn't let a company decide what programming language I should use. What if I pick up C# and a couple of years later, just as I'm getting comfortable with it, they tell me that C# is not cool anymore? Am I shooting a moving target?

That was the time when I picked up my bags, and moved from the MS platform to open platforms. I picked up PHP because it's programming model resembled ASP, so the learning curve would be smooth. Of course, I still had to learn a new language, but at least this time it wasn't controlled by a company and I could use it just because there was community support. And PHP had (and still has) great community support. I had immunized myself from what companies have to say about my development tool chain. I was free!

In hindsight, this was the single most important decision I've taken that transformed my career. Not that I was any good at PHP. But the world of open platforms and open standards based development made me a better programmer.

Though the situation is not exactly the same in Apple's case, it's not too different. Here's a company screwing it's developers up because of what they think is the ideal vision for the platform. It's not a democratic decision — neither MS nor Apple consulted me when they were making this change. If I was now an Apple developer, I would hear alarm bells ringing, and would refuse to work in such a totalitarian environment.

But the iPhone is where my target demographic is!

Sure. I still think despite all of this that the iPhone is still a cool gadget, and users will continue to be attracted to it. And developers go where the users are. What's the point developing applications for platforms where there are no users! So, you want to build for the iPhone, but you don't want to build for the iPhone. How do you fix this?

CC: Masakazu Matsumoto

The solution is simple. Move to an open platform. I'm not saying that you should stop building for the iPhone, and move to Android. That'd be stupid. I'm saying that you build for the browser, and serve both iPhone and Android users in one go. As a long-time web developer and currently exploring the mobile-WebKit browser, I can tell you that the mobile-WebKit browser is the best thing to happen to web development in a long time. It has imbibed standards support like no other browser has, even on desktop computers. HTML5 provides access to APIs that are mostly sufficient to build rich mobile applications. You've got excellent control on layout etc, since the CSS support is one of the best in the browser landscape. In fact, the browser in the latest phones is so good, I find it difficult to understand why I'd ever build a native application.

Here's a listing of some APIs that are available in the iPhone's and Android's browsers, that you probably didn't know existed. Yes, you can use all of these APIs today!

APIs to get the users location using the GPS or cell-tower triangulation
APIs to make the application work offline
Local storage in the form of:
- key-value stores, or
- relational ACID compliant DBs
Awesome drawing APIs and vector graphics APIs

Of course, there are cases where you need to build a native application. Like if you want access to the camera. Or if you want to use the user's contact list. Or access the accelerometer. I'd still go native for those kinds of applications. However, very soon, that's likely to change as well, with the upcoming Capture API and Contacts API that are being spec'd. And I'm sure WebKit will one of the first browsers to adopt it.

On the whole, there's very little reason now to build native applications for the iPhone. Do it only if you know what you are doing, and you absolutely need to. Ask yourself before you start if you absolutely must go native. You'll discover that in most cases you won't need to. The browser is good enough. And you'll have supported other touch-phones while you are at it, for free, at its very least. At best, you've supported the entire mobile browser landscape, though that's a hard one, and realistically speaking you will compromise on the user experience.

One last concern remains. What if Apple decides to somehow ban browser based applications? Technologically speaking, I don't see how they can do that without reducing the power of the browser itself. One of the reasons the iPhone took off was because it shipped with a real browser. If they reduce the power of the browser, they reduce the usefulness of the phone itself. I don't see that happening. Secondly, the browser engine is actually developed independently of Apple — in fact Google contributes more to WebKit than Apple does. Unless Apple decides to revert to an older version of WebKit, or cherry-pick features from the public builds, they'll have to continue shipping the public builds of WebKit or feature-freeze on the current build. If anyone thinks Apple will (or can) control browser based applications, they're just plain wrong. The web is far too big for Apple to make such a move.

These are my thoughts. I'd be extremely interested in knowing what you think. Are you affected by this change? Are you going to move to the browser?

geocitieslycostripod.com

2009-10-18T01:03:00.002+05:30

Just deployed a new site to display my HTML5 learnings so far.

The idea is to demonstrate the proper use of the section, article, time, header and footer tags. I might have used a couple others. I've also used some CSS3 text-shadow rules for the first time ever in a production website. I hope to get positive comments from you about the site.

So go to my new site: http://geocitieslycostripod.com for the full glory of HTML5.

PS. Hey, I didn't say anything about Web 1.0 or Web 2.0 or anything!

Songs In Code

2009-08-22T16:04:00.001+05:30

Christian Heilmann of YDN fame, started a meme on twitter for writing songs in code, within the 140 char limit of course. Participation was simple: simply add a hashtag of #songsincode to the tweet. Quite soon, it became a trending topic on twitter. One way to look at it is that people on twitter have nothing to do, but the more likely one is that geeks found something to kill time with on a Friday.

Of course, quite a few gems came out of it. I'm listing a couple of my favourites below:

!my.isLover(billyJean) && billyJean.claims(my.theOne) && !my.isSon(theKid)
while (countdown > FINAL) countdown--;
public void setShirt(Shirt s){ throw new ImTooSexyException(s); }
if (this.streets.name == undefined) { _root.where = this }
SELECT person WHERE AGE > 12 AND AGE <20 AND SMELLS LIKE '%SPIRIT%
<span style="color:#f00"> <span style="color:#f00">wine</span> </span>
if(me.crazy.go()){ you.call(meSuperman) }; function meSuperman(){ return '?' //Kryptonite }
.clowns{float:left;} .jokers{float:right}; #me_you{position:fixed;margin:0 auto;width:100%}
var i = {shot:{sheriff:true,deputy:false}}
try{if(money>0 && work=='' && chicks=='free'){ throw 'that ain\'t working' }}
class HotelCalifornia { void checkOut () { canLeave=false; } }
while(1){ try { Britney.Sing(); } catch (Exception ex) { throw new Exception("Oops"); } }
UPDATE people SET parent_occupation = 'preacher man' WHERE has_pleased = 1
["step", "move"].forEach(i.watchingYou);
(defun get (x) (if (neq x 'satisfaction) (error))) (get (not satisfaction)) ;
99.times {Ballon.new(:red)}

Downloading JavaScript Files in Parallel

2009-03-20T16:12:00.009+05:30

Update: There were some bugs in the code here, which have been fixed. If you were using the older version of this script on your site, you should update it.
Also, a lot of people have got back to me about them getting undefined symbols, so I've highlighted parts of this post that are absolutely critical for it's functioning.

Steve Souders, creator of YSlow, author of the book High Performance Web Sites, is back in action writing a book titled Even Faster Websites. In it he details what one can do after the 14 YSlow rules (laws?) have been implemented, and you still want better better performance.

6 days ago, Steve gave a talk at SXSW Interactive, the slides of which are available on Slideshare. In it, he goes on to suggest (slide 27), that we should load scripts without blocking. To me, this seems like a very interesting idea, and based on his hints in the next few slides, I started experimenting.

Let me back up a little. When browsers download scripts, they block all other resources from downloading until such time that the script has finished downloading. When I mean all other resources, it includes even other CSS files and images. There are several ways to reduce the impact of serial script download, and the High Performance Websites book makes a couple of good suggestions.

Rule 1 - Make Fewer HTTP Requests
Rule 5 - Put Stylesheets at the Top
Rule 6 - Put Scripts at the Bottom
Rule 8 - Make JavaScript and CSS External
Rule 10 - Minify JavaScript

There are several others, mostly around caching strategies and reducing HTTP overhead, but these alone reduce the impact of serial script download significantly.

Now, if you haven't already taken care of these rules of optimization, my suggestion will be hard to implement, or will reap no benefits. You can stop reading now, and go back to your site to optimize your code.

Regular `<script>` tags:

See that waterfall pattern of file downloads? Nothing else is downloaded when a script is being downloaded, not even other scripts. The time gap between successive downloads is the time taken to evaluate the script, roughly proportional to the size of the script. Notice also that this takes in excess of 600ms even when the files are being served from my local machine, effectively having near-zero network latency.

With script parallelization

Now, this looks much better, doesn't it? Not only has everything downloaded in parallel, it has taken less than half the time for the same size of files. In fact, you will notice that some noise when recording this data made the files take longer to download in this case, yet the total time was less than half of the pervious case.

So, how did I do this? Read on...

One script tag to rule them all

Reading into Souders' suggested techniques (If you still have that slideshow open, go to slide 26), I decided that what I wanted was:

I want the browser busy indicators to show,
I want a script that doesn't care if I'm downloading from the same domain or not, and
I wanted to preserve the evaluation order in case of interdependent scripts.

So, I came up with the following little script:

<script type="text/javascript">
    (function() {
        var s = [
            "/javascripts/script1.js",
            "/javascripts/script2.js",
            "/javascripts/script3.js",
            "/javascripts/script4.js",
            "/javascripts/script5.js"
        ];

        var sc = "script", tp = "text/javascript", sa = "setAttribute", doc = document, ua = window.navigator.userAgent;
        for(var i=0, l=s.length; i<l; ++i) {
            if(ua.indexOf("Firefox")!==-1 || ua.indexOf("Opera")!==-1) {
                var t=doc.createElement(sc);
                t[sa]("src", s[i]);
                t[sa]("type", tp);
                doc.getElementsByTagName("head")[0].appendChild(t);
            } else {
                doc.writeln("<" + sc + " type=\"" + tp + "\" src=\"" + s[i] + "\"></" + sc + ">");
            }
        }
    })();
</script>

It's a little ugly: There's a user-agent sniff happening in there and I've written it so as to use the least number of bytes possible (save for the indentation), but it works, and has no dependencies on any library. Just modify the array on top to place your list of scripts you wish to include, and let the rest of the script do the dirty work. If you need to include scripts from another domain, just use an absolute path.

This code was written keeping in mind that this should be the only piece of on-page inline JavaScript. This can then go on and fetch the script required in parallel, and those in turn can unobtrusively do their thing.

This works as advertised in IE and FF. ~~I haven't tested the parallelization in other browsers, but at least it fails gracefully and preserves script execution order.~~ This has now been tested in Safari, Chrome and Opera as well, and works as advertised everywhere.

Find this interesting? Follow me on twitter at @rakesh314 for more.

JsMemcached.js - A Jaxer client for memcached

2009-01-21T19:20:00.003+05:30

Two days ago, on a lazy evening, I started work on my first solid Jaxer project — building a memcached client. As a testimony to the elegance of JavaScript, it took me less than 2 hours to get a basic memcached client up and running.

What is memcached, you ask? From the memcached website:

memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.

What it does is, lets you use excess RAM on your server machines as temporary stores of data, so that you can avoid going to your DB when you want frequently accessed data. Needless to say, accessing data from RAM is much faster. Since the creation of memcached for LiveJournal.com, memcached has become the cheapest and fastest way to scale a website.

Now, my implementation is not feature complete, nor at peak performance, but I aim to take it there. Even so, I decided to get my code out and available for everyone to see, so that people can tell me what they think of it.

You can go to the Google code page for the JsMemcached-client project, or download the code right away. Though limited in features and with a possible bug in an edge case in the get call, you can start using this already.

This is my first open-source project, so please don't be too harsh in your feedback.

Help needed: I need to figure out how to performance-optimize this code. Either I need to get rid of that loop in the get call, or I need to write a wrapper around libmemcached. I would prefer the latter, since I have to add more features for feature-completeness. Any idea on how I can get Jaxer to talk with libmemcached (or any other such out-of-process thing)?

Function declaration vs. function assignment in JavaScript

2008-12-29T19:51:00.004+05:30

I'm surprised how much I learn about JavaScript every single day.

It all started with a post that's wrongly titled to indicate a bug in Internet Explorer. The comments are an interesting read, where people go ahead to suggest that this "bug" exists in all browsers except Firefox. Then, they discover that it's actually a bug in Firefox, and not the other way round. Then a bug report is filed with Firefox. Brendan Eich comes along and resolves it as an invalid bug, with a brief explanation.

To explain, here's what's happening:

Ned Batchelder (the poster of that blog post) came across this piece of code that worked differently in IE and Firefox.

function really() { alert("Original"); }
if (0) {
    alert("No");
    function really() { alert("Yes, really"); }
}
really();

The explanation is pretty simple. A function really is defined which alerts "Original". Inside an if block which should never get called, the really function is redefined to alert "Yes, really". Since the code block is inside an if that should never get called, the assumption would be that the function shouldn't get redefined. This is how Firefox behaves. However, not so with IE, which redefines the function. Weirdly, the alert("No"); is never executed, even though the function gets redefined.

Turns out, IE is not the only one doing this. All webkit browsers and Opera also exhibit this behavior. Kris Kowal was the first to suggest that this is a bug in Firefox for the right reasons. So, a bug report was created and BE closed it. Here's his explanation:

ECMA-262 Edition does not specify functions in sub-statements, only at top level in another function or a program (see the normative grammar). Therefore this bug is invalid as summarized.

Moreover, we have extended ES3 (as allowed by its chapter 16) for ~ten years to support "function statements" whose bindings depend on control flow. So this again is invalid. There's a bug to dup against, if someone finds it feel free to change resolution accordingly.

/be

For those who didn't understand, here's a simpler version of what BE said.

function really() { ... } is a function declaration.
Function declarations can only exist at the top level, or inside other functions. They cannot be inside the if statement.
If the browser finds that it is inside the if block, the browser is not allowed to throw an error. Instead, it should handle it gracefully.
There's no spec that defines how such situations should be handled, so browsers are free to do what they want to.
All browsers except Firefox first scan the code at load time to find function declarations. When doing so, they look at the function first, and then it's redefinition. In this case, the original function should be discarded, and the new function should be used.
Firefox does this at runtime, evaluating the functions when the code execution sees it. Hence Firefox doesn't redefine the function at all.

So, BE's explanation that this is not a bug is valid. This is a gray area in the spec, and the browser is free to implement it the way it wants.

Also, and more interestingly, BE brings up function statements which do not follow this rule. A function statement would look like this:

var really = function() { ... };

Now, the spec very clearly says that function statements should be evaluated at runtime based on control flow - stuff like that if statement. Ned wouldn't have run into this problem if he was using function statements.

I learn new things about JavaScript every day!

HTTP cache optimization

2008-11-21T22:22:00.004+05:30

You know what else Twitter is good for? Quotations. As good friend and colleague, Piyush Ranjan said:

Recession is [a] good time for innovation. Best innovation happens in crunch situations. Otherwise people just throw money at the problem!

At Cleartrip, as with any other company, we're always looking for ways to reduce our costs. Now with the travel industry in India hit hard, and the general economic slowdown, it's very interesting for us techies to innovate in ways that will help us cut costs.

One the recent things we've been working on, and the stuff I want to talk about here, is the area of bandwidth savings. The benefits of bandwidth savings are usually twofold. Firstly and obviously, it reduces our bills. Secondly, it usually manifests itself as a better experience for the user, since he doesn't have to wait as long for stuff to transfer from our servers to his browser every time he moves between pages.

Now, our site is a fairly dynamic site. Almost every page in the site (well, the significant ones at least), are so dynamic, they cannot even be cached for a couple of minutes. So, caching HTML doesn't suit us. What we can cache is everything else - images, CSS and JavaScripts. Also, since we try to adhere to web standards as much as possible while being as Web 2.0 as possible (whatever that means), our use of CSS and JavaScripts is pretty heavy.

Phase 1

So, a couple of months ago, we made our first set of optimizations. We noticed that our images change very rarely - some of them hadn't changed since we first made them. There was no point sending down copies of the images to our users frequently. These could be cached pretty aggressively. We decided on an arbitrary time of 1 month for the caching of images.

Next came the JavaScript and the CSS. This posed a considerable problem. We keep doing JS and CSS changes very frequently on our site - as frequently as a couple of times a day. We couldn't afford to have them aggressively cached at the client end. We needed the agility to update our users' cache with the new versions of our code. Again, arbitrarily, we decided that the cache time for JS and CSS files would be 2 hours. That way, it wouldn't be in users' cache very aggressively, while remaining in his cache for about the length of his usage session. At the same time, it would take at most 2 hours for our changes to propagate to all users.

So, with this configuration change rolled out (it's not at all hard to do if you understand caches well) we sat back and monitored our savings. Turns out, the savings were pretty amazing. Hrush, our founder, even blogged about how our data center providers were surprised to the extent that they said that it was "just not possible" that we have such low bandwidth consumption for the traffic we get!

The problems

How ironic our data center guys said that, because just around that time, we were looking at how we can optimize bandwidth usage even more. And why did we decide to optimize further?

Because you can
Some of our files never changed at all - core JS libraries, for example. Why bother downloading them again after 2 hours?
Because this setup was hard to work with. Remember I said we patch stuff to production very frequently? That it takes two hours to propagate meant that if it was a bug fix, it might be broken for two hours even after we've put up the patch.
Because it gets very hard to make changes that have dependencies with other resources. For example, if the JS needs certain CSS changes, and certain markup changes, in what order do you put the changes up on the server?

This usually meant that we had to plan in advance and we would still have some backwards-compatibility cruft in our JS to manage this 2 hour transition. Sometimes it would take an entire day to make even a minor patch since it had to be batched with breaks of two hours. One quick-fix would be to rename the file and all references to it, but it's easy to see how painful that is to do on a file-by-file basis, not to mention that we'd run out of file names pretty soon!

Phase 2

One thing for sure, though. If we could somehow manage the file name issue, we can solve all the problems I listed out. That's because every time we made a patch with a different file name, it would instantly be available to all users, irrespective of their cache status. This gives rise to another interesting possibility: we didn't have to restrict ourselves to the 2 hour window anymore. We could potentially increase our cache expires time to 20 years for all that matters. That should give us MUCH more saving than we get currently, and our users will download as little as necessary.

Except, we didn't know yet how to solve the file name problem gracefully. Ideally, there shouldn't be a human being deciding which files have changed, what the file names are, and going all over the place and changing them. That would make it tedious and error prone, not to mention boring. Then of course you have to think about how these file name modifications would work with source control. You don't want to mess up your clean source code management history.

The solution to the source control mess thing was rather easy. We fake the file name. Here's what we do. We take a file name and append a random number to it. This will make the client believe that the file name has changed, and will negotiate with the server for the file. Meanwhile, at the server, we could have a rewrite rule that transforms the file name to something that maps to a real file on our server. Sounds simple enough. Tried it, and it worked like a charm.

Now, to crack the real problem - how do we generate these numbers in a sensible way. The number essentially had to be such that it would never repeat (at least for any given file), it would be global in that two pages shouldn't be using different numbers for the same resource, and when the number changes it should instantly reflect site wide. Now that we knew how the number should behave, the quest was on to come up with a mechanism to generate these numbers.

The solution

After a lot of thinking, we had a shameful duh moment, and it suddenly all made sense. We didn't need to invent these numbers at all. We just needed to use our source-control revision numbers! The revision numbers match all the characteristics of the number we want. Why bother with complex systems to generate and track numbers when it was already available, even if very disguised.

I'll save you the implementation details about how we made this available site wide, and how we made it possible to have instant global changes to this number. That definitely wasn't the tough part, and I'm sure you'll figure out the details. Who knows, maybe Piyush might just release a plugin for Rails to do it automatically for you. However what surprises me is that it's very hard to find such gems of knowledge on the net. I'm now beginning to think that maybe this design pattern should be used for distribution of all static resources on the web. We're definitely not the first to invent this pattern - why is no one else talking about it?

We've only just rolled this out on cleartrip.com and are still to get a decent sample of data to see how it has impacted our bandwidth consumption. But any fool could guess that our bills should reduce significantly with this change.

Joel on Project Managers

2008-11-12T14:48:00.003+05:30

This quote is long, in typical Joel On Software style. He said this in his latest podcast over at Stack Overflow with Jeff Atwood. I've ripped it off the transcript wiki. Definitely worth a read.

Here's my feeling about project managers:
One of the things that is interesting is that project managers, traditionally, are brought on because you have a team of yahoos - and this is just as true in construction, or in building an oil rig, or in any kind of project as it is in the making of anything - making a new car at general motors, or designing the new Boeing 787 dream liner - as it is in the software industry. Project managers are brought in because management says: "Hey, you yahoos! You're just working and working and working and never get the thing done and nobody knows how long it's going to take." If you don't know how long something's going to take and you can't control that a little bit then this really sucks from a business perspective. I mean; if you think of a typical business project - you invest some money and then you make some money back. The money you make back - the return on investment - might be double the amount of money you invest and then it's a good investment. But if the investment doubles because it took you twice as long to do this thing as you thought it would then you've lost all your profit on the thing. So this is bad for businesses to make decisions in the face of poor information about how long the project is going to take and so keeping a project on track and on schedule is really important.
It's so important that they started hiring people to do this and they said: "OK, you're the project manager - make sure that we're on track." These project managers were just bright college kids with spreadsheets and Microsoft project and clipboards. They pretty much had to go around with no authority what so ever and walk around the project and talk to the people and find out where things were up to and they spent all their time creating and maintaining these gigantic gantt charts - which everybody else ignored. So the gantt charts, and the Microsoft project, and all those project schedules, and all that kind of stuff, was an artifact created by a kind of low level person. Although it might be accurate depending on how good that low level person was, but it was still an output only thing from the current project: Where are we up to? What have we done? How much time have we spent? What's left? Who is working on what?
Then, for some reason, these relatively low level people, who were not actually domain experts, (if they were at Boeing they don't know anything about designing planes, if they were on the software team they're not programmers - they're project managers, and they don't know anything about writing code) they start getting blame when things went wrong and they started clamoring for more responsibility, more authority to actually make changes and to actually influence things and say: "Hey, Joe's taking too long here - we should get Mary to do this task, she's not busy." The truth is that they started getting frustrated because they were low level secretarial-like members of their teams and they wanted to move their profession up the scale so they created the project management institute - or whatever it's called - and they created this thing called... ah, I don't even know! But they created a whole professional way to learn to be a professional project manager and they decided to try to make it something a little bit fancier than just the kid with the clipboard that has to maintain these gantt charts all day long. You can tell this is what happened because the first thing project managers will tell you about their profession is that the most important thing is that they have the authority to actually change things and that they are the ones that actually have all the skills that can get a project back on track, or to keep a project on track, and therefore they need to have the authority to exercise these skills otherwise they'll never get anything done, they'll never be able to keep the project on track, they don't just want to be stenographers writing things down.
The trouble is, they don't actually have the domain skills - that's why they are project managers. If you are working on a software project you know how to bring it in on time and you've got to cut features, and you know which features to cut, becuase you understand software intrinsically and you know what things are slow and what things are fast and where you might be able to combine two features into one feature, where you might be able to take a shortcut. That's the stuff a good developer knows, that's not the stuff a project manager knows. In a construction project it's the architects and the head contractors who know where shortcuts can be taken and how to bring a project in on time not the project manager. The project managers don't have any of the right skills to affect the project and so they inevitably get really frustrated and everybody treats them like secretaries, or treats them like 'annoying boy with clipboard', when they really don't have a leadership role in the project - and they're not going to be able to because they don't have the domain expertise. No matter how much they learn about project management, no matter how many books they read, or how many certificates they get, no matter how long they've been doing project management: if they don't know about software, and software development, if they don't have that experience, they are always going to be second class citizens and they're never going to be able to fix a broken project.

Understanding eval scope. Spoiler: It's unreliable!

2008-10-08T21:46:00.010+05:30

Today, I ran some tests to help me understand the scope in which an eval runs. Turns out, like so many things in the browser world, it's very unpredictable and exhibit different behaviors in different browsers.

Let's start with the following snippet of code. I've added comments to demarcate areas in the code, which I will be changing with each iteration.


var foo = 123;
var bar = {
    changeFoo: function() {
        // We'll keep changing the following snippet
        alert(this);
        eval("var foo = 456");
        // Changing snippet ends
    }
};

bar.changeFoo();
alert(foo);

A little explanation of the code above. foo is a variable in the global scope, and it's value is set to 123. An object bar is created with a single method changeFoo which does an eval. The eval creates a local variable (thanks to the var) foo, and sets it's value to 456. bar.changeFoo is called, and the value of the global foo is alerted.

The aim is to test the scope in which eval runs. If eval is in the global scope, the global variable foo should change it's value. If eval is in the local scope, the global foo should be unaffected. Then there are various things we can do inside the changeFoo method which should keep altering the scope of this, so we are also alerting this to see what happens.

The findings are listed below:



alert(this);eval("var foo=456");
alert(this);window.eval("var foo=456");
alert(this);this.eval("var foo=456");
alert(this);eval("var foo=456", window);
(function() {    alert(this);    eval("var foo=456");})();
(function() {    alert(this);    window.eval("var foo=456");})();
with(window) {    alert(this);    eval("var foo=456");}
with(window) {    alert(this);    window.eval("var foo=456");}

	Changed snippet	Internet Explorer	Safari 3.x	Firefox	Google Chrome	Safari Nightlies
1	`alert(this); eval("var foo=456");`	123	object	123	object	123	object	123	object	123	object
2	`alert(this); window.eval("var foo=456");`	123	object	123	object	456	object	123	object	456	object
3	`alert(this); this.eval("var foo=456");`	error	object	error	object	error	object	error	object	error	object
4	`alert(this); eval("var foo=456", window);`	123	object	123	object	456	object	123	object	123	object
5	`(function() { alert(this); eval("var foo=456"); })();`	123	object	123	window	123	window	123	object	123	window
6	`(function() { alert(this); window.eval("var foo=456"); })();`	123	object	123	window	456	window	123	object	456	window
7	`with(window) { alert(this); eval("var foo=456"); }`	456	object	456	object	456	object	456	object	456	object
8	`with(window) { alert(this); window.eval("var foo=456"); }`	456	object	456	object	456	object	456	object	456	object

What I think of these results:

I don't know what Firefox is doing in case 2, and for some reason Safari Nightlies seem to be following it. Maybe it's just beyond my understanding, but case 2 is not supposed to be different from case 1. Why does case 2 operate in global scope? If window.eval is different from eval, case 3 shouldn't all have given errors. Someone please help me understand that $hit.
Case 4 makes sense, but that's a non-standard behavior in Firefox. Understandable that no one else exhibits it.
IE baffles me in case 5, and Chrome seems to ape it. In this scenario, the anonymous function is supposed to have the global scope - so, in this case, this should point to the window. WTF is happening here!
Consistent with case 2 above, Firefox and Safari Nightlies continue to display weird behavior in case 6. For some reason, in these two cases, the eval operates in the global scope.
Now, I have no idea why, but only cases 8 and 9 seem to really work at all. This is despite Doug Crockford going on and on about not using with constructs. It's also despite being beyond (my) understanding about why the with should make any difference to the eval, since eval is part of the window object.

All in all, if you are going to be evaling JavaScript (not JSON), and you want the eval'd code to run in the global scope, you should use the with block around the JavaScript snippet. Or else, you can lose a lot of hair handling cross-browser issues.

Hope you don't lose as much hair as me.

Housekeeping

2008-09-17T23:28:00.002+05:30

I've done a couple of minor changes to this blog's UI. Nothing dramatic, but I thought I should draw your attention to it, especially if you are one reading only from my Atom/RSS feed.

The first change came from realizing that my posts are longer than they should be. Somehow, I can't seem to compress them beyond what I already do. Long pages are a pain the wrong spots to read, so I decided to expand Douglas Bowman's original layout to a fluid width page, so that my posts consume lesser vertical space. (I just noticed that Steve Yegge has done similar fixes - I'm flattered.)

Secondly, and sort of to compensate for my lowered rate of posting on this blog, I've included two new feeds you can subscribe to on this blog. You can find latest updates to these feeds in the right sidebar. First is my feed from del.icio.us, which happens to be my bookmarking service of preference. Secondly, is my list of shared RSS feeds from my Google Reader. Both of these feeds get updated more frequently than my blog itself, so you might find these interesting.

This way, not only do you keep in touch with what I'm writing, you can also keep in touch with the stuff I'm reading. Expect to find some tech humor in these feeds too ;). Here's the rule of the thumb: The two new feeds reflect what I'm thinking strongly about, but I do not necessarily have an opinion about. My blog is my list of opinions. That's the difference.

I've been testing these thingies on my blog for some time now, so if you've been around here recently, you might have already noticed these changes. I just thought I'd wait a bit before I can announce these new things - turns out Google is doing a reasonable job of ensuring these things work, after all. ;)

JavaScript for Linux Hackers

2008-09-03T14:25:00.004+05:30

Two weekends ago (24 August), I gave a talk about JavaScript at the Indian GNU/Linux Users Group of Mumbai (ILUG-BOM) - A small gathering of Linux hackers from around the city. The talk was held at the Homi Bhabha Centre for Science Education (HBSCE), TIFR, Mumbai.

It was very weird having to explain JavaScript to kernel hackers and sysadmins. It entails a different approach - one where you have to assume that the audience knows a lot already, probably more than you in some respects. They are not one to get wowed by browser effects and visual fanciness. Also I know very little about Linux systems, so we had very little in common. It's very challenging preparing for such an audience.

I spoke about the language, it's history, it's expressiveness, the type system, variable casting, objects, marshaling objects, it's lambda nature, and several language constructs, especially functions. What I didn't cover was things like the DOM, inheritance patterns and constructor functions, but there has to be something for next time, right? ;)

I think it went pretty well. Well enough for them to invite me for another session where we could cover the left-out topics. I'm sorry - I would have put my slides on slideshare or something, but honestly, when I was running through my slideshow the day before the presentation, I nearly dozed off. So I decided that I'd just do the presentation without the slides - just me talking, and a JavaScript console on the screen.

element.hasFocus? document.activeElement!

2008-08-29T20:48:00.005+05:30

Today at work, in some code I was writing, I wanted to know if a given input box has focus or not. Turned out, this is surprisingly difficult. The input element doesn't have any hasFocus or similar property! No wonder working with the DOM keeps tripping people up!

Turns out, from quite some time now, Internet Exploder has been supporting a proprietary property - document.activeElement - which tells you which element is current focussed. Exactly what I needed. Except this is proprietary - I tried in Firefox 2, and it didn't work as expected. However, fortunately, turns out the HTML 5 spec has now incorporated this new property of the document object, and all future browsers should support it. Firefox 3 already supports document.activeElement. I've read that Opera supports it, but haven't tried. Safari does not, but the latest nightlies support it as well. Of course IE6 and IE7 support it perfectly well - IE invented it after all. So, of the big browsers, only Firefox 2 and Safari are problematic.

Since my code was not super critical, I've decided to skip support for just this bit for Firefox 2 and Safari. In any case, I'm hoping (against hope?) that both these browsers have a faster upgrade cycle than others, so they'll be outdated pretty soon.

Just in case you were thinking that the focused element can easily be 'discovered' by using the onblur and onfocus events, think again. Firstly, according to the specs, the focus and blur events don't bubble, so you can't use event delegation to capture all focus/blur events on the document. In any case, if you could use event delegation, putting these event handlers in an external script would mean that the script will kick in after a little delay - either after the script has loaded if the script tag is placed at the bottom, or after the page load happens if you are waiting for the DOM to be ready before you can use it, which in my case wasn't acceptable. The only other solution is to have a script include or a inline script tag that declares a function before the DOM is loaded, and then have inline onblur and onfocus event handlers DOM Level 0 style. That's just plain ugly. None of these solutions are either workable or graceful.

Brendan Eich on code translation to JavaScript

2008-08-13T21:28:00.003+05:30

I've always hated the idea of some server-side language (like ASP.Net, GWT, RoR, what-have-you) generating JS code to run on the client. I'm glad at least Eich agrees with me, as is published in this interview. (Jump to page 3 for this excerpt.)

I did not intend JS to be a "target" language for compilers such as Google Web Toolkit (GWT) or (before GWT) HaXe and similar such code generators, which take a different source language and produce JS as the "object" or "target" executable language.
The code generator approach uses JS as a "safe" mid-level intermediate language between a high-level source language written on the server side, and the optimized C or C++ code in the browser that implements JS. This stresses different performance paths in the JS engine code, and potentially causes people to push for features in the Ecma standard that are not appropriate for most human coders.
JS code generation by compilers and runtimes that use a different source language does seem to be "working", in the sense that JS performance is good enough and getting better, and everyone wants to maximize "reach" by targeting JS in the browser. But most JS is hand-coded, and I expect it will remain so for a long time.

That said, I think Eich doesn't highlight some of the other problems with server-generated JavaScript: ability to debug, potentially unoptimized output, and potentially inefficient code. I've worked with server-generated JavaScript in ASP.Net and RoR, and I know what a pain it can be.

IE Congratulates Firefox

2008-06-20T14:59:00.004+05:30

... on shipping Firefox 3.0.

The comments from around the web are hilarious:

Don't eat it.
Is it not poisoned?
That cake will give you CSS rendering errors, in your colon.
Moments later the cake hit a knife/plate standard it wasn't compliant with.
It must have been hard for them to put "love" on the cake
As you eat away the icing, you'll see that the cake is blue... little by little, it's becoming clear... it's the blue screen of death!
Congratulations on shitting the IE7 Team
...did it come with an End User License Agreement...?
There should be some bugs inside the cake.
...it's probably half baked too!
I guess that box was rendered in quirks mode.
Sheesh, even their cake has box model bugs.
I was wondering what the IE team had been doing for the past 3 years...
There's actually an IE team?
[Apple] snuck their cake through during the last Quicktime update.
And if you didn't like the candles, you had to replace the whole cake.
...that the cake tasted pretty good, but as they started to dig in, they sadly realized that instead of a whole cake, they had actually gotten a thin layer of cake on top of a cake-shaped support structure made of toothpicks and glue.
Turns out they forgot to add sugar to the cake. That will be added on Patch Tuesday.
Good luck getting the recipe for that cake.

Simply use HTML. Not XHTML.

2008-06-10T19:24:00.003+05:30

The good 'ol argument about HTML vs. XHTML seems to have resurfaced on the Internets. I have been firmly in the XHTML camp at one time, but I had made a mention in a previous post about why I think that there was no point in fighting this battle anymore. There is a clear winner - HTML.

Of the lot of recent posts out there about which is better than the other, this little thought experiment echoes my sentiments about XHTML vs. HTML.

You pore through the raw source code of the page and find what you think is the problem, but it’s not in your content. In fact, it’s in an auto-generated part of the page that you have no control over. What happened was, someone linked to you, and when they linked to you they sent a trackback with some illegal characters (illegal for you, not for them, since they declare a different character set than you do). But your publishing tool had a bug, and it automatically inserted their illegal characters into your carefully and validly authored page, and now all hell has broken loose.

The emails are really pouring in now. You desperately jump to your administration page to delete the offending trackback, but oh no! The administration page itself tries to display the trackbacks you’ve received, and you get an XML processing error. The same bug that was preventing your readers from reading your published page is now preventing you from fixing it!

The fact is today's web is one where content might pour in from various locations, many of which you might not have control over. It is important to inter-operate with these kinds of content sources. Expecting strictness from an external source is not only overkill, it's folly to do so.

I had faced this problem when I had worked on the Sacramento Kings website. The content was coming from various sources, some even as trustworthy (for them at least) as the NBA. However, content encoding and ill formed markup issues were huge enough to get the JavaScript all crazy. I can't even imagine the amount of problems I'd have faced if we'd have decided to use a XHTML strict, or even transitional, doctype for this job. How can we force a content author to ensure that his content validates, and that the reference validation for your site and the reference validation for the content author is the same?

Simply use HTML. Let the onus of making sense of the content lie with the browser. It's not a human's job to make content appealing to a computer. If a computer cannot understand it, it should work hard. Not the human.

Just for the humor, check out this page that a friend happened to hit when pulling up W3.org the other day. I know I'm being harsh when I say this, but the guys who made the standard can't seem to respect it.

Goa

2008-06-03T15:48:00.004+05:30

Just got back from a trip to Goa with colleagues. Here are some of the pics:

Head over to Flickr for all the pics.

Getting iSync to work with the Nokia N91 8GB

2008-04-21T15:50:00.002+05:30

My phone is a Nokia N91 8GB, and my primary OS these days is the Mac OSX 10.4.11. When I followed instructions I could find anywhere on the web - the simple connect, launch, sync instructions - it simply didn't work. iSync kept complaining that it couldn't sync with my device.

That just meant it's time to get under the hood and do some hacking! If you ever face this problem, here's how you solve this issue.

Quit iSync if you already have it open.
Go to your applications folder, right-click on the iSync application icon, and select "Show Package Contents".
Keep clicking through to the following path: Contents/PlugIns/ApplePhoneConduit.syncdevice/Contents/Plugins/Nokia-N91.phoneplugin/Contents/Resources.
Once there, duplicate the MetaClasses.plist file just to have a backup. You can do that by right-clicking the file, and selecting "Duplicate".
Now, open the file with a text editor - I used TextWrangler, and search for the line that says <key>com.nokia.n91</key>. A little lower, you should find a <key>Identification</key>. Right below that should be a <dict> XML node.

Edit it to look as follows:

<dict>
    <key>com.apple.usb.vendorid-modelid</key>
    <string>0x0421/0x042F</string>
    <key>com.apple.gmi+gmm</key>
    <array>
        <string>Nokia+Nokia N91-1</string>
        <string>Nokia+Nokia N91-2</string>
    </array>
</dict>

That's it - you are set. Now, launch iSync and it should now be able to work with your N91 8GB as advertised.

The key here is that the N91 8GB model is identified as Nokia+Nokia N91-2, which isn't available in the supported devices list by default - the regular N91 is identified as Nokia+Nokia N91-1 or simply Nokia+Nokia N91, which is supported. The hack just adds support for the N91 8GB by telling iSync to treat it as the Nokia+Nokia N91-1 for all practical purposes.

Web 2.0 Professionals

2008-02-28T14:08:00.002+05:30

Got this job offer in my mail today:

COMPANY: [Company Name] ...with a reputation of being a leading supplier of networking equipment and network management for the Internet.

LOCATION: Bangalore

JOB OVERVIEW: We are looking for Senior Web.20 professionals on a very Urgent basis. Person with good relavant experience is most preferable.

EXPERIENCE: Min. 4 yrs to 12 yrs

POSITION: Permanent

If you a are looking for a change then plz fwd your updated word formatted (*.doc) CV to me ASAP with following details:

[snip]

5. Experience in Web 2.0

[snip]

Typos and poor language apart, can someone please explain what a Web 2.0 Professional is? What does he do? How in the world is he supposed to have 4 to 12 years experience? And how can he give details of his Experience in Web 2.0? Not to mention, I am very curious about how Web 2.0 is relevant to a leading supplier of networking equipment and network management for the Internet.

I guess this just shows that we are at the peak of the hype.

Some where in a board room:
How do we boost sales of our NICs and routers?
What we really need is some Web 2.0 action going for us.
What is that?
Don't you know? Everyone's talking about it. It's the greatest thing to have happend!
Ok. Get HR to find a Web 2.0 Professional. Make sure he has a decent amount of experience.

On X-UA-Compatible

2008-01-29T13:01:00.000+05:30

There's been so much said about this...

Chris Wilson spells out the need for it.
Aaron Gustafson explains the details on A List Apart (!).
Eric Meyer welcomes it.
So does Jonathan Snook.
Anne Van Kesteren thinks it's an IE lock-in all over again.
Mozilla devs have questions.
PPK observes quitely.
WaSP guys clarify that they were not necessarily involved, though MS claims so.
Jeremy Keith thinks MS's got it backwards.
Andy Budd thinks IE just shot itself in the foot.
Jeffery Zeldman defends the idea anyway.
John Resig thinks the trouble is worthless.
Dean Edwards sits on the fence and snickers.
Roger Johansson is not convinced that it's a good idea.
Rachel Andrew thinks this is a step backwards.
Safari says they are not going to implement it.
Ian Hickson thinks MS is going to be in trouble.
Mike Davies says that it's the end of the line for IE.

... that if I write an opinion piece, it will go unnoticed.

So, what do I think anyway? If this is MS's only chance at fixing the web, I love the idea. However, this is a drastic step, and MS cannot botch this up. If they do, no one will want to work for their browser anymore. If no sites are written for their browser, users won't use their browser anymore. As a front-end developer, having to cater to three different browser types (IE6, IE7 and good browsers) with HUGE differences between them, is already a pain in the wrong spots. Adding one more to the mix will only worsen the situation. But if IE8 starts actually behaving like the good browsers, we can finally hope that all our problems will vanish with IE6 and IE7 - whenever that happens.

So, if MS thinks that this is the solution to all their problems, so be it. The world will comply this one last time. This is a lot of trouble. It better be worth it. If this ends up having a less-than-desirable result, MS is doomed. IE is doomed. And the web will be a better place anyway, IE or otherwise.

Bill G Has Left The Building

2008-01-24T21:27:00.000+05:30

A Movie About Coffee

2007-12-11T15:34:00.000+05:30

How To Build A Read/Write JavaScript API

2007-11-20T01:30:00.000+05:30

I've learnt most of this primarily by reading through Google Calendar's JavaScript Client Library code. I've also picked up clues from lots of other material around the Internet. There are also some minor improvements I've added.

So, here's the use-case: You probably already have a REST (or similar) API for server to server communication. Having a JavaScript API would be a great idea (after all, JavaScript is the most deployed programming language available on almost every platform in the form of a browser runtime). This poses many problems. Most significantly, browsers are very strict about the same origin policy. You are aware of certain hacks out there to use JavaScript across domains, but at best they give you read access or rely on browser plugins. You can do writes using query string parameters, but you know that that's just plain wrong.

Whatever be your solution to this problem, you want to play within the browser's security model, and not depend on any browser-specific security loopholes. Another very important thing you want to achieve is to ensure that your API users do not have to do any setup at their end – be it in terms of installing a server-side proxy, or jumping through hoops of any other kind. If a setup is unavoidable, it should be very simple to do, requiring little or no effort. You might also add additional requirements of user authentication (after all, you are letting them do writes), preferably at your domain – OpenID style – and have access to your cookies even when your application is being used from another domain entirely.

People might point out solutions like CrossSafe and Subspace. From what I gather of both these ideas, their goal is to secure your site from any third-party script snippet. That is not a necessary goal in our case. Also, both these techniques rely very heavily on some form of setup at the API consumer's end (which aren't very easy to do either – may even be impossible for say shared hosting environments), which we don't want to have. The technique I'm suggesting here is very similar in it's operation to both Subspace and CrossSafe, but eliminates (or reduces drastically) the need for any setup at the user's end.

The JSONRequest specification also needs mentioning. Unfortunately, the spec itself is rather new. Needless to say, there's no native working implementation of it as of this writing. CrossSafe comes rather close as an implementation, but it's not complete. (To make matters worse, completing the implementation will require even more server-side co-operation at the API consumer's end.) That said, I don't know why Doug Crockford has decided to keep PUT and DELETE methods out of the spec, among others. I guess it might be for simplicity. However, I think in today's RESTful days not having those methods supported is not a good idea. If Crockford's spec ever becomes the standard, I will be a little unhappy that the additional methods are not supported. The API creation technique I'm mentioning here supports all the HTTP methods that the browser supports for HTML forms (which is only GET and POST for all major browsers to the best of my knowledge), but at least it's a browser limitation – not one imposed by this technique.¹

So, let's get started. Here's what you require to get cross-domain read write JavaScript APIs to work.

The "setup" required at the client's end is that he should have at least one static cacheable resource embedded in the page where he's consuming the API, which is loaded from the same domain as his page. This could be in the form of a static CSS file, or an image. If the page doesn't have either, it will be required to insert one – maybe in the form of a 1px image hidden away by using inline style attributes. This is usually not too much to ask for, considering that pages are either made up of spacer GIFs or CSS documents, usually loaded from within the same domain. The static resources I mentioned could even be from a different sub-domain within the same domain, but it might complicate scripts slightly to have it set up that way. If this setup is not possible at all (oh, come on!), you could still find a work around², but I think that this is the easiest way to get things up and running.
You will need to do some setup at your end, if you are the creator of the API. In particular, you will need to setup a "proxy" page that intercepts the requests from the JavaScript client API, conditions the data, and passes it along to the REST API. This proxy page also reads the response from the REST API, conditions the data to suit the client, and flushes it down to the JavaScript.

Now, let's go over the process of actually orchestrating the communication.

The API client library is included on the page by means of a script tag pointing to your domain (your domain being the host of the client library). This is similar to including the Google Maps API on the page.
Once included, the script scans the page for the static resource mentioned above. This is done by walking the DOM looking for link or img tags, and checking the value of the href/src attribute to ensure it lies within the same domain as the calling page. The URL of this resource is stored for use later. At this point, if required, the client library can signal to the developer that it is ready for communication with the server. If the resource is not found, the client-library should throw an error and terminate.
When a request requires to be made, the client library takes the request parameters and prepares the markup for a form. This form can have any method attribute value, and should have it's action attribute set to the proxy page on your domain. The parameters to be sent to the server should be enumerated as hidden fields within the form. The client library also specifies the resource (in a RESTful sense) that needs to be acted upon. Also, the name of the static resource we had hunted down earlier is passed on to the server. This form is not appended to the document yet. This markup is then wrapped into <html> and <body> tags. The body tag should have onload=”document.forms[0].submit();”.
The client library then creates a 0px x 0px iframe, without setting the src attribute, and appends it to the page's DOM. This makes the browser think that the iframe exists in the same domain as the calling page. Then, by using the iframe document object's open(), write() and close() methods the markup created in the previous step is dumped into the iframe. As soon as the close method is called, the form gets submitted to the proxy page on your domain because of the onload in the body tag. Also note that this gives the server access to any cookies it might have created from within it's domain, letting you do things like authentication. In this way one part of the communication is complete, and the data has been sent to the server across domains. However, the iframe's document.domain has now switched to point to your domain. The browser's security model now prevents any script access to most parts of the iframe.
The proxy page sitting on your server now queries your REST API – basically doing it's thing – and gets the response. Response in hand, the proxy is now ready to flush the response to the client.
If the response is rather large in size, as might be the case with a huge GET call for instance, the proxy breaks it up into chunks of not more than say 1.5k characters³.
The proxy is now ready to flush the response. The response consists of iframes – one iframe for each of these 1.5k chunks. The iframe's src attribute is set to the static resource we had discovered earlier. It is for exactly this purpose that we had hunted the resource down and passed on the URL to the server. At the end of each of these URLs, the proxy appends one of the chunks of the response, after a “#” symbol, so that it works as a URL fragment identifier. Also, the iframe tags are each given a name attribute, so that the client script can locate them.
Meanwhile, the client-side code is where it had left off at the end of step 4 above. The script then starts polling the iframe it created to check for the existance of child iframes. This check of iframes will need to based on the iframe name the server will be sending down. It will look something like this: window.frames[0].frames[“grandChildIframeName”]. Since the static resource we have loaded into the grandchild iframe is of the same domain as the parent page, the parent page now has access to it, even the intermediate iframe is of a different domain.
The client script now reads the src attributes of the iframe, isolates the URL fragments (iframe.location.hash), and reassembles the data. This data would typically be some JSON string. This JSON can then be eval'd and passed on to a success handler. This completes the down-stream communication from the server to the client, again across domains.
With the entire process complete, the client-library can now perform some cleanup actions, and destroy the child iframe it created. Though leaving the iframe around is not a problem, it is not necessary and simply adds to junk lying around in the DOM. It's best to get rid of it.

This was simply the outline of the process, and there are several additions/improvements that can be done. For example, better control on reading/writing HTTP headers, having a reliable readyState value, error handling in case of HTTP errors (4xx, 5xx errors), handling of HTTP timeouts, etc. are all desired. However, this should be enough to get you started.

If you haven't already realized the significance of this, we should now be able to build much more sophisticated mashups that do much more than the current breed of mashups on the web. It opens up the floodgates to entirely new kind of applications on the Internet – applications we haven't seen as yet.

Let's enable better mashups! Nothing should now stop you from being able to give open secure access to your site's functionality in JavaScript.

A little creative thinking will let you circumvent the problem of browser-restricted HTTP methods when querying your REST API. Send an extra parameter to the proxy page when you are creating the form to specify which method to use. Let the proxy page then hit your REST API with the specified method.
The work around to not having any same-domain static resource would be to ask the API user to have a blank HTML page on his domain, the URL for which should be manually provided by the user to the client script. I don't think this is a great idea since it is an extra step that the API user has to do. However this can be used for one of those if-all-else-fails situations.
This 1.5k restriction is to overcome a URL length restriction in Internet Explorer, though most other browsers allow much more. Note, HTTP itself does not impose any restriction on the URL length.

Pics from Kerala

2007-11-09T18:57:00.000+05:30

Finally managed to get some time today to upload my pics from my trip to Kerala to Flickr. Here are some of my favorites from that list.

Head over to Flickr to see the complete photo set.

Dojo, Flash, SWFObject, Packer, IE's "Click here to activate and use this control" and Eval Contexts

2007-10-18T21:30:00.000+05:30

Boy, that's a long title!

Solving this problem I had at hand took a good day and a half. What I discovered seems obvious in hindsight, but it wasn't obvious to me until I had solved it. So that no one ever goes through the pain, here's what happened.

There is this thing I'm working on at work that required the use of SWFObject class simply to get around the IE "Click here to activate and use this control" nuisance when inserting flash files into the page.

Now, the reason why that message comes up is pretty shitty, but the problem and solution is very well documented. SWFObject is supposed to solve this problem. So, rather than re-inventing the proverbial wheel, we decided to use SWFObject. However, needless to say, IE would still keep throwing the message.

Now, a bit about the setup we have. We are using Dojo for this particular thing. I have written a wrapper around SWFObject so that I don't have to bother passing it all the stuff it needs every time I need to use it. Also, on a test machine, we host built versions of the code, which used Packer to compress the JavaScript. We were using Packer more as a compresser than as an obfuscator, since Packer gave us a considerable improvement in the compression ratios over anything else. On my local machine, I use the unbuilt version of the code.

Irrespective of where the code ran from, we used to get the nasty message in IE.

For those who don't know yet, here's how you get around the message - it's pretty simple. Create the object/embed tag from an external JavaScript file, and insert it into the HTML document. It's that simple.

Now, going by unobtrusive principles, our JavaScript always lies in external files (unless there's very good reason to not do so). So, why was this message showing up? There were two scenarios here:

My dev machine: Because of the way I had layered the files in Dojo for ease of maintenance, Dojo would dynamically pull in the references on the fly. This is very convenient and makes for easy to organize code. The way Dojo does this is by making an XHR call to the server to fetch the .js file, and then evaling the code. Now, these evals are run in the context of the window, effectively making them inline scripts. IE thus thought the code was inline, and showed the error message.
The test machine: So, even if it doesn't run on my machine, that's fine if we can get it to run on a test machine correctly. On this test machine we always house the built version of the Dojo file. With a properly written build profile, Dojo might not have to go around and pull in references as required since they would already be baked into the built files. So, that would make the SWFObject code external, and IE shouldn't have a problem with it, right? Almost. Packer requires an eval of the code it has obfuscated to make sense of it. Again, the eval is run in the context of the browser, and IE treats the resultant code as inline, again showing the error.

So, in both the cases, the problem was the context of the eval, though in entirely different scenarios. It could also be concluded that SWFObject cannot ever be compressed using Packer. It was just painful to track down and fix this bug. I hope no one ever has to go through this pain again.

If you need to know, we had to switch to ShrinkSafe to avoid the eval that Packer does. There are definitely better ways to compress, but this should do for now. The code-size increase wasn't too significant, so we were fine with using ShrinkSafe. Ideally, I would use ShrinkSafe for SWFObject and packer for everything else, giving the best of compression and avoiding the implicit eval. This doesn't solve the problem on my local dev machine (since the code is unbuilt), but that doesn't really matter.

Client-Side Performance Optimization of Ajax Applications

2007-10-16T11:52:00.000+05:30

There has a lot been said about server-side performance optimization. But a recent report from Yahoo concluded that the server accounted for less than 5% of the time for a user to view a web page. Here's how you can performance optimize the client-side code. Note that this article is targeted towards pretty advanced JavaScript programmers, working with pretty client-heavy applications.

Network performance

This feels just stupid to say: Reduce the amount of source-code you've written. There are several ways of doing this. The first is to simply not write any JavaScript at all. But that might not be an option for you. Another way is to lazy load code - don't download code unnecessarily on the client. This is especially true of single page applications. Another thing you simply must do is pass your code through a good compressor - like Dojo's Shrinksafe, Crockford's JSMin, Edwards' Packer or the YUI Compressor (or even a combination of those).
Another thing that I've heard most people recommend is that gzipping of JavaScript files helps reduce network latency. While this is entirely true, a bug in a rather prevelent version of IE makes me wonder if I should do that. If anyone can prove me wrong, I'll only be glad.
In all popular browsers today, JavaScript files are always sequentially downloaded. It doesn't matter if HTTP says you can have 2 connections open. It doesn't matter that CDNs on different domains can serve files in parallel. It doesn't matter that Firefox always disregards the HTTP restriction and downloads multiple files all the time. When it comes to JavaScript, all files are always downloaded sequentially.
This only makes sense, since script should be executed in the order in which they appeared in the markup. Reduce the number of files to be downloaded. This can be done by using a build process, something similar to what the Dojo build system does - combining the JavaScript files into one file.
Cache Ajax responses. The network is undoubtedly the weakest link in the chain. Avoid making requests. A request once made should never be made again. Implement cache invalidation if you need. Even then don't fetch data just because the cache is now invalid. Wait till it is actually required. If you never end up needing it, you've saved another hit.

Perceived performance

Reduce the amount of source-code you've written. I know this sounds like a repeat of a point above, but I had to bring this up from a perception point of view too. It seems that the more JavaScript that's downloaded, the more time it requires for the browser to interpret it, increasing at an exponential rate (not linear). Which means that even after your code has been downloaded, the browser will just sit there doing (apparently) nothing for some time. Usually, this is a problem above say 500 kb of code.
In any case, if you are downloading 500k of JavaScript on the load of the page, there better be a very good reason for it. You should be able to have much faster download times by splitting up these files into modules, which you can download at a later time - maybe on demand.
Get something downloaded and displayed as soon as possible. This might be something as simple as markup with the UI skeleton for the application, and simple "Loading..." indicators. It helps a great deal in reducing the frustration in working with an application.
If you can help it, put your JavaScript includes at the bottom of the page. This gives the browser enough time to download and render most of the page before even starting to mess with your scripts. Considering that JavaScript downloads sequentially, and doesn't let any other resource be downloaded at that time, you should only download JavaScript once you already have something to show the user.

JavaScript performance

There's a lot that can be said here. I've started getting a lot of kicks lately in trying to milk every millisecond of performance from a browser. So here's what I've learnt so far.

If you are writing a function that returns an array, you usually want to pass in a callback as a parameter of that function. This will improve the performance by at least a 100%.

Instead of:


    var anArrayOfData = getAnArrayOfData();
    for(var i=0; i<anArrayOfData.length; i++) {
        // do something with anArrayOfData[i]
    }

Do the following:


    getAnArrayOfData(function(item) {
        // do something with item
    });

This is better because you usually loop inside the function anyway to build the array. Having to loop through the returned array again is a waste of processing time.

Instead of:


    function getAnArrayOfData() {
        var returnData = [];
  
        for(var i=0; i<largeSetOfData.length; i++) {
            // Some code...
            if(condition === true) {
                returnData.push(largeSetOfData[i]);
            }
        }
  
        return returnData;
    }

Do:


    function getAnArrayOfData(callback) {
        var returnData = [];
        
        for(var i=0; i<largeSetOfData.length; i++) {
            // Some code...
            if(condition === true) {
                returnData.push(largeSetOfData[i]);
                if(callback) {
                    callback(largeSetOfData[i]);
                }
            }
        }
  
        return returnData;
    }

This way, the callback parameter is optional, and you still return the returnData, but you could also provide the callback function and avoid another external loop to iterate through the return data. I've changed all the getElementsBySelector methods in my libraries to use this approach, for example. It only seems logical - if I get an array, I will usually need to iterate through it.

Use native functionality whenever possible. Case in point: forEach iterators. This is very helpful, and part of the 1.6 standard, but the most popular browser in the world can't do forEach loops. Most people either live with it, write their own forEach iterator using simple for statements, or use a library that already has this built in. If you are the second type of person, you aren't achieving much except code readability, which is not a bad thing. Most frameworks' forEach loops also take much the same approach. However, there's a better way.
```
    function myForEach(array, callback) {
        if(array.forEach) {
            array.forEach(callback);
        } else {
            for(var i=0; i<array.length; i++) {
                callback(array[i]);
            }
        }
    }
```
In almost all browsers, the block in the if statement will be executed, giving the best possible performance, since you are using native functionality. However in less modern browsers that happen to be more popular and which you have to support but can't do much more about optimization, the else block will still work. Think of it as being the graceful degradation principles of CSS being applied to performance.
Now, I haven't done it above, but I strongly recommend that you stick to the JavaScript standards when deciding the function signatures of both the myForEach and the callback functions. This is because if the world does become a better place one day, and the most popular browser in the world actually learns how to be modern, you code will work such that it uses the most optimum features in the browser, without you having to change a single line of code.
Don't build too much of scaffolding code to make JavaScript behave like classical object oriented programming languages. Usually, you will not end up with much more than helper functions. A lot of the paradigms of classical OO don't apply to JavaScript. Learn to use JavaScript for what it can do. Don't make it what you want it to be.
Use threads. Ok, JavaScript doesn't really do threads at all. However, you can kinda simulate the effect of threads. What you achieve by doing this is that you hand over control back to the browser for a brief instant before proceeding with your code. This gives the browser time to react to any other user action that might have happened, make any updates to the DOM that you had asked for, bypass that nasty The script on this page is unresponsive warning, etc. So, how do you do this?
```
    // some code
    setTimeout(function() {
        // some more code
    }, 0);
```
If you don't understand how exactly this works, this could be a source for a lot of bugs. Use this with caution. However, I've used to get a very high apparent performance very successfully.
Cache function results. If for a given set of parameters a function will always return the same results, you really only need to calculate it the first time. Once calculated, save the data in a variable, and read from that variable hence forth. For example:
```
    var squaresCache = {};
    function getSquare(number) {
        if(!squaresCache[number]) {
            squaresCache[number] = number * number;
        }
 
        return squaresCache[number];
    }
```
The example above isn't very good for at least two reasons. Firstly, using this pattern for computing squares is just plain stupid. Secondly, it seems (though it need not be) that squaresCache is a global variable, which is plain evil in any programming language. However, I hope it illustrates the idea of populating the cache the first time the function executes and subsequently reading from the cache instead of re-calculating the data.
Strings in JavaScript, like in many other languages are immutable. So, for lots of string concatenation operations, you need to use the string builder pattern in JavaScript too. The simplest way to do that is to declare an array instead of a string, push strings into that array instead of concatenating, and finally call array.join(""); to get the concatenated string.
Do not use eval. Eval is painfully slow. But why do you need to use eval? Other than converting a JSON string to an object, I never write any code that needs to be eval'ed. Remember the other cousins of eval - new Function(someString) and setTimeout(someString, ms). You don't need the Function constructor at all, and you don't need to pass strings into setTimeout at all. Instead, in both cases, you can use anonymous functions. Thus, the implicit eval is avoided. Using anonymous functions give the added benefit of retaining variable scope through the creation of the closure. The eval is always carried out in the global scope.

Unfold your if statements. This is particularly useful for code that checks for browser features. For example, instead of:


    function addEvent(element, eventName, callback) {
        if(element.addEventListner) {
            // add the event one way
        } else {
            // add the event another way
        }
    }

Do the following:


    if(element.addEventListner) {
        function(element, eventName, callback) {
            // add the event one way
        }
    } else {
        function(element, eventName, callback) {
            // add the event another way
        }
    }

This unfolding of ifs applies even to loops, for example. So, if you can keep if statements outside a loop, do that. It doesn't make for readable code, but it's significantly faster. Bonus points to you if you just thought to yourself that my forEach example can be improved using this technique.

DOM Performance

Of all the parts making up client script, DOM manipulations are the slowest. So, you have to take the most care here.

Use innerHTML. Don't be too much of a purist. Being a purist won't make your application faster. You wouldn't believe how much faster your code is if you use innerHTML.
Never update the DOM. Ok, if that's not possible, at least do it as infrequently as possible. Bunch up your updates to the DOM and save them for a later time. Realize that it is not the size of the update but the high frequency of updates that's slow. Doing appendChild in a loop is updating the DOM frequently. Caching the markup in a string, and then setting the innerHTML in the end is batching and updating infrequently. The second is much faster.
However, the technique above is mostly only useful if you are adding new stuff to the DOM. What if you are updating existing elements on the DOM? How do you keep updates to a minimum when you want to change style, class names, content and children of a node that already exists? Simple. Clone the node you want to work with. Now you will be working with a clone of the real node, and the cloned node doesn't exist in the DOM. Updating the cloned node doesn't affect the DOM. When you are done with your manipulations, replace the original node with the cloned node. However, note that the performance problems here are because of the content and rendering reflow that the browser has to do. You might get similar benefits by simply hiding the element first, making the changes, and then showing it. Though I haven't tried this, it should work in theory.
Keep track of events. For me, this is the worst part of working with the DOM. This is important because when your application (or any DOM nodes) are being unloaded or destroyed, you will have to manually unregister the events from the nodes BEFORE you destroy the elements. Yes, this is the garbage collector's job, and that's supposed to be the job of the environment your code runs in, but guess which browser is the offender here. Internet Explorer doesn't free all the references even when the user leaves your web page. Unless you want your web app to earn the reputation of being responsible for many a crashed browser, and a horrid browsing experience for other websites too, count your references.
If you are going to iterate through a node list to attach event handlers, you are probably wasting processor time. Instead, simply attach the event handler to some parent of the node list and read from the event object to know what was clicked on. You save the cycles required to iterate over the nodes this way.
Avoid calls to functions like getElementsBySelector, where there's lot of DOM walking involved. If you cannot, then make sure you work on as small an area of the DOM as possible. If your favourite version of getElementsBySelector lets you send in a root node under which to search, do that. Otherwise, provide a very high specificity, starting with a "#someId" so that the function can narrow down the search. Also, understand how these functions work internally. For example, you could use a getElementsByClassName to find divs with the class "foo", and the implementation of getElementsByClassName will probably be just three lines, However, using getElementsBySelector("div.foo") will be faster in almost all frameworks, even though it might have a hundred lines of code in it's implementation, since it has less DOM walking to do.

Sorry for the kinda horrible organization of this post. I should also say that not all of these ideas are my original - I found a lot of these by reading many sites scattered across the web. However, I hope you found this post useful.

Much Deserved Update

2007-09-21T10:55:00.000+05:30

It's been an eternity since I wrote to this blog, so an update is in order. I fear this update will seem very similar to a pervious post. Also, please bear with me if this post seems too long.

Much in the vein of that previous post, I've quit my job again. Iventa was a great place to work at (Notice, I didn't say that about my employer before Iventa), and it has let me learn, explore and part with (and thus expand) my knowledge more than any other place I've worked at before.
I'm now with Cleartrip.com. One of the top travel portals today in India, Cleartrip could easily be mistaken to be just a travel thing out there. Truth is, outside of the IITs - an organization I used to interact with regularly - this is one place where I've seen more innovations happen more frequently than any other place. All the people you meet at Cleartrip are gurus in their areas of work. I can only consider myself to be lucky to be in the company of such a congregation of sheer genius.
I've joined Cleartrip as a JavaScript developer guy. If you look at that from a organizational chart perspective, this is a slight demotion in rank for me. But that was completely intentional. I was starting to move towards managing people at Iventa, and I think I had still not had enough of playing with technology. I guess that only means that I want to grow some more in the area of technology, and not in the area of management. Tech is where I get my kicks from, and I don't see that changing at least for some time.
The management at Cleartrip was kind enough to allow me a short vacation between jobs. I took the opportunity to go to Kerala - this time not because it's my home town, but because I had never been to a place of such scenic beauty as a tourist. I've got very interesting stories (including one where I'm chased by a wild elephant trying to protect her kid from me, since I was armed with a camera), but I've got even more interesting photographs. I shall be uploading them soon. Which brings me on nicely to the next two points.
The reason I've not uploaded any pics so far is because my beloved Hangy is dead. Again. This time, it seems that the moisture from the Mumbai rains got to her chipset on the motherboard, and AFAIK there's no one who can fix that. So, my only option is to replace the board, but I'm reconsidering that in favor of a huge upgrade. I've meanwhile asked my computer-fixit-guy to come up with an alternative - probably a second-hand motherboard I can buy from him. Let's see what he comes up with.
So, assuming I get ready to post pics online to share, which service is really the better? I like Google, so Picassa seems to be an interesting option, but I've not found that to be reason enough to change from Flickr yet. Any opinions for or against either of these? Please enlighten me.

This post would be incomplete without some more important information.

This blog is NOT dead. I really mean to post much more. In fact, since Hangy's dead, I got my MacBook Pro from work home today so that I can compose this post. (Which incidentally makes this the first post on this blog written on a Mac. I wouldn't be surprised if the next one is written in Emacs on Ubuntu, or something!)
That said, this blog is going to deviate a bit in its direction. So far this blog has largely been about markup and style. However, IMHO, all that had to be said about markup and style has been said, either here or elsewhere. The subject is so beaten now, that a new acronym had to be invented in hopes of reviving interest. (POSH, for God's sake!) Meanwhile, I've decided to move on. I need to give a better explanation of why I'm moving on, and I think that's a topic for another post. I really want to share my thoughts about why I think all the fuss about markup and style is not worth it - at least in the connotations it started to carry. That would be an ironic post, since the most popular post on my blog so far has vehemently promoted XHTML! I guess I had to go through all of it to learn how unimportant it is.
I've moved on to JavaScript, if you haven't guessed already from my last few posts. I've been hungrily learning so much about JavaScript these days, that I can easily claim to know much more than some of the good JS coders out there. I know that's a tall claim, but on more than one occasion I've realized that some of these gurus' arguments don't make sense. I guess that's a good sign.
Which nicely brings me on to the last point I want to share. This blog is going to turn from a primarily web standards promotion blog to a primarily JavaScript hacking blog. I shall now discuss lessons I've learned in JavaScript, application architectures from a JavaScript thick-client perspective, interesting hacks and tricks in JavaScript that I've picked up along the way, and occasionally the stupid browser nuances (you know which browser I'm talking about) I come across. Expect posts talking about JavaScript as a language (one of the most modern - old as it is - and among the richest most expressive languages in the entire computer industry IMHO, and already available on your desktop!) for all the cool things it can do, and JavaScript from a more serious application design point of view, being an important part of application architecture design sitting at the top-most layer, ensuring that users have a great experience. This particular topic about JavaScript being a serious thick-client programming language has been of particular interest to me lately, and the few forays I've had are very promising. So, expect me to talk a lot about these kinds of topics now on.

URI fragment identifiers and HTTP

2007-06-18T16:48:00.000+05:30

I came across an interesting problem today with how HTTP handles URI fragment identifiers. Here's the spoiler - it does not!

Here's the long story. If you are on a page which has a URL that looks like this:
http://www.domain.com/page.html#fragment

Now, #fragment is known as the URI fragment identifier. This particular thing has got very popular lately with it's potential uses in Ajax applications, since it can be easily (mis)used to let client-side code perform many actions.

This also helps take care of some back-button problems with Ajax. For example, let's say you are on page.html. Then, you perform some client-side operation that appends #fragment to the URL. Now, let's say you navigate to page2.html and press the back button, you would land up on page.html#fragment. Then, the JavaScript on the page could read the #fragment and perform an Ajax action to restore the page to the state you had left it at.

However, I just discovered when working on this one project that the #fragment is never sent to the server as part of the request headers. The HTTP specification says nothing about handling URI fragment identifiers, and sure enough most browsers do nothing with them.

So, if you ever have to read the #fragment on a server, remember that you can't! That's just one more of the problems that we have to deal with as RIA developers.

Safari for Windows

2007-06-12T20:59:00.000+05:30

Yes, that's right. It has finally happened. Safari for Windows is now available as a free download.

There are still some questions unanswered - my number one question is if it uses the same rendering engine as the Mac version. I hope it does.

On a side note, I wonder what will happen to Swift.

Web 2.0 ... The Machine is Us/ing Us

2007-02-20T06:48:00.000+05:30

I find it very hard sometimes to explain, even to techies, that I work on JavaScript, CSS and markup. They just don't get that it involves an entirely different approach as opposed to old-school web programming. Hopefully this beautifully made video will explain what it means to work on those technologies.

IE's Unknown Runtime Error When Using innerHTML

2007-02-01T10:32:00.001+05:30

IE never fails to surprise me. Look at the following code for example.

<html>
    <body>
        <p id="someId"></p>
        <script type="text/javascript">
            document.getElementById("someId").innerHTML = "<li>Some content</li>";
        </script>
    </body>
</html>

This code has surprising results in Internet Explorer and Firefox, and I haven't found a decent explanation on the Internet of what exactly happens, so I'm posting this out of utter surprise.

First thing you'd notice is that someId is a paragraph (p) tag. Secondly we are inserting a list item (li) into this paragraph, without having a unordered list (ul) as a parent element of this list item. If you are really the kind of markup nazi that I am, you'll notice that the p tag doesn't allow any block-level tags within it, and both LI and UL are block level tags, which is not permitted by the W3C rules.

So, how do browsers react to this?

Firefox does some code cleanup (I guess), and renders what looks and behaves like a list item, complete with a bullet and stuff. (Interestingly, it assumes that it is an unordered list and not an ordered list. Wonder why that's the case.)

IE's JavaScript on the other hand breaks with an "Unknown runtime error"! I agree completely that this is not a good error message at all, but really, IE is enforcing correct W3C block/inline tag recommendations here - something Firefox is not doing. To demonstrate this, change the p to a ul, and the code will work in IE.

IE's not 100% percent correct, though. It looks like it only enforces block/inline tags and not really tag semantics. Which means if you change the p to div, the code will execute correctly, since the div element allows other block-level tags within it. So, IE doesn't seem to be perfect, but seems to be kinda stricter than Firefox. Which may or may not be a good thing.

America Calling

2006-11-30T00:11:00.000+05:30

Within the coming week, I shall be leaving for Los Angeles, California for (at least) a three month period. I'm going to be there to do the ground-work towards the launch a product that has been very close to my heart for the last year, and has been taking up all my time. Finally, it looks like the product has now matured enough for real people with real businesses to start playing with.

I'm also looking forward to catching up with old friends, and other bloggers in and around LA. If there's anyone staying around the LA area, please leave me a comment, or email me, and we can take it from there.

Interviewing UI Designers

2006-02-15T20:05:00.000+05:30

Since we are in the process of building a team of UI designers at work, I have been assigned the task of conducting interviews to decide on potential candidates. Today, I held my first few rounds of interviews. Until today, I have never realized how entertaining an interview can be.

Me: So, on a scale of 1 to 10, how do you rate your CSS skills?
She: 6, at least. (smile)
Me: Nice. 6 is not bad. So, what does CSS stand for?
She: Cascading Style Sheets
Me: Ok. Why are they called 'cascading' style sheets?
She: Because you can cascade it onto multiple pages.

Me: So, I need to write a JavaScript snippet that can read a user's inputs in a form, prepare a text file, and save it on the user's desktop. Can I do this using JavaScript?
Him: Sure!
Me: (understandably surprised) Can you show me the code?
Him: Sure! (starts scribbling something down, but gets stuck)
Me: (probing) Are you sure this can be done using JavaScript again?
Him: Yeah, I'm pretty sure.
Me: Have you seen any examples of this before?
Him: Yeah. We have used similar things in our previous organization.

Me: How do I add a style sheet to my HTML document?
Him: Simple. You click on 'Insert' on the menu bar, and click on "Style sheet".
Me: No, I meant by hand-coding in markup
Him: Yeah. You can do it that way too.
Me: Yeah, that's what I'm asking. How do you do it?
Him: You should use the right tag for that purpose.
Me: Which is the right tag for this purpose?
Him: (thinks for some time, but can't come up with anything)
Me: (trying to help him out) Are you familiar with the link and style tags? What do they do?
Him: You use the style tag for attaching style sheets, and the link tag for creating links.

Me: Allright, how good are you at JavaScript?
She: Very good.
Me: That's quite a relief. So, what is the DOM?
She: (thinks for some time) I'm not really sure. I've heard that for the first time.

Me: Is JavaScript an Object Oriented language, or is it a Procedural language? Or is it some weird mix of both? Or is it neither?
Him: I did not understand the question. Could you please tell me what is 'Object Oriented'?

Me: So, about image editing, when would you use the GIF format, and when would you use the JPG format?
She: I'll use the GIF format for making animations, and the JPG for static images.
Me: I meant static images itself. Which format will you use, and on what basis will you decide?
She: Static images? I'll use the JPG format.

Say Hi To JSON

2006-01-24T17:52:00.000+05:30

At least one good thing about getting low site hits is that every small spike in traffic is noticeable. One such spike I got recently was from the Off Topic forum at Joel On Software. Mark Warner agrees that using JavaScript as the return value of an Ajax call is a great way to exchange data between the server and client.

At Iventa, I'm currently working with a team of very talented individuals in developing a next-generation Web 2.0 application that does some really cool stuff. Needless to say, Ajax technologies are an important part of our interface design. Even if we don’t realize it, we have turned out to use exactly the same architecture that Jessie James Garret had talked about some time ago in his now-famous article. With one significant difference, though. We are still not using XML for transferring data. We don't need the X in Ajax!

What we are using, though, is JSON. JavaScript Object Notation might not be new to most people here, and it isn't rocket science either. Unfortunately, there's not enough information on the Internet that talks about using JSON well. So, well, here goes: A short tutorial on using JSON for Ajax.

We are using ASP.Net 2.0 as the core server-side technology. Personally, I hate anything to do with Microsoft, but I guess business decisions prevail over personal preferences. However, this blog is mine, and I will talk about whatever the hell I like to talk about, and I hate Microsoft, so we are not going to talk about ASP.Net here. We shall just talk about the JavaScript side of things here.

That said, the server is just as important in an Ajax call as the client. Usually, one would use a framework that would let one make "client callbacks" on the server, but this is not necessarily the only way to transmit Ajax data. One could use a more barebones language like PHP directly without any frameworks to do just that – in fact if your site uses very few Ajax calls it is probably better to avoid an Ajax framework anyway.

Back to JSON. So, when we make an Ajax call using JavaScript, the server side script fetches the data we have requested (which could be from a database or from XML files, or any other kind of storage medium). The next step would be to convert it to a format that we can use on the client. This is where JSON kicks in.

Here’s how a typical JSON string would look. I’ve added line-breaks for clarity.

{
 "UserInfo": {

  "id": "100",
  "firstName": "Rakesh",
  "lastName": "Pai",
  "emailAddress": "spamme@spammer.net"
 },
 "MembershipInfo": {

  "JoinDate": "2/31/2006",
  "MemberType": "3"
 }
}

Now, let’s say that I have a JavaScript function defined on the client, already available in a JavaScript include that uses this function as a parameter. Most frameworks will let you define which function will be called. If not, an approach similar to what I had talked about before can be used.

So, the function will look as follows:

function showUserDetails(serializedObject) {
 objResponse = eval("(" + serializedObject + ")");

 // objResponse can now be used as an object with its properties set.
 alert("User’s first name is " + objResponse.UserInfo.firstName);

 // Process the object as required
 ...
}

See how easy it is to use the data coming from the server? JSON makes it amazingly easy to get the data down from the server, create a neat object out of the data that has come in, and consume it the way you want to. The object, of course, can be rather complex, allowing for exchange of very complex data between the server and the browser.

This might not be the most efficient way of doing things. The comments are open for opinions.

Previously

Why XML In XMLHttpRequest

Back In Action

2005-12-26T11:10:00.000+05:30

For the record, I never stopped blogging. I just took a three and a half month vacation.

There has been a lot going on in the last couple of weeks. I've missed blogging so much, but it has been hard to even get to see how my blog looks lately. My incoming links have not increased at the same pace as it used to. My hit count has hit an all time low. Google is the only one hitting my site (other than a few guys who come from blogs where I leave an odd comment). The good times had stopped rolling.

All of that is about to change. I shall now, as a rule, dish out posts more frequently, and try to remain focussed on the topic. (Did you notice that none of my recent posts had anything to do with web design?)

To start, here's a (partial) list of things that have happened to me over the last couple of months.

I've quit my job at HSBC Asset Management. I don't want to say bad things about my previous employer here right now. I might change my mind.
I've joined a small company called Iventa Corporation as a Team Lead - User Interface Design and Integration.
I've never thought that work can be as much fun, thanks to a great team and an awesome work culture at Iventa. (And I'm not just saying this because my employer might be watching this blog right now.)
I've started growing a paunch. It's hard work, but it seems to be working.
My computer - Hangy - has died multiple times, and has usually come back alive. She has been asking for a lot of my attention lately.

There's so much more I could add to that list. The last couple of months have been action-packed. But the point of this post is to remind you that this blog is not dead. It has, in fact, just sprung back to life!

PS: Thank you for all those lovely mails asking me to get back to writing. Your mails mean a lot to me. Thank you again. (You know who you are.)

PPS: Almost forgot! Wish you a Merry Christmas and a great New Year! Keep Partyin'!

Google Indexes The Future

2005-09-19T21:40:00.000+05:30

I love Google, if you haven't gathered from my blog already. But now I love it even more. If you haven't checked out Google Desktop, you should. What is really cool about it, is that it even indexes files you haven't created yet, so that you can search through it. It makes for a really powerful search, since you can get documents from the future today. Take a look at the screenshot of the indexing status if you don't believe me.

Google Indexes the Future

Yellow Sun, Yellow Plastic

2005-09-05T22:34:00.000+05:30

Yellow Sun, Yellow Plastic

I was in Goa a couple of days ago for a "official trip". Though the trip was largely hectic, I did manage to get a shot or two.

This pic was shot at a desolate stretch of beach at Canaconam, Goa.

And sorry for the corny title. Creativity eludes me at the end of a tiring day.

One Year...

2005-08-30T18:19:00.000+05:30

...and counting.

When Referrals Are Funny

2005-08-22T22:46:00.000+05:30

Rather frequently, people enter weird things in the search-box in search engines. Very rarely some of those results point to my site. Almost always I note down those search terms. Here’s a partial compilation of the funny search terms that have landed people on this blog.

MSN: Man converting lions to Christianity – And a man with a lot of time at hand.
Yahoo: Apologize for electing Bush – What kind of search string is that!
Yahoo: Why you always feel smarter after a couple of beers
Google: Google hacks Jaipur – And I thought Google was not an evil empire.
Google: Picture of devil – for some reason, Google repeatedly thinks that I’m some authority in pics of the devil.
Google: Kitchen designer in Mumbai – Why on earth is Google sending this guy to my site?
Google: Censored Marathi sex articles – I can understand where this guy comes from, but it’s where he comes to that surprises me.
Google: Attack of the nerds – yes, I use my site primarily to congregate nerds so that we can take over the world.
Google: Parvathi Goddess MP3 – Wow! I didn’t know she was into modern music delivery formats.
Google: Haven Pai – I have no clue what that means.
Google: Buildings with CSS in Mumbai – Yeah. It’s CSS that makes buildings look good.
Google: Web page not responsive in the cash – Well, ever considered having a business model?
Google: What is the search string to turn up camera feeds on Google – someone actually typed this. In Google. A search for a search. Cool, huh?
Google: Food preparation using microwave oven and Tamil fonts – Should make for a spicy meal.
Google: Rakesh is God – I know that already.
Google: Illegal Rakesh – Please read the point above.
Yahoo: Gravitation cannot be held responsible for people falling in love – Of course. Only stupidity can.
Yahoo: Atlanta booty shake – Sorry to disappoint you on my site, mate.

Mumbai Under Water

2005-07-28T20:30:00.000+05:30

Mumbai is recovering fast from the downpour two days ago. You may want to see pics of it at flickr.

It took me two days to come back home, but I'm fine. Thanks everyone for those mails. Everyone I know is fine too. I hope everyone you know is fine.

Not Jobless Anymore

2005-07-14T13:21:00.000+05:30

I just picked up my offer letter from HSBC Asset Management yesterday, for the position of Executive - Web Design.

I still get to continue doing my freelance projects as I was, though an immediate slow-down is inevitable. I've been doing it for more than two years now, and simply quitting would be impossible.

I am still to settle down at the new job with the new work timings (I'll actually have to get up in the morning), new bunch of work-related problems (for starters, I'll have to make an hour long train commute to work everyday) and new dress code (I understand I can't code in my underwear anymore). I start the routine on Monday.

I hope this means that I'll get a lot more time at hand to do more reading (my feed reader indicates that I have more than 4000 unread items in my box), and writing (and you thought I had plans to wrap up this blog soon). I will also hopefully get more material on and exposure to real-world web-based issues.

Anyway, for now, it's time for celebrations. Time for hitting that bottle of beer. Again. After all, it's a new excuse.

Chainsaw In Red And Blue

2005-06-24T19:49:00.000+05:30

Chainsaw in blue plastic wraps

So, two days ago at 3 in the morning, the huge tree opposite my house came crashing down with the wind and rain, breaking a compound wall, shattering a couple of windows in my apartment, and crushing two cars among other things. Fortunately, other than one really dumb guy who ran toward the broken glass to see what happened, no one was hurt. The fire-brigade was there in minutes and chainsawed the tree into managable chunks to clean the place up.

I got this pic when they were busy planning their strategies.

For those interested, I have a couple of more pics on Flickr.

On The Edge Of The World

2005-06-10T17:42:00.000+05:30

The Edge Of The World

The funny thing about computer games is that every map has an edge. It's called The Edge Of The World. It always looks like a hazy area fading into blackness. An area you just can't access.

If I was living my life in a computer game as a game character, I'd know it wasn't real if I came to The Edge Of The World.

This pic was shot in Podanur, not too far from where this pic was shot.

What Would You Do?

2005-06-05T16:04:00.000+05:30

Let's say you are a freelancing web developer and designer. You take pride in the quality and technology of the stuff you deliver. You like to work on the bleeding edge of web technology. You will go out of your way if necessary, to implement solutions that are apt for the client's business. You like to study their way of working and the goals of their site, and prepare a solution that makes good sense for their business, both technologically and economically.

You are just starting out with your career. You have no money. You are almost completely broke. You could do with any project that will bring in money.

A prospective client from a wealthy country approaches you with a great deal. He is willing to pay you outrageous amounts of money for getting his website developed. There's only one hitch.

The site contains sexually suggestive content.

What Would You Do?

PS. If you are wondering, I bailed out. I might be the century's biggest fool, but sometimes money isn't everything, I guess. Let's just say I didn't do it because of ideological issues.

Gone Fishing

2005-05-31T15:10:00.000+05:30

Gone Fishing

This photograph, shot at a beach in Mahe, Kerala, is a panorama composed of 3 photographs arranged in a row. To the extreme right, is a fisherman grabbing his catch for the day.

I was wondering how the panorama would turn out, because of varying exposures in the different frames, the dynamic nature of the sea and the waves, a slight haze in the air, and no real subject. I'll let you judge that, though.

(Yes, I know I could have done a better job of stitching them together, but I wanted to give the Adobe Photoshop CS's Photomerge function a shot. It took all of 5 minutes to stitch them together.)

The Real Problem With Ajax

2005-05-27T18:00:00.000+05:30

The real problem with Ajax is that you have to stop thinking of the process of getting information as a linear sequential process, and start thinking of the browser as a true application platform.

Now, only if that problem was easy to solve.

Communication

2005-05-22T19:44:00.000+05:30

Communication

This image was shot in a small town called Podanur, about 15 minutes drive from Coimbatore, Tamil Nadu.

By the way, I wanted to know what tools you use to correct spherical aberrations. Could you please leave me suggestions in the comments? Thanks.

You Know When It Happens...

2005-05-13T19:25:00.000+05:30

Today I was at the barbers, and he said that he wouldn't cut my hair too short, because "it would show".

You know when it happens...

Back From God's Own Country

2005-05-12T23:51:00.000+05:30

Kerala Backwaters

Just got back from Kerala, so I'm making a quick post. This image was shot at the backwaters in Kerala somewhere about an hour's drive from Ernakulam.

Oh, I had a great trip too, if you have to ask. Kinda tired. I'll post something more soon.

I'll Be Right Back

2005-05-04T10:08:00.000+05:30

As if I haven't been ignoring this blog enough, I'll be taking a 10 day break to go to my home-town, Kerala.

When I'm back, I promise to have LOADS of photographs, website design talk and other tech stuff. It's been sitting in my mind/drafts for a long time now, but time has not been a good friend lately.

Until next time!

Two Women And A Kid

2005-04-14T21:55:00.000+05:30

Two women and a kid

What Extensions Do You Use?

2005-04-08T15:35:00.000+05:30

I have quite a few extensions installed for my Firefox, some of which I cannot do without, and some others that make me wonder what I was thinking when I installed them. Here's a list, in no particular order.

For the surfer in me

GMail Notifier - I've almost substituted this by a Konfabulator widget that does a much better job, but this is still rather useful.
Bloglines Toolkit - Because I'm such a Bloglines fan.
Mouse Gestures - I admit I'm lazy. And that this is really cool.
LiveLines - I never really liked LiveBookmarks anyway.
Dictionary Search - Cause my English sucks.

For the web-developer in me

DOM Inspector - Always nice to have this around, though I've still to learn to use this well.
ieview- Saves me a lot of URL copy-pasting to check my designs in IE.
Web Developer - Simply indespensible. It's probably the single most important reason to develop for Firefox, second only to the whole standards thing. This is probably more important than even a good code editor!
ColorZilla - For the times when I've forgotten my color codes, or am too lazy to go through that dreaded CSS file again. Or when you just want to steal that cool color. (Wait. Did I just say that?)

For I-don't-know-what

Google-Preview - I actually liked this at one time, and was actually using it, until realization dawned upon me that this takes up more bandwidth than it deserves.
Mozilla Calendar - It's really cool. For what?
BugMeNot - I haven't tried, but does this work with my pr0n sites?
SpellBound - Neat idea, but I only wish it wasn't so clunky.
fireFTP - I almost fell in love with Firefox all over again thanks to this extension, until I found a bug that didn't let me see my .htaccess file. And, boy, do I need to play with my .htaccess a lot!

Which are your favourite extensions? Maybe I should use some that you are using to simplify my work? Share your list in the comments.

Call Center Chaos

2005-04-03T11:09:00.000+05:30

I was on the floor laughing when I saw this video of an episode of The Tonight Show with Conan O'Brian. It is funny enough to devote an entire post to it, even if short, so go download yourself a copy.

I find it interesting that people are finding humor in this now, as opposed to the initial hatred towards these jobs.

On a side note, I picked up this video from a very close friend's blog. Vikram has only just started his blog, and promises to keep it good. Go over and say hi!

Lunch

2005-03-25T00:44:00.000+05:30

Lunch

Lunch seemed interestingly photogenic today.

Protesting To The Gods

2005-03-21T22:25:00.000+05:30

After what seems like ages, I turned on television today, and happened to stop by at the local cable channel. The screen, instead of showing the latest Bollywood movie, showed scrolling text on a black background.

Due to the sad demise of Mr. Sanjay Gupta (Cable Operator / Distributor) of New Bombay. We will unanimously keeping the cable channel shut in protest.

Firefox's USP

2005-03-09T02:14:00.001+05:30

During an idle conversation with a friend this afternoon:

She: You know, these days I get pop-ups with Firefox.
Me: Yeah I know. Those darn advertising guys. They've found a way around the pop-up blocker.
She: But the pop-up blocker was the greatest thing about Firefox. I'm afraid there's not much difference left between Internet Explorer and Firefox this way.

I considered starting an argument about standards, and how Firefox is going to save the world, but I knew that was futile. For the lay-person, Firefox gave a better experience when surfing. And now, that experience is threatened.

She is terrifyingly correct.

Script Tag In Internet Explorer

2005-03-08T00:05:00.000+05:30

After a sleepless night or two, I just discovered this bug in Internet Explorer the hard way.

I was bascially including a JavaScript file in my XHTML document. The scripts in this file were meant to attach to my XHTML elements unobtrusively, and this file was a unit by itself. So I didn't have any JavaScript within my script tags. This is how my tag looked.

<script language="javascript" type="text/javascript" src="script.js" />

This works like a dream everywhere, except in the world's most popular browser. In IE, the entire page is just blank! The markup is downloaded properly (I can see it when I view source), even my CSS background-color is applied to the page, but there's absolutely nothing on it! I blamed my content-negotiation scripts first (I am serving HTML Transitional to IE and XHTML everywhere else), and then on IE's support for CSS (I thought I made a grave little mistake somewhere). However, on removing this tag, everything worked fine in IE.

Turns out, IE doesn't like the script tags if they are using element minimization. I got the page rendering just as I intended by changing the tag to look like this:

<script language="javascript" type="text/javascript" src="script.js"></script>

Doing some research, I came across this post in theList by Eric Vitiello which clarifies this more. Apparently the DTD declaration for the script tag says <!ELEMENT script (#PCDATA)>, and the XHTML specs says (under Appendix C. 3):

Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />).

So, I guess this isn't really a bug in IE. I'd think instead, that this is a bug in the DTD itself. The script tag doesn't have to contain #PCDATA (in fact, I consider it graceful if it doesn't), and forcing it is, well, stupid.

For now, I am explicitly closing the script tag with a seperate closing tag, and everything seems to be working well. Does anyone have any idea about handling this better, preferably with minimized element closures?

Knopfler Leaves A Mark

2005-03-07T20:03:00.000+05:30

Knopfler Leaves A Mark

It was one hell of a night. We had to smuggle in the Vada Pavs and the Bacardis and the Wills and the matches and the ... well, you get the idea. But they managed to catch us when we were smuggling the water in. Damn! Had to waste a whole bottle!

Anyway. I was hoping that he'd play some more of the Dire Straits and atleast one little song of The Notting Hillbillies, but I had to be happy with about 40% of his solos and the rest almost exclusively from Brothers In Arms and Money For Nothing. But who's complaining!

Sorry for the cheezy pic. I had clicked pics at the show, of course. (I had smuggled my cam in too.) But let's just say that the shots turned out to be a little shaky.

Help Me Escape This!

2005-03-04T01:08:00.000+05:30

Help Me Escape!

Yup, today is one of those days. I spent my last 10 minutes staring at my text editor, thinking that the syntax highlighting looked trippy. Then I got up to drink some water. When I came back I checked and double checked if my white-space and indenting was correct and consistent. Then I thought I'll get some chips from the kitchen. When I got back I started thinking how I can add more comments to the code to make it readable. Then I was deciding if asterisks work better than slashes as the thing you put before and after a line of comment in the code.

I guess it's fair to say that I am having an utterly unproductive day today. Do you have such unproductive days too? What do you find yourself doing on such days?

MotorShow @ Mumbai

2005-02-28T11:38:00.000+05:30

Here are some of my pics from Flickr abouts the Motor Show I had been to recently in Bandra Kurla Complex, Mumbai.

Skoda

One hell of a crazy mod

Isn't she beautiful!

The Future, Now In Russian

2005-02-22T13:44:00.000+05:30

One of my previous posts titled "Web Applications - The Wave Of The Future" has been translated to Russian by Alexander Kachanov. I myself don't know Russian, but I think it's pretty cool to be able to read a post in a language of your choice after it has gone through a human translation.

So, Russian audiences, head to his site if you prefer to read my post in Russian.

Though I've been getting referals from non-english sites discussing my posts, this would be the first time that one of my posts has been translated to a non-english language.
/me swells chest.

Google and Flash

2005-02-15T01:26:00.000+05:30

Google And Flash

Now, this is toally surprising to me. I always thought that Flash was bad for SEO, but this search result has proved me completely wrong. I was doing a random search for "All your base are belong to us", and the first hit turned out to be a Flash file!

I didn't know that Google indexes swf files at all. In fact, I always recommended against using Flash for a site primarily for SEO reasons. Since when did Google start indexing Flash files?

Even more interstingly, the little line below the main hit result link shows a link to "View as HTML". Unfortunately, when I tried, none of these links worked. Looks like Google is broken there.

This is really interesting. Not only is Google able to spider and index swf files, it is also able to potentially convert them to HTML files! How can Google access the content of the swf file? How can it sensibly convert that data to an HTML file? (Can someone please have a look at those "View as HTML" links and tell me what you see?) Has this been going on for some time now?

Check it out for yourself. Google swf.

Update: It appears that I spoke too soon without adequate research. Google has been indexing Flash files for almost a year now. Check it out! Even so, don't you think this Google-Flash thing deserves more attention? How come no one has been talking about it? Can someone shed some light on the topic?

Flowery Fuzz

2005-02-10T14:38:00.000+05:30

Flowery Fuzz

I apologize for not posting too frequently anymore. There is a lot of work piled up, and for once I am running short of time.

This post is just my way of saying that this blog is not dead, though it might seem like it at first sight. It is just one of those slow-downs. There are a lot of things I have planned out for this blog, and I'll start doling them out as soon as I am sure I can get it out of the drafts.

P.S. I have entered this photo in the Photo Friday challenge this week, for the theme "Distorted". If you have nothing better to do, please go over and drop me a vote. If I win, I promise you and your entire family GMail Invites. I've got lots! I know that using GMail invites as bribe doesn't work anymore, but I can't afford too much more.

Google Hitting Me Hard

2005-02-01T11:50:00.000+05:30

One would think that the number of visitors to a blog would drop, considering that it is not updated frequently.

However, in my case, my hits have been steadily increasing over the last two weeks. One of the largest source of these hits (about 14%!) is Google Image Search, pointing to an old post and its pic.

Now, that pic is one of my all time favourites. I had clicked that pic just casually, and the uploaded version is un-touched-up. It is also one of my first macro shots ever. That pic will remain a special one for me.

What makes me curious is, how come I have such a sudden surge of visitors going to see that pic? Unfortunately, the Google Image Search referrer URL doesn't give me any details of the search string, or their referrers. I tried doing basic searches at Google Images, but that didn't turn up my pic for the keywords I could come up with.

If anyone has come here from Google Image Search, could you please tell me how you got here?

Thoughts on XMLHttpRequest

2005-01-27T04:42:00.000+05:30

Some more thoughts on XMLHttpRequest, from my recent experiences with the tool.

Continue Reading...

I was going through my referrer list today, and come across another user who came to me through Eric Meyer’s post about (and in response to my older post) the Economics of XHTML, where he (Eric) talks about how the savings in bandwidth appreciates the value of the site.

These days, I have moved away from talks about markup (as most of you must have noticed), mostly for two reasons.

XHTML is too stringent. It is so stringent, it is not practical.
There are other ways to save bandwidth.

I have to explain. Though I’ve been talking about standards frequently on my site, only recently have I decided to get my hands dirty with a project that talks in XHTML and respects it (which is more difficult that it seems at first glance) at least when talking to browsers that can handle it well.

Reasonable digress: Of late, I have been damn busy. I guess everyone goes through these phases where he thinks that he’s reading too much RSS, but I’ve just stopped keeping myself updated because I don’t have the time anymore. However, I still take the time to comment on the odd good article.

One such post was Roger Johansson’s. He talked about how XHTML can be made easier to use, but in his comments (though he tried hard not to), the discussion shifted to whether XHTML is really worth the effort or not. I maintained that though XHTML is a good way to learn, it is probably not what we’ll use in practice.

That apart, here’s why I am making this post.

I’ve been working on a lot of DHTML these days. Not in the traditional sense – I probably have to call it DOM Scripting to be politically correct. XMLHttpRequest has been my most interesting toy. I’ve been playing with it like a baby boy plays with his first toy truck. He just rides it all over the place. He runs it over terrains that the toy couldn’t possibly take on, just because somewhere in his heart he’s confident that it’ll hold out. XMLHttpRequest has been my toy, and the web is my terrain.

Here are my lessons, good and bad, listed out, while working with XMLHttpRequest.

I think this is the most important issue. Using XMLHttpRequest doesn’t change the URL. Think about this. Eric said that a page that loads faster is good for business, and XMLHttpRequest does that for you in more ways than one. But XMLHttpRequest doesn’t respect URL resources, as seen by the address bar. If you use XMLHttpRequest, your page’s URL remains the same, whatever else you do. Do you need permalinks for your content? XMLHttpRequest can't deliver.
Using XMLHttpRequest involves a lot of DOM Scripting (especially if you think I am correct when I say that data should be passed as JavaScript over XMLHttpRequest). This is a problem for me, mostly because I use XMLHttpRequest in conjunction with XHTML. A command as simple as element.innerHTML won’t work with XHTML. You’ll have to get into the mess of document.createElement, element.setAttribute and element.appendChild way too often. There are a couple of tutorials on the web to explain these concepts, but mostly you are on your own.
XMLHttpRequest doesn’t come without its differences between browsers and their implementations. I don’t mean to scare the one’s who are starting – it’s really not that difficult. But just don’t expect one piece of code to work everywhere. We haven’t reached markup, styling and scripting nirvana yet.
I’ve come across a lot of browser bugs in the implementation of XHTML and XMLHttpRequest scripting. I use Firefox, and (ok, probably after Opera) I think Firefox’s support for standards is pretty good. Yet, Firefox catches me off guard sometimes. And don’t get me started about other browsers yet, including the most popular one. (By the way, for the uninformed, XMLHttpRequest is NOT part of the standard – probably why Opera hadn’t supported it until recently.)
In the end, probably in a nerdy sort of way, XMLHttpRequest is fun. It makes entire page-loads unnecessary. It makes information easier and faster to get to. It makes the user happy. It doesn’t involve too many UI issues. (I thought a user will never be comfortable unless he sees a page refresh when he clicks on a link in the browser. Obviously, I am wrong.) If well planned, XMLHttpRequest rocks!
XMLHttpRequest is tempting to overuse. This not such a problem from the developer’s point of view. However, I am not so sure if it’ll really save you bandwidth in the long run. The problem is that, since users find it so responsive, users will like to pamper themselves with more data than they’d otherwise need. XMLHttpRequest makes it easy, and fast. Just what the users need to have a good experience. I think all those talks about XMLHttpRequest saving the developers’ bandwidth needs to be re-thought. I have no math to back me up, but this is what my hunch tells me.
Did I say yet that XMLHttpRequest rocks? It’s the best thing that happened to the web since the invention of HTTP itself. It’s the stuff that’s going to direct the development of the Internet itself for the next half decade. But like every other intoxicating substance, it could be a life-saver or a poison depending on how you use it.

I guess I have no point to make in the end – I am probably too drunk to conclude. (I’ve been celebrating a VERY close friend’s wedding engagement tonight.) But I hope I’ve put across the point that XMLHttpRequest is good and yet bad, in it’s own ways. And that is so much like every other programming tool.

It’s just a matter of what suits the job best. Flying a jet to work is too much power in your hands, but walking down to work is too little, if you know what I mean. You just have to use the right tool at the right time. XMLHttpRequest is just a tool – you have to decide when it’d be good and when it’d be impractical.

For those who are in doubt, XMLHttpRequest is a tool you are not going to be able to do without. I think that web-developers who still work with old style HTML are already on their way to losing out, but now web-developers who haven’t mastered XMLHttpRequest are on their way to meeting the same fate. Yet, it’s a tool like any other – it has to be used at the right time for the right purpose. Every other time, it’s probably more effort than it’s worth.

Previously:

Why XML in XMLHttpRequest

Jazz By The Gateway

2005-01-24T08:57:00.000+05:30

Jazz By The Gateway

This pic was taken at the Gateway of India, during a jazz show as part of the Mumbai Festival. Performing at the show were some of the greatest living exponents of the art of jazz - Al Jarreau, George Duke, Ravi Coltrane and Earl Klugh along with members of The Thelonious Monk Institute of Jazz.

I didn't go for the show, if you had to ask. (I'd probably have got better pics if I had, but I was too late to get the tickets.) This is a Hail Mary shot taken from outside.

For readers who do not understand photography jargon, Hail Mary shots are where the photograph is taken with the camera held above your head, like in a crowd, without looking through the viewfinder. The camera settings have to be adjusted beforehand, and the frame is just plain guessed.

In this case, I was outside a barracade containing the show. I couldn't see this frame - I had a sheet of asbestos between me and the Gateway. I only held my cam above that barracade and shot.

(Ok, I promise that's the last post about the Gateway, its waters, or of the Mumbai Festival.)

Previously:

Blog Of The Day

2005-01-24T08:20:00.000+05:30

This is probably not a big feat, but the excitement is because this is a first.

This blog has been featured as the Blog of the Day for today, on BlogStreet India.

Cheers!

Mumbai Fest - Some Pics

2005-01-19T13:03:00.000+05:30

There was a huge collaborative street art project at Kala Ghoda, Mumbai as part of the 10-day Mumbai Fest. I happened to be around, and get some pics. (The pics link to Flickr)

Pic 1

Pic 2

Pic 3

Support drugs. Do good karma.

Illegal To Display Feeds?

2005-01-18T14:32:00.000+05:30

I came across (and I must say this) a really stupid post at The Trademark Blog, where the author accuses Bloglines for illegally reproducing his site's content.

It was brought to my attention that a website named Bloglines was reproducing the Trademark Blog, surrounding it with its own frame, stripping the page of my contact info. It identifies itself as a news aggregator. It is not authorized to reproduce my content nor to change the appearance of my pages, which it does.

I think this kind of thoughts either stem from a poor understanding of feeds, or maybe this guy is just looking for legal issues to talk about (he's a lawyer, after all), or both.

Bloglines might be putting their ads next to my content and earning money out of it. I don't think that constitutes "commercial use" of my content. They are providing a service, for which they are going to need money to run, and ads are a good way to get that done. The ad money I make off my site is barely anything, anyway. I don't mind if I lose an additional $2.05 to Bloglines, considering that my user-base is actually increasing thanks to services like Bloglines. I could think of it as paying them to keep my audience coming.

Besides, it's not like Bloglines is running a site that makes money thanks to my content being published there. The users of Bloglines choose to put a feed in their reader, and Bloglines just provies a means to read that feed easily. Bloglines makes money because they provide a great way for users to read a site's content, grabbing what the site's authors have willingly distributed for just that purpose.

Personally, I read a lot of feeds too, a lot of which I prefer to read in Bloglines and not on the original sites. This is because, with Bloglines, I can strip off the clutter on a site, and grab just the content of the site, in a font, style and layout that I am comfortable with, and that works with all the other 130 sites in my feeds list, consistently.

I did come across a similar problem recently, where a blogger had published one of my recent posts on his site, even though he gave me full credit for the post. I just sent him a friendly mail asking him to get my content off his site, and instead link to me if my articles are really important to his site's audience. Promptly, he removed that entire section off his site. (Apparently, it was his personal link blog, and he has now put that behind an authentication system ensuring that he's the only one reading it.) I am ok with him reading my feeds, really. I guess it would be a problem if he publishes my posts without asking me first. Publishing my post on his site, and reading my feeds are two different things, though. Obviously this blogger respected that when I brought it to his notice, and did the needful to correct the mistake.

In the end, is it illegal to view/display/publish feeds from a site? No, it isn't, considering that the site's author willingly distributed the feeds. Is it illegal to publish one single article on a site without the author's permission? It probably is, but more than that, it's unethical, and should be refrained from doing. Is it illegal to make money by providing a service that reads feeds? Definitely not!

I think I am thankful to Bloglines for making sure that I get a consistent flow of people reading my content, even if they don't ever visit my site. If I don't like Bloglines' idea of reading feeds, I should probably just stop publishing feeds. But that'll just crash my audience-size. In fact, I like the idea of Bloglines displaying my feeds so much, that I had written a post earlier recommending that people read my feeds through Bloglines, and I even added a permanent link on my sidebar making it easier for people to subscribe to my feeds with Bloglines.

How about that, Mr. Lawyer?

Lights, Camera, Arches!

2005-01-16T13:30:00.000+05:30

Lights, Camera, Arches!

Shot the other day at the Gateway of India. I had to clean up the monument a lot with my copy of Photoshop, because the government hadn't done a good job. (Thanks Kaushik, for patiently showing me how to play with Photoshop.)

Previously:

Reflections

I Graduated!!!

2005-01-12T14:35:00.000+05:30

News has just come in. I am finally a graduate.

Bachelor of Engineering (Electrical and Electronics). Aaaah! That feels good!

Meet me at my local watering hole tonight to join in the celebrations.

Why XML in XmlHTTPRequest?

2005-01-12T13:44:00.000+05:30

The XmlHTTPRequest function was designed so that the client can get small pieces of information from the server without having to do a page refresh. Obviously, the developers thought that XML will be the format of choice for this data exchange.

Thank God they didn’t make XML validation necessary!

I say this because XML will not be the format of choice for this data exchange. Let’s see why.

Read on...

Firstly, let’s see how the data flow will be in the case of XML over XmlHTTPRequest. A typical scenario is where the data lies in a database on the server, and the data is requested by the client. The steps in the process will be:

Server reads the request, extracts the data from the database.
Server prepares an XML document using this data.
This XML is sent to the client.
Client validates the XML for well-formed-ness.
Client extracts data from the XML markup.
Client calls functions/triggers events which use this data as parameters in some way or other.

For several reasons, this model is not optimum. The questions that come to the mind immediately are:

Is it necessary to prepare an XML document (step 2 above)? Isn’t that an extra step that is probably not necessary?
Client validation is necessary (step 4 above) to ensure that the XML parser can parse the XML. This puts heavy processing requirements on the client. Is this really necessary?
The data from the XML will then have to be extracted (step 5 above). This isn’t really a necessary step either if the data is not marked up as XML. So, then, is it really necessary to use XML?

Then there are more problems. In web applications, where XmlHTTPRequest is most likely to be used, speed is of utmost importance, and optimizing for fast response times will be imperative. In such cases, the amount of time taken for any kind of operation, especially if it happens over the network or the internet, has to be minutely scrutinized and optimized. In such cases, XML is probably not the best suited format for data exchange. XML files are heavy as far as sizes go. A simple text like “Hello World” (11 characters) can be transmitted over XmlHTTPRequest as 11 bytes of data. Marking this up as XML will increase this at least 4 fold (say, and that’s still a conservative estimate) even if whitespaces are stripped off the document, increasing download sizes four times, and reducing response by a factor of 4. Point is, XML comes with its overheads which cannot be tolerated in a web application.

So, in what format will data be transferred over XmlHTTPRequest? The simplest way is as a plain old string of data. This will be the most efficient as far as download speeds are concerned. You will download only 11 bytes where 11 bytes of download is required, not more. Besides, there won’t be any XML parsing or validation in the picture, making the application that much faster.

However, somehow, I don’t see data flowing over XmlHTTPRequest in the form of plain strings of data either. Instead, I think it’ll flow in the form of JavaScript code.

Let me use an example from the guy who deconstructed Google Suggest, and the way XmlHTTPRequest works there. According to him, the code returned by Google when you hit a keystroke looks like this.

sendRPCDone(frameElement, "fast bug", new Array("fast bug track", "fast bugs", "fast bug", "fast bugtrack"), new Array("793,000 results", "2,040,000 results", "6,000,000 results", "7,910 results"), new Array(""));

Basically, what this code does is call a function, with a bunch of parameters. The function called, sendRPCDone, is defined in client side JavaScript code. The parameters are generated depending on server side processing (probably from Google’s cached searches). Then, later in the code, this response text is run through an eval function to execute the function on the client side (eval(_xmlHttp.responseText);).

I think the eval function is really a boon here. It makes JavaScript as the language of choice over XML for XmlHTTPRequest. For who don’t know what eval does, it basically takes a piece of string, treats it as though it is JavaScript code, and executes it. The string could be dynamically generated by client-side code, or as in this case, returned from the server. Just what we need here!

To summarize, here’s why we’ll use JavaScript instead of XML when using XmlHTTPRequest.

Downloading XML data will take more time as compared to JavaScript. Depending on the amount of data to be transferred, this difference might be huge.
Use of XML will necessitate validation of the markup, so that a parser can read the document – a process that requires extra processing on the client-side. This is not necessary with JavaScript.
The XML data is not already in a position to call scripts. Client side code will have to handle that, based on event handlers or such. JavaScript, on the other hand will be ready to be executed on the client.

It's easy to see why XML will not be used as the format of choice over XmlHTTPRequest. A little thought later, JavaScript emerges as the winner as the format of choice for data exchange over XmlHTTPRequest.

Did someone say that JavaScript will be coming out of the closet this year?

Previously:

Look Ma, No Refresh

Google Logos

2005-01-11T21:07:00.000+05:30

You are probably aware of the fact that occassionally Google changes their logos to celebrate a festive occassion. These logos (called the Google Doodles) are really nice to look at. Go have a look.

What I didn't know (and I happened to notice it from somewhere) is that Google has different search sites for specific topics. Here's the list of some of them, with their logos:

I could'nt help notice the Google Microsoft Search logo. It is the only one with a non-white background. Somehow, it seems to be mocking MS with its sky and grassy hills combination.

Reflections

2005-01-09T02:03:00.000+05:30

Reflections

Was spending a night out on the streets of Mumbai today with a friend's camera. I am totally not used to this camera but I managed to get an interesting shot or two. The cam is a Nikon Coolpix 3100 - the same series as mine, but only slightly less loaded.

This pic shows the reflection of the lights of Hotel Taj in the waters of the Arabian Sea, at the Gateway of India.

Web Applications - The Wave Of The Future

2005-01-06T16:59:00.000+05:30

Web applications are finally beginning to see the light of the day. I am putting all my money on this. I am sure this is the future of the web, application design, networked software architectures, maybe even desktops and operating systems itself.

Web based applications will make inroads into (almost) every kind of application we use today. In this post, I try to list out some of the benefits of using web based apps.

Read the complete post...

First, a quick introduction to web based apps, for those who just tuned in. Examples of web based applications are GMail, Bloglines, and OddPost. GMail is a full featured mail client that does everything that a desktop mail client does, only ups it a few notches. So does OddPost. Bloglines is a web based feed reader that is directly competing with desktop feed readers, and winning. These web apps are basically applications that run on a server, whose UI is exposed in the form of web pages. By the very nature of its architecture, the program logic lies in a central place (the server), and the UI is available to the client in a piece of software that has been around since the birth of HTTP itself (the browser). The use of JavaScript and the DOM is probably the single most important factor that has made these apps possible.

The use of JavaScript is very different from the way it was used in 1999. Back then, JavaScript was just a cool way to make mouseovers and cool (now irritating) dynamic elements on the page like mouse pointer trails and flashy text that change colors. JavaScript was used because it could be, not because it should be. At one point, I thought JavaScript was dead, indeed like many other developers must have thought. The use of JavaScript became an example of bad web design, and the language was pushed into the dark annals of the world of notorious web pages.

Now, though, JavaScript has matured. It is used just what it was designed for - creating dynamic changes on the client side without introducing a server refresh lag. A dynamic front end in a browser window has always been a problem for application design and is probably the only reason why web based applications have not yet seen the light of the day. Today’s use of JavaScript circumvents that problem.

Now that we can make web applications, here's why we should, and will, do it.

The application lies at only one place

The application logic lies on the server, unlike desktop applications, where the application logic lies on the user’s computer. Since there is only one working copy of the application, it’s much easier to distribute. In fact, distributing applications in the traditional way doesn’t make sense here at all, since the user doesn’t really get a copy of the app at all. All the user gets is the UI, which is really all he needs. Application distribution is a non-existent problem, which means it is as easy as it can get.

The user doesn’t need any software

All the user does is fire his browser and type in a URL. These days, browsers are a standard piece of software that usually gets bundled with the OS itself, so finding a browser on the client is not a problem at all, and really, that’s all the user needs.

The user isn’t the administrator

Typically, when a user has the need for an application, he has to prepare himself to be the administrator of the application. He will have to do the setup, running, maintenance and troubleshooting, and handle all the problems that come with it. But in the case of web apps, since the app is really not with the user at all, the user won’t have to worry about these problems. And really the user shouldn’t. That makes for a happy user. That translates into a good application. This, of course, is impossible with desktop applications.

The administrator is the application’s programmer

Yes, the load on the programmers is more. But if you compare that to the costs of making deployable applications and then managing a service team to help users install, maintain and troubleshoot the application, it’s easy to see which is cheaper, not to mention more efficient. A small team of programmers working at one central location to maintain, manage and troubleshoot applications makes more economic sense to app manufacturers.

The application makes no assumptions about the user

Ok, that is a small lie. The user is assumed to have a capable browser to handle the application. But really, is that such a big deal? Because of the very nature of HTTP, the application is platform independent. This means that the user can use any operating system he wishes to use, and that doesn’t make a difference. This is a huge change from the traditional “Designed for <operating system name here>” applications. The user doesn’t have 512 MB RAM? No problem. The user doesn’t have processing power? No problem. The user has an outdated motherboard? No problem.

Multiple versions is a thing of the past

When a new version of the application is out, every single user gets to use it instantly. Literally. How cool is that! Again, this is possible since the application is centralized, and there’s really only one running copy of the application. All version changes are instantaneous and the user doesn’t need to know how to upgrade. This also means that the app developers don’t have to worry about supporting legacy versions and backward compatibility is not an issue.

It’s lightweight

The user doesn’t really download the whole application before using it. (Take that, Java fans!). He doesn’t even download the whole UI. He only downloads the part of the UI that is required for his use immediately over the URI that he’s on. This makes the application very lightweight and hence responsive and fast. Even very complex applications can load in seconds, maybe less, even over a bad connection, thanks to this.

It’s portable

There’s nothing installed at the users end, so the user can use the app from any location. Any location means literally any location across the globe. You can use the application in your office, and then at home, and then from your vacation in Hawaii, and every time it works just as well, without any problems of portability.

It’s simple and trustworthy

No messy extra protocols or port numbers. If your firewalls lets you see web pages (and which firewall blocks that!) you can access the application. So the user doesn’t have to know a thing, or worry about it. He just fires up his browsers, and enters a URL. Simple. Even better, since the application works in the protected environment of the browser, the application can be trusted and can never mess with the user’s system. No more can an application “slow down your system”, or “crash every once in a while”. Those complaints are a thing of the past.

The app architecture is transparent to the client

So, the programmers think that it would be a good idea to have separate data servers? Maybe split up demanding processes and push them to different computers to handle the job? Maybe they need a whole bank of a hundred thousand computers working together to do the job? This kind of architecture can be designed for optimum load balancing between servers. However this is entirely impossible with desktop applications. With centralized applications, it’s not difficult to construct and maintain such systems. In any case, whatever be the server architecture, the user doesn’t need to know or care.

Sure, web applications can never do some things that desktop applications can do – far from it. You will never be able to do a defrag through a browser. You can never run 3D modeling software through a browser. Browser based apps cannot replace system programs at all. Not for a long time to come, at least. However, for application programs, the desktop’s days are numbered.

Welcome to the show. Today’s act: The beginning of the end of the desktop.

Update: This post is now available in Russian. (Thanks, Alexander Kachanov)

Bad Forms

2005-01-05T21:13:00.000+05:30

A site I frequent has a nice little local weather update shown on its sidebar. Now, I get my local weather forecasts delivered on my desktop through a Konfabulator widget, The Weather, and have been reasonably happy with it. Also, considering that in the web design circles, not too many bloggers are from Mumbai, I thought it'd be a nice touch to add to my site.

After some digging, I discovered that my weather feeds are coming from weather.com. Over at their site, they have tools to display the current local weather on my site, and was very pleased with it at first glance, until I discovered that I have to register to use it.

I have to say, I have issues with registering for services, especially free ones. I can cite various reasons why I do not and probably should not register. Most web designers must know that users do not like to register on a site. If they don't, they don't make for good web designers.

Aaagh! Let me get to my point.

Have a look at this form I had to fill to register. Done? Now, let me list my peeves out.

The form says that fields marked with the red asterisk are required fields. Is it just me, or do you find it funny too that every field has this red asterisk next to it?
Really, do they need my first name, last name, date of birth (what?), and gender (whaaaaat???) so that I can sign up for a weather service?
The address (and its various fields) are also marked with that asterisk. However, the state I belong to here in India is Maharashtra, which isn't listed there. In fact, none of the Indian states are listed there at all! Wait, it's only American states listed there? Maybe the developers forgot that The Internet is a worldwide network, and America is not the only place in the world? Wonder why they hired developers like that! Required field, you say? What do I select now?
Oh, hang on. They have a option where I can change the country from USA to India. However, I found that only after I found the 'State' dropdown box. Smart layout, I must say!
Oh, I am wrong again. Changing the country is of no consequence to the list of states. Even if I select "India", the states shown are all American! Smart!
Here in India, our pin codes are 6 digits long. However, I can only enter 5 digits in that box they have on their page. Let me guess, America has 5 digit pins?
Notice, I have not talked about concepts like accessibility yet. Obviously (or, the impression that I get without doing my right click > view source is that) the form is not the least bit accessible to other kinds of browsers.

I must say, it is really irritating when companies like this just assume that their audience is only American. The Internet is not just about America, you know. Don't make me fill forms which require my local information, without doing a study of what local information looks like outside your locality. In any case, when designing a form, please don't assume that America is the world. And please do not ask for stupid irrelevant information, like my gender. By the way, would you also mind giving a little thought to this little thing called 'Usability', while you are at it?

Sorry weather.com. I do not like you any more. I know you'll probably say "So what?", but that doesn't help improve your image. Quite the contrary, in fact.

May the web design community use that form as an example of badly designed forms. When you see forms like this, you can put one hand your stomach, point the index finger of your other hand to the screen, tilt your head backwards slightly, and laugh out loud with your stomach bobbing rhythmically up and down.

Link Bin

2005-01-04T02:34:00.000+05:30

Ever wondered what your favourite cartoon characters' skeletal structures are like? Take a look.
Did you know that Homer Simpson uses tabbed browsing?
Firefox 1.0 cumulative downloads graph. (via)
Best Of The Post 2004 - Politics: a collection of the best political pics of the year.
The BitTorrent Effect.
How to fix Mom's computer - a novice guide to fixing up a messed up computer.
Floating Logos Project - Interesting, but you can't help but wonder how much time people have at hand.
Eating your mouse can be injurious to health.
A collection of pics sent in to the BBC by its readers over the last year.
Winners of the 2004 Bad Science Awards.
Bloggers are the People of the Year, 2004, according to ABC News. (via)
An amusing QuickTime animation about procrastination. (via)

Tsunami Links

2005-01-02T14:17:00.000+05:30

Here are some links related to the Indian Ocean Tsunami.

The wikipedia entry is extremely informative, with a lot of information, pics, animations, videos and more links.
Waxy.org for more amateur tsunami video footage.
U.S. should not help the tsunami victims. Just what the victims need. Let the U.S. discuss tax issues and ownership of government money, while people die half way across the globe when they could do with some help.
A collection of before and after satellite pics of the affected areas. (via)
People dead = hundreds of thousands. Animals dead = zero.

Predictions for 2005

2005-01-02T13:24:00.000+05:30

I am making this post for two reasons.

Everyone is making similar posts.
It’ll be fun to come back to this list at the end of the year to see how correct I was.

So, here are my predictions about the web for the coming year.

People will understand why IE sucks

We know why IE sucks, but the regular user doesn’t even know of his options. Alternative browsers that provide a better surfing environment will make users turn to them. Firefox will lead this bunch, probably breaking the 50% browser share barrier.

Developers will still not take to XHTML

Developers will realize that XHTML validation is a lot of work and not really worth the effort. Web pages will continue to use HTML. We will use the lessons we’ve learnt from XHTML, like semantics, separation of code and content, CSS based design and accessibility driven design, but the web pages will continue to be invalid XHTML, and people will discover that the validation doesn’t really matter at all. XHTML will be used only by purists. It will remain a great idea that we can’t use yet.

JavaScript will take the stage

2005 will probably be remembered most for the use of JavaScript and related innovations. Yes, that happened in 1999 too, but it will be different this time around. Developers will understand how to use JavaScript in a fashion that keeps the page accessible to even incapable user agents. XmlHTTPRequest will probably be the hero of the show through this year.

More Web Applications

There’ll be more applications running off a browser over the Internet. I can already feel this happening with me – I probably use fewer desktop applications than web applications. More and more system independent applications will run off the browser.

Brower independence will be in vogue

Sites that work only in one browser will be looked down upon. Most such sites will alter their code to accommodate multiple browsers or otherwise be totally browser independent.

Mobile browsing will be more important than ever

In the long term future, I don’t see people using a desktop computer just to check mail or send an IM. Instead, such things can be done faster and more efficiently on a mobile device, like a phone. Good browsing capabilities for such phones will be very important, and we’ll see crucial steps being taking in that direction this year.

Most of these are rather obvious. But then, not always is the obvious the necessary consequence. Let’s see what happens at the end of the year.

Happy new year to one and all. Hope the year is great for you.

Donate For Relief

2004-12-30T21:27:00.000+05:30

Amazon makes it easy for you to donate to the American Red Cross Society for the tsunami victims. (via)

Earthquake! Tsunami!

2004-12-28T11:02:00.000+05:30

Read on for the horror in first-person.

Home was hit by Tidal wave... Practically lost everything.... Family is fine... Thank God... - Ronnietan

... and then tidal waves about 16 feet high hit the West coast of Phuket (Rawai, Patong), the Similans, Koh Lanta, Phi Phi Islands. The wave reached 300 m inland at Patong and swept hundreds of tourists into the sea. - ellie_elephant

There was a kinda big earthquake in my place this morning... It woke me up, and I ran downstairs amazingly fast... That was shocking. I thought this house will be ruined... - Meilathena

Priya and I are safe, barring a nasty shock when she was jerked out of bed early today morning by the quake... - Suresh Ramasubramanian

Thankfully my parents are okay - they have not been affected physically. However we have lost some of our closest friends... - Dhruhini

I am closer to the beach. A church by the beach is supposedly flooded, and there are reports of people being drowned, while in Church. I wonder if they got trapped or something! - notangel78

The beach is totally flooded. Chennai without a beach feels totally weird, even though its only temporary... People around the beach have been forced to evacuate. Looks sad. - Vyshnavi

We had tremors, and floods. Apparently there are dead bodies up the coastline. Fuck... We're fine. But scared. - Rulinian Wexile

I'm scared... My best friend, Alyssa is currently on holiday in Langkawi, Malaysia - Sophia

He was jet-skiing at a beach in Phang-nga province, one of the place that the wave hit hardest. They found his body about 100 metres away from the hotel. - D.M.

The water went out then came back in very, very quickly, taking everything with it. When the water came into the bungalow, we put everything on the beds... All the windows were closed, so the water kept pushing everything up towards the roof. It pushed us up to the roof, then the roof came off and we floated away - Mr Sköld in Daily News

We were standing there taking pictures and the wave started coming back, faster and faster, so we started to run away, faster and faster, but my parents didn’t run fast enough. - Mrs Holmberg in Daily News

Jayanti Lakshmi, 70, had gone shopping with her daughter-in-law in Cuddalore, southern India. Ms Lakshmi returned to find her son and twin grandsons dead in their hut. - BBC

People that were snorkeling were dragged along the coral and washed up on the beach, and people that were sunbathing got washed into the sea. - Simon Clark in CNN

My mate's staying in a police station for the night and luckily she hasn't had to go through the trauma that some of the survivors of the tsunami have had to go through. - Eshin

I feel sad too to see the victim, and the tsunami is 9 mtr high, and it swept out all the living near the beach... - In a post to Meg

People are rushing out from the coastal area into town, ambulance the other way round. Bodies have been found, many still missing, millions worth of assets damage, coastline of Penang is in mess. - calmocean

It's the way of the world. There's only so much we can do against the forces of nature. - Aerna

We called up our friends in South India and Sri Lanka and they are safe. Still, they know people who have been affected and some are still missing. We are all affected. - Dina Mehta

The wave(s) that came were 4-5 m high. If they could pick up those cars and throw them over the fence, we wouldn't have had a chance. - The Command Post

There was an earthquake, after five minutes there was water all around and we ran away. When we came back, our homes had been destroyed - in NDTV

As we watched it became apparent that the sea was behaving very oddly. Waves were not breaking as normal. The sea appeared to be surging. One such surge practically emptied what we could see of the bay. This was followed by the sea moving repidly back into the bay and reaching right up to the promanade area (and possibly beyond) [...] At no time could we make out any people. - Andrew Sutton

Later on we went down to the beach and believe me, the paradise has been changed to hell. We know also for sure that the official figures underestimate the number of casualtiesa, if you think about all the fishermen. - (via)

He recounted hearing what sounded like repeated explosions coming from the coast. When he left his home to investigate, he spotted a wave towering above the tree line about a mile inland. - Yahoo! News

Since I was now sure I was fully awake, I sat on the bed. There it was again. There was a definite tremor in my bed. It went on for another two minutes. - MadMan

I heard an eerie sound that I have never heard before. It was a high pitched sound followed by a deafening roar. I told everyone to run for their life. - Chellappa in Reuters

At 10am (local time) all of a sudden, just out of nowhere, a massive wall of water came through. There are cars upturned and floating, there's debris, there are beach chairs and beach umbrellas, bits of restaurants are starting to float by. - Australian State MP John Hyde in smh.com.au

...her family lives right on the beach. Her frantic phone calls were unanswered. Her husband and teenage son, who just celebrated his birthday a month or two ago, are either homeless or dead. - David Lok

A lot of these were originally compiled by Insomnia

Tropical Snowflakes

2004-12-27T09:30:00.000+05:30

Tropical Snowflakes

It doesn't snow much in India, not even in Kodaikanal. But that doesn't stop nature from placing beautiful white fluffs all over the place in the winters. Shot in Bryant Park, Kodaikanal.

A Very Good Year

2004-12-26T23:09:00.000+05:30

According to the browser stats maintained at the W3Schools, this December the number of Mozilla (mostly Firefox) users was more than 20% of the Internet's crowds. That's a leap from 8.2% to 21.2% in a year. Internet Explorer crashed from a high of 84.1% to 71.7%.

Let that sink in again. One in every five users is a Firefox user.

I like the sound of that. I think that makes this a very happy year! Cheers to that!

Did you get Firefox yet?

Previously:

Browser Trends

Link Bin

2004-12-26T01:27:00.000+05:30

Long time no idea for a post. It's time for a link dump!

A great article on Using the XMLHttpRequest Object.
The Institute of Internet History (via) - for a record of the origins of the Internet.
Some people just done care about spyware!
A slashdot review of Debugging Indian Computer Programmers: Dude, Did I Steal Your Job? by N. Sivakumar. The comments that ensue are very interesting.
Now, after the iPod, it's the iPhone!
Don't boot me! I'll sue you! (via)
Why nerds are unpopular. Now you know.
Orgasms at a push of a button, now available on your cell phone. (I love her columns, by the way.)
Top 20 IT mistakes to avoid. At #11 is "Developing Web apps for IE only".
Most hated online advertising techniques.
Google that speaks. Speegle. (via)
2004 Year-End Google Zeitgeist.
CSS Zen Garden? (via)
Our relationship just hasn't been working for a while, and now, this is it. I'm leaving you for another browser.
The Nit Picker's Guide to the Lord of the Rings - so that you know where the movie went wrong.

Ho Ho Ho!

2004-12-25T01:46:00.000+05:30

From a friend over SMS, a few days before Christmas:

Merry X'mas. A bit early I know, but there's thousands of beautiful and sexy people to wish, so I thought I'd start with the ugly fuckers first.

Merry Christmas to you too! Hope you have a great time!

What Do You Suggest?

2004-12-23T01:21:00.000+05:30

It's no news now, but some time ago Google announced the launch of Google Suggest. Sure enough, it got slashdotted. Some talked about it, some dissected it, some others hacked it.

Then the fun stuff started rolling out. Some others got more serious about the fun. Some others thought the fun was news! Weird, isn't it?

An Incredible Time

2004-12-22T08:34:00.000+05:30

My 10 day holiday has now extended into 15 days, and I still can't have enough.

Yesterday, I went for The Incredibles - an animation by the really cool guys at Pixar Studios (the guys behind such movies as Finding Nemo and Toy Story). It's a wonderful story about a family of retired super-heros who eventually get back into the "saving the world while wearing spandex" business, interspersed with very humorous takes on mid-life crises and growing up super-kids.

Needless to say, this is a can't-miss.

GMail Invites Again

2004-12-21T17:46:00.000+05:30

I don't know a single person who doesn't have GMail already (ok, I do, but they don't need it anyway), so when I get invites, I turn to my blog.

I've got 4 GMail invites with me. If you want an invite, leave me your first name, last name (yes, seriously - I am tired of making up first names and last names from e-mail addresses), and your e-mail address, and I'll zip you an invite within a day. I have only 4, so I'll give it off to the first 4 who write in.

The Firefox NYT Ad Is Out

2004-12-17T15:00:00.000+05:30

Sorry for one too many Firefox posts, but there's stuff happening that cannot be ignored.

The Firefox advertisement that has been in the pipeline is finally out on two pages in the New York Times.

For those who want to see a copy but cannot grab the NYT, you can download a PDF version from the Mozilla site.

Previously:

More On The Firefox NYT Campaign

The Fox On Fire

2004-12-16T11:42:00.000+05:30

Need I say more?

That was on the 12th. Right now, its beyond 11 million. That's 11 million happy users. And a lot of happy developers. As I see it, there's only one company in Redmond worried right now.

I'm Back

2004-12-16T10:37:00.000+05:30

It has been 12 days since I hit that "New Post" button. It feels so good to be clicking it again.

In my last post, I just assumed that my site hits will plummet to a new low. However, when Dave Shea gave me a link in his Dailies, it started a chain reaction with more site linking to me, resulting in one of the highest ever hits I have got on my site in one day. That effect is still to dwindle.

Anyway, enough about when I was away. Let's get on with some more blogging, shall we?

Previously:

We'll Be Right Back

We'll Be Right Back

2004-12-05T02:30:00.000+05:30

I'm off for 10 days. I will be in a dusty town with no computer access, let alone the chance of getting online and making blog posts. I know my site hits will plummet to a new low. After all, since the inception of this blog, this is going to be the longest break I'll be taking from blogging. But I have to do this. I have no way out.

Regular programming shall commence on the 16th of this month. Please don't go anywhere. We'll be right back after the break.

Link Bin

2004-12-05T01:44:00.000+05:30

This is probably going to be my largest link dump till date.

Crap Jobs - tales of woe can make for hilarious reading and it is with this in mind that the Idler Crap Job project began.
The most persistent design bugs - some of the biggest mistakes we have yet to fix.
Portable Firefox - keeping Firefox on a USB drive that you can carry around. (via)
Really simple and foolproof traffic building tips - Nothing new, but a good summary.
Arabian Gulf? What Arabian Gulf?
WTF is that? VB++?
I didn't like the semantics of the markup, but these menus are awesome!
Hicks rebrands Joshuaink. From the designer of the Firefox logo, here's his finest work yet.
I found this interesting set over at Flickr the other day.
Lycos launches attacks on spam servers by asking users to install a screen-saver, like how the SETI project worked. (via)
Worst excuses people give after being caught speeding by the safety cameras. (via)
An interview with the co-founders of Flickr.
Beer logos, available for download in Illustrator and EPS formats. (via)
Wikinews (English, German) launched by The Wikimedia Foundation (the guys behind the hugely successful Wikipeida) launch the Wikinews, a free news-source created collaboratively by volunteers around the planet.
Firefox users ignore ads. Now I know why it'll really take 5 years for me to get any money for my ads on this site!
Tech Support jokes. And more Tech Support jokes. (via)

Fatal Error

2004-12-03T14:54:00.000+05:30

A small mistake in my previous post, a bandwidth crunch over my network, and Blogger's servers going down temporarily all happened at the same time, pulling my site down for a couple of minutes. I've fixed most of the things now, and everything should work as normal. Only my feeds would have (probably) gotten a little cluttered with titles linking to non-existant posts. I apologize for the confusion. I'll try my best to ensure that it doesn't recur.

Continuum Navigation Links

2004-12-03T13:44:00.002+05:30

Heavily inspired by Web-log Continuums at Functioning Form, I have started adding a list of relevent links, titled "Previously", at the bottom of some of my posts.

This lays out a contextually relevant path for readers who are interested in how a particular idea has continued to evolve on this blog.

Though the idea presented there is rather complex to implement, I decided I'd rather get started with using them in my blog. Currently, I am manually adding the links and the relevent markup and style. In my "Perfect Blogging CMS", these links will be more detailed, and will be inserted automatically. But then again, perfect blogging CMSs have yet to see the light of the day.

From my site's stats, the continuum navigation looks well received. I would appreciate it if you could tell me first-hand if you like this type of navigation, or if you think it is just some clutter-stub.

Road To Ten Million

2004-12-03T13:28:00.000+05:30

From a recent post on the SFx Site:

In just 23 days, you all have helped over 8,000,000 people discover a better Web experience. If we keep up this pace, we have a shot at hitting 10 million downloads in the first month.

Please do your bit. Get a co-worker to switch. Give it as a Christmas gift. Spread it in your school. Talk about it to your Internet Cafe guys. Do anything you can. Let's make browser history!

Previously:

1 Day, 1,000,000+ Downloads

World AIDS Day

2004-12-01T23:47:00.000+05:30

Just a quick note to remind everyone that the AIDS threat is real. Please do what you can in your powers to prevent it, and help those who are suffering.

	Changed snippet	Internet Explorer		Safari 3.x		Firefox		Google Chrome		Safari Nightlies
		foo	this	foo	this	foo	this	foo	this	foo	this
1	`alert(this); eval("var foo=456");`	123	object	123	object	123	object	123	object	123	object
2	`alert(this); window.eval("var foo=456");`	123	object	123	object	456	object	123	object	456	object
3	`alert(this); this.eval("var foo=456");`	error	object	error	object	error	object	error	object	error	object
4	`alert(this); eval("var foo=456", window);`	123	object	123	object	456	object	123	object	123	object
5	`(function() { alert(this); eval("var foo=456"); })();`	123	object	123	window	123	window	123	object	123	window
6	`(function() { alert(this); window.eval("var foo=456"); })();`	123	object	123	window	456	window	123	object	456	window
7	`with(window) { alert(this); eval("var foo=456"); }`	456	object	456	object	456	object	456	object	456	object
8	`with(window) { alert(this); window.eval("var foo=456"); }`	456	object	456	object	456	object	456	object	456	object

blog.rakeshpai.me

Announcing AceSeller.com

Thoughts On Taking the Entrepreneurship Plunge

Financial aspects

Creating something

Starting up

The Impact of HTML5^H: Feature Detection

Practical CSS3 Media Queries and Mobile Browsers

The Mobile Web

Mobile First

The code

Wrapping it up

In the end

Section 3.3.1 of iPhone SDK License Agreement

On APIs

On language of choice

On compatibility layers

History repeats itself, sort of

But the iPhone is where my target demographic is!

geocitieslycostripod.com

Songs In Code

Downloading JavaScript Files in Parallel

Regular <script> tags:

With script parallelization

One script tag to rule them all

JsMemcached.js - A Jaxer client for memcached

Function declaration vs. function assignment in JavaScript

HTTP cache optimization

Phase 1

The problems

Phase 2

The solution

Joel on Project Managers

Understanding eval scope. Spoiler: It's unreliable!

Housekeeping

JavaScript for Linux Hackers

element.hasFocus? document.activeElement!

Brendan Eich on code translation to JavaScript

IE Congratulates Firefox

Simply use HTML. Not XHTML.

Goa

Getting iSync to work with the Nokia N91 8GB

Web 2.0 Professionals

On X-UA-Compatible

Bill G Has Left The Building

A Movie About Coffee

How To Build A Read/Write JavaScript API

Pics from Kerala

Dojo, Flash, SWFObject, Packer, IE's "Click here to activate and use this control" and Eval Contexts

Client-Side Performance Optimization of Ajax Applications

Network performance

Perceived performance

JavaScript performance

DOM Performance

Much Deserved Update

URI fragment identifiers and HTTP

Safari for Windows

Web 2.0 ... The Machine is Us/ing Us

IE's Unknown Runtime Error When Using innerHTML

America Calling

Interviewing UI Designers

Say Hi To JSON

Back In Action

Google Indexes The Future

Yellow Sun, Yellow Plastic

One Year...

When Referrals Are Funny

Mumbai Under Water

Not Jobless Anymore

Chainsaw In Red And Blue

On The Edge Of The World

What Would You Do?

Gone Fishing

The Real Problem With Ajax

Communication

You Know When It Happens...

Back From God's Own Country

I'll Be Right Back

Two Women And A Kid

What Extensions Do You Use?

Regular `<script>` tags: