At the Amsterdam Wicket meetup 2009 I did a presentation about Scala and Wicket. These are all the materials that you can download to get started with Scala and Wicket today!
The slides are also on slideshare:
Today I visited TNO Information and Communication Technology to socialize and share some ideas, which was really inspiring. We covered almost everything, from Scrum to buying cars to the paradox of choice and much more. Agile minds wander along random paths, I guess…
Anyhow, Erik talked about the discussion of combining user centered design/interaction design and extreme programming. Here is a small analysis of both and some pointers for anyone taking interest in the discussion.
Basically, the discussion boils down to this: Alan Cooper says you should do interaction design before doing anything else. Kent Beck disagrees as he wants to integrate interaction design in the iterations of XP. What is your opinion?
Interaction Design deals with user related issues and tries to build products starting from the users point of view and not from the implementation or technological side. This “user-centered design“ approach is proposed by Alan Cooper, a very well known author in the usability community. He positions the task of interaction design as the first phase prior to the other phases of the waterfall model. It is important for him that no line is coded before interaction design is done in order not to influence or narrow interaction issues by pieces of the product that are already present. (source)
The Extreme Programming software development methodology was conceived by Kent Beck. It presents an alternative to the waterfall model of software engineering by encouraging practices that invite early feedback and iteration based development.
It seems the link to the original discussion is not working. Fortunately, archive.org has it.
Alan Cooper says at the end of the discussion:
The interaction designers would begin a field study of the businesspeople and what they’re trying to accomplish, and of the staff in the organization and what problems they’re trying to solve. Then I would do a lot of field work talking to users, trying to understand what their goals are and trying to get an understanding of how would you differentiate the user community. Then, we would apply our goal-directed method to this to develop a set of user personas that we use as our creation and testing tools. Then, we would begin our transformal process of sketching out a solution of how the product would behave and what problems it would solve.
Next, we go through a period of back-and-forth, communicating what we’re proposing and why, so that they can have buy-in. When they consent, we create a detailed set of blueprints for the behavior of that product.
As we get more and more detailed in the description of the behavior, we’re talking to the developers to make sure they understand it and can tell us their point of view.
At a certain point, the detailed blueprints would be complete and they would be known by both sides. Then there would be a semiformal passing of the baton to the development team where they would begin construction. At this point, all the tenets of XP would go into play, with a couple of exceptions. First, while requirements always shift, the interaction design gives you a high-level solution that’s of a much better quality than you would get by talking directly to customers. Second, the amount of shifting that goes on should be reduced by three or four orders of magnitude.
Kent tries to prevent the ‘phases’ in developing software with XP. He responds:
I’ll divide what Alan is talking about into two things: a set of techniques, and the larger process into which they fit. While I’m 100 percent with the techniques themselves, I’m 100 percent against the process that he described for using them. The techniques are optimized for being thoughtful in a cognitively difficult, complicated area where you’re breaking new ground, and the thinking that’s embedded in the practices is absolutely essential to doing effective software development.
[..]
To me, the shining city on the hill is to create a process that uses XP engineering and the story writing out of interaction design. This could create something that’s really far more effective than either of those two things in isolation.
It would be great if interaction design and extreme programming or other agile techniques can be combined. I have been in projects without the input of an interaction designer. After some time, you see where the user interface should be improved, but you have no time or knowledge to solve the issues. In my opinion, an interaction designer definitely has it’s place after starting a project.
But… I have no idea if it would work to start a project from the interaction design phase, as Alan proposes. I think a ‘proof of concept’ at the start of a project is very helpful, but when reading the discussion, Alan prohibits doing technical stuff when doing interaction design up-front…
Interesting discussion! What’s your opinion on this? Can interaction design and extreme programming be combined?
On February 4th I gave a talk at the London Wicket User Group. These are all the materials that you can download to get started with Scala and Wicket today!
If you want to attend one of the Wicket User group meetings in London, just visit the jWeekend site and register there. It’s really cool to attend, there is a good atmosphere and nice and smart people everywhere…
Or download everything at once (22.2 MB)
In this separate post you find links to Scala resources on the web (they are also in the slides, but this is much easier to click on).
During my Basic Scala and Wicket talk at the London Wicket Event I showed some good Scala starting points for Java programmers. Here they are, clickable and all.
If you want to attend one of the Wicket User group meetings in London, just visit the jWeekend site and register there. It’s really cool to attend, there is a good atmosphere and nice and smart people everywhere…
 |
Scala Homepage
Contains reference manuals, tutorials, |
 |
First steps to Scala
When you don’t know anything about Scala, start here. Covers the interpreter, variables, methods, loops, arrays, lists, tuples, sets, maps, classes, singletons, traits, mixins. |
 |
Scala for Java refugees
Series of 6 great articles covering a lot of Scala. Aimed at Java developers. |
 |
Scala Wiki
An ever growing collection of resources on Scala. FAQ, code samples, design patterns, Scala job openings |
 |
Scala for Java programmers
Multiple articles covering a feature by feature comparison of Scala and Java. |
 |
Scala Mailing Lists
Official mailing lists |
A lot of ‘performance tests’ are posted online lately. Many times these performance tests are implemented and executed in a way that completely ignores the inner workings of the Java VM. In this post you can find some basic knowledge to improve your performance testing. Remember, I am not a professional performance tester, so put your tips in the comments!
For example, some days ago a ‘performance test’ on while loops, iterators and for loops was posted. This test is wrong and inaccurate. I will use this test as an example, but there are many other tests that suffer from the same problems.
So, let’s execute this test for the first time. It tests the relative performance on some loop constructs on the Java VM. The first results:
Iterator – Elapsed time in milliseconds: 78
For – Elapsed time in milliseconds: 28
While – Elapsed time in milliseconds: 30
Allright, looks interesting. Let’s change the test a bit. When I reshuffle the code, putting the Iterator test at the end, I get:
For – Elapsed time in milliseconds: 37
While – Elapsed time in milliseconds: 28
Iterator – Elapsed time in milliseconds: 30
Hey, suddenly the For loop is the slowest! That’s weird!
So, when I run the test again, the results should be the same, right?
For – Elapsed time in milliseconds: 37
While – Elapsed time in milliseconds: 32
Iterator – Elapsed time in milliseconds: 33
And now the While loop is a lot slower! Why is that?
The example above shows that obtaining valid test results can be hard. You have to know something about the Java VM to get more accurate numbers, and you have to prepare a good test environment.
The Java HotSpot compiler kicks in when it sees a ‘hot spot’ in your code. It is therefore quite common that your code will run faster over time! So, you should adapt your testing methods.
The HotSpot compiler compiles in the background, eating away CPU cycles. So when the compiler is busy, your program is temporarily slower. But after compiling some hot spots, your program will suddenly run faster!
When you make a graph of the througput of your application over time, you can see when the HotSpot compiler is active:
Througput of a running application over time
The warm up period shows the time the HotSpot compiler needs to get your application up to speed.
Do not draw conclusions from the performance statistics during the warm up time!
From Dries Buytaert I received a link to a paper called Statistically rigorous Java performance evaluation. I highly recommend reading it when you want to know more about measuring Java performance.
Remember, I am not a professional performance tester, so put your tips in the comments!
Welcome to my blog. I am a software engineer and interaction designer from The Netherlands.
Thanks for stopping by!
© 2012 STUQ.nl. All Rights Reserved.
Powered by WordPress. Designed by 
Recent comments