Putting my personal projects on Subversion

Several personal projects, including the ones I've done for job interviews, little tutorials I've made for myself, and the tool for EvE Online.
I noticed recently that DreamHost offers free svn hosting, and I just got around to jumping on that. Funny - it just feels SO good to give those projects a proper home. I just don't feel like code is in any stable state until it's in a VCS. :)
Unfortunately, in order to get DreamHost to let me run Atlassian Jira/Greenhopper and Jetbrain's TeamCity, I'd need a Virtual Private Server plan with them so I can run tomcat. I doubt that's worth it at the moment.
Still, it's nice to have a home for my code :)

Most of it is in private repositories, but I've exposed MarketAgent (read-only).

The clearest and most complete ReST(ROA) and SOAP(SOA) comparision I've ever seen

Of the many clarifying nuggets in this article, I got from it:

• ROA is resource-centric, with the resource specified by the url, and the client specifies the method (GET, PUT, etc) to be called on the resource.
• SOA is service-centric, with the service specified by the url, and the client specifies the resource upon which the service is to be performed.

InfoQ: Is REST the future for SOA?

From Red Tape to No Tape - Part 2: A Self-evaluation to Recognize Organizational Misalignment with Agile Values

From Red Tape to No Tape - Part 2: A Self-evaluation to Recognize Organizational Misalignment with Agile Values

And here's the second part.

Here are a couple of contrasting elements of each company structure:

Bureaucratic vs. Post Industrial (Agile)

Hiring is viewed as fulfilling an immediate skill set need.

Hiring is viewed in the long term with cultural fit and individual contributions outside of skills being considered.

Language in the meetings focuses on I, me, individual contribution.

Language in meetings focuses on team and collective contribution.

maven release plugin

It's magic, yes, but for the odd piece.

When I'm ready to send a release candidate to QA, I expect to make a release branch. Mainline development can continue, and if I need to fix a bug QA has found I can make it in the branch and merge it to trunk.
When I think of vcs "tags," I think of some marker that indicates that a release was made from "this revision."

It seems that the maven release plugin expects that your code is perfect when you've run "mvn release:prepare." For subversion, it creates an "svn copy" in your "tags" directory. While in svn, that's no different from a copy in a directory of any arbitrary name, it, by convention, implies "no further work in this copy."
So that's sort of in conflict with how I want to use it. I want it to make an "svn copy" in my "branches" directory, because I expect I might need to patch it.

You can set a "tagbase" variable to point to your "branches" directory, but while it (presumably) works if you set it to something arbitrary (say, "mytags"), it doesn't work when you set it to "branches."

So, I've just "gotten over it," and I'm using "tags" for release candidates that might get modified.

:(

From Red Tape to No Tape: Maximizing Agile in Your Organization - Part One

From Red Tape to No Tape: Maximizing Agile in Your Organization - Part One: "By limiting people’s creative thinking, initiative, and ultimately sense of control over their work, some of the major advantages of agile are quashed; the ability to push decisions to the level of the organization where the work is (and therefore the most is known about the work) and the ability to use many minds to collaborate in ideas."

Don't checkin ToDo

That's what I think, anyway.

ToDo markers generally shouldn't survive a commit.
If you commit code with ToDo markers in them, you're not done with your current, discrete piece of work yet.
Oh! The ToDo notes are for some other piece of work? OK, then I think it's best if they're entered into an issue tracker, and you delete the ToDo. Then you can check in.

Because ToDo work gets lost. How many times have you seen some ToDo marker in your code that's been there who knows how many months (years?)? Was it important? Is it still important? Is this what's been causing that weird bug?
The whole point of an issue tracking system is to make sure the work you want to get done gets done, and nothing else. If you're supposed to do it, it goes in the issue tracker. If it's just an ephemeral indicator of work to be done in this checkin, then ToDo is a perfect reminder.
The best IDEs offer a window in which you can see all your ToDo markers and go wrap them up before you check in. (Or make issues out of them)

---

Edit (May 17):
Intellij Idea just released v10.5. On their "What's new" page, I see they agree with me:

Now you're painting with Portals

-no spoilers-
You know that one level in Portal 2 where you can spray the white paint everywhere?
I did. Took me about 30 minutes. I don't know why I did that.
Then I watched my wife play. Wordlessly, I watched, and internally giggled as she did the same thing. Why?
It's like, "Oh, I missed a spot. There, that should do it. Ahh... a winter wonderland!"
At some point, we all have to ask ourselves the question, "What area do I *actually* need painted?"
But that question comes much too late, because we avoid it. We pointlessly and happily busy ourselves with the paint, pretending the question doesn't exist, or deciding just to think about it later.
That level truly is some kind of psychological test.

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.

4 reasons Agile Story Points > Hours

1. Velocity
1. Normal velocity = d/t. Wouldn't make much sense to measure distance in hours. You'd get t/t.
2. You need a measurement of work (which corresponds to the measurement of distance) to divide by time and get a measurement of Work per Time.
2. Time estimates are relative (to the engineer)
1. Measurement of work is empirical. Doesn't matter who's doing it. 
2. It's a measure of the work to be done, not the time it takes to complete.
3. When estimates go bad
1. If you've been estimating Stories in hours, the response to underestimating is too often:
1. Work more hours (which increases the numerator in the t/t ratio, right?), or
2. Work faster (which decreases the denominator in the t/t ratio, right?)
2. If you're properly estimating by Story points, the response is:
1. Adjusting your estimates or
2. Adjust your velocity.
3. The net result of all this is the subtle creation of the assumption that the engineers are in fact motivated and talented to work to their capacity without strict oversight. The option to mandate more work in order to correct team product output is quietly removed.
4. Story points are the only work type that is measured in story points. Story points are also, not coincidentally, the only unit which is counted as progress toward project completion. Since, as an agile team, we agree to deliver a functional product, rather than to work a set number of hours, the amount of time we work is of no relevance. It doesn't count to project completion. But story points measure the amount of functionality added to the project.
1. My measuring stories in points, and other issues in hours, you ensure that those other issues (like bugs, or improvements) do *not* count toward project completion. 
2. This is critical in calculating your velocity. If you spend half your iteration fixing bugs introduced from the previous iteration, you will have only the remaining time to work on stories. This will reflect in your velocity, and you will therefore be correctly informed that your poor quality is affecting your forward progress.
3. By contrast, a team which writes quality code the first time (and therefore does not use up their time with bugs) will have more time to add forward progress (story points) to the project.