That blasted maven target directory

[WARN] Slightly thick maven discussion, incoming.

Sort of a holdover from when the normal procedure for checking in was to check in everything recursively in your local working copy tree, I just hate it when files that aren't controlled by my VCS/SCM get placed under that directory tree.
So I never do it. I've always made sure that the ant builds I make/use build artifacts OUTside that tree.
And along comes maven.
Come on, guys. What were you thinking?
Well, maybe they were thinking, "Hey, we all use modern IDE's which help partition our SVN checkins into changelists for us, so we don't *have* to checkin everything recursively. And also, we can easily run our status checks while excluding external directories and files we don't want to see."
Oh.
But still! Why not build the product up one directory and make the target directory a peer to your vcs-controlled one?

Well, it's configurable. You don't *have* to leave it as the default. It's part of the <build> element:


<build>
<directory>${project.basedir}/../target</directory>
</build>

But I don't like that on my CI build server, because builds of 2 different projects can clobber eachother's target directory (or leave junk in there). 

So what I really want is for this to happen only in a developer's environment. And only optionally.

There's a few ways to do this, but I chose to use the maven <profiles> in the pom, along with the <activeProfiles> in the developer's settings.xml.

In the pom:

<profiles>

  <profile>

    <id>dev_environment</id>

    <build>

      <directory>${project.basedir}/../target</directory>

    </build>

  </profile>

</profiles>

And in the settings.xml:

<activeProfiles>

  <activeProfile>dev_environment</activeProfile>

</activeProfiles>

Crappy Interview Questions

From The Oatmeal (Thanks to Daniel Spangler for the shared link)
That was so true. And hilarious.

In particular, I've personally always hated these two:

• "Why do you want to work here?" - which instantly creates a conflict of interest, and you'll find out nothing useful.
• "What's your greatest weakness?" - same reason.

Don't ask questions that create a conflict within the interviewee. Sheesh. Instead, just engage them in a dialog so you can hear how they think and communicate.
You really want to know what it's like to work with this person, so ideally, if you could arrange to work on a small problem on the board (or actually program it!) together (rather than watching them pseudo-implement your requirements), that would give you the best idea.

Engineering quote

Engineering: you're finished not when there's nothing more to add, but when there's nothing more to take away

... unless you're doing Test-driven development, of course.
That seems to have flipped that all around.