Mike`s Blog

I've been playing around recently regarding visualization of dataflow in Java applications. It seems that there are tons of tools to inspect the control flow, but I had no luck yet finding something which can visualize the amount of data and the type of data flowing through complex systems.

Not being an AOP guru, i wondered if there was something else to use. Something, which is unobtrusive and can be applied to existing systems. The first thing i'm trying is Java's Debugging APIs, namely JDI, to automatically step through a program and record method entries.

• Comment (1)
• Trackbacks (0)
• Continue reading "Visualizing Dataflow"

What happens in the first minute after you tweet?

When you post an update to your Twitter status (engl. to tweet) which contains a URL, there is going to be some automated reaction from the network. Let's examine what happens after I've tweeted the following:



The first thing happening within seconds is that Twitter's own bot (Twitterbot/0.1) performs a request to see if the URL is valid. The IP 128.242.241.133 is hosted at dedicatedserver.com, an NTT company located in San Jose. The data center seems to be the same where Twitter itself is hosted. They do not retrieve the contents (they're using the HEAD command instead of GET), perhaps to resolve redirects from shortened URLs.

• Comment (1)
• Trackbacks (0)
• Continue reading "A tale of a Tweet"

We all know that passwords ought to be strong - strong enough to withstand common attack vectors, such as brute-force dictionary attacks or plain guessing. Most software systems with identity management also incorporate some kind of password policy enforcement and their configuration options (here, here, here and here).

There are even commercial standalone tools focusing on enforcing password policies. For example, the Password Policy Enforcer by Anixis or Specops Password Policy. Many of these products enable administrators to define policies and configure rules to prevent users from chosing weak passwords and comply to corporate security policies.

In this blog post, I'd like to show the principle steps in implementing a password policy enforcement component using flow rules, decisions and scoring (bonuses and penalties) to calculate the strength of a given password using Visual Rules. In contrast to commercial tools, which often already integrate with domain controllers, this example only shows the rules, not how it could be integrated into the Windows domain or into a web application.

• Comment (1)
• Trackbacks (0)
• Continue reading "How to implement password policies using business rules modeling"

Logging is some weird kind of aspect of software development. It's a necessary evil so to say. On the one hand, it's great to have the flexibility to either log in a file or to console, to roll the files, to enable certain log statements at runtime etc. But on the other hand, there are so many logging frameworks and so manyof them did wrong in their first encounter, it became quiet insane.

A few years ago, driven by the well-known problems of commons-logging, we've switched over to slf4j with log4j as engine. I don't regret that, as I like the slf4j-api and modularized design. I also kind of like log4j - its log4j.xml, its debug system parameters and that its practically spread all over the Java world. Yes, sure, there are some minor drawbacks, like the inability of the log4j committers to provide clean Maven pom.xml files for some version. Did they fix that btw?

Anyway, to cut a long story short: i've played around with Neo4j and Maven and came up with a quick Maven Repository scanner which counts the dependencies from reverse: it shows how often a certain artifact is referenced by another project as dependency. The data basis was my local repository (11988 artifacts) and it's surely biased to some degree. I'll try to get a clean Maven Repo mirror some day and rerun the experiment.

The winner is:

1162 times used (9,69%): org.slf4j
867 times used (7,23%): log4j
837 times used (6,98%): commons-logging


There is other interesting information in that experiment, like
20,33% of the artifacts are using junit, thereas 1,9% use testng. 21,13% use the Spring Framework and 6,45% of all the Maven artifacts in my repo use the javax.servlet spec. Easymock is used by 5,62% of the artifacts. Other popular libraries include com.sun.xml.bind, commons-lang, asm, Xerces, Apache Camel, Jetty, javax.xml.bind, javax.xml.soap, wsdl4j, commons-collections, Ant, Apache Cocoon, Apache Abdera, org.eclipse, commons-io, cglib, hibernate, velocity, woodstox and derby.

• Comments (0)
• Trackbacks (0)

How does my company/my team score at The Joel Test?

Let's see...
1. Do you use source control? YES
2. Can you make a build in one step? YES for most products, NO for others.
3. Do you make daily builds? YES
4. Do you have a bug database? YES
5. Do you fix bugs before writing new code? NO
6. Do you have an up-to-date schedule? NO. Either it changes too often, or stuff gets moved, or we're behind the schedule because we forgot something to do.
7. Do you have a spec? NO
8. Do programmers have quiet working conditions? NO. Coders interrupt each other very often.
9. Do you use the best tools money can buy? NO. The only good commercial tools are PL/SQL Developer and JProfiler. All others are open-source or other free tools with bad usability or incomplete integration (e.g. The Gimp, M2Eclipse)
10. Do you have testers? NO
11. Do new candidates write code during their interview? NO
12. Do you do hallway usability testing? NO. Occasionally we do, with at most 1 other "user".

Final score: 4/12

According to Joel, that's above average, but still too bad. We'll have to work on that.

The things i'm going to change next:
5) - fixing existing/known bugs before writing new code/new features.
2) - making all our high-level builds automated, not only single artifacts.

What concerns me most is point 7), although I haven't got a clear idea why and how to write a spec for something which is already being built. The current plan is to use the user's manual and developer's manual, extract abstract information and then detail it out into an architectural overview documentation.

• Comments (0)
• Trackbacks (0)