Learn to Read Graphs or Go Home

(this is a rhetorical post to Code Hard or Go Home, ’cause the amount of bullshit in the post is so much that you can call it almost a “cesspool post” instead of “blog post”)

There is one thing I really don’t like: Percentages, because it’s so easy to mess with the information in a single message. If one product suddenly jumped from 10 users to 20, you can clearly say that it “had a 100% grow!” and call it “the fastest growing” product in its niche. Sure, the other brand with 100.000 users will have a hard way to debunk that, as the message is, for all cases, right.

The other is graphs. Because they show, in a nice way, number without reveling what they mean.

Like the ones John Siracusa used to veiled show that Chrome is better than any other browser.

But let’s break this to show how much bullshit there is in that so you can tell this guy to join Atwood and Jeremy Khan and move to farm and stop spreading misinformation as fact.

The first thing wrong, right out of the bat, is how he portraits Open Source communities[1]. You can pick any other open source project, Python, GNOME, KDE — you know, the ones that basically wrote the story on how to open source projects — and see that, way above every project, there is a leadership (Python have Guide, GNOME have the GNOME foundation and KDE have the KDE foundation). Dunno about Guido, but the people in the GNOME foundation, which drives the force behind GNOME, organize, divide resources, help developers with timelines and give some ideas on how to proceed in the next version but they barely do any changes (those are left to the developers themselves). And they still manage and “own” the project.

(I know, for a fact, that Guido reviews a lot of PEPs and give opinions about those, but I’m not quite sure how much “changes” he does in the Python interpreter these days, so I’ll keep that out of the discussion for awhile. And feel free to correct me here.)

The second wrong thing are the graphs, with wild claims about what they mean. I’ll prove this by reading the graphs in a complete opposite way: If you look at the second graph, you can see that Google have a huge turn-around of developers, while the number of people working on WebKit at Apple is almost steadily. This means that the Apple team probably knows the code a lot better than the Google team.

Stopping here for a second just to say that I, too, can be completely wrong: Apple could have a constant turn-around of developers, keeping the number of those almost the same during all the time while Google may have a core of developers who drive the most of the “Android Green”[2] team. Just saying that to point that, absolutely, this guy needs to learn how to read graphs, ’cause those just tell about numbers and not what those mean.

Now, back to the first graph (which blends with the paragraph just above it): Google had more commits. This means they contributed a lot more, right? Well, if that’s the fact and Google really “contributed” to the project, why the WebKit devs claiming they can finally get rid of code that is specific to Chrome? This may actually mean another thing: Google was already fucking with WebKit to do what they want instead of play ball with all the other developers. In that case, the WebKit developers are more into “open source” philosophy than Google, ’cause they accepted things they wouldn’t need just to keep the ball rolling.

And stopping again to prove the point that that’s what I’m reading and distorting to prove my point that Google is the bad guy in this instead of going after the facts. It could really be that Google, while adding new features, had to open space for its own extensions. But I could also point that, just a few paragraphs later, John points that Google didn’t play ball with the open source community when they decided to not to contribute the multi-process architecture back to WebKit. So I can, once again, point that Google never really did embraced the open source nature of WebKit and was, all the time, just fucking it up.

“But I look at those graphs and wonder.”, he says. Well, yes, I look at those graphs and wonder: Do you have any idea of what you’re talking about?

And then there is the anecdote of Safari crashing more than Chrome. Well, fun fact: I thought ArenaNet botched a patch and was constantly sending reports and was almost furious that they never fixed. Then the NVidia settings panel crashed and I realized it was my system that was botched, not the game. I can also add that, along with Safari, in this year Pwn2Own, Chrome was the first browser to fell (with a bug that they don’t to tell anyone and sell to be exploited around); Firefox fell only on the third day. So yeah, I can claim that while John keeps pointing that Chrome is super-duper secure, Firefox is light years ahead ’cause it took longer to crack and, then, this whole debacle is pointless and Firefox clearly won.

But, then again, I’d be doing slight distortion of facts just to prove my point. Exactly how John did with his whole post[3].

But why do I mention the story of my botched system? Because your Safari crashing more than your Chrome means absolutely nothing. It could be a gazillion different things that prove absolutely nothing. The guy could be running Safari with extensions (yes, they exist) and Chrome with absolutely nothing and the extension is preventing Safari from running flawlessly and the pages stop responding to protect the browser itself. It’s like people that claimed Firefox was slow and bloated compared to Chrome, when they had a pristine copy of Chrome while their Firefox had more than a dozen extensions.

