The big secret my dad always reminded us about was that adventure was an everyday thing.

Via Keenan Cummings.

Read the original at Adventure is an everyday thing or go to the homepage of STUQ.nl

No related posts.

“We’re not finished until all the computers in the world work like this.”
John Underkoffler

See original

John Underkoffler led the team that came up with this interface, called the g-speak Spatial Operating Environment. His company, Oblong Industries, was founded to move g-speak into the real world. Oblong is building apps for aerospace, bioinformatics, video editing and more. But the big vision is ubiquity: g-speak on every laptop, every desktop, every microwave oven, TV, dashboard. “It has to be like this,” he says. “We all of us every day feel that. We build starting there. We want to change it all.”

Before founding Oblong, Underkoffler spent 15 years at MIT’s Media Laboratory, working in holography, animation and visualization techniques, and building the I/O Bulb and Luminous Room Systems.

Read the original at Minority Report interface is reality or go to the homepage of STUQ.nl

No related posts.

Group think

The first risk in decision making is group think.

Group think has the following symptoms:

• Little or no consideration of alternate plans
• Risk is not assessed
• No review is taken of rejected plans
• Advice from outsiders is not sought
• Facts that support the plan are acknowledged, facts that do not support the plan are ignored
• Contingency plans are not created

Surprisingly, synergy and loyalty to each other and to the team leader are a team’s greatest qualities, however, they are the same factors that lead to group think.

Abilene Paradox symptom

The second risk in decision making is the Abilene Paradox symptom.

The Abilene Paradox symptom has the following symptoms:

• Members, as individuals, privately agree on the correct decision to make. This is not shared with the group.
• Members, as individuals, privately agree on how the problem or situation being addressed can be resolved. This is not shared with the group.
• Instead of communicating their views, members keep their views and reservations to themselves, agreeing with views they are opposed to. As the individuals have not presented their views and reservations, a collective decision is made that is actually contrary to the views of all members.
• Members feel frustration, even anger, at this and find someone, or some people, to blame.

The Abilene Paradox is real. How often have you agreed to a suboptimal solution? What if every other team member felt the same way about this solution?

Decision hijacking

The third risk in decision making is decision hijacking. This happens when for example a developer implements features that are not needed right now. The developer hijacks the decision to implement these features.

Example during daily stand-up:
Developer: The customer databases will be used by several applications, so I have implemented support for dealing with various technologies, including Oracle. It took a lot of time. Scrum master: Did we not agree on postponing this? Developer: We need this later and now it is done.”

Decision hijacking is a big problem because the decision making itself is removed from the team as a whole. This behavior has a big impact on trust within the team.

Solutions

Conflict in Agile software development projects can be beneficial to both process and product.

The literature proposes some solutions to the problems with decision making described above. These solutions are based on the existence or stimulation of intra-group conflict:

• Separate groups should be formed, under different leaders, to propose solutions to the same problem (groupthink)
• A devil’s advocate should be appointed (groupthink, Abilene paradox)

For the decision hijacking risk, make sure that developers are on the same page. Working together as a team means taking decisions together.

Sources:

1. McAvoy, John, en Tom Butler. “The role of project management in ineffective decision making within Agile software development projects.” European Journal of Information Systems 18.4 (2009): 372-383. Web.
2. Moe, Nils Brede, Torgeir Dingsøyr, en Tore Dybå. “A teamwork model for understanding an agile team: A case study of a Scrum project.” Information and Software Technology 52.5 (2010): 480-491. Web.

Read the original at 3 risks with Agile decision making or go to the homepage of STUQ.nl

No related posts.

I believe that any software developing company that wants to have a competitive advantage needs to stop focusing on just building features, but instead focus on the users.

Many companies seem to focus on the checklist of features that are dreamed up by marketing. Most of these checklists result from doing ‘competitive analysis’, just look at what the competitors, and do that too. Development teams have to copy all the software features of the competition, just to keep up. That is mediocrity at its best.

Developing software is not a unique trait. It’s not that hard as it used to be, the lab coats are long since gone. Coding can be outsourced to China or India at a fraction of the cost, as can many other aspects of software development.

Shipping a huge amount of features became relatively cheap. The time of industrialization has come for software development. Lines of code are becoming cheaper every minute. A lot of open source software (‘free software’) now has the same (or more) features as commercial available software.

