If you’ve got a 20 min smiting plan I’ll go with it, other than that I’ll just stick to the boycott.

It occurs to me that for around £600 p.a. you can buy a little gazebo tent, a second hand tea urn, a years supply of tea bags, sachets of sugar, stirrers, UHT milks and even a stack of those wonderful planet destroying cups with java-jackets.

Find the parking space immediately before the Costa Coffee and assemble the above items beside a nice big sign stating - hello downtrodden commuters, pull over for free tea to stick it to Costa F**king Coffee

You’d still get your morning tea on the way to work, and for less than £1000 p.a..
You’d get the feeling of contentment from helping your fellow man.
You’d be sticking it to Costa Coffee in a very public way that would probably get you noticed as an “and finally…” story on Reporting Scotland.
You’d also get 3rd degree burns each morning from manhandling a large urn of boiling water into the back of your car.

Put an honesty box up pinned to a charity and you’re practically a saint. I can see it 300 years from now - “Saint Rob of Newton, patron saint of commuters.”

http://thepiratebay.org/torrent/3861532/Barcelona_-_Absolutes_%282007%29_320_MP3_%5Bby_JCP%5D

One person takes in something and regurgitates it in a more processed (or degraded?) form to the next. The analogy falls down though on scale as it’s usually half a dozen steps of birds vomiting into the mouths of ever smaller birds and then the final bird plops out the finished product that bears little resemblence to the orginal intent.

One person takes in something and regurgitates it in a more processed (or degraded?) form to the next. The analogy falls down though on scale as it’s usually half a dozen steps of birds vomiting into the mouths of ever smaller birds and then the final bird plops out the finished product that bears.

Don’t beat yourself up on the display name thing. Java Beans are actually quite complicated by the time you add in BeanInfo objects plus change listeners and property change veto listeners. But nobody really uses that stuff, in fact I doubt many people even know that the Bean spec covers anything beyond ‘write getters and setters’.

http://java.sun.com/javase/technologies/desktop/javabeans/index.jsp

R.

Thats me that is.

I mistook the enumerated data types for something else - but now I see the point in doing this.

You know, the Sizable has the methods setWidth(float width, int unit) etc. which is basically the same as what you have here. For example, you can write textfield.setWidth(5,TextField.UNITS_PIXELS);. It doesn’t look as nice as setWidth(7 pixels) but works in the same manner. i always use “5px” because it is just faster to write than fetchin that constant etc., and looks cleaner. I’d say your solution is easier to use with the benefits of restricted data types.

Nicely done and I stand corrected!

1) With the String version, I could enter any arbitrary string and it would compile:

componentSetWidth(”I like chicken soup”)

With the Scala implicit version you have strict compile time type checking so there’s no way to enter an invalid value.

2) My IDE can provide me with code completion with the Scala version so with respect to typing.. you can do less and you don’t need to remember all of the possibilities. There are in fact about 8 or so different measurement schemes that can be used and I don’t know what they all are. So in-code discoverability is a win here.

3) If it gets into a competition about typing less, I could have called the pixels version px and then I’d be typing ‘4 px’ which is four characters as opposed to the five characters for “4px”. The % method is already in use in Scala as a binary operator on numbers, so I’ll have to check if I could add an arbitrary unary version with a different return type.

Great question!

In many code-bases comments can be the most valuable part of the code. That’s because people wrote comments rather than clear code. If people didn’t have comments they’d be compelled to write clearer code.

I don’t believe that you’re really suggesting that the fact that Swing is not thread safe is something that should be communicated by a comment? Which file should I put that in? Line 293 of JContainer sound like a good place?

Comments are not documentation. They’re a crutch where people can describe what they intended the code to do - quite often what they intended the code to do when they first wrote it. It doesn’t always describe what it did when they were finished. It even less often reflects what the code does after two years. Automated refactoring tools have made this even more true.

You say you’ve lost days and days trying to understand the intent of code that wasn’t working correctly. Comments that describe the implementation wouldn’t help. Comments that describe the intent of the writer would only help sometimes. They wrote code that doesn’t work, what’s the chances they wrote a comment that accurately described their intent?