And I can cite again, using John words, that if Google was really into open source, they wouldn’t refuse to contribute to the multi-process architecture and Safari could have better protection. But hey, they didn’t and you have to ask what was the point of the claiming that “Google chose to participate in the existing WebKit community” when they clearly didn’t.

You know, for a guy with a blog titled “Hypercritical”, this guy is pretty full of bullshit instead of being critical to his own writing. Maybe it’s a sarcastic title, meaning people that read that are not really critical…

Edit: Forgot to mention this: If the Google developers have “already proven” they are capable, why does Chrome is second in number of hacks inside jQuery, just after IE? This just helps my point that, since the start, Google was just fucking with WebKit code.

Still edit: And just breaking this paragraph to point that this doesn’t mean your choice of browser is wrong. The fact that Google seems incapable of being a real open source contributor (which is more than just “post commits with code”) doesn’t mean the feature you really like in Chrome is bad and you should feel bad (in Zoidberg voice). It just mean that you don’t need to pick a graph, read it completely wrong just to have some affirmation on your choice.

[1] And I’ll give him credit for at least telling the correct story behind WebKit.

[2] Yes, I saw what you did there. It was not clever, by the way.

[3] And did that with a bunch of links, nonetheless, just to look like a Wikipedia page and give some street cred to the post (including an “already proven” link that actually just goes to the Chrome page without proving a damn thing!)

I Don’t Support a WebKit Monoculture Deux

Things in the internet space are weird.

First you have a guy telling that he would support a monopoly in the browser market (which I fully raged against). And then, out of nowhere, one of the jQuery guys come out and tell everyone that they are tired of doing hacks to avoid WebKit bugs — which finally sparked the Chrome/WebKit team to fix said bugs, which was even celebrated by John Resig himself.

But the thing is: Ok, the WebKit team fixes the bugs. Does that mean that they can simply remove said hacks?

The answer is a loud “no”. Because WebKit is not a single browser; it’s four, with a fifth coming around. Chrome, Chromium, Safari for OS X, Safari for iOS and, soon enough, Opera (and we still need to see how many versions of it will appear — although I believe that there will be at least a desktop version and a mobile version).

If tomorrow the Chromium team releases a WebKit version with all the fixes, will my Safaris (iOS and OS X) finally be updated? I don’t think I need to answer this, right? This just proves how “not smart” (to play nicely) the “WebKit monoculture guy” is: The fact that it’s being support by two different companies, with two different release timelines, is actually creating a fragmentation of the WebKit market (something that you should be used to if you use any Google tool, apparently).

I’m not a full time hater of everything WebKit. Firefox got a lot better since Chrome showed up, but the fact that some many people are brown-nosing it is simply sad. Chrome had some good ideas, but it’s far from being the “awesome browser to rule them all” like everybody is claiming.

I Don’t Support a WebKit Monoculture

So there is this post by Jeremy Khan about his support for a WebKit monoculture. The whole thing is so retarded and moronic it’s not even worth reading, but I did and now I’m in full rage.

Let me explain why this is stupid:

Strong Corporate Leadership

This is cited twice in the post and, honestly, it may actually be a bad thing instead of good. Say, one of the things that annoy me is the number of people who claims they wrote a “pure CSS counter in HTML5″ but the thing only works on Chrome ’cause the moron added a bunch of non-standard “-webkit-” tags. Now, testing tags before they are fully approved and documented by W3C isn’t a bad thing per se, but the browser shouldn’t expose these things to the user unless they are actually developers trying new things. So I go and write a patch to force non-standard tags to be enabled only when the user selects so, and the default is Off (in other words, this would break every single site that wrongly relies on “-webkit-” tags). I’m pretty sure Apple and Google won’t approve it because, well, they are really interested in showing their sites in most snazziest way possible (Apple more than Google, but you get the idea).

Second, he cites “strong corporate support” for the rapid release cycles. Well, Java have a strong support from Oracle and it doesn’t have a rapid release cycle, even when it strongly needs due the amount of security holes being found every day.

So we can scratch the idea that “strong corporate support” does anything good.

The Chrome Updater

I find it absolutely retarded that he cites Chrome updater as a good thing. It’s one of the most atrocious, retarded things I ever had to deal with as a user, because it simply runs. You’re in the middle of your WoW raid, WoW is the only thing running and BLAM! download goes without you asking for it (and there goes you latency too, depending on were you leave).

Personal anecdote, one time my ISP crapped itself and I had to quickly check my emails to write down the address were I had an interview. So I did some tethering and off I went to Gmail. And it took way too long to answer. WAY too long. To the point that I was getting in the “fuck, I’ll be late” zone. That’s when I realize Chrome Updater was running and downloading a new version of Chrome. Did I ask for it? No. Was I informed about it? No. Now, the real kicker is this: Was I using Chrome? NO! Why was that thing updating something I wasn’t even using at the time? It’s ok to download in the background while it’s running, like Firefox does, but when it’s not even in memory is completely retarded and the guy who came with that idea should be taken outside and shot, to serve as an example for the others.

It IS IE6 All Over Again

This argument is going around for a while and, again, it’s true: Chrome/WebKit is the IE6 of this generation. Why? Because it exposes a bunch of non-standard (or, better yet, non-standardized) tags without telling anyone about it.

Don’t you remember the number of “Chrome Only” sites that appeared a few years ago? Why do you think there were “Chrome Only”?

That’s the whole fight we had when IE6 was king, not about “ActiveX” or anything (we can compare the ActiveX problems with what the Java holes are today, if you want). It was the fact that IE6 had some ideas about rendering stuff that were not defined as standard that broke everything and made life as a web designer a hell.

(And, for the record, so should Firefox and their “-gecko-” tags — or whatever they are these days.)

Chrome Does Not Have the Best Tools

He cites that Chrome have an awesome developer tools. I disagree. Firebug have a cleaner interface and more direct access to things, compared to Chrome. Firefox is slowly backporting those things directly into the browser itself, with a better looking tools.

Also, if Chrome had such amazing tools, Google wouldn’t feel the need to hire the guy who was writing Firebug.

Let’s Kill One and Keep One

And this, ladies and gentlemen, is where we need to get this guy and put a ban on his use of anything electronic: Kill Gecko and put them in the WebKit dev team because Gecko is “old”.

Kids these days, I tell you: If something is old, it means it found a lot more problems that your new, shiny thingy. It has covered all the corner cases your project doesn’t. So I tell you: Let’s actually kill WebKit and move everyone to Gecko! Since it’s older, it has a lot less corner cases to fix! </sarcasm>

On a serious note, I won’t even get into the “mystical man month” argument ’cause that would probably be a too strong point for this fellow.

Are posts like this that make me feel bad that web has such strong presence everywhere. ‘Cause this guy works for YouTube and should know better how those things work. Except he doesn’t.

PS: Yes, it’s all personal opinion. Yes, it’s my personal opinion against his personal opinion. Yes, I still think he’s a moron.

TwentyEleven With Easy Rotating Header Images

I have a secondary blog which I wanted to have some special header images. One nice thing about the new default WordPress theme, TwentyEleven, is that you can have a couple of header images and rotate them randomly. A bad thing about the new default WordPress theme is that it’s annoying adding new header images.

At first I got this post about adding your own images. One thing I did a bit different was the way I was generating thumbnails with the same name of the image, but in a different directory. Because of that, all I really needed was the image name. Thus, my wptis_new_default_header_images() turned into:

function wptips_new_default_header_images() {
    $dir = get_bloginfo('stylesheet_directory');
    $headers = array(
        'image1',
        'image2',
        'image3',
        'image4'
    );

    $images = array()
    foreach($headers as $filename) {
        $images[] = array(
            'url' => "$dir/images/$filename.jpg",
            'thumbnail_url' => "$dir/images/thumbs/$filename.jpg",
            'description' => __($filename, 'twentyelevenheaders')
        );
    }
    register_default_headers($images);
}

This way, when I needed to add a new header, all I had to do was upload it to the theme package (with the thumbnail) and edit the $headers array to add the new filename.

But that was a bit annoying ’cause, well, I had to create the thumbnail, upload both the image and the thumbnail and then edit the function again. That’s when it occurred to me that I could make a page, add a gallery to it and then make the theme load the images from that gallery. That way, I could use WordPress itself to upload the images and let it create the thumbnails. The result was this:

function wptips_new_default_header_images() {
	$child2011_dir = get_bloginfo('stylesheet_directory');
	$images = array();

	$page = get_page_by_title('The Headers');
	$attachments = get_children(
		array(
			'post_parent' => $page->ID,
			'post_type' => 'attachment',
			'orderby' => 'menu_order ASC, ID',
			'order' => 'DESC'
		) 
	);
	foreach($attachments as $id => $info) {
		$image_id = $info->ID;
		$url = wp_get_attachment_image_src($image_id, 'full');
		$thumb = wp_get_attachment_image_src($image_id, 'medium');
		$images[] = array(
			'url' => $url[0],
			'thumbnail_url' =>  $thumb[0],
			'description' => __($info->post_title, 'twentyelevenheaders')
		);
	}

    register_default_headers($images);
}

After that, I created a page named “The Headers” and uploaded all images I wanted (following the guildelines of 1000×288) and let WordPress take care of the rest, including saving them on the server and creating the thumbnail. The thumbnail is a bit larger than the normal size, but that’s not a big issue IMHO.

Anyway, if you’re interested, here is the theme. Install like any other WordPress theme, but you’ll need a page named “The Headers” for it to work (or create a page and change the name in the code).

Your Editor Shows the Flaws of Your Language

In a recent update of Sublime Text 2, my programming editor of choice of these days (only ’cause I wanted a break from VIM, for the fun of having to learn how to edit things in the “normal person” way) got a “Vim mode” and I decided to enable all the other features, just for kicks. One of those features was the “auto close brackets” (or whatever name they call that these days).

The only thing I’m using the “auto close brackets” feature is to make sure all the mess with opening square brackets inside functions inside functions would have the proper closing element. It’s somewhat easy to get lost in a str_replace(' ', '', trim($param['string'])) line.

But that’s only one thing editors do that are only there to work as a “walking stick” for the language you’re working on.

  • Auto close brackets: As I mentioned, that’s because accessing most array elements requires at least two characters ("[" and "]") or 4 if you use associative arrays/dictionaries/objects. JavaScript does this right by not having associative arrays and making objects. You can kinda do the same with Python objects, but it feels somewhat wrong when you do have dictionaries. You can somewhat fix that with __getitem__ or just monkeypatching the dict object. But in some languages, there is no such option. Also, as you can imagine, the problem is “lessened” with languages where all the basic types are objects: instead of making function return the parameter of another function (like I did above), you simply call function and then the next function. The same example above in Python would be something like param['string'].trim().replace(' ', ''). This obviously reduces the changes of forgetting to close one of the parenthesis.
  • Snippets: Snippets are small pieces of code that you repeat most, but not to the point you can simply write a function to do such thing. C/C++ allow you to somewhat skip that by using macros but one must reckon that macro syntax is a bit cumbersome.
  • Templates: Templates are large snippets that encompass whole files. It seems templates are there not to just solve a language design problem, but a general “language design principle” problem. The most obvious example I can think of is using Eclipse to write a Java application to connect to a database. To do it so, it requires so much boilerplate that Eclipse itself offers a way to create the whole file to you based on a simple database definition.

I’m probably forgetting a lot more programming editors do these days just to cover languages’ asses here. But I guess you start viewing programming languages a lot different when you think any feature in the editor is just to solve a problem with the languages we use today.

Timely screenshots in OS X

Silly thing I did this weekend: I wanted to take some screenshots of a game I was playing, but pressing F12 (the Steam shortcut to take a screenshot) while pressing all other keys isn’t that easy. So I came up with this very small script:

#!/bin/bash

while True; do
	sleep $1
	file=`date "+%Y%m%d-%H%M%S"`
	echo "Capturing $file..."
	screencapture -x -tpng $file.png
done

I know I could use something like -T$1 to make screencapture wait till taking the screenshot instead of using sleep $1 but then the name won’t match the time of the screenshot (not that that would be a big problem, but I’m that kind of anal retentive).

Little Stupid CSS Insight Of The Day

Today, after fighting several minutes to understand why my form was not being send and then checking it with Firebug and seeing it completely broken (as in “the form had no inputs ’cause it was being closed right after being opened). I checked and rechecked my HTML for errors and nothing. Then I understood why.

This is a <div>. It works like a box (also, you’ll hear a lot about “boxing model” and such).
This is a <form>.
This is a table.

So, if you keep that mind: You can box your desk; you can put a box inside your desk drawers but you can’t cover your desk drawers with your box while putting both inside your desk. It doesn’t work like that.

Workaround for Broken ElementTrees

(or “Your broken XML broke my Tree!”)

Recently, I decided to parse an HTML file using ElementTree. Nothing fancy, seems most of the HTML is well-formed anyway. But (there is always a but) the source file I’m trying to parse starts with , have no and, for some reason, this makes ElementTree a very confused parser. And, by confused, all the elements, instead of keeping their original tags (e.g., table) have the prefix “{http://www.w3.org/1999/xhtml}” added to them (e.g., {http://www.w3.org/1999/xhtml}table).

Now, this isn’t purely a problem with ElementTree. If I save the file and use TextMate “tidy HTML” and run through ElementTree again, everything works perfectly.

Not only the elements themselves get weird, but ElementTree can’t use any special filters in its XPath search, like indexes (div[2]), or any attribute search ([@class="class"]).

The solution I found was convert the whole XPath (without any attribute search) to a longer form, which seems to work fine (it solves my problem), adding the “{http://www.w3.org/1999/xhtml}” to every element and doing the index search manually.

def _find_xpath(root, path):
    """Finds an XPath element "path" in the element "root", converting to the
    weird information ElementTree."""
    elements = path.split('/')
    path = []
    for el in elements:
        if not el.endswith(']'):
            path.append('{http://www.w3.org/1999/xhtml}'+el)
        else:
            # collect what we have, find the element, reset root and path
            this_element = el.split('[')
            # first part, without the 
            path.append('{http://www.w3.org/1999/xhtml}'+this_element[0])
            xpath = '/'.join(path)
            root = root.findall(xpath)

            pos = int(this_element[1][0:-1]) -1
            root = root[pos]

            path = []

    if len(path) > 0:
        xpath = '/'.join(path)
        root = root.find(xpath)

    return root

I reckon is not the cleanest solution and that I should probably use recursion somehow, but it works.

Improvement suggestions are welcomed.

A case against Twitter OAuth

It’s not a mystery that I have a problem with Twitter and their API. I never made that a “hidden agenda” of sorts: I always said publicly that they suck, plain and simple. Their API is full of holes, bad bad designs (like returning blocked content to the user and requiring applications to do their filtering) and they insist in aiming for new, stupid features while leaving a lot of bugs behind. Personally, I think their programme manager should be fired and get someone with at least half-brain to lead their development.

But there is one thing that is really annoying me as a user and they never tried to solve: Applications that require write access even when all they want is to read your data to do some calculation. Do they really need write access? No, they don’t. All they want is that access to spam your account without your consent. And don’t even tell you what they want to write on it.

Take, for example, this application (and I recommend you to not put your account info there). Simply put, it tells you who you’re following that are not following back (and who is following you and you’re not). All good and such but, in the end, it posts, on your timeline, a spam back to the site. In no point, the app told me that and in no point I was able to configure what kind of access I’d give to that app.

Not only they took away the user preferences over their own account, but the authorisation screen is so empty and devoid of information that it doesn’t even say what the application do, much less why it wants read or write permissions.

Unfortunately, I don’t think Twitter will ever fix that. Forcing applications to declare that they require write access to post spam (with any more “friendly” terms) would ruin their “ecosystem” and reduce the number of applications. At the same time, adding a preferences pane to the user account would be “unnecessary” ’cause applications should “behave”.

The demise of Mitter

The first post I can find about Mitter was in 2007, which makes it about 3 years old. It is one of my longest living personal projects.

Or better, it was. As for yesterday, I decided I had enough of it. So Mitter is, officially, unmaintained.

I posted most of the reasons for that in this blog recently. The biggest one is the way Twitter is handling their broken implementation of OAuth and making it hard for open source developers to distribute their Twitter clients. Second, which was the real “ok, I had enough” moment, was when I pointed that blocked users still appear in the timeline and got the answer that blocking should be done in the client side.

So you have a broken implementation of a security protocol and a broken behaviour, all in a small package. Even as a simple user, I think this is stupid, to say the least.

It’s not that Mitter is tied with Twitter. Since december last year, the network layer was redesigned to support multiple networks and I had plans to add at least Identi.ca and pave the way to a lot more. But, in the end, I got so burned out with the constant problems with Twitter and their general lack of interest in helping the small guys that I don’t want to make another application where I depend on someone that doesn’t give a fuck about what I write.

Also, it’s not that I hate Mitter now. I surely love it. Some of the best design decisions (and some of the worst too) I had I put there. I like the way the data flows in the application. I learnt a lot about Python and PyGTK with it. Even now, I look at the code and it looks pretty nice (so nice that I had to put a piece of the code in the header of my blog — although that piece doesn’t say much.)

But, in the end, it’s a matter of continuously dealing with bullshit. If at least I could make a living out of Mitter, I’d deal with it, as I did my whole life. But I wrote and kept Mitter on my spare time and now it’s not fun anymore. So Mitter is now orphan and unmaintained, but its source code is still available for anyone who wants to keep it going. I’m even here in case someone needs help understanding my design or needs someone to do releases.