So, it is not about building a huge amount of features.

It is about building clever software that works really well, in its context. Companies have to build revolutionary, groundbreaking, surprisingly good software to be noticed and successful. It has to be different and fresh, revolutionary perhaps.

How do you do that? Invest in interaction design. Do research to find out who your users really are. Talk to them. The real users.

Learn about them. Find out what they need. Find out what they like, what they don’t like.
Learn where your software becomes part of their lives.

Learn how to improve. Improve your software, and learn more. Make your users happy. Never lose them out of sight.

Read the original at It’s not about the features! or go to the homepage of STUQ.nl

Related posts:

• 3 risks with Agile decision making
• Create RESTful URLs with Wicket
• Wicket: how to write a reusable modal window popup

Everyday a nice read about Scala. I’ve added it to my newsreader and if you like Scala, you should do too!

http://daily-scala.blogspot.com/

Read the original at Daily Scala or go to the homepage of STUQ.nl

Related posts:

• Scala basics: What is Scala?
• 4 steps to add Scala to your Maven Java projects
• 6 Scala resources for Java programmers

This is the summary of that afternoon. You should have been there…

Keep an eye on this page for when the next London Wicket event is scheduled.

Overview

Click on an item to jump down (same page) to the notes from that presentation.

• Cemal Bayramoglu: Introduction
• Jeremy Thomerson (USA): Custom JavaScript Integrations with Wicket + Auto Resolvers
• Lionel Armanet (FR): Announcing WiQuery 1.0: Introduction & Demo
• Matej Knopp (SK): BRIX CMS + Wicket 1.5 Developments Q&A
• Sven Meier (DE): Trees, Drag&Drop and more:
• Martijn Dashorst (NL): Writing Books vs Making Babies
• Wicket Q&A

(Unfortunately Alastair Maw couldn’t make it as he was sick. Hope you will soon be better!)

Cemal giving the introductory talk

Cemal Bayramoglu: Introduction

As usual, the London Wicket Meetup is kindly hosted by Cemal Bayramoglu of jWeekend. Thanks Cemal!

Jeremy Thomerson showing some code

Jeremy Thomerson (USA): Custom JavaScript Integrations with Wicket + Auto Resolvers

Jeremy Thomerson started his talk with an example of how to do client side validation in Wicket. He showed abstract validation behaviors that validated form input with jQuery.

The remarkable thing was that by adding just one behavior to a component, validation was added for both the server side and the client side. This makes it very easy to keep client and server side validation in sync.

The Javascript behavior is added by letting the behavior implement iHeaderContributor and adding the script in the onRenderHead method call.

Auto component resolution

The next part of Jeremy’s presentation was about the AutoComponentResolver. The AutoComponentResolver makes it possible to wire components directly in HTML, without adding the component explicitly in Java. His demo showed how to use an AutoComponentResolver.

Matej Knopp commented that it is not really recommended to use automatic component resolving, because it has a limited use. The main purpose of auto component resolvers is for simple components that do not have a long lifetime on the page. For example the <wicket:message> tag is handled by automatic component resolving and is replaced by a Label with a ResourceModel. More complicated use cases are not supported nor recommended.

Components added via auto-resolving are not serialized or stored in the session and lose all state.

Lionel Armanet showing us the WiQuery goodness he and his fellow Frenchmen created.

Lionel Armanet (FR): Announcing WiQuery 1.0: Introduction & Demo

The presentation of Lionel Armanet was an impressive demo of what WiQuery is capable of. WiQuery integrates jQuery with Wicket, with clever tricks that ease development. WickeXt was merged with jQuery4Wicket and changed its name to WiQuery. Last week was the 1.0 release, and the library is available under the MIT license.

The rationale behind WiQuery is that to build rich internet applications, you need rich behaviors and components. jQuery is simple, unobtrusive and powerful, there are tons of plugins and jQuery UI has fancy components. So, let’s get jQuery, integrate it with Wicket and have the best of both worlds!

WiQuery has standard components and behaviors like the resize behavior, drag and drop behavior, datepicker component, etcetera. By simply adding Java components, WiQuery generates the Javascript for you and imports the required libraries.

Setting up WiQuery

There are two ways to setup wiquery:

With a WiQueryCoreInstantiationListener:

