Jonathan Kohl is again shedding light on how a professional tester works in an agile environment.
Speaking of professional testers, we're currently on the lookout for skilled testers with the skills to work in an agile environment at Reaktor. If you're interested, check out the job ad and submit a resume. The ad is in Finnish only but we do accept resumes in English as well--just send your resume to careers(at)ri.fi and we'll have a look.
No, not the Java SSH library. JSSh is a promising-looking cross-platform plugin for the Mozilla family of browsers that lets us script a browser over a network socket.
The way it works is that you install the .xpi file (the plugin), launch the browser with the "-jssh" option, and start sending commands to port 9997. Sounds like the automator's wet dream? It sure does... But it's not that simple.
You see, some weeks ago I was trying to get that damn .xpi file installed on my Fedora laptop for 15 minutes and it just wouldn't happen. I could download the file alright, but when I tried to actually install it, Firefox said something about not finding the file. Later on, I figured out that I needed to use Mozilla--the "real" Mozilla--and not Firefox.
Bang.
Plugin installed.
Bang.
Browser launched with the "-jssh" option.
Somebody's listening on port 9997.
Can this be true?
Of course not.
[lkoskela@kera ~]$ telnet localhost 9997
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
JSSh server: new connection!
###!!! ASSERTION: failed to get script security manager: 'Error', file /home/alex/devel/mozilla-trees/clean/mozilla/extensions/jssh/nsJSSh.cpp, line 567
Break: at file /home/alex/devel/mozilla-trees/clean/mozilla/extensions/jssh/nsJSSh.cpp, line 567
Welcome to the Mozilla JavaScript Shell!
> print("hello")
Connection closed by foreign host.
[1]+ Segmentation fault mozilla -jssh
As I said, this was a few weeks ago and the need is no longer that urgent but if you've gotten this to work and have documented your setup somewhere online, I'd love a pointer.
Having said that, I am aware of the disclaimers about JSSh depending on unfrozen Mozilla APIs which might change from one version to another ("WARNING: As JSSh uses unfrozen Mozilla APIs there is quite a big chance that these XPIs will not work in a particular Mozilla release."). What I'm basically looking for is rumors of which versions of which have been proven to work...
Apparently people really don't talk the same language...
Mike Clark gets a lot of email about all sorts of automation and continuous integration implementations around the world. This time, he got a very nice graph of the build history of a zero-defect product release. Nice!
Speaking of releases, I just noticed that Eric's latest book, Ajax in Action is shipping from Amazon. I know Eric from JavaRanch and he's a real wizard with all things JavaScript. I haven't read the book yet but I'm looking forward to it--the early reviews have been great, I've heard!
UPDATE: now also available in blue
Ed Gibbs is apparently about to embark on a little mission constituting presentations, seminars, and pair programming with the goal of test-infecting a group of developers.
The common responses he lists do indeed have a familiar sting to them. Here's the deal: you can't convince someone who's thinking about TDD like that by talking. There are some people who, based on the extensive experience, recognize the enormous value a technique like test-driven development has to offer. And then there are lots of people who will only believe the marketing once they've tried it themselves.
In my job as a TDD coach (among other things), the hardest but also biggest win is to convince a strong, self-confident individual to give it a shot. A single, honest trial of a week or two has made many a skeptic become a test-driven developer and as such a more productive developer for the organization. For some, pairing for 30 minutes with someone who knows the ropes is enough to really "feel" the support and guidance tests give you when developing test-first.
A couple of years ago, I was convinced that "selling" agile methods to management was the most difficult part. I was also convinced that selling low-level, agile techniques such as pair programming and test-driven development to management was much more difficult than selling the idea to developers. Boy was I wrong about all that.
In the end, it all comes down to motivation.
In an organization trying to adopt agile methods, what are the drivers regarding the change from management's point of view? Profit. Higher quality, faster lead times, less operational costs. All that equals higher profit.
Now, think of the developer in that same organization. What are the drivers she's affected by with regards to the organization pushing agile methods, writing tests first, or--god forbid--pairing with another programmer? It's not profit, that's for sure.
Safety. This is all based on just my personal observations but I have come to believe most developers' biggest issue with, say, TDD is not whether it's more productive or not. I believe that most of the time the biggest issue is that of insecurity. Insecurity of people around you suddenly realizing you've developed software in a less than optimal manner for all your career (which isn't the case!). Insecurity of not knowing whether you will be able to learn a new trick. Insecurity of not knowing whether you'll suddenly become the other end of a pecking order.
I've said this before (and many others before me). Change is hard. Sometimes it's so hard we don't do it, even though we know it would probably be for the better. These are the kinds of challenges I enjoy struggling with, even though I might feel outmanned and overpowered at times.
(I found Ed's blog entry via Bieber Labs)
James Duncan Davidson is a professional photographer. Well, at least when he's not developing software with the best of them.
He also has some tips for making the best impact you can when speaking in public. In fact, those tips are good for you off stage as well.
Would you be worried if I'd tell you people using your intranet website with links named, say, "Delete", might have installed this cool little web accelerator called Google Web Accelerator which pre-fetches the content behind that "Delete" link?
Interested? Read more about it over at 37signals.
UPDATE: It was a bug
Mike has a knack for writing short, compact, beautifully written pieces that teach me stuff about stuff. This time, it looks like I'll have to get an update on how testing has changed in Rails 1.0.
Speaking of beautifully written pieces, reading this bit of Nat Pryce's report from OOPSLA got me rolling on the floor, laughing:
I've just got back from OOPSLA 2005. It was held in a soulless conference center in San Diego that was, strangely, shared with a couple of quite scary fundamentalist christian groups who publicised their predictions about when Jesus was going to return and sit on the British throne in magazines left around the foyer.
It was odd to be surrounded by two groups of people who clung zealously to their strange ideas in the face of incomprehension from the general public. But of course there's more to OOPSLA than Smalltalk and Common LISP.
Heh. I just spotted this old entry from Jim Weirich's blog:
<paulv> matthew immediately declared that we were already cracked. :)
<matthew> yeah, it's all good. Although, can you prove you're Jim?
<jweirich> yes
<jweirich> ask me a Ruby question
<paulv> implement the Y-combinator!
<matthew> heh
<paulv> then I'll believe.
<jweirich> p proc { |le|
<jweirich> proc { |f| f.call(f) } \
<jweirich> .call ( proc { |f|
<jweirich> le.call (proc { |x| f.call(f).call(x) }) })
<jweirich> }.call(proc { |recurse|
<jweirich> proc { |n|
<jweirich> if n == 0 then
<jweirich> 1
<jweirich> else
<jweirich> n * recurse.call (n-1)
<jweirich> end
<jweirich> }
<jweirich> }).call(5)
<matthew> wow. This is better than gpg keys.
<matthew> I hope you had that laying around
<jweirich> nah, did it from memory ;)
<paulv> this *is* better than GPG keys.
Gotta love that right there.
Anyone going to XPDay in London end of November?
I'll be staying at the Comfort Inn at King's Cross. It's inexpensive (relatively speaking) at 63-68 pounds per night, it's conveniently in the junction of Piccadilly and Northern Line, and they've got wireless :)
Dr. Robert Koss blogs about refridgerator code:
It’s code that you’re so proud of that you want to
take it home and hang it on the refrigerator,
right alongside of your children’s drawings.
While I'm not likely to pick up the term itself, I have to say asking myself every now and then "would I hang this code on the refridgerator" would certainly be a good idea.
One Rick Bradley reports on a J2EE-turned-Rails project which is experiencing an amazing 1:25 ratio between trivial LOC counts between the two platforms.
That in itself isn't that interesting, however. I've already seen plenty of similar reports and my own experiments have hinted at something around that ballpark as well. What's interesting is that Rick needs nested transactions to implement certain regulatory requirements.
This gets us to the topic of Ruby on Rails and enterprise features.
We don't have nested transactions in the current J2EE spec but there are some workarounds available for implementing some kind of nested transactions in J2EE by hand. (Then again, how many times you've seen someone actually doing that?) As far as I know, there's no known workaround yet for implementing nested transactions with Ruby on Rails. That's a small advantage for J2EE. (Then again, I wouldn't be surprised if someone was already working on adding nested transaction support by now)
Another "enterprise feature" Rails is lacking is distributed transactions, i.e. two-phase commit. J2EE obviously has this but Rails is currently limited to simple transactions even though it is possible to split your domain objects to be persisted in multiple databases.
Authentication is another feature that people seem to have "extra" requirements for in enterprise environments. Again, Rails doesn't support Single Sign-On (SSO) out of the box but adding support for, say, perimeter authentication with SiteMinder and Apache should be as trivial as it is in J2EE.
I'd be interested to hear what other features you'd consider belonging to this "enterprise" category that Rails doesn't have (or you're not sure if it has).
So, as some of the rumor websites speculated, Apple released updates to the 15" and 17" Powerbooks. Great. Bigger resolution, brighter display, and better battery consumption. Except that I don't want a 15" monster, let alone a 17" mammoth, on my lap in the airplane. I want a 12" Powerbook with a higher resolution than 1024x768 and preferably 2 gigs of memory. Pretty please?
It's not just big-name companies that are joining the movement that is Eclipse. The latest news is that Ward Cunningham is leaving Microsoft to join Eclipse.
Here. It seems like an objective piece. Found it through Curt Hibbs' blog.
Jim Shore tackles "design"--that loaded word we all talk about so fluently and yet define and think of so differently. The way Jim slices and dices "design" into a taxonomy that communicates the true meaning is an example of the kind of work consultants all around the world do every day, trying to help their clients see their software development projects and organizations from a new angle.
Much of the problems encountered when introducing techniques, methods, and processes to an organization are at least in part strenghtened by prior bad experiences with similar sounding, yet different vehicles. A client once mentioned they couldn't use the word "functional testing" in their organization because the term had a bad ring to it dating back to the 90's. Another client has a hard time convincing some colleagues that agile methods are any different from the RUP stuff they had experimented with some years ago with less than admirable results. The problems started when they heard the magic words "iterative and incremental" and snapped right into the knee-jerk position combined with a temporary blindness and a malfunctioning hearing aid. And without the slightest insight into the reality--them having applied RUP as a glorified waterfall method instead of tailoring an iterative, incremental process. Yet another client always jumps from 2.x to 4.0 in their release numbers because the 3.0 release for a certain big project was such a flop that it stained the number 3 for good.
In a world riddled with such quasi-superstition, it certainly is difficult to bring forth change. Fortunately, it is not impossible. Just difficult. And every time we succeed it becomes a bit less intimidating even though it doesn't get any less difficult. Luckily, these days I have the luxury of not facing these difficulties alone. More and more, I'm seeing clients taking the lead on their agile adoption just like they should instead of bringing in a consultant and walking away thinking they've done their part.
Understanding is a prerequisite for change. Interestingly enough, often times the perhaps most important work I do as a consultant is to make problems visible and name them as such. Again, not an easy task. Nobody likes the outsider who thinks there's something less than perfect in how we've always written software. Yet, someone has to do it and I like doing it. Maybe it's the challenge. Maybe it's plain old masochism. Maybe I'm just addicted to being able to help.
You read correctly. IBM is open sourcing RUP.
My take on this? I think this is the process world's equivalent for The Daily WTF.
The only reason why open sourcing RUP would make a splash in someone's world would--in my opinion--be because that someone can now get part of the supporting software free of charge. Yeah. Too bad that the software is just a loaded gun with which you can easily shoot yourself in the foot...
Take this quote from one of the news articles Pete links to: "They will also donate 300,000 lines of code, which will serve as the foundation for a proposed tool to capture best practices in software development." Now I might be a bit daft but how on earth will 300,000 lines of software capture "best practices in software development"? No, let me rephrase that. Why on earth would we need 300,000 lines of software to capture best practices in software development? Oh, and why on earth would I listen to what "CapGemini, BearingPoint, Covansys, Number Six Software, Armstrong Process Group, and Unisys" say about best practices in software development? That's like asking a Gartner analyst to write the software for your prosthetic heart.
Yes, I'm ranting and I digress.
Seriously speaking, I see this as just another publicity stunt by IBM. They realize that RUP is not going to be the kind of cash cow it used to be for much longer. The Fortune 500 is experimenting with agile methods after the consultancies gave RUP a bad rap by tailoring monstrous processes for their clients in exchange for hefty sums of cash plus a front row season ticket in the IT project spending spree that followed.
I feel sorry for Philippe Kruchten, the 90's equivalent for Dr. Royce. A smart guy, Kruchten created a decent framework for tailoring a software process to specific situations. Then the consultants came and got it all wrong.
Sigh.
I was again away from the HQ for most of the week and today when I came back from the Merito Forum seminar, Pekka proudly showed what they had figured out with Joni while I was gone. In short, my first impressions are that this seems like a reasonably clean way of sharing fixtures between JUnit tests.
Ruby on Rails has a similar capability built right into the framework itself. Ok, ok, the Rails stuff is much more powerful than the above static import trick but obviously it would be possible to implement some sort of a YAML-fixtures-in-classpath utility on top of JUnit and Hibernate, for example.
I gave a short 30-minute demonstration of test-driven development earlier today in a tiny meeting room with almost no oxygen to a mixed audience of developers with backgrounds in various programming languages from C to C++ to some of those old proprietary state-machine based languages ending with "DL". Since my personal commercial experience in C and C++ (which seemed to have the biggest following in the room) is limited to some 3 weeks of fixing a couple of bugs in a home-grown PDF generator (populated with variables named "p", "p2", "pp", "k", and "j") while "the C guys" were on summer vacation and "the Java guy" was the only one with even the slightest chance of getting it fixed, I used my trusted companion Eclipse to show a bit of TDD live on the projector. In any case, it wasn't a problem since the process of test-driven development itself is language-agnostic (and assuming that you don't get stuck in trying to understand all the nuances of the code being shown on screen). It's the green bar and red bar that matter, and the notion of test code and production code.
Interestingly (or perhaps not so interestingly) one of the C++ guys said, instead of commenting on the TDD process itself, "Oh man, I want to do Java!", as he had watched me "CTRL-1", "CTRL-SPACE", "ALT-SHIFT-M", and "ALT-SHIFT-I" away with Eclipse.
And I agree. The tool support for TDD (or even unit testing in general) is apparently still pretty much non-existent in the C/C++ world. Yes, there are frameworks like CppUnit, CppUnitLite, CxxTest, CUnit, and so forth, but all of the frameworks this guy's team had tried had choked on some particulars of their system (don't know the details and quite possibly wouldn't understand them even if someone would try to explain since I'm really lost with my pointers). Pekka, who was also there to demo a functional testing framework mentioned a unit testing framework for C code named Check that might work. Or not. We'll see. Or they'll see, I should say, since I'm not in any way involved with that C++ project.
The same goes for refactoring--there's hardly any tools for C/C++ developers to aid them in that task, fundamental to keeping your codebase clean and tight.
This sort of encounters always remind me of how Giovanni has done refactoring on C++ code using shell scripts and regular expressions... (Much respect, brother!)
Via C. Keith Ray:
1[...] I had been a programmer for nearly thirty years before I was introduced to TDD. I did not think anyone could teach me a low level programming practice that would make a difference. Thirty years is a lot of experience after all. But when I started to use TDD, I was dumbfounded at the effectiveness of the technique.
Software is a very sensitive domain. If a single bit of a 100MB executable is wrong, the entire application can be brought to it's knees. Very few other domains suffer such extreme sensitivity to error. But one very important domain does: Accounting. A single digit error in a massive pile of spreadsheets and financial statements, can cost millions, and bankrupt an organization.
Accountants solved this problem long ago. They use a set of practices and disciplines that reduce the probability that errors can go undetected. One of these practices is Dual Entry Bookkeeping. Every transaction is entered twice; once in the credit books, and once in the debit books. The two entries participate in very different calculations but eventually result in a final result of zero. That zero means that the all the entries balance. The strong implication is that there are no single digit errors. [...]
We in software have a similar mechanism that provides a first line of defense: Test Driven Development (TDD). Every intention is entered in two places: once in a unit test, and once in the production code. These two entries follow very different pathways, but eventually sum to a green bar. That green bar means that the two intents balance, i.e. the production code agrees with the tests. This is not perfect, and other controls are necessary; but there can be little doubt that TDD vastly decreases the defect load in software projects. [...]
When tests are ugly, maintaining them is hard; and that makes maintaining the production code hard because the tests have to be maintained along with the production code. [...] If you want your production code to be easy to maintain, you must keep your tests easy to maintain.
Ken Schwaber was in town today. He's now a proud owner of one of Reaktor's infamous "I Love Servers" trucker caps :)
Thanks to agile executive, I realize that golf and agile really are much alike.
Ben Griffiths seems to know how to pull the right strings to get Rubyists drool sporadically:
What we don’t do:
Java; XML; wait for compilers to build our code; J2EE; Websphere; Windows.
What we do do:
Ruby; Automated testing; Continuous integration; Daily releases; Rails; Macs.
Simon asks, How do you map requirements to code and presents an idea he had recently, basically tagging certain points in your code with an annotation identifying the requirement related to that specific action.
So, how do I map requirements to code? I don't. I really don't. Explicitly. But if I did, I'd probably tag my acceptance tests instead of the production code because I'm more interested about the reality itself rather than the difference between the reality (observed coverage of a given acceptance test) and my intent (annotation on production code).
I am of the opinion that simply having a suite of acceptance tests written in the domain's language is enough for mapping requirements to tests, and from there we can more or less let the computer figure out which parts of our system are involved in implementing a given feature or an aspect of it.
I don't know if my take on this is any more right or wrong, better or worse than anyone else's. Not to mention that I haven't spent much cycles on thinking about the whole thing in the first place. I would also be interested in finding new perspectives to look at requirements traceability from.
I recently found the following blog entry through my referral logs. It collects some very useful links to various presentation styles into a single place. Nice. Thanks.
The Good, Bad, and Ugly of PowerPoint
I'm personally very fond of extensive usage of pictures instead of bullet points. The less text on a slide, the better. Knobs turned to 11 (or perhaps "-1" would be more appropriate in this context). In fact, here's a couple of thumbnails from the slideshow I'm going to present next week in a Merito Forum seminar on testing.
Isn't it interesting how sometimes you can just tell that a given team or community is jelling?
Reading the above blog entry from project.ioni.st got me thinking why is it that we typically (and I might be over-generalizing a bit here) bond through playful name-calling and other similar acts. And yes, it's predominantly a male thing.
The name-calling thing is harmless and seems to be a rather effective means of bonding as long as everyone involved has an understanding of the rules of the game. For example, saying "oh my god, I haven't seen crappier code than what you just checked in in ages!" is probably not going to fly with any software developer alive while accusing the same software developer of having an abnormal preference for beep-beep-beep beep beep-be-beep beep is quite ok. The farther the topic is from the actual work being done, the easier it is to recognize the name-calling from real opinions.
Obviously visual clues have a lot to do with it. I would seriously recommend avoiding such a name-calling pattern when dealing with a multi-site scenario where the name-calling happens over a wire and not face-to-face. The smile saying "you couldn't have come up with anything smarter than the line I just threw at you" that accompanies the witty insult is pretty crucial...
Anyway, yes, the bent-over-backwards approach to bonding that is this name-calling game does indeed seem to work. Teams that develop this kind of behavior are often those that seem to possess ownership of what they do and hold common goals. Yet, I can't help but thinking that the reverse psychology part of it is muda, waste.
Keeping my amateur psychologist hat on a while longer, I suspect that the reason we aren't too keen on bonding in a more direct way is because of personal safety. We want to feel safe. It's the hierarchy of needs thing, remember? For some reason, we tend to feel less secure revealing our true emotions and true feelings than we feel about giving hints along those lines, while still retaining a chance to take our words back.
We all know how good it feels when someone you think highly of says something nice about your work. Imagine if even a small part of that playful nagging and name-calling would be replaced by direct communication about the good work you or another team member has done.
Via Jason Yip, Linus Torvalds on specifications:
Specs are a basis for _talking_about_ things.
But they are _not_ a basis for implementing software.
Cool. But nowhere near as astonishing as Backpack was when I first saw it. I didn't have too much expectations, not having had the time recently to keep up with everything in the blogosphere, so I can't say I'm disappointed as such. Besides, it's a free service (for now) and clearly of some value even if it wouldn't be all it was (apparently) cranked up to be.
I find it encouraging that ThoughtWorks is selling Ruby on Rails expertise on their website. Althought that shouldn't come as a surprise since their chief scientist has come out of the Ruby closet already long ago...
What I'm curious about, though, is the sentence "ThoughtWorks employs some of the world's leading Ruby developers and committers to the Rails project" on the page. Now I might not be all up to speed on the Rails community's who's who, but I've been living under the assumption that none of the Rails committers are working for ThoughtWorks? Especially since the WorkingProfessionallyWithRails page in the Rails wiki lists only two TWers, neither of which are committers. Maybe they got "committer" and "contributor" mixed?
Whether or not you're interested in Identity 2.0, you owe yourself to invest a couple of minutes on seeing through this OSCON 2005 presentation by Dick Hardt from Sxip. It's not so much the message, it's the way Dick delivers the message. Using Lawrence Lessig's style of presentation.