“Software is a Process”

Two very insightful posts from Dave Winer -

1. We Make Shitty Software (from year 1995)
2. A message from developers to users

Dave writes -

“Software is a process, it’s never finished, it’s always evolving. That’s its nature. We know our software sucks. But it’s shipping! Next time we’ll do better, but even then it will be shitty. The only software that’s perfect is one you’re dreaming about. Real software crashes, loses data, is hard to learn and hard to use. But it’s a process. We’ll make it less shitty.”

Google Gears and Linux

“Google Gears” could not be installed because it is not compatible with
your Firefox build type (Linux_x86-gcc3). Please contact the author of this
item about the problem.

Found the fix in this Google group post which says re-installing Gears should fix this issue.

On more digging, it appears that there are several bugs reported with this issue e.g. Bug # 975, 977. Apparently someone uploaded a custom gears xpi to fix versioning issue. Google indeed has moved on to phase out Gears in favour of HTML5.

Tags: google

Simple Update Protocol (SUP)

Paul Buchheit (the creator and ex-lead developer of Gmail) of FriendFeed has suggested a new format – Simple Update Protocol (SUP) to minimize multiple feed polling.

The idea is simple -

• The feed provider will generate a live or cached feed for ALL recent updates with an ID field to identify the updated entities.
• The feed consumer will poll this SUP feed instead of polling individual RSS feed.
• The feed consumer will request only relevant updated feeds.

HTTP header If-Modified-Since does something similar. But, that would still means requesting for each individual feed.

The proposal looks good for both feed generators and consumers, and not very difficult to implement either. However, the format is too vulnerable to feature creep and standardization can be a painful process.

PHP Sucks, But It Doesn’t Matter

Jeff Atwood at “Coding Horror” – PHP Sucks, But It Doesn’t Matter:

Some of the largest sites on the internet — sites you probably interact with on a daily basis — are written in PHP. If PHP sucks so profoundly, why is it powering so much of the internet?
The only conclusion I can draw is that building a compelling application is far more important than choice of language. While PHP wouldn’t be my choice, and if pressed, I might argue that it should never be the choice for any rational human being sitting in front of a computer, I can’t argue with the results.

Blogged with the Flock Browser

Internet Explorer’s Trailing Comma Woes

Internet Explorer is notorious for breaking on trailing commas in JavaScript array declaration. e.g.

var obj = {
     a: 1,
      b: 2,
};

fails on IE, while all other browsers just ignore the innocuous trailing comma after second element.

Weeding out these commas from JavaScript code is absolute PITA. However, here is a regular expression search string I wrote to search such instances in the code.

,\s*\n+\s*[\}\)\]]

Even better,
,\s*\n+(\s*\/\/.*\n)*\s*[\}\)\]]
matches multiple new lines and comments.

Safari on Windows Crashes Too Often

I’m not much of a fan of Apple softwares on Windows. I like iTunes though, even if it’s a bit bulky. I’ve tried using Safari on Windows for its super pleasing font rendering, aesthetics and, of late, some testing on WebKit/KHTML. However, it crashes just too often to be of any serious use and, of course, doesn’t have any DOM inspector. It has a barely usable JavaScript console though.
On a side-note, I’ve read that Safari can work on Linux under Wine. I’ll give it a try sometime. Now, if only I could run iTunes under Wine .

Static File Retrieval From Web Server Quicker Than Browser Cache

It’s a small not-very-useful exercise, but, as the result is unexpected for me – here it is.

I’ve created a web page where two images are served as static files, and two images are served by a Java Servlet. The images served as static files (top two images) are cached by the browser for future runs.

The results are as following:
Jetty:

[Server]

[Cache]

Tomcat:

[Server]

[Cache]

The actual numbers are irrelevant, but the relative ratios consistently demonstrate that the web server “can” serve images much quicker (disregarding network latency) than the browser can retrieve them from cache. As expected, web servers serve static files quicker than they can serve Java Servlets.

Sidenote: damn, browser image resize is ugly.

Linus-logue

http://groups.google.com/group/fa.linux.kernel/msg/52f04d4ab1121c9b

From: Linus Torvalds
Date: Sat, 1 Dec 2001 00:58:03 GMT
Subject: Re: Coding style – a non-issue

Newsgroups: fa.linux.kernel

On Fri, 30 Nov 2001, Rik van Riel wrote:

> I’m very interested too, though I’ll have to agree with Larry
> that Linux really isn’t going anywhere in particular and seems
> to be making progress through sheer luck.

Hey, that’s not a bug, that’s a FEATURE!

You know what the most complex piece of engineering known to man in the whole solar system is?

Guess what – it’s not Linux, it’s not Solaris, and it’s not your car.

It’s you. And me.

And think about how you and me actually came about – not through any complex design.

Right. “sheer luck”.

Well, sheer luck, AND:
- free availability and _crosspollination_ through sharing of “source code”, although biologists call it DNA.
- a rather unforgiving user environment, that happily replaces bad versions of us with better working versions and thus culls the herd (biologists often call this “survival of the fittest”)
- massive undirected parallel development (“trial and error”)

I’m deadly serious: we humans have _never_ been able to replicate something more complicated than what we ourselves are, yet natural selection did it without even thinking.

Don’t underestimate the power of survival of the fittest.

And don’t EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That’s giving your intelligence _much_ too much credit.

Quite frankly, Sun is doomed. And it has nothing to do with their engineering practices or their coding style.

Linus

Jetty/JBoss Code Redeployment Slow on Eclipse

I’ve downloaded Jetty Server Adapter for Eclipse recently. Jetty is supposedly very nimble Java-based HTTP Server and Servlet Container. I’m not sure if I’m doing it wrong, but I find code redeployment very slow and buggy when using Jetty on Eclipse. Even Jboss, another heavy duty application server, is bad on Eclipse with 15-25 second redeployment time.

So far I’ve found only Tomcat to be suitable for development with almost instant redeployment.

Another nuisance is that Jetty relies on the presence of PID file ( on my RHEL 4.2) to determine whether it’s running or not, which is, more often than not, inaccurate as I usually close Eclipse without shutting down Jetty server. Tomcat is much more stable in that sense. However, Jetty seems much more exciting to develop “for” (as opposed to “on”) as it has continuations, a very clever hack/feature.

I suppose that the preferred way to develop on Jetty is to use Maven, and Jetty Server Adapter will improve with future releases of WTP/Eclipse milestones.

Google Chart API: Simple and Awesome

The Google Chart API looks to be the simplest way of generating high quality dynamic chart images for Line chart, Bar chart, Pie chart, Venn diagram and Scatter Plots. You just have to pass the chart data as URL parameters e.g.

http://chart.apis.google.com/chart?

cht=lc&
chs=200x100&
chd=s:ThisIsReallyReallyCool&
chxt=x,y&
chxl=0:|Apr|May|June|1:||666+KB


would produce this chart -