I just discovered that string comparisons in MySQL ignore trailing whitespace in strings, CHAR, and VARCHAR fields (but not TEXT) - in short, use "like" instead of "=" for literal string comparison.

The strings 'a' and 'a ' (same thing followed by single space) are considered equivalent by MySQL, because trailing whitespace is ignored. But leading whitespace is significant, so 'a' is not equivalent to ' a'.

Why?

This is the kind of subtle, no-idea-until-you-discover-it behavior that makes Perl suck, and I'm disappointed that MySQL has behavior like that, too.

Principle of least surprise, anyone?

mysql> select 'a' = 'a ';
+------------+
| 'a' = 'a ' |
+------------+
|          1 | 
+------------+
1 row in set (0.00 sec)

mysql> select 'a' = ' a';
+------------+
| 'a' = ' a' |
+------------+
|          0 | 
+------------+
1 row in set (0.00 sec)

Using LIKE is a workaround.

mysql> select 'a' like 'a ';
+---------------+
| 'a' like 'a ' |
+---------------+
|             0 | 
+---------------+
1 row in set (0.00 sec)

Got a question about vim pattern matching that I had to look up, probably worth sharing.

Say you have the following text, and you want to modify the quoted things, so you start with this:

blah blah blah "BLAH" blah blah "FOO" blah blah

And want to end up with this:

blah blah blah <"BLAH"> blah blah <"FOO"> blah blah

Run this:

:%s/\(".\{-\}"\)/<\1>/g

