Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:
JavaWorld Daily Brew

jhannes

Thinking Inside a Bigger Box

Johannes Brodwall's Musings on Software Architecture and Programming. RSS feed


Effective Enterprise Java at Öredev


Just three weeks ago, I was asked to step in for Ted Neward to give a tutorial at Öredev on Effective Enterprise Java. As I did not have time to get the tutorial materials printed, I present them here on the web for the participants and others.

Read more ...

Your rating: None

Testing Servlets with Mockito

Tags:

When I write Java-projects that produce web pages, I test on several levels. First, I use Jetty and WebDriver to test the result via http. (WebDriver even lets me test JavaScript!)

But for speed and agility, unit-level tests beat even the fastest integration level tests. Unit tests run much much faster, and lets me pinpoint problems much more accurately. As a general rule: If you introduce a bug, you want a unit test to be the one that sees it first.

Read more ...

Your rating: None

Extreme Integration: The future of software development?


What will the daily experience of software development look like, say, five years from now? Have our current processes reached their peak, or will the world continue to change? Alan Kay said “the easiest way to predict the future is to invent it.” Here are some ideas of the future I want to invent: I hope it will be dramatically better than what we currently do.

Read more ...

Your rating: None Average: 1.5 (2 votes)

Unit testing tricks: Using unit tests to validate static code

Tags:

In my current project, we use Flex as the user interface framework of choice. Flex has some nice features, but it takes a long time to build changes and start up, so it takes a while to validate our changes. Yesterday, we found a problem with one our UI components, and used JUnit to hunt down the same problem all over our code.

Read more ...

Your rating: None

Unit testing tricks: Look ma, no setters!


Here’s a neat trick if you want set an object in a specific state in a unit test, but you don’t want to violate encapsulation:

Read more ...

Your rating: None Average: 1 (1 vote)

Cool algorithm


Back to:
www.javaworld.com/javaworld/jw-03-2009/jw-03-lamport-otp.html
.

I found it a little hard to understand the underlying security aspects. Is the security of the algorithm based on the fact that the successor-function F is hard to reverse? So that if

A = F(B)

Then it's hard to reverse F? So that knowing A and F will not help you find B?

Secondly, is it correct that the algorithm is insufficient to establish trust? It merely verifying that a visitor is a returning user.

Finally: Is there a common way to handle it if the client runs out of keys?

0

How to stay ahead


This is a test case from my current project:

Scenario: Finish gathering information
Given I have an open case
And the case has a task "gather information from X"
And the case has a task "gather information from Y"
When the user confirms that task "gather information from X" is completed
And the user confirms that task "gather information from Y" is completed
Then the case should generate a new task "evaluate customer standing"

It seems pretty run of the mill. A tester will sit down with a bunch of these and try out the application.

Read more ...

Your rating: None

Refactoring on @Ignore


Doing the Code Dojo at Oslo XP meetup last Monday, I realized a new concept that I’ve been using unconsciously for a while: I only add to the structure of my system when I have a test that cannot be satisfied by the current design. The rules of test-driven development tells me to wait to create a more advanced design until I have a reason to do so. And that reason should be a failing test. However, the rules of refactoring require all tests to be green during a refactoring. So the failing test must be Ignored during the refactoring.

Read more ...

Your rating: None

Planning by value


Agile development is easy to understand and hard to do. One of the hardest things to do is to base plans and actions on value instead of effort.

An article by Alistair Cockburn includes a story that illustrates the point:

A boy is behind on his German language home work. He now has to read ten stories and answer a set of question for each. He will be graded on the number of correct answers.

Read more ...

Your rating: None Average: 3.3 (3 votes)

Five unit testing tips #4: Don’t mock your way into accidental complexity


I’ve all but stopped using mock objects in my tests. The reason is that mocking have had a detrimental effect on the design of my systems. I’ve often ended up having the mocks trick me into adding a needless layer of indirection that does nothing except delegate to the next layer, just to satisfy the mocks.

Read more ...

Your rating: None

… but please do repeat me


The hard choice between duplication, paralysis and chaos

A common programmer credo is “Don’t Repeat Yourself” (Pragmatic Programmer) or “Once and only once” (Extreme Programming). Like all credos, we risk following it even when it is not appropriate.

The larger truth is that we have choice between three evils:

Read more ...

Your rating: None

Five Unit Tests Tips #3: Parametrized test methods


The following is a trick I don’t use very often, but when I do need it, it comes in very handy. It’s a trick that many developers aren’t aware of, even though it’s been possible to do with JUnit at least since version 3.

Sometimes you want to have a lot of tests that are almost the same, but that contain different arguments. For example, for a yahtzee calculator, you might want to have the following tests:

Read more ...

Your rating: None Average: 4 (1 vote)

Architecture as tidying up



Unstructured picture

Read more ...

Your rating: None Average: 4 (1 vote)

Simpler Java deployment?

Tags:

“The service went down because another service running on the same application server went down.” “You can’t use the improved version of your programming language because you’re running on the same application server as some old applications.” “We can’t help you deploy your application on the application server, because we’re busy with some other application.”

If you’ve ever heard any of these statements, you’ve been victim to the accidental complexity of the application server.

Read more ...

Your rating: None Average: 4 (1 vote)

Keep the build clean


Have you ever looked at a list of compiler warnings the length of an essay on bad coding and thought to yourself: “You know, I really should do something about that… but I don’t have time just now”? On the other hand, have you ever looked at a lone warning that just appeared in a compilation and just fixed it?

Read more ...

Your rating: None Average: 4 (1 vote)
Syndicate content