soledad penadés

repeat 4[fd 100 rt 90]

In almost every programming language, parsing errors tend to be boring, and PHP is not going to be an exception… unless you get one of these:

Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM

If you aren't aware, what it means is "Oh, there's an unexpected double colon where it shouldn't have appeared".

But even if it's a bit obscure, sometimes it's funny to get this error. Just for contrasting with all the plainly boring rest, like unexpected '}', unexpected ',' … all that. Even more funny is that those characters ('::') are also defined as T_DOUBLE_COLON. But why did the programmers decide to use the cryptic error message is something of a mistery for me yet.

The first time I got the error I thought I had found an easter egg! Either that, or the php interpreter had gone nuts…

According to this document at Mozilla Developer Center, Javascript 1.5 has been implemented in a browser since at least the first releases of Mozilla as open source browser, which means, in other words, since around 1998. Let's assume it was 2002 which is marked as the release of the 1.0 version.

And I was doing some interface programming lately and I needed to check if an element was in an array. Went to Gecko's documentation (that's the one I normally use, since it's less overbloated with crappy ads) and checked that Array objects had an indexOf function. Cool! I used that function on my code. Then once I finished with all the development, went to The Horror (i.e. Internet Explorer) and tested it.

Surprise! It was broken! What had I done? (You know the debugger for Internet Explorer is not specially helpful)

I suspected of the indexOf function, and recalled vague memories about doing a custom search function in the past for looking into arrays and not having to write a for(i=0; i<ar.length;i++) thing each time…

Mmmm… did a alert('Array.indexO') in ie and what did I get?: undefined

So they have been spent five years for releasing ie7 and still they didn't implement Array.indexOf!

No worries, though. Javascript is flexible! Look, IE, I don't care if you choke on the mere seeing of indexOf, you're going to run it whether you like it or not!

	if(!Array.indexOf){
	    Array.prototype.indexOf = function(obj){
	        for(var i=0; i<this.length; i++){
	            if(this[i]==obj){
	                return i;
	            }
	        }
	        return -1;
	    }
	}

and voila! my script wasn't broken anymore!

I have been doing some RubyOnRails stuff lately, for fun basically. I decided to build my new site (supersole.net) with Rails, and I also decided to use the shiny REST stuff which comes built in with the latest versions of Rails.

But I don't know if it's just me and my (mis)understanding of how this is supposed to work, but I'm fighting with the framework more than desired. The main problem is not with REST, and is not with caching either, but with both at the same time.

I have a controller (PostsController), whose index action takes care of showing the latest posts if an html response was required, and the RSS feed if the rss format was required. Until here, it's all fine, I set :cache_action to :index and it was generating beatiful posts.cache and posts.rss.cache versions. The problem came when I decided to add an "archive" view of the index page: it would allow me to show a list with all the posts in the site, using a url like /posts?type=archive. In the code, if type==archive, it would retrieve every post and show only the titles plus a link; in any other cases it would have the normal behaviour.

Ahh but how to discern what to cache this time? If I visited first the archived version and then went to the non-archived view, I found the cache was showing the same contents for both /posts and /posts?type=archive. The feed was correctly cached, though.

Then I switched to manually cache the fragments, specifying the type (archive/index) and the request format (html or rss) as params for the cache, but with no luck, since I couldn't find a way of caching the rxml output, although the different html versions were working well in this case, with two different versions being generated.

It could be a bad approach on my side, also. Maybe I'm putting just too much logic into what should be a neater function. The only idea that comes to mind is a PostsArchive resource which would show all the posts and could then be easily cached (would be just a single page!), but it looks a bit exaggerated to create a new Controller just for showing a listing of posts, since in fact it is simply another view of the same resource.

Again, I understood that the philosophy of REST in Rails was to have many simple controllers rather than a handful of complex controllers, and while I am all in favour of that concept, it is still a bit complicated to put those little controllers in place in a meaningful way.

Some years ago, a guy which wanted to communicate with his scientific colleagues decided to create a mark-up language called HTML, with additional stuff, which proved to be quite useful later on, such as the HTTP protocol. Surprisingly for them, these tools came to be very popular, even if (or because) they were quite loosely defined and far away from strict.

Since there was no authority for ruling what should or shouldn't be allowed in it, big companies somehow began to add new features to the language, because they wanted their own products (browsers!) to do funkier stuff than their competitors' products. So if one added BLINK, the other one added MARQUEE, the other one added FONT and so on.

Meanwhile, or maybe at the same time, an abstract entity called W3C was created. Or maybe it existed before! Anyway, although they attributed themselves the maximum authority over all-things-WWW, they were mostly ignored by both software vendors and HTML publishers. Publishers kept doing their loose stuff (if it works why should I change my way of doing things?) and vendors kept developing browsers which tried to fix publishers errors so that pages could be rendered even if they deserved to win one of those WTF!? prizes.

Some time after, people got concerned about the situation. Somebody thought Hey, all of this was meant for communicating but we are actually making it harder to communicate! We need to be serious about this!. And they decided to push for Standards to be used.

"Standards" is quite an abstract term as well, but has proven to be very productive and led to lots of literature, conferences and even job titles. All of a sudden and along with the blogosphere explosion, masses of bloggers began to discuss about Standards, the need for using them and the best techniques for each use. Actually, there was just a handful of people leading the masses, which diligently contributed to rolling the standards snow ball by copying and pasting and trackbacking and pinging to the leaders' blogs, so that they could label themselves with a "I'm a standards developer" in their sidebars, along with a long list of links in the blogroll (including at least one link to A List Apart) and a couple of 88×31px icons proudly proclaiming they passed a syntax validation test.

Parallel to all of this were the normal people which saw themselves in a transition phase where developing desktop applications was a no-no and the general trend was to have a web client interface plus a web server. Some of them just sticked to whatever they found handy, like using tables for laying things out in their application. Some others tried to make sense of all those things which they read in the forums and blogs in the outside world, but it was all too late. It had gone crazy!

When W3C saw their little children going with big bad boys they decided to prepare a long list of directives, working drafts and normatives which they should follow if they wanted to be good and be amongst the golden top of good formats, but they kept being loose and indeterministic, making it harder for developers (instead of easing the process of creating good mark up). More literature about standards was generated, this time resurging in differently flavoured waves: now worried about usability, now accessibility, then XHTML, then XML, then XSLT, then something else. Everything was OK as long as you were worried about standards.

And concerned about standards people, seeing the slow reaction ability of W3C decided to create their own groups, like WHATWG and WHATEVERELSE (joking). Vendors sometimes belonged to both (W3C and independent groups), making the whole thing even more complicated because… who are you going to listen to?

Developers tended to position themselves in two groups:
A) the ones trying to make sense about standards. Spending too much time trying to make sense of technical documents which were too many years in "draft" status, while vendors had implemented them however they felt was more convenient, years ago.
B) the ones which completely ignored everything, to the horror of group A

Group A believed group B weren't professionals and Group B believed group A spent too much time fixing the errors of others and fussing about abstractions instead of focusing on getting the job done.

And both were right.

If you want to have a developer title, stop creating abominations. Producing invalid code which renders badly in serious browsers is like being a C++ developer and producing code which leaks memory like crazy and then asking the operating system to clean up after your horrible code. You should be kicked out of the profession!

But on the other hand, being a developer doesn't mean one needs to devote all of the precious [free] time to learn about browser render errors, hacks, different box model theories, and so on and on. Being a developer means one wants to develop, not fix what is inherently wrongly designed (unless one gets to work in one of those projects, that is). Developers are here for the business.

What are you here for?