I expected ".*?" to work (valid Perl regex syntax?), but ultimately found ".{-}" worked with Vim (and don't forget to escape the "{" and "}" characters, so \{ and \}).

Wtf is up with so many dev tools using auto-complete, suggestions, tooltips, etc.? Seeing all of these "helper" add-ons really makes me depressed that developers are asking for (and using!) these "features". If you're working with SQL, shouldn't you know the syntax of an insert statement? If you don't, and rely on the tool to guide you through it, maybe you shouldn't be writing SQL at all. Perhaps I'm just a bit of an old school purist, but having all of this automatic bullshit is like constantly reminding a carpenter about basic stuff.

"This is a hammer, hold it like this, ok?"

"That's a mitre saw! Be careful!"

Tips such as these are only relevant if you're a shitty carpenter, and the same goes for dev tools.

If I'm going to be badgered, I want useful tips.

For instance, run static analysis to tell me I've got a potential deadlock scenario in my code.

Or make observations about layout and suggest a design pattern to improve organization.

Or highlight certain methods (or blocks of code) that are fully self-contained and amenable to writing unit tests, thereby encouraging me to do something useful and beneficial.

But instant activation of all possible keywords in a particular context? "Here are 20 things you might want to type now..."

Come on. That's not useful, and it's faster for me to just type out what I want, rather than scroll through a tiny little context menu looking for the answer. That's really my complaint. These "features" are intrusive, inefficient, and encourage people to blindly rely on them without learning (and using) the basic skills of the trade.

I wonder how detached developers will be in 20 years. I imagine they'll be using some insanely abstract high-level language where the author has no idea what the hell is going.

I tried vi integration in Eclipse a long time ago, gave up because the integration was crappy. I don't remember what I used. Anyway, I just checked again and found Eclim which has great features. It doesn't hurt that it's free + open source, unlike viPlugin which costs 15 Euros.

Update: I finally managed to get Eclim sort of running on my Mac. After wasting time to discover that the Eclim installer didn't recognize Mac Vim, I downloaded Vim source for unix and ran configure + make + make install, then the Eclim installer let me proceed. So I started eclimd but the first test failed, I cannot run :PingEclim. The docs say I should go to the forums for help. You've got to be kidding! I've already wasted enough time to declare Eclim a lame, half-baked solution, and the install docs are to post on forums and wait for who-knows-how-long? ...Deleting Eclim right now...

Click to enlarge

I made this logo for a project I worked on at a previous job. It was a play on an existing logo submission but I included the communist tone as a fun jab (it was funny given the circumstances). I have no idea what logo they ended up using. Last I heard, the entire project - 8 months of work - had been scrapped so it could be rebuilt from the ground up in Python because Java was "a failed experiment".

I just read Java statics by Ted Neward. He's been migrating old articles he wrote, and he's posting updated links. Anyway, it's an interesting look at how static data is managed across multiple class loaders.

I'm writing in stunned disbelief after discovering that, mere hours ago, the Atlassian team dealt an awful blow to JIRA users around the world; they've decided once and for all to mark Field level security permissions as "Won't Fix".

4+ year old feature request...
400+ votes...
200+ watchers...

The workarounds are rather hacky and frankly don't cut it. I guess we'll have to suck it up or come up with our own hacky solution. Ugh.

I just came across Google Gears (gearsblog.blogspot.com). It basically queues and persists outbound network traffic and automatically sends it when network connectivity is restored. There are several error / exception scenarios I can think of, but overall this is a cool idea.

If you ever need a nice reference for JSTL, check this one out. It was made by Bill Siggelkow.

Brian Goetz recently posted about exception handling in Java (Remove checked exceptions?), and offered an excellent suggestion for eliminating duplicate code when catching multiple exception types. His idea is to allow disjunctive type bounds on catch clauses, so you could do something like this:

public void addInstance(String className) {
    try {
        Class clazz = Class.forName(className);
        objectSet.add(clazz.newInstance());
    }
   catch (IllegalAccessException | InstantiationException | ClassNotFoundException  e) {
        logger.log("Exception in addInstance", e);
    }
}

Not only is it prettier, it would also make code easier to read and maintain.

I just read Good Agile, Bad Agile from Stevey's Blog Rants. Don't know much about him, but he was a developer at Amazon way back, and now works at Google. It's a long post, and really hit home on a few particular areas of software development.

Excerpt #1 about how most companies approach software development:

• hire a bunch of engineers, then hire more.
  
• dream up a project.
  
• set a date for when they want it launched.
  
• put some engineers on it.
  
• whip them until they're either dead or it's launched. or both.
  
• throw a cheap-ass pathetic little party, maybe. This step is optional.
  
• then start over.

Ouch. I wish it weren't so easy to cite several great examples of this from my own personal experience.

Favorite excerpt #2 about the laws of marketing:

• anything that calls itself a "Methodology" is stupid, on general principle.
  
• anything that requires "evangelists" and offers seminars, exists soley for the purpose of making money.
  
• anything that never mentions any competition or alternatives is dubiously self-serving.
  
• anything that does diagrams with hand-wavy math is stupid, on general principle.
  

  And by "stupid", I mean it's "incredibly brilliant marketing targeted at stupid people."

I'm starting to really like this guy. This fits nicely with one of my long-held beliefs about products and business: if something is touted as being Really Good but requires a long explanation to prove it, it's safe to assume "Stupid and Bad".

He goes on to talk about specific things Google does to take care of their people - and not just developers, but all of their people. They basically give them everything they need to do their jobs, whatever it is, as well as awesome rewards for doing great work, huge incentives for spending time on things that matter. And "things that matter" does not mean "things that someone gathers metrics about", or "hitting a date".

You cannot put a label or metric on individual little tasks for a developer. Instead, software development is a big moving target that cannot be pinned down. You know when you've hit it (or not), but you cannot tell before-hand what you'll need to do in order to get there. And trying to give incentives based on your provably-incorrect predictions of getting there is a big mistake. You will be wrong, your team will not get "the prize", they'll feel like asses for trusting you, and they'll be a lot less likely to believe you the next time around. Nice. Rinse and repeat a few times, and it won't be long before the team has lost all respect for the leadership. What a way to run a software group.

So given Google's committment to truly taking care of everyone, and going out of their way to address all areas where people could possibly complain about anything, they have created an extremely productive, self-managed group of people who do the right thing without management. People work quickly, projects run smoothly, the results are good, and employees are happy about it.

Excerpt #3, which makes a job at Google sound very attractive:

This eliminates the need for a bunch of standard project management ideas and methods: all the ones concerned with dealing with slackers, calling bluffs on estimates, forcing people to come to consensus on shared design issues, and so on. You don't need "war team meetings," and you don't need status reports. You don't need them because people are already incented to do the right things and to work together well.

I've been playing around with Ruby, and I like it. Ruby is powerful and simple. I haven't spent much time figuring out how to get the language to do what I want like I would with Java. Instead, I just do what I'm trying to do, without focusing so much on how.

For example, if I want to build lists of a custom objects, and allow sorting and filtering, I only add one simple method to my object definition to get a ton of cool comparison behavior for free. In Java, I have to do a lot more work, and the results aren't as good, or maybe I decide against proper code organization in Java in favor of some gross, hacky solution that's quick and dirty.

So it's interesting to hear people defend Java. "Oh come on, Java's not that bad", "you're just a Ruby zealot!", "I can do all of that in Java", blah blah blah. To an extent, those comments are correct. But what do they really mean?

"Oh come on, Java's not that bad"
Fine. I'll agree that Java is not that bad. But take this argument a little further. We can build a world-class application in C, Lisp, or Haskell almost as easily as Java. There are plenty of rich libraries of functionality that we can leverage in other languages, so we're not going to 'reinvent the wheel' as is often hyped with OO languages like Java. In reality, the language choice doesn't matter that much. It's not like software development didn't exist before Java. I know several viable software shops here in Austin that are using languages other than Java (including C++, Ruby, Php, Python, ...). The attitude of "software can only be done in Java" is just silly. The heart of this comment is really a posture of defensiveness. I don't care if you say your tools are better than mine, I like Java just fine, I'm not gonna change, you leave me alone!

"You're just a Ruby zealot!"
Say that I am in fact a zealot, I can't shut up about how great Ruby is, I'm sooo excited about the language. Say all of that is true (it mostly is). Here's the big question: what the hell is wrong with that? As long as the language will handle the technical requirements of the project, it's great for the developer to be excited about the tools, excited about building the software, excited about how much he loves doing his work. Java is not exciting. It's big, fat, and bloated. Being a zealot is not a bad thing, and is often quite powerful. You should be happy that your team is excited about doing work on the basis of the tools alone. Happy developers = Good work = Successful company.

Of course, there are practical realities that cannot be ignored - the team may not know Ruby (or whatever language / tool is on the table), there might be a large, pre-existing code base, business demands may prevent the ramp-up to use a new language. All of that stuff is valid, and may very well trump the excited zealotry of the team over Ruby. That's a trade-off you have to make. Happy, excited, forward progress vs. business needs, collective team knowledge. No right answer for everyone, but it's definitely not bad to have zealots. In fact, you should probably always have a few, otherwise you'll be driven by your marketing people or stupid articles about business trends. I don't care how many shops are using Java, it still might not be the right choice for our group. The number one language in terms of lines of code on the entire planet is Cobol (thank you, military), but that means nothing for my software group. Without a zealot among you, you're likely to end up being another sheep in the flock, doing what everyone else is doing. That's bad. This is exactly what Dave Thomas was talking about in his keynote address at NFJS earlier this year. Angry monkeys, indeed.

"I can do all of that in Java"
I'm sure you can, but that's not the point. Think of any task you do in a day (at home, at work, where ever), and consider how many different ways you could achieve the same result. I'm sure you can think of several options. But which one do you choose? The fastest, simplest way to get the correct results. It's an almost unavoidable aspect of human nature - we tend toward the shortest path, and that tendency grows stronger with increases in stress or pressure. In a work context, this means people will favor "getting it finished" over "doing it correctly". Happens all the time in software. TODO: fix this! it's gross and inefficient, need more time to do it right! This is exactly why we have "best practices" in software, and simultaneously why almost nobody follows those practices.

So after I've built something in Ruby, and you've built it in Java, I'll have moved on to think about adding new features, and you'll be reading through javadoc about which package to use, or how to work within Java's linguistic constraints to do what I've already done in Ruby. In the end, we'll both have code that achieves the same result, but mine will be shorter and simpler, and therefore easier to understand, maintain, and extend. And I'll have had an easier time building new stuff because my head was less involved with "Ruby" and more involved with my problem domain, so it will take less mental effort to make more forward progress.