addComponentInstantiationListener(new WiQueryInstantiationListener)

Or by extending the Abstract class WiQueryWebApplication.

Demo

After the theory, Lionel showed an impressive demo with a drag-and-drop Scrum taskboard. The task board had three columns (new, in progress, done), from which task items could be dragged and dropped around. Double clicking an item showes the details for that task.

The double click action is easily added with:

add(new WiQueryAjaxEventBehavior(MouseEvent.DBLCLICK){
   ....
});

With the IThemableApplication interface you can make your application themable, like the themes that jQuery UI has.

Matej Knopp talked about Brix and Wicket 1.5.

Matej Knopp (SK): BRIX CMS + Wicket 1.5 Developments Q&A

Matej Knopp showed what the content management system Brix is all about. Brix is based on Wicket and is a component based content management system based on JCR for storage.

Brix is meant for integration with Wicket web applications and looks very interesting. The basic building blocks in Brix are Tiles, Pages, and Templates.

In Brix, Tiles are like a factory for embedding Wicket components. So any Wicket component can be added to a Page which is nearly impossible in ‘regular’ CMS systems. More information about Brix can be found on the Brix website.

Wicket 1.5

Matej also talked about some new developments that can possibly be shipped in Wicket 1.5:

• New RequestCycle
• New RequestMapper
• New Ajax implementation

New RequestCycle and RequestMapper

One of the areas where improvements can be made is the RequestCycle. The RequestCycle in Wicket 1.4.x is big and complicated, and hard to step through while debugging. Matej worked on an improved RequestCycle.

Matej talked about the drawbacks of the Wicket 1.4 code for handling requests and mapping requests to URL’s:

• Complicated, huge code base
• Many abstractions, most of them on wrong level
• Complicated class hierarchy, hard to find proper extension point

He proposed a new RequestMapper that handles Request mapping in a different way.

RequestMapper Interface

The RequestMapper will get the following interface.

public interface RequestMapper {
int getCompatibilityScore(Request request);
RequestHandler mapRequest(Request request);
Url mapHandler(RequestHandler requestHandler);
}

With the RequestMapper interface you can implement your own Request Mapping behavior for various URL’s.
There can be a hierarchy of RequestMappers. When there is more than one RequestMapper, the compatibility score can be used to choose which RequestMapper will be used.

Calculating RequestMapper compatibility score

The compatibility score is calculated by counting how many URL segments match the mount point.
For example, having an application where two RequestMappers are defined with these URLs:

1. /mounted/page
2. /mounted/page/that/is/different

When there is a new Request on “/mounted/page/that/is/”, the second RequestMapper gets a higher compatibility score (4) than the RequestMapper matching only the first two parts of the URL (“/mounted/page/”).

New AJAX implementation

About a year ago, Matej created a new Ajax implementation for Wicket. The new Ajax implementation is way better than what is now in Wicket 1.4. It is faster, simpler to use and will be based on a standard library. There is only one problem, the new Ajax implementation Matej built uses YUI. It seems that the world prefers jQuery over YUI. Matej told that rewriting it to jQuery will be a lot of work.

The focus of the new Ajax implementation is removing browser inconsistency code. The custom-written Wicket Javascript will be swapped for more standard Javascript (like the YUI or jQuery libraries).

The API for working with Javascript will be different and much cleaner according to Matej. Also, the generated Javascript is nicer: code is not put directly in the onclick of a UI control, but separately. This looks like how WiQuery does stuff. This means that the Javascript handlers are much shorter, so the page loads faster.

There is an experimental branch in source control, so if you want to try it out or convert it to jQuery, you are welcome to check it out.

Problems with implementation Wicket 1.5

There are some challenges with the implementation of Wicket 1.5. Matej touched a few and gave some insight in what needs to be done. The big question is: how to build this without breaking anything? How can we undo the universe?

One point was the use of global state during the 1.4 Wicket RequestCycle. This makes it difficult to implement the new RequestCycle in core, because much code and unit tests rely on this global state.

Another challenge is keeping the WicketTester in a workable state. The new RequestCycle breaks WicketTester, which is problematic because many people are using WicketTester. Fixing WicketTester is not really easy, because it is a big class with much functionality. It can simulate a lot of actions, like file upload and form submission.

Sven Meier encouraged us to not refrain from writing custom Javascript.

Sven Meier (DE):

Sven Meier showed us his implementation of a TreeModel. He argued that Swing’s TreeModel is not suitable for implementing a tree in Wicket: “The treemodel is ugly, and there are many methods you don’t need in Wicket.”

His implementation allows hierarchical markup in the tree. This makes it easier to use and extend. It uses simple and known patterns. Partial update is not there yet.

Google Code hosts the Wicket Tree project.

Drag and drop

Sven also created Wicket drag and drop functionality, which is also hosted at Google Code.

This project enables you to drag and drop between any Wicket component. It supports common desktop metaphors with ‘MOVE’, ‘COPY’ and ‘LINK’ operations and is fully themable.

Sven’s closing remarks were: “Don’t fret from developing custom Javascript. It’s really easy with Wicket!”

Martijn Dashorst compared having a baby to writing a book.

Martijn Dashorst (NL):

Martijn’s presentation was titled “Writing Books vs Making Babies” and was a hilarious story with good slides. We have been informed of all the gory details of writing a book (finding the publisher, writing, editing, checking, etcetera) and learned something about having a baby as well!

Wicket Q&A

There were not many questions about Wicket, which is proof for the developer friendliness of Wicket

Were you there?

If you were at the London Wicket meetup (presenter or attendee) or plan to go there next time, please comment below!

If you send me links to the presentations, I will add them to the article.

Read the original at London Wicket Meetup: Wicket 1.5, WiQuery, Brix and more.. or go to the homepage of STUQ.nl

No related posts.

In this blog post I describe a way of automatically verifying that the HTML markup of Wicket panels match the Java code. Scroll down to download the demo project!

Unit test

I created a JUnit test that you can add to your project to automatically test as much Wicket Panels as possible. Automatic testing works by resolving all panels on the Java class path and feeding them to the WicketTester. When a panel has invalid markup, the WicketTester will give an error: early feedback!

How does it work?

The Wicket panels that can automatically be tested should have a ‘default’ Wicket constructor, like this:

public DemoPanel(String id)

Resolving all panels is done with Spring 2.5’s ClassPathScanningCandidateComponentProvider (don’t you love those names! How can they stay below 120 characters per line?)

The ClassPathScanningCandidateComponentProvider is a component provider that scans the classpath from a base package. It then applies exclude and include filters to the resulting classes to find candidates.

Testing panels

@Test
    public void testAllWicketPanels() throws Exception {
        WicketTester wicketTester = new WicketTester(new WicketApplication());
 
    	ClassPathScanningCandidateComponentProvider provider = new ClassPathScanningCandidateComponentProvider(true);
        provider.addIncludeFilter(new AssignableTypeFilter(Panel.class));
 
        Set components = provider.findCandidateComponents("nl/stuq/demo");
        for (BeanDefinition component : components) {
            Class clazz = Class.forName(component.getBeanClassName());
            if(hasDefaultConstructor(clazz)){
            	testWicketPanel(wicketTester, clazz);
            }
        }
    }
 
    private void testWicketPanel(WicketTester wicketTester, Class clazz) {
    	wicketTester.startPanel(clazz);
    	wicketTester.assertNoErrorMessage();
    	wicketTester.assertNoInfoMessage();
    }
 
    private boolean hasDefaultConstructor(Class clazz) {
        for(Constructor constructor : clazz.getConstructors()){
            if(constructor.getParameterTypes().length == 1 &&
               constructor.getParameterTypes()[0].getSimpleName().equals("String")){
                return true;
            }
        }
 
        return false;
    }

The test instantiates a new WicketTester. After that, the ClassPathScanningCandidateComponentProvider is created and configured to scan only for Panel classes in the nl.stuq.demo package and below.
After that, the found components are all checked. If they have a default constructor, the test is executed.

The boolean hasDefaultConstructor(clazz) method checks if the class has a constructor with only one String argument, the Wicket id.

Keep in mind

• This is only for lazy people (good developers are lazy in some ways).
• You need a dependency to Spring.
• Only Panels with a certain constructor are tested.
• Only instantiating the Panel is tested, so code coverage has no meaning for this test. Real testing is still needed.

Download demo project

The demo project is a Maven project based on the Wicket 1.4.3 quickstart that contains the test class and an example panel to be tested.
Download demo project.

Extract the zip file and run mvn test to run the tests. Then fire up your IDE and check how it’s done.

You can change or adapt the given JUnit test to also automatically test classes extending from Page or Component.

Join in with your opinions and code! I’m curious to see what clever way you have of testing code.

Read the original at Automatically test your Wicket panel HTML markup or go to the homepage of STUQ.nl

Related posts:

• Wicket: how to write a reusable modal window popup
• Create RESTful URLs with Wicket
• User friendly form validation with Wicket

You can get these and more on the DZone Refcardz site.

Read the original at Refcard: Getting started with Wicket released or go to the homepage of STUQ.nl

No related posts.

In their research, they analyzed a number of attacks and their characteristics, like host name, TCP port, IP address, user agent strings, request urls, redirection and so on. They applied a scoring mechanism with rules quite similar to the detection rules of modern spam-filters. These rules determined in 14 out of 15 cases correctly if an attack was taking place.

The research is based on a months worth of data, so the rules are probably not 100% future proof. As we know from spam filter rules, they constantly need to be revised to stay one step ahead of the game.

The next step

I think someone should take this and implement a browser plugin with a central ruleset for the detection of drive-by infections. The Firefox browser would be a good candidate, but it should also be possible to develop a plugin for other browsers, like Safari or Internet Explorer.

View the report.

Read the original at Better detection of browser drive-by infections or go to the homepage of STUQ.nl

Related posts:

• User friendly form validation with Wicket
• 37 Factories: statistics about Tomcat 6

This year I went to the ApacheCon community meetups. There were several, but I chose to attend the Maven and the Wicket meetup. I made some short notes on the most interesting things.

Monday 23-03-2009: Maven

The meetup on Maven was about new features and new projects.

Eclipse Integration

The community is working on a new tool for Eclipse Integration called Eclipse IAM (Integration for Apache Maven). The plugin aims at simplicity and will bring the best Eclipse integration for what Maven offers. It will integrate with JDT and WTP. The following features will be in the package:

• Direct project import with a POM. Instead of using the Eclipse archetype.
• You can setup projects in Eclipse by using predefined archetypes.
• You can configure autobuilds so building isn’t annoying.
• There will be a FormBased POM editor, just like you are used to in Eclipse.
• Dependency search
• Dependency management
• Dependency graphing and analysis

Eclipse IAM will be worth looking at, it can be found at http://www.eclipse.org/iam/.

Maven 3.0 new features

The community is working on Maven 3.0. Some new features:

• Embeddable, so it will be faster
• Some improvements to make it easier to use with the repository
• New transport mechanism for simultaneous downloads.

Eclipse 3.0 projectpage: http://docs.codehaus.org/display/MAVEN/Maven+3.0.x
After this two subjects and some live demos there was an open discussion. Because it was late in the evening I left. One thing I wrote down is that SourceSense made an Alfresco archetype for Maven.

Tuesday 24-03-2009: Wicket

The Wicket meetup was quite different in comparison with the Wicket meeting. There where several presentations about testing, Scala and Wicket, Wicket and DB4O.

JDave

For testing nothing was really new… Except the following framework for Behaviour Driven Development: JDave. More info on: http://www.jdave.org/.
Presentation of the ApacheCon and examples on: http://www.jdave.org/bdd-wicket/.

DB4O

DB4O is a Object Database for Java and .NET shipped with two different licenses. More detailed information about DB4O can be found on the DB4O website.

You can look at DB4O as a large factory (like the Factory design pattern (GoF)) just for storage. It is a good practice to use some XML storage together with DB4O. For this you can use XStream. Using XML for storage together with object storage offers you a good backup mechanism.

Some disadvantages of DB4O are:

• When data is corrupt there are strange exceptions.
• Version Management for the objects is hard to do.

Scala and Wicket

The presentation about Scala and Wicket was really a hands-on presentation. The slides, code examples and handouts can be found at http://stuq.nl/weblog/2009-02-04/download-the-basic-and-wicket-scala-talk-materials. Just try it and get introduced to the concepts of functional programming using the JVM and Wicket.

After all I had two nice evenings and learned a lot. I hope this article gives you some nice and hopefully new useful information!

Read the original at ApacheCon Europe 2009 community meetup experiences or go to the homepage of STUQ.nl

No related posts.