As Rod already mentioned Infinitest 5.0 for IntelliJ is out. We've added some great new features to it, including gutter annotations that make it crystal clear where and why your test is failing. If you haven't tried it already, now's a great time.
s = "Theses are the words I want to reverse"
" ".join([x[::-1] for x in s.split()])
I just finished submitting the first draft of my Agile 2009 presentation proposal: Continuous Testing Evolved. A lot has changed since I presented on the same topic last year, and I felt there was a lot of value in exploring some of those changes. It's also still a very new practice, and there's a lot of people who are unfamiliar with it and would benefit from this talk.
If you've worked on projects of any reasonable size, you know that managing dependencies is an very important part of software maintenance. However, the terms used to describe coupling between packages, efferent and afferent coupling, sound so much alike that I can never remember which one is which. So, I don't use those names...I have my own naming convention.
Yakov Smirnoff was well known in the 1980's for jokes using the following template:
In America, you [verb] [noun]
In Soviet Russia, [noun] [verb] you!
I use this now popularized meme to differentiate between the two basic types of coupling, like so:
In America, you depend on other classes
In Soviet Russia, other classes depend on you!
So American Coupling equates to efferent coupling, while Soviet Coupling is the same as afferent coupling. When using these cold-war era terms to analyze a particular class or package, I never get confused about which sort of coupling is which. I just think of Yakov and all becomes clear.
So, I built an alarm to notify our team of build failures.
If you're using the @Ignore annotation to disable failing JUnit 4 tests, you might consider using a different technique. By adding the expects=AssertionError.class parameter to the @Test annotation, you can actually assert that the test fails as expected, instead of just ignoring it.
I try to learn a new programming language every year. Not necessarily to an expert level, but well enough to solve non-trivial problems with it. Last year's language was Groovy. The year before was Python. This year's language is (drum-roll please)...
Is very difficult to improve upon perfection.
If you have the ideas in your head that your (product, tool, process, organization, whatever) is perfect, or even close to perfect, you're not going to have the right mindset to improve it.
Even if it was perfect at some point (highly unlikely), it's probably not now. A commitment to continuous improvement is the hallmark of a true craftsman. You have to accept the fact that everything you do is a hack; A workaround until you can find another way that's less hacky. That's not to imply that you shouldn't make it as good as you can get it...you should. You just need to realize that it can always be made better.