Firebird, bleh [en]

[Version française]

Almost everyday, I read someone saying "why would someone still use [a suposedly abandoned] IE when he could indeed use a [supposedly better] Firebird ?".

Hold on guys... you know brainwashing may not be the best way to evangelize, right? ... and could we at least try to sound a little less naïve?

I'll tell you why: because, as of today, Firebird is just a prototype, far from offering the usage comfort IE does! :(

Firebird may be good at respecting web standards... nevertheless pretty poor at respecting windows standards. And the sad thing is, the average user reacts to that! Even unconsciously!

For example: while Windows menus look "outset" by default, Firebirds menus look "inset"; toolbars cannot be moved (I'd like to have those links in that wide empty space right to the menu); the windows resizing handle is invisible; etc... globally Firebird really doesn't fit into the OS it tries to conquer...

Add all those annoying details like the ALT texts not being displayed (even when no TITLE is specified) or the insertion point not being blinking whenever there happens to be an animated GIF on the page... and you'll probably understand why Firebird just doesn't feel natural to plain Windows users. (Not mentionning incompatible javascripts...)

Don't get me wrong, I am *not* saying that IE is the best browser. As a developer, I favor Mozilla... but as an end user, I definitely favor IE! By the way, as an end-user, I really don't need to open 30 pages simultaneously that often... thus, not even needing tabbed browsing that much... ;D

(Once again, don't get me wrong: I think Firebird has a great future and can't wait to see if the next versions get better on these flaws... but it just isn't ready to seduce the Windows world yet!)

Date Arithmetic With MySQL

MySQL offers pretty useful functions when you want to manipulate days:

  • You can add a time interval to a date value with ADDDATE() or DATE_ADD()
  • You can subtract a time interval from a date value witf DATE_SUB()
  • You can find the interval between two dates with  DATEDIFF()

It's often easier to compute this stuff directly in MySQL rather than in PHP.

For all date functions see the MySQL Manual.


We used to have an article here about styling textareas with CSS in IE. It was one more post on the web about one more bug in Internet Explorer 6. It has been fixed in between.

In case you still need this, we had a workaround which consisted of applying width:100% on a div around the form, like this:

<div style="width:100%">
    <label for="t1">Try to type in here:</label>
    <textarea id="t1" style="width:100%">Try to type here!</textarea>

Web application caching

Blogs, as most current web applications, need to address the server-side caching issue in order to reduce webserver load.

It looks like most people are quite happy with caching static versions of their pages for some defined amount of time. This method has often been called something like "half-baked/half-fried" in reference to the long running baked (static) versus fried (dynamic) discussion.

I'd actually call it "baked on demand"... but regardless of what name we use, I would not be satisfied with this.

I have actually done some experiments caching my blog homepages which is enough to significantly reduce load, but this really makes them too static for me. I do want to log some stuff in realtime, I do want new user comments to show up instantly, and most of all: I do want the page to be customized for each user: display new posts since last visit, display his personal choice of categories, etc... Caching a whole page for every possible combination seems plain stupid. (And it is! :>> )

Actually, the only smart caching mechanism one can be satisfied with in high-end web-applications is block-caching. As a matter of fact, a web page can actually almost always be considered as an assembly of different blocks. Some are static, some are dynamically updated several times a day, some are related to the user himself and some are so dynamic they change everytime the page is displayed, no matter what! By caching each of these blocks individually when it makes sense and rebuilding only those necessary at a given time, you can then reconstruct your whole page dynamically significantly faster than if you had to reconstruct all blocks from scratch every time.

And there you have it: performance and functionality. Yeah, Okay, I know... it's also much more complex to implement than any other caching mechanism... ;D

Unsubscribring from spam *STILL NOT* ;)

Following up on wether or not to unsubscribe from spam, Cédric [site gone] adds some clarifications:

I am talking about the particular case of a spam email that defeated my filters and ended up in my Inbox. This is the one I want to get rid of. I don't care if more spammers end up getting my email address this way because their spams will most likely join all the others in my Spam folder (I suspect the success rate of my various filters is about 99% these days).

Very interesting point! Unsubscribing from those particular spams that pass the filters makes total sense and may succeed in getting less visible spam... but still, I'm not sure: what if they resell your qualified address to 50 spammers and 10% of them use clever spam filter defeating techniques? You run the risk of replacing one known spammer by 5 new spammers.

But I must admit: I'm far from conviced myself that 10% can really make it through the filters! :.

What puzzles me more is this:

[...] we are fighting a different war on spam these days. The goal is no longer to eradicate spam (this will never happen) but simply to acknowledge that spam is a reality and therefore, do your best so that its nuisance is limited to a minimum. In other words: design excellent spam filters.

=> I think that filtering is only the worst solution we have found so far: all the extra spam we allow to generate but don't see in our inboxes still harms network and mailserver fluidity... sometimes a lot! So replacing 1 unfiltered spam with 50 filtered ones just doesn't feel right to me...

...and I'm so glad I'm not administering mail servers any more :>>

Actually, we're all bearing the costs generated by all that spam on our networks! So we really may want to think twice before we promote any behaviour potentially allowing for (even slow) exponential growth! |-|