The English language is vague and imprecise. If you can’t describe your intent in a structured, type-safe programming language why should I believe you can do it in free-form prose?

I’m not opposed to comments entirely - that’s why I put ‘mostly’ in the sentence. There are occasions when a comment can be really helpful. Not many, but a few times.

When you look at code-bases that are heavily commented, often the majority of lines are comments. This means you can see less of the code and have to scroll around more. Is this sort of JavaDoc comments actually helpful?

/**
* Adds two strings
* @param string1 a String
* @param string2 another String
* @return a String
*/
public String addTwoStrings(String string1, String string2) {
return string1 + string1;
}

Not at all from my perspective. Two thirds of that code is comment. There is no new information at all in those comments. It is in fact duplication - you’ve said the same thing twice. And as any engineer will tell you, writing the same thing in two places is asking for problems.

You’re right, I’ve always worked in teams. And I can categorically state that banning comments and demanding clean code leads to a much higher quality of code. I’ve worked on code-bases that have been handed off to other teams that have had a ratio of one line of comment per thousand lines of code and the team who took over the project had no problems picking things up.

I’m not being confrontational, but have you ever tried building a multi-year, multi-developer project and insisting on readable code without comments. I have and it works really, really well. I’ve done it repeatedly with different teams and I’m always happy with the results. So are the developers who work on them. It takes a while for people to adjust, but once they do they never want to go back.

I think there’s some ground we both agree on well documented code but poor code is still poor code. I’d rather have well documented poor code than poor code alone. But I’d rather have clear code WITHOUT comments than clear code WITH comments because at that point the comments add more cost than the value they bring.

Overall, my point is that comments directly lead to poor code. Comments make it easier to get away with writing unclear code.

Thanks for the comment, I really appreciate you taking the time to talk and talk in a civilised manner. Good man!

R.

Still, I’m digging the combination however it works out.

Your point about the different possible types of listeners is spot-on. Java only gives you so many choices and they’re all either cumbersome or flawed. My mind flip-flops between which is the worst. I hope I don’t come across as having been critical of the developers - they’re in a tough situation and they’ve done the best they could and given people choices.

“I also removed the comments because I believe that comments are, for the most part, an abomination, a crutch that has removed the need for programmers to support their own weight and write clean code.”

Are you serious? Comments may be the most important parts of code. They are, de facto, part of the code. Think about the JavaDocs for Swing. Swing is not thread-safe, but nothing in the code spells that out except the comments.

I have lost days and days of work trying to understand the intent of some code that was not working correctly, where if someone had just taken two minutes to write some comments then I would have known what the code was supposed to do and I could have fixed it quickly.

A comment like yours makes it sound like you don’t work with others, which probably isn’t true. So let me try to explain this way: people don’t always write code correctly, but at least comments in the code can be “correct” so that someone else down the line has a chance of maintaining things.

I agree with you totally that people should write clean, understandable code. But sometimes the best-chosen field and method names don’t go as far as a couple sentences saying what some code is supposed to do and, MUCH more importantly, what it isn’t supposed to do.

To complete the circuit: poorly-written, well-documented code, is still poor code.

Cheers,
Bobby

