About this blog

Having just moved this blog to a different platform, I realize that this blog may set the wrong expectations. So in case you were wondering, here is a little background.

This blog has been started when I was freelancing under the "stage name" of "WebPro Development". Most articles and comments written by me before the end of 2007 represent my tech-related findings that I meant to share either with my clients or my coworkers back then.

I find some of the articles outdated and some representing old views that have changed. Please mind the date of the posts.

And thanks for checking out this blog!

loop... until in Java

In case you are wondering where's do-until (or loop-until) in Java, you might want to remember that

loop {
...
} until (condition);

tastes just the same as

do {
...
} while (!condition);

parseInt returns 0 or weird numbers

Here's a time waster. Why would JavaScript's parseInt return 0 when you pass on a string like '08' ? Or 668 for '01234' ?

The reason is that the 1-parameter version tries to do it's best to figure out what radix you are using for your string. So you can have 0xCAFE for a lovely hex number (that can also wake you in the morning :) ). Guess what 01234 is ? It's an octal number because it starts with a zero.

If you want '08' to be 8, you can use the second parameter of parseInt which is the radix for the conversion.

Good luck!

PHP ghost array item at index 0

Here's a copy-paste that boiled me for some minutes today (in collaboration with PEAR's Mail and Mail_Mime, but it wasn't their fault):

$something = array(
'key1' => 'abracadabra',
'key2' => "Some longer string, {$somearray['somekey']}", $scalar,
);

All in all, there was a ghost item at $something's index 0. Yep, in my case above, $something[0] == $scalar.

So here's the lesson: if an item shows up at index 0 in a PHP array where you defined key=>value pairs, you probably have a value running loose somewhere in your definition...

DON'T! Just don't! (wild queries gone bad)

If you have a Roku SoundBridge, you'll probably find Radio Roku interesting. It's a great product, but however, the "radio roku" is an extremely slow website. Today I have searched for stations playing "electro" music and here's what I got:

Error SELECT stations.id AS id, stations.name AS name, stations.rating AS rating, if(stations_rank.id is null, 1000000000, stations_rank.id) AS rank FROM stations LEFT JOIN countries ON stations.country = countries.id and countries.languages_id= LEFT JOIN languages ON stations.language = languages.id and languages.languages_id= LEFT JOIN genres ON genre = genres.id and genres.languages_id= LEFT JOIN stations_rank ON stations_rank.stream_id = stations.id WHERE (name like '%electro%' or description like '%electro%' or location like '%electro%' or genres.value like '%electro%' or countries.value like '%electro%' or languages.value like '%electro%') ORDER BY rank ASC

Ok... so that's why the website is moving soooo slow. Here's a practical list of "don't do this" from a single query:

• model logic in data retrieval: if(stations_rank.id is null, 1000000000, stations_rank.id) AS rank. You should avoid this. It's much better to calculate this as an additional field and not to do an evaluation every single time you retrieve results (especially as this calculated field is probably required in looots of listings, what if you want to change this logic?). Also try to avoid SQL constructs specific to a database engine, in this case IF(cond, a, b). Well, if you'll live all your life in MySQL you may use some functions, ok...


• order by calculated field: ORDER BY rank. Makes any query cache useless and is not properly indexed by most engines.


• field like '%value%'. Never use this on a table larger than 1000 rows that you care about. If on MySQL, try the fulltext indexes available on MyISAM. If not, use a solution for a similar fulltext search.


• condition_on_field1 OR condition_on_field2. Most likely it won't be indexed.

Ok, so why would we care? Because of scalability. We want those tens of millions of users hit our application and browse those pages and do this and that. And we don't want a datacenter just to handle their simple queries (which is the other solution for badly written queries).

And of course, we all want to sell. Roku has a couple of very good under-promoted audio players (SoundBridge and SoundBridge Radio are brilliant, probably except for a minor glitch with AAC streams). If I would have seen radioroku.com before the product, I'd think "neeah, that's too slow"...

E4X's double dot operator

ECMAScript 4 (currently implemented in ActionScript, but not directly in web browsers which are still dealing with ECMAScript 3 incompatibilities) has a couple of very neat power-features that will save some lines of code, especially when using the E4x extension (ECMAScript 4 XML).

One of them is the double dot (..) operator. As in

myElement..subNode

This is an array of all "subNode" children below myElement. For a Canvas, myCanvas..Label will be an array of all the Labels in your canvas. Neat, huh?

How about the .@ operator? As in...

myCanvas..Label.@(thisXML.@id == "1234").text

This will help you select directly the first Label with an attribute of id equal to 1234.

It does not sum up!

As I recently discovered there are a lot of mature frameworks used in Java and other languages, I have considered leaving PHP behind and focusing on other language and possibly one of these frameworks for the next period.

A part of my research (which has not reached a decision!) was to compare a list of languages and database engines. Starting with the latter, which I've recently tickled in this article:

Hmmm... descending trends overall... how about scripting languages?

Hummm... descending again.

Google Trends is limited to 5 items per graph, so I left Ruby out, it's somewhere around Python, but the trend is just the opposite (it's slightly over Python since mid 2006 - well done, Rails! - and it's an overall growing search term). It's not a boost though.

There is a descending trend for searches on all languages (just search your favorite!) and database systems. I can only see two possible reasons here:

1. people know all about them, don't need to search (I will need 3 pints of Guinness to believe that)


2. people are less interested about them

Let's see how PHP stands in comparison with a few popular applications written in PHP: Joomla, SMF and phpBB.

Is this what we're missing? People are adding a new level of abstraction and being interested rather about frameworks and applications they can build on top of web languages instead of knowing the language itself?

If this is true, web programmers knowing the core languages will be fewer and fewer, there will soon be openings for "Joomla programmer" or "DJango programmer" or "Rails programmer" (Joomla has a framework too) and we will see a lot of unexperienced people doing easy routine programming jobs and finding a great challenge creating a simple database structure for a product listing site that does not run Rails or Joomla.

(which reminds me that I was bulkly invited earlier this year to become a SAP consultant for a company that scheduled 12 interviews in 2 hours, go figure what a coffee-drinking career I have missed!)