cwash into software

Update: I cleaned up the example based on Rogerio’s comments.

Recently I stumbled onto JMockit and have been pretty impressed with the flexibility of the approach it takes.

Many mocking frameworks seem to take an elitist attitude toward testable code, not attempting to solve certain problems in favor of guiding one toward a more testable design. It appears JMockit is a response to this. (continue reading…)

As of JUnit 4.4, if you happen to peek into the distributed JAR you’ll notice something a little off: in addition to the org.junit.* packages there is this a funny-looking org.hamcrest.* package sticking out like a sore thumb. You may have seen other projects pick up a dependency on Hamcrest lately as well, and I bet you’re wondering what it is. Let’s get to the bottom of it. (continue reading…)

Update: A great article on OSGi popped up on Javalobby today. Check it out.

I haven’t yet written any thoughts about OSGi but it’s something that’s increasingly found its way on to my radar over the past year and a half or so. I’ve been doing a little bit of reading and research on it lately, (a quick introduction can be found via Adrian Colyer’s talks on InfoQ about it). Needless to say it’s got me excited. Really excited – to the point where I’m catching myself geeking out uncontrollably like Quagmire from Family Guy. What’s got me all giggity? (continue reading…)

The first Ruby I looked at was actually back in 2002, well before Rails, during college as part of a group project in a programming languages course. At the time, most of the information my team could find on it was in Japanese. I looked at Rails initially in 2005 and found some things I thought were lacking in the framework.  I never pursued it much more than that because I didn’t feel like paying the early adopter tax. It had some growing up to do. But seeing as how I recently have been working with Prototype a lot, which aims to almost turn Javascript into Ruby, (a few plugins will get you even closer…) I’ve found a renewed interest in Ruby. I figured I’d take a closer look at what is going on in Ruby-land and to that end, I drove down to RubyRX in Durham, NC last week.

Career 2.0

Jared Richardson recently published a new book based on some ideas he’s been floating around in talks for a while. Jared stopped in at the Richmond JUG recently to give a talk and we were all really intrigued and entertained with his presentation. I was fortunate to pick up a copy of Career 2.0 while I was at RubyRX and it’s a great handbook for investing in your knowledge portfolio through sharing knowledge. There are a lot of useful tips on how to improve your writing, speaking and networking skills. Take a look at the book’s blog for more info.

Dr. Nil

I was interested in seeing Nathaniel Talbot’s talks. I had already seen his talk The Fear of Programming in video, which he has refined a bit and created an alter-ego “Dr. Nil” (Phil?) by asking developers to talk about their feelings/emotions and how that influences how you think and act. It was a very interesting talk. I also saw his talk Five Skills Every Freelancer Should Have and he’s floated the idea of spinning that off into a book. Keep an eye out for it!

HAML and SASS

These technologies were mentioned in a few different talks I attended and I found them interesting because what I’ve never liked about Rails is that its view templates had code snippets in them. This leads to tag soup and has been discouraged in JSP and other areas for a while now. I’ll blog more on this in another post. But  HAML and SASS take an interesting approach. I have my doubts about whether or not it will gain the traction needed to make “pretty” templates a bigger issue. From what I hear, (and feel free to correct me if I am wrong) it seems some of the more prominent voices out there aren’t sold on it yet and have strong feelings about the whole idea.

Build Up Vs. Build Down

I write here often about what I’ve been doing with Seam and Java EE. Seam’s success has come from the philosophy that a developer’s job will be easier if there is a simple interface to a deeply integrated set of powerful frameworks. Grails has a similar philosophy. A common thread in talks I attended at RubyRX was the idea of building down instead. Seeing all of the neat tricks you can do with metaprogramming, this makes a lot of sense for Ruby and many frameworks in the Ruby world take advantage of this idea. There are some very interesting implications with these two paradigms and how they affect code reuse. But that’s another blog post…

It’s All Been Done Before…

Rick DeNatale gave a very interesting talk on the history of dynamic-typed languages and their parallel evolution along with static-typed languages. I always find talks about how languages have evolved to be fascinating, especially if you consider there are a number of problems that we just keep solving over and over again every 20 years. There is wisdom gained in knowing how we got to the present, and I’d like to think these kinds of discussions leave you with insights about where we’ll go from here.

I just read Your Unit Tests Lie to You by Janusz Gorycki and I was going to leave a comment there, but thought it was more appropriate to expand my comments off into their own thing.  For those that haven’t read the article, its basic premise is to grab hold of the nearest “test infected” reader and shake the warm and fuzzy out of them.  It paints the short sightedness of many recent “unit testing” converts as living in a dream world where unit tests should replace formal testing. It follows with many sentiments I’ve read (and written about here) for a while now.  It’s not that I disagree with what is being said in the article, or its tone for that matter; most of what is being said is spot on.  Unit testing is definitely not a silver bullet.  If you read my blog often, you no doubt get that. The article ends:

So please, don’t fire your QA department just yet. Their job is still important, even if you unit test.

So to Janusz, the fundamental problem here is a general ignorance of the purposes behind a unit test suite.  I agree 100% that’s the primary factor behind his problem.  What don’t we agree on?  Semantics.  But semantics are important!  How far do we have to go for a true zen-understanding of this issue?  Not far.  Indulge me — (continue reading…)