About the listeners, this is something I’ve been lobbying for, and there is actually a ticket: http://dev.vaadin.com/ticket/2490
This is definitely the worst kind of listener. Almost as bad, for other reasons, is having ‘this’ implement the listener interface, exposing it to the world - as in new Button(”Ok”, this).
What we have left is an inner class listener { new Button(”Ok”, new OkListener(); } and private variable holding an anonymous listener { new Button(”Ok”, okListener); }.
Yeah, they’re all bad in comparison - verbose, if not conceptually flawed.

Best Regards,
Marc

Nice writeups. You make a good point about jetty-run. In the just released 0.5.1 version of sbt, there is a new ‘jetty’ action that will wait around for a keypress before completing. Thanks for pointing this out.

-Mark

This really makes me want to take a better look at Scala, amazing stuff

About the inner class event handlers, though, one probably shouldn’t use them for anything bigger than one-liners. For anything more complex it will be clearer to move the click listener logic to a separate method. This can be done like how you did by creating a new class that implements the ClickListener interface, or by letting the class handling the button implement it. I’ve found that the latter way is often clearer, because it keeps a component’s logic near the component itself. Doing it that way results in (IMO) pretty clear code:

public class ClickListenerApp extends Application implements ClickListener {

private Window mainWindow;

@Override
public void init() {
setMainWindow(mainWindow = new Window(”Myproject Application”));

mainWindow.addComponent(new Label(”Hello Vaadin user”));
mainWindow.addComponent(new Button(”What is the time?”, this));
}

@Override
public void buttonClick(ClickEvent event) {
mainWindow.showNotification(”The time is ” + new Date());
}
}

I agree with you about the mandatory main window initialization stuff. I created a ticked about it (http://dev.vaadin.com/ticket/3108), lets see what our R&D team thinks about it.

However you break it down, the work of developers needs to be scheduled, planned and controlled. That the work of programmers is creative and unpredictable in nature is certain, this doesn’t mean that you can’t or shouldn’t try to track, understand, guide and control it as a project manager. It makes it harder that the programmers aren’t churning out widgets, but that’s the nature of the game.

In a sense, is like the life of a production-line widget assembler. Requirements come, you create the solution, you release it, more requirements come…

Bruce

Focusing on and critiquing individual portions of the process outside of their context confuses the issue. I’m going to make an assumption here, but from your confusion as to what BDD is and is used for, it sounds as though you have not spent a significant enough amount of time working with the process/tools to get a full understanding of their value.

Statements like ‘BDD isn’t AN answer, so it certainly can’t be THE answer’ show a bit too much ‘I know everything’ attitude. There are people who say the same sorts of things about , but, in general, most descriptive processes are THE answer for someone. Is it the BEST answer for that person, probably not, but the important thing is that there is something.

It is important to realize that there are no THE answers that work across the board, but there do exist answers for people. BDD fills the need for a lot of people. The fact that you don’t see its benefit does not mean it can’t work.

http://continuousthinking.com/2009/5/28/bdd-not-so-much-really-part-ii

Not to shamelessly keep posting links, but I feel horrible for writing a multi-page comment on your blog.I think there’s a confusion that BDD == toolset (ie. Cucumber, Cucumber+RSpec, rspec). That needs to stop because its wrong and that means we’re going to end up with x number of definitions at least where x is the number of unique combinations between tools that can be used in a BDD style manner.

Your definition of BDD seems to be different from Matt who commented before you. Matt, as I understand it from the limited context of a single comment, feels that BDD lies aligned more with functional testing than TDD. This kind of makes my point. Without agreement about what it is, it isn’t really a useful term, yet.

I make nothing at all of the award that easyb won an award. I always said I had no problems with the tools, only the philosophy behind their use in BDD.

Interestingly easyb won as a testing tool, not as a design tool.

Beyond that, my belief in awards as a ‘Good Thing’ has been jaded by too many years of watching self selecting groups skew polls. The number of years that VisualStudio won IDE of the Year awards when it was nothing more than notepad with highlighting and code completion when IDEA and Eclipse and JBuilder and TogetherJ were 1000 times better was depressing. Rational Rose won countless awards as a design tool and as a productivity tool.. and I never found that to be useful.

So, the awaard doesn’t make me feel one way, or another. It is what it is. I do hope that the developers of easyb were pleased with it. I’m sure they worked hard and any recognition must be nice.

I’m glad you’re happy with your tools. If you’ve found a pattern where they work really well for you.. fantastic. My point was never about tools, it was always about the methods by which one uses them.

Your point seems to be that you use Cucumber for acceptance tests and RSpec for TDD. And together this makes BDD. But then you say that RSpec probably isn’t a DBB framework.

What does that leave? BDD == Cucumber == acceptance testing? I’m not buying that.

If RSpec isn’t a BDD framework then easyb and ScalaTest aren’t either. Can you point me at some other things that you’d call a BDD tool?

I have no problem with acceptance testing. I am a strong advocate of having acceptance tests before you start writing code - otherwise how do you really know when you’re done. I’m sure we agree 100% here.

But this isn’t new, it already has a name. A good name. Acceptance tests. Adding a non-descriptive name, a name highly polluted by previous usage doesn’t help. If I were pairing with you used BDD when you meant acceptance tests I’d ask for the keyboard.

As for the section about BDD code that doesn’t look like actual code, I hoped I was clear that I was talking about tools such as easyb where the testing isn’t even done in the same language.

http://www.continuousthinking.com/2009/5/28/bdd-not-so-much-really

http://rubyforge.org/pipermail/rspec-users/2009-May/014704.html

I think BDD is strong related with TDD - I like the Borland metaphor So if TDD isn’t an answer, then BDD either; but if TDD is an answer, BDD should be an answer too.

what do you make of the fact that easyb has won the 19th annual Jolt award! in the Testing Tools category?

Using the domain language of the customer in your acceptance tests, whether you’re writing them in Fit, Cucumber or straight-up xUnit, is an un-disputably good habit. BDD just makes this a first-class practice, and provides the tooling to make it easy.

I think this is the key but subtle point that people who dismiss BDD miss out on. Forcing yourself to wear the customer’s hat to write an automated test before you write any code can save a lot of headaches later by driving out any misunderstandings and uncertainty early on. Who wouldn’t want that?

Rspec should probably not be called a BDD framework - it’s really just a nice way to write unit tests, and I think you’d struggle to find anyone who uses RSpec and Cucumber regularly who would claim much differently. I’m surprised you’ve found that ‘BDD frameworks don’t look or work like the code that will be calling the final code’ - this is exactly how I use RSpec every day.

Thanks for sharing your thoughts though - it’s an interesting debate

Hill

I guess my concern was that being an externally imposed leader was detrimental to the team and the project. I’ll relax and mull it over some more.

Thanks guys,

R.

Put a bunch of people together and some sort of structure will automatically come into being, and someone will end up in a leadership position - formal or informal.

Sometimes it ends up with a somewhat meritocratic structure, sometimes you have a ‘leader’ who tries to dominate the group, sometimes you have a leader that everyone respects and are happy enough to follow.

Self organisation just means that everyone is involved in the process and that they feel that they have some ownership in the way the team does things. Whether there is an actual leader or not, it doesn’t matter.

So, in essence, I think you can say it was mostly indistinguishable from being self-organising. If it looks like duck…

Reminded me of this…

http://en.wikipedia.org/wiki/The_Paradox_of_Choice
http://www.ted.com/index.php/talks/barry_schwartz_on_the_paradox_of_choice.html

Neil.

Now, on to the meat:

“The user experience is secondary on this king of project” .. the classic Unix developers cry. Sort of fits in well with the posts title.

I didn’t attack the ideals and choices of the macport developers, I commented on their lack of competence in the UI domain. They created a user experience so bad that I thought their installer was broken. That’s not a good thing. I’m sure the original developers would be disappointed to hear that I almost ended up not using the application they spent so much time on.

The cry of ‘it is an open-source’ project is bull-shit. As I mentioned here http://robertlally.com/post/is-the-erlang-community-too-experimental, open-source projects, particularly projects like macports, get their hooks into other open-source projects and you lose the ability to choose to use them or not. As an example, I was originally installing Erlang and had to install macports to get it running. I didn’t want macports, but I didn’t have much of a choice. Today I wanted to upgrade my ruby installation. At ruby-lang.org the instructions rely on macports.

If macports didn’t exist, there would be another viable alternative. Since it does, they’ve cornered that market and they’ve taken on a responsibility. I’d gladly pay for a commercial service that did what macports does, but they’ve killed that market segment. When you create an open source project you take on a responsibility. Their installation experience is bad, I said so.

To paraphrase you, my writing is free .. you’re free not to read it. Unlike my comments, your ad-hominem attack is aimed at my choices and values.

Physician, heal thyself.

They spent a lot of time making the installer work, and work well on different varieties of OS X. That is what matters to them. And that is what matters to me with this kind of project too.

It is also an open source project. You can not use it if it doesn’t suit you, but attacking their ideals and choices feels pretty low.

Your rant makes you look pernickety and ungrateful. So I hope that is what you intended.