Desirable traits in software teams?
In a recent article published in Computing Now, Phillip A. Laplante ponders cultural differences and their impact on software engineering practices:
[T]he question I’m addressing here is in the actual practices of software engineering— not the management of it. In other words, do people practice software engineering differently because of cultural differences?
He cites some data from Geert Hofstede's social studies - page 3 contains a neat looking graph which is particularly telling. This reminded me of Paul Graham's essay Made in USA:
Americans are good at some things and bad at others. We're good at making movies and software, and bad at making cars and cities. And I think we may be good at what we're good at for the same reason we're bad at what we're bad at. We're impatient. In America, if you want to do something, you don't worry that it might come out badly, or upset delicate social balances, or that people might think you're getting above yourself. If you want to do something, as Nike says, just do it.
Ignore for a moment the fancy-pants practices of software engineering, and let's just agree that some of the best software innovation comes from North America despite efforts to ship it off to "software factories" in the East. Does this mean that, all else being equal, you should hire the tattooed and pierced guy who talks back to you, with a short term focus and high risk affinity for your next software project?
Quick and dirty web service testing
For command line geeks (on Windows the easiest way to get these utilities is to install Cygwin):
curl -s -d @request.xml -H "Content-type: text/xml" \
http://example.com/endpoint | xmllint --format -
Create a file request.xml with your XML input, pretty XML output will appear on the standard output. Curl is an HTTP swiss army knife, xmllint is a XML verification and manipulation tool.
SWI-Prolog has a sense of humor
Deep Thought jokes just never get old! SWI-Prolog, when asked an open-ended question for which no rules are defined, answers like so:
?- A. % ... 1,000,000 ............ 10,000,000 years later % % >> 42 << (last release gives the question) ?-
That's just awesome 
Reminded me that I haven't (re)read HHGG in recent years - maybe I'll put it on me phone. Seems like the perfect book to read a chapter here and there when bored.
Annotation-based dispatch for Spring ApplicationEvents
I created a little extension that allows you to dispatch Spring application context events in a clean and type-safe way to POJO beans. Instead of implementing the ApplicationListener interface, one can simply create a handler as follows:
public class EventListener {
@EventHandler
public void onAppEvent(MyCustomEvent event) {
// ...
}
}
Update on 2011/05/07.
The code was moved to Github.
Please also see the Spring Custom Annotations project on Google Code.
Quick and easy image resizing with Java ImageIO
There are quite a lot of examples of image resizing floating around the web but they all seem to access all sort of hidden features and classes deep inside the JDK to achieve their goal. Here is the most straightforward method that I could come up with - all in all just 5 lines of code. It requires ImageIO and requires Java 1.4 or later to run. If the ImageIO.write() method accepted plain ol' AWT Image arguments it could have been reduced further still to three lines, but you have to give it a BufferedImage instance as input.
The snippet below assumes that there exist the following variables (coloured green in the code):
- an input stream to read from
- a desired width variable (specifying the height as -1 tells the toolkit to preserve the original aspect ratio)
- and an output stream to write the encoded image to.
Sample code:
import java.awt.Image; import java.awt.image.BufferedImage; import javax.imageio.ImageIO;
// ... BufferedImage sourceImage = ImageIO.read(inputStream); Image thumbnail = sourceImage.getScaledInstance(width, -1, Image.SCALE_SMOOTH); BufferedImage bufferedThumbnail = new BufferedImage(thumbnail.getWidth(null), thumbnail.getHeight(null), BufferedImage.TYPE_INT_RGB); bufferedThumbnail.getGraphics().drawImage(thumbnail, 0, 0, null); ImageIO.write(bufferedThumbnail, "jpeg", outputStream);
Effective Java Updated
Brush up on your Java 5 bag of tricks with this talk by Joshua Bloch based on his updated Effective Java book (can't recommend it highly enough).
A colleague of mine commented that this book has about the same information density as maths textbooks, so don't be mislead by the low number of pages - it is excellent value for money 
QCon Enterprise Service Bus Presentation
Jim Webber and Martin Fowler discuss ESBs, agile methods, and... ASCII man-boob p0rn. Must see!
JetBrains’ Dmitry Jemerov on Scala
I can rave about JetBrains' IntelliJ IDEA until the cows come home - it is simply a superbly executed and very well focused product. What I found especially interesting is the following quote on Scala becoming a dominant language for the JVM:
I don't believe that, however: Scala is very complicated, it's tricky, and has a lot of surprises and edge-cases. I would say that Scala is at least as complicated as C++, and with C++ you need a hundred-page style guide before you even start writing C++ code, otherwise you'll end up writing C++ code that nobody will understand.
Scala gives an impression of great elegance and simplicity at first glance but the same goes for Perl as well. The one feature of Scala I really like is the language-level support for traits which allow reusing multiple concrete implementations similarly to multiple inheritance, but with fewer gotchas.
Via Artima: JetBrains' Dmitry Jemerov on IntelliJ 8, Flex, and Scala.
Donald Knuth Interview
I came across this fascinating Donald Knuth interview via Artima. A couple of snippets to pique your interest, one on the subject of open source software:
[...] I think that a few programs, such as Adobe Photoshop, will always be superior to competitors like the Gimp—for some reason, I really don’t know why! I’m quite willing to pay good money for really good software [...]
And his opinon of reuse, with which I wholeheartedly agree:
I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.
Other interesting topics he touches on include multi-core processor architectures and XP. Happy reading!