Nerd Life

mySQL has been planing to implement stored procedures and triggers in mySQL 5 for some time now...

But lately, it looks like it's just gonna get better than expected...

Via Simon Willison (great blog!), from chromatic's wrap-up of OSCON day 3:

Brian Aker, fresh on his new job as Senior Architect at MySQL, shocked the world (or, at least, me) when he announced that he'd embedded Perl in MySQL and was using it for stored procedures a couple of years ago. Of course, it did segfault rather often. Fortunately, it's highly mature now. In his talk on "Making MySQL Do More", Brian showed the embedded function API. You can write new functions for MySQL in Perl, Python, PHP, and Java. (Keep asking him about Ruby.) You can link to C libraries; he's used Image Magick and zlib. I'm excited about how easily you can modify queries — SELECT DIFF(foo) ... anyone?

However, if mySQL alone gets that interesting, I wonder what are they going to do with SAP DB ? Weren't they planing on merging both databases somehow?

Anyway, the real question is: how long is it going to take again for hosting companies to offer mySQL 5 as a standard feature on their hosting plans... :?: Most of them still run the ridiculously dumb 3.23 version! Even worse, most customers seem to be happy with it!

Isn't this ironic, on one side databases are becoming a commodity and on the other side, people think being able to INSERT / UPDATE / SELECT (if not just SELECT) is all you need to call something a DBMS...

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.)

-Joel on Software

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%">
  <form>
    <label for="t1">Try to type in here:</label>
    <textarea id="t1" style="width:100%">Try to type here!</textarea>
  </form>
</div>

Looks like the Echo Project Roadmap is getting a pretty wide acceptance in what we probably could call the ~`blogging industry'~ by now.

I definitely plan to support Echo in b2evolution... RSS has been such a mess for such a long time... something really has to change...

(I hope they'll move this project to some decent place though... the project is still small be the Wiki that hosts it is already a headache to navigate... :>> but I won't say more on this... since it's been up for 3 weeks now I think and I still haven't moved on with the new b2evo website :. )

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