Excel 2007 is quite a horrible experience. Someone recently told me a story where apparently, Micro$oft said that it’s easier for new users to learn, yet would take three weeks of re-training for existing office users. Shame I fall into the latter crowd and not the former. Read on if you are wondering where your worksheets went and want to insert a new worksheet. (more…)
What’s wrong with this: “Cannot execute mojo: resources. It requires a project with an existing pom.xml, but the build is not using one.”
How about? What are you talking mojo to me for? What is going wrong and how do I fix it?
Perhaps something like this would be a better error message: “Maven is looking for the pom.xml file and cannot find it. Maven assumes this file is in the directory you are running it from. If you are running Maven in a different directory, perhaps you might want to use the –file switch.”
I’m a big believer in letting people try things out. Unfortunately, most training programs don’t let people do this enough. In fact, most of the time, training is seen as some way of “fixing problems” or a “all-in-one solution”. I can tell you a simple reason why training fails… people don’t have support to actually use the things they are trained on. They don’t get the essential feedback loop in their real environment and they quickly forget what they learned.
It’s all fantastic when you have an opportunity in class to try what you learned out. What really matters if whether or not you have long term lasting support in your environment to apply it to what you do. Unfortunately most training programs fail to address that, or the trainers don’t feel like it’s something they can influence.
Training lasts a day. True learning lasts a lifetime. If you send people on training, make sure they have a safe environment to apply it as well. Don’t view training as a silver bullet. Use it as a tactical solution as part of a larger strategic initiative.
Ticketmaster sent me an email this morning suggesting a concert for, apparently, “one of my favourite performers”.
They’re as far off as they could be. Much as I have a lot of respect for some of the music this artist produces, I doubt I’d ever place it on my favourite artist of all time list. Ever.
Respect for customers is really important in today’s world. Choosing what language and words you use demonstrates this. It’s even more important if you only send emails.
Amazon uses recommendations or suggestions when offering alternatives, as they know they get it wrong sometimes. At least they’re honest about it. In case you wonder, I prefer a more local site (GigsAndTours.com or Stargreen.com) for buying tickets.
It always amazes me at how many people misinterpret FIT (Framework for Integrated Testing) and I guess it’s based on the way that it’s been marketed. I’m not exactly a big fan of FIT and the biggest reason is that people don’t really understand what it’s best for, and use it all over the place where it’s not very appropriate more so than people who do know what they’re doing with it. In the last month, I’d heard statements such as “FIT is good for driving tests below the UI layer”, “FIT is great for acceptance tests”, or “We use FIT all the time”. Please stop this!
Let’s have a look at this table I put together that compares FIT and JUnit. Of course, this comparison also applies when comparing FIT to NUnit or one of its other close brethren (TestNG, etc):
Let’s get this straight: The only thing FIT is good for, is using it as a tool to help communicate with a customer. That’s it. It’s terrible for writing automated test suites, FIT encourages terrible programming habits, IDEs offer very minimal tool support and many developers don’t seem to really understand, nor want to understand how it works. I’ve seen a test suite where developers deployed FIT tests to a web container because “it was HTML” and they thought it had to be deployed for it to run. Grrrr.
The biggest barrier for FIT is that it requires a lot of education around how developers best use it, how they use it to help aid communication, and then understanding how to maintain it. Unfortunately I’ve never seen the payback you get from investing this time that’s better spent directly trying to improve the communication gap. I think it’s because the conventions used to bridge HTML to code aren’t natural and, without spending the effort to really help developers understand it, quickly leading to a whole mess of tightly coupled code and eventually, test coma.
The recommendation
I’d use FIT sporadically to help bridge gaps between the team (analysts, developers, testers) and the customer - especially for data driven examples. Acceptance level tests in JUnit should be refactored to a point where it’s understandable to customers (i.e. using as much of their language as possible). If you decide to go down the FIT route, refactor mercilessly to split out what the FIT fixture do and how they do that (some sort of driver, component, etc). In my experience, the latter should be immediately usable in another test framework, and in fact, should be what you’re striving to reuse in that other test framework.
In trying to change my return flight to London from Bangalore, I’ve been trying to reach British Airways. Calling two of their numbers (the only ones given to me in fact) resulted in the following experience:
*Ring*, *Ring*
“This is British Airways. You have reached our India free number. This service is currently unavailable. Please redial using the advertised number.”
*Click*
That’s it. No greeting. No explanation. No alternatives. A simple message offerings many lessons to learn from.
You miss the valuable things that other people have to say. Listen, reflect, and then comment. Not before.
I’ve seen several projects use FIT and thankfully I didn’t hang around on them too long. I’ve not been a huge fan of FIT (though I will admit it has its purposes). Thanks to James Shore for writing a blog entry about when not to use FIT (and hey, it’s really not that often you should be!). He’s also very humble enough to admit his mistake around promoting it with his articles on “executable specifications”.
If you’re a FIT fan, have a good read of this.
Our project has had enough time lately to really focus on some good clean up around the codebase. The project has been under major development for well over a year with plenty of people having worked on it so I find it an interesting experience to see from a high level how things are. FxCop helps us to a certain degree but here’s some very simple metrics I’ve been using to help draw out things to fix:
Overall I was surprised at how little there was to fix with these considering how quickly the codebase has been moving and how many developers have been involved. It’s great to see everyone living the values and I think it shows in the quality of the software.
Speed, speed, speed… I wish MS tools would give me faster and faster feedback.
My lesson from last week - stay far away from ItemGroup elements in MSBuild files for most normal fileset equivalents (most especially if they only get used once). They are far better as CreateItem elements (though unfortunately only declarable within a Target element), taking almost the same syntax.
The result - instantaneous execution of any other targets outside of the one that uses these items, and a quicker ability to fail faster if you mistype the target name. Maybe it’s time to convert all of our targets to Nant?
Comments(3)