Totally awesome. Must-read for any production Rails dev. Heiko Webers is totally
providing a huge service by compiling a comprehensive list of items to
check for.
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.
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.
via haskell.org
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.
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.
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.
