Rails/MySQL surprise of the day: WHERE clauses on VARCHARs are not case sensitive by default

Ran into a totally from-left field bug today, and was surprised to find that WHERE clauses against VARCHAR fields are totally case insensitive. So if you have two rows in table FOO that have values "Bar" and "bar", and you run SELECT * FROM Foo WHERE FIELD = 'Bar' -- you will actually get BOTH 'Bar' and 'bar' rows returned.

Now there are ways in which you can set a particular column to always be treated in a case sensitive manner.

But the simple/braindead fix to make your query case sensitive is to use this instead: SELECT * FROM FOO WHERE FIELD LIKE BINARY 'Bar'  -- running that will cause case sensitive behavior to occur and only one row to be returned.

And knowing is half the battle.

Haskell Hackers vs Blub Java Engineers

If you post an advert for a Haskell developer you will get 20 applicants. All of those people will be the kind of developer who learns new programming languages to improve their own abilities and stretch themselves, because nobody yet learns Haskell just to get a job.

If you post an advert for a Java developer you will get 200 applicants. Most of them will be the kind of developer who learned Java because there are lots of Java jobs out there, and as long as they know enough to hold down a job then they see no reason to learn anything.

If you're a 100% Java coder, you'll always have a job, and there are legitimately interesting things that are happening in the Java world... but its pretty far from a majority in any sense. The problem with Java is that there are too many jobs that only need passable engineers. There are too many Java engineers who are plug-and-chug.

It's all about the hobbyist languages. That's where the magic happens. If you're a Java engineer, you should pick up Ruby on Rails at least -- it'll be a breath of fresh air.

Javascript super killer tip: Always use innerHTML if you have no JS lib and it has to work in IE.

Recently while writing some features for Posterous, I ran into a super simple but insanely annoying bug where IE fails to properly pick up id and name fields when creating new DOM elements in JavaScript using document.createElement().

Internet Explorer completely fails to add created DOM elements to the lookup table of named elements as targets. If you generate an iframe and want to POST to it from your programmatically generated FORM tag (by setting TARGET="your_new_element_name"), you're out of luck and IE will try to create a new window instead.

InnerHTML to the rescue. The abomination of standards that is innerHTML works pretty well across all browsers. John Resig is so right when he says the DOM is a mess. Thank god for things like jquery.

Developing Flash? Sick of the browser caching your newly published swf file? Turn off that cache.

Uncheck "Store common Flash components to reduce download times" in your Adobe Flash Player Settings Manager. I was getting sick of having to rename my flash swf file / try to reload my browser cache.

Strangely, the best way to get to the Flash Player Settings Manager is actually through the official Adobe website's help page, by clicking here.