Archive for February, 2006

The Tangled Web We Weave

Published by
amurphy
at February 24, 2006 in IT and Uncategorized. 0 Comments

A conversation over the proverbial water-cooler recently between myself and a DSI architect about the various agonies and ecstacies of CSS, Javascript and DOM manipulation led him to express surprise that a web designer from a creative background (me!) would be involved in such designer-unfriendly things as Javascript development. Funnily enough, I was thinking the same about him viz stylesheets!

In truth, CSS, Javascript and DHTML inhabit a fuzzy area between web design and presentation layer development/architecture (that fuzzy area just happens to be where I currently work). And while not all designers or developers need to make use of them all to the same extent, they are powerful and usable ways of presenting and manipulating HTML content, not to mention adhering to current W3C web standards.

HTML as we all know has a static presentation model. The browser parses, interprets and displays the marked-up content served to it. Which just sits there, looking pretty (or not). As the complexity of this beautifully simple idea developed sometime late last century, the infamous “tag soup” became more and more common - a well-nigh impenetrable bunch of structural and style tags including nested tables commonly (ab)used to control images and structure, and later, javascript to respond to user events - oh, what a tangled web we wove (to paraphrase this chap)!

In fact the rise of CSS is finally leading us in the opposite direction - back to simple mark-up, despite the increasing complexity of the contemporary webblication. Stylesheets allow us to separate structure from content in much the same way as ye olde HTML did, BUT with maximum control over the styling - so a simple collection of basic HTML and Div tags can be positioned and styled from a central stylesheet external to the served page e.g. www.decare.com.

DHTML allows a further level of control and user interactivity: Javascript, using the modern browser’s Document Object Model, can respond to user events to manipulate content - everything from simple image swaps on mouseover (don’t laugh, techno-kids, this is the primary feature that led to the universal browser take-up of Javascript during the Netscape/Microsoft browser wars!) to dynamically adding/removing objects, complex data filtering, etc. - all on the client side. Almost any HTML element can be both styled and positioned by CSS and manipulated as an object dynamically by Javascript, especially easily using the ID attribute to directly “capture” it without having to know its position in the object hierarchy.

In DSI we have used DHTML even more intensively in JSP Intranet apps, with Microsoft’s HTML Components concept allowing the even more modular use of client-side scripting - the .htc file contains javascript which can dynamically attach behaviours such as column sorting and the like to screen elements, and, uniquely, can be attached via style classes and IDs via the non-standard behaviour:(url) style attribute in the CSS. Of course this is only possible in a browser-controlled environment, but demonstrates the power of DHTML to approach the feature-rich functionality of FAT client software.    

The web may still be tangled, but adhering to standards and using good scripting practices may help us to negotiate a well-styled and usable route through it.

- Alan Murphy

Eclipse 3.2 M5

Published by
Yagiz Erkan
at February 20, 2006 in Java. 0 Comments

As of February the 17th, Eclipse 3.2 M5 (Milestone 5 release) is out. There are some interesting updates in this release that would please most of us:

Generate hashcode() and equals(): This functionality used be provided by the Jakarta Commons plugin. Now it comes as a standard functionality under the Source submenu (Source > Generate hashcode() and equals()…).

JUnit View: JUnit view now allows multiple concurrent test runs. Switching between tests is now possible, as well as starting new tests without stopping the running ones.

“Introduce Indirection” refactoring: It lets you redirect all callers of a method to a new method.

Multiple Quick Fixes: It is now possible to apply a quick fix or a quick assist to the whole file. “Ctrl + Enter” will do the job when the quick fix/assist window is open (as it will be indicated at the bottom of the popup).

Create and apply refactoring scripts: Now you can create scripts (Refactor > Create Script…) and perform refactorings by applying them on an arbitrary (Refactor > Apply Script…).

Type Selection History: There’s little improvement in the Type Selection popup too. Now it has a memory :). It remembers the last types used so that they are suggested first. So, for example, once you start to use java.util.List, you won’t get suggested java.awt.List as the first item in the popup window. The first type will be java.util.List because you’re already using it.

Detection of Method Parameter Assignments: Assigning to method parameters are considered poor practice by many. Now it’s possible to detect it by enabling the corresponding option (Preferences > Java > Compiler > Errors/Warnings > Parameter assignment).

Null Reference Analysis: Null reference analysis is added as part of the potential problem detection. You can enable it at Preferences > Java > Compiler > Errors/Warnings > Potential programming problems > Null reference.

Grouping Java Problems: The Problems view now has an option called Group By with 4 sub-options:

  • Type
  • Java Problem Type
  • Severity
  • None

Scalability Improvement: The memory requirement can now be lowered to 128Mb thanks to the recent improvements (Hmmm… Who wants to test this?).

Java SE 6.0 compliance.

- Yagiz Erkan -

The Joy of Test (or Why I Really Really Love Writing Unit Tests)

Published by
Brendan Lawlor
at February 10, 2006 in Agile and IT. 0 Comments

When you’ve been banging the drum for years about the importance of proper unit testing, a strange thing can happen: You can forget why you started banging it in the first place. On those rare occasions when I’m asked why we unit test, I recite a few decades of the Regression Rosary with the necessary reverence, before moving on to the Liturgy of Loose Coupling.

Well I’ve been right back at the coalface for the last few weeks, and it’s reminded me again why I started unit testing and why the only way I’ll ever give it up is when they wrench the green bar out of my dead hands.

The high-level reasons for unit testing are many and well known. They are detailed on websites like www.junit.org. And here is a particularly good way of explaining why unit tests are vital, using ideas from the heady world of bookkeeping.

But what I was reminded of in these past few weeks was how good it feels to use unit tests. This is something that has to be experienced to be truely appreciated. So allow me to share what it is about writing unit tests that I really really love:

I like to know when I’m done.

I can go home. Or get a coffee. Or go to lunch without brooding over a problem. With my regular fix of green bars, I can see that I’m making ground - and that I’m not going to lose that ground to regression errors the next time I make a change. I have distant and unhappy memories of working on code for weeks, knowing only that it compiled, and having to wait a very long time indeed to experience the inevitable ‘oh, you meant…’ moments that big bang integration will always provide. I don’t ever ever want to go back to that feeling of coding in the dark, sure that I’m planting bugs, but never knowing where - until it’s too late.

I like knowing what problem it is I’m trying to solve.

Ever get that feeling of drift? You’ve been coding for ages, but you don’t seem to be getting much closer to the goal. Maybe you’ve been writing code to do the wrong thing. It is so easy to get too caught up in the ‘how’ of a problem that you lose sight of the ‘what’. We’ve all done it, but it’s a lot harder to do when you have tried to code your unit tests before the class being tested. Why? Because the first question you ask yourself - when your fingers are hovering over the keyboard and the empty unit test is open in the editor - is ‘What is the damn thing supposed to be doing anyway’. It’s a great question that sometimes leads to a lot of other questions. And the proliferation of questions can get annoying and frustrating when all you want to do is get on with your application. Until you consider what kind of a mess you’d be in if you were faced with all these annoying questions after the code was written.

Once you’ve been around the Test First block a few times, the familiar feeling - that you don’t know enought about the requirements yet to code them - actually comes as a relief. Whew! I’m glad I didn’t spend a day wandering down that blind alley!

I hate pointless deployments.

When I was in my first year in university (late Jurassic/early Cretaceous) we learned to program using Pascal, and were obliged to use a three-pass compiler. You could hard boil an egg faster than that compiler could deal with a 100 line program, and when we were finally free to start using the phenomenon that was Turbo Pascal, we thought all our troubles were over. But something strange happened - we started to rely on the compiler to catch not only glaring syntax mistakes but even functional errors in our code. Instead of scanning the code to find the source of a problem, we thought “It only takes a few seconds to compile and run - lets just tweak this line here and see what happens“. It was a disaster. We left our brains at the door of the PC lab and succumbed to voodoo coding. We entered into frantic cycles of tweak-compile-run-check, and though compilation time was insignificant, the checking required us to go through all the steps of the running program to get the part that was broken. All this activity made us feel very productive, but it really just made us busy. We were no longer analysing, we were merely tinkering.

Some things never change - every half-decent IDE offers us the same kind of temptation when it lets us deploy quickly - even instantly. It might seem like a real fast way to track down a problem, but the same patterns as described above takes hold. This thrashing behaviour is compounded by the fact that most IDE’s have wrinkles when it comes to redeploying: Did the fix really get deployed? Have I just spend the last hour labouring under some misconception?

Presentation issues and anything involving browser-side processing still need to be eyeballed during a systems test. But most everything else can be unit tested - even Struts actions. I get a satisfying endorphin snack when I find that I can reproduce a system level problem in a unit test. I know that I’ve avoided the deployment frenzy trap, and I may even have found some issues that the requirements overlooked.

How many things are there out there that are both fun and good for you!?

It remains to be seen whether the arrival of JUnit4 has any impact on the fun factor in unit testing.
- brendan lawlor -

Securing your LDAP transactions to an Active Directory server instance (in Java) with little or no pain.

Published by
anthony geoghegan
at February 9, 2006 in Java and Security. 3 Comments

Typical LDAP transactions have little or no security attached to the authentication process.  Passwords are often not transmitted or worse, transmitted in the clear.

Active Directory LDAP logins use the UPN (User Principal Name) or windows login name (in the form DOMAIN\USERNAME) and not the usual distinguished name “cn=<user’s name>, cn=Users, dc=<domain>, dc=com” typical of an LDAP login name.  Thus capturing the login data used for an LDAP transaction gives you the domain username for a genuine domain user (and quite possibly the password in the clear as well!). The potential for abuse of insecure LDAP transactions within a domain is quite high.  Capturing this data with a “packet sniffer” is fairly trivial.

Fortunately an out-of-the-box solution exists!  Active Directory’s LDAP implementation will readily accept transactions with simple authentication (password transmitted in the clear), but it also accepts secure LDAP transactions wrapped within a SASL layer.

SASL is a security layer between client and server that defines how authentication data is to be exchanged, but doesn’t specify the contents of the data itself.  It’s a framework into which authentication mechanisms are plugged, to provide the actual security.  Sun’s JDK comes with a standard SASL implementation included. I’ve successfully used two SASL secure authentication mechanisms with LDAP transactions against and Active Directory instance.

The GSSAPI SASL mechanism is really Active Directory’s Kerberos V authentication (GSSAPI is the preferred way of using Kerberos within an application).  Kerberos authentications are very secure, but usually require a considerable amount of configuration (certainly with Sun’s implementation of the GSSAPI included with the Sun JDK from version 1.4 onwards).  A detailed look at the Kerberos authentication process and how it can be accomplished via JGSS is definitely one for another day.

The DIGEST-MD5 SASL mechanism is a much more viable option, with little or no configuration required in most circumstances.  Below is an example of configuring a SASL authentication process for LDAP in Java.

Hashtable env = new Hashtable();
env.put(”com.sun.jndi.ldap.connect.pool”, “true”);
env.put(”java.naming.security.principal”, “user@domain.com”);
env.put(”java.naming.security.credentials”, “mypassword”);
env.put(”com.sun.jndi.ldap.connect.pool.authentication”, “DIGEST-MD5″);
env.put(Context.PROVIDER_URL, url);
env.put(Context.INITIAL_CONTEXT_FACTORY, “com.sun.jndi.ldap.LdapCtxFactory”);
DirContext ctx = new InitialDirContext(env);
…

Yes, it is just that simple. By setting the following environment settings the level of security required can be dramatically increased.

javax.security.sasl.qop

The value of this property is a ‘,’-separated list of quality-of-protection (qop) values used to specify the client’s qop preference. A qop value is one of

  • “auth” - authentication only
  • “auth-int” - authentication plus integrity protection
  • “auth-conf” - authentication plus integrity and confidentiality protection

The order of the list specifies the preference order. If this property is absent, the default qop is “auth”.

javax.security.sasl.strength

The value of this property is a ‘,’-separated list of cipher strength values used to specify the client’s preference. A strength value is one of

  • “low”
  • “medium”
  • “high”

The order of the list specifies the preference order. If this property is absent, the default strength is “high,medium,low”.For privacy in DIGEST-MD5, “high” maps to “3des”, “medium” to “rc4″ or “des”, and “low” to “rc4-56″ or “rc4-40″.

Note:  Two potential gotchas exist!

1. Make sure the url for the LDAP service uses a domain name and not just an IP address or Active directory will complain with:

   The digest-uri does not match any LDAP SPN’s registered for this server

If no domain name is mapped to the LDAP server, a simple addition of a “fictional” domain name within the etc\HOSTS file will alleviate the issue.

2. When the DIGEST-MD5 mechanism is used, the Active Directory user has to be configured to store its password in a reversible manner.  Otherwise, it’s impossible for the LDAP server to validate the password.  Since MD5 is not itself reversible the LDAP server must be able to decrypt the user’s password from the SAM database in order to make the password validation.

Links: 
Using LDAP and SASL with JNDI
JNDI, Active Directory & Authentication

- Anthony Geoghegan

Declarative Programming (Business Rules)

Published by
nkeating
at February 3, 2006 in IT. 2 Comments

Complex business logic is the main issue that keeps developers awake at night. As the application evolves, it’s very hard to write and maintain this code.

The problem behind this is that this cannot be easily solved using standard imperative programming style (imperative programs are a sequence of commands for the computer to perform, e.g. languages like Java, C++ …). The most straightforward approach is to use declarative programming (languages that describe a problem rather than defining a solution, e.g. Prolog, SQL, XSLT) i.e. you are not saying “how” the computer should do it, but “what” it should do.

Since we are using an imperative programming languages one common way to avail of benefits that declarative programming brings is to use a Rule Engine or Expert System. Wikipedia defines the use of a rule engine in IT as follows:

“For any application the business rules change more frequently then the rest of the application code. Rule Engine or Inference Engines are the pluggable software components that separate the business rules from the application code. This allows the business users to modify the rules frequently without the need of IT intervention and hence allowing the applications to be more adaptable with the dynamic rules.”

Simple example
An imperative method for ensuring you have your sunglasses if the sun is shining would be:

  1. Step outside and determine if it the sun is shining.
  2. If the sun is shining, then get sunglasses from shelf

The above could also be represented by two declarative rules:

If it the sun is shining
Then you need you’re sunglasses

If you need your sunglasses
Then get them from the shelf

Given declarative rules, the knowledge that it is sunny could produce two
courses of action:

  1. You already have your sunglasses, perhaps because you’re cool, in
    which case, you’re ready.
  2. You don’t have your sunglasses, so you go get them from the shelf.

This allows you to use the knowledge you have and respond to that knowledge in the most appropriate way. You could, for example, already know it is sunny and simply get your sunglasses from the shelf. If you thought the sun was going to shine you could add another rule to the ones above:

If the sun might shine later, and
If you’ll be away from the house
Then you need your sunglasses

At this point, you only need to get your sunglasses if you know you don’t already have then, and either the sun is shining, or that it might shine later while you’re away from the house. If you were to write that all out in procedural code, it’d quickly get tangled and complex.

Some of the advantages of the declarative method:

  • Simpler (i.e. cheaper) maintenance
  • Reduced development time for complex business logic
  • Higher performance, due to the algorithm optimization (business logic doesn’t run more times than necessary)

It might be surprising to discover that rule engines receive a lot of attention in the insurance claims, tax preparation, and medical industries. Sometimes, just having a system that can sift through reams of data and highlight the extreme cases can be of tremendous help.

Jess - Java Expert System Shell
Jess is the JSR-94 reference implementation. The syntax for the rules definition in Jess is based on LISP. The cost of learning a new language to define rules was considered too high to justify the uses of Jess for projects here in DSI. Coupled with that, Jess requires a license for commercial use. However, there is an interesting article on when to use a rule engine. I would disagree with the conclusions on ROI we saw payback almost immediately. This was mainly due to changing requirements.

Drools

“Drools is a Rules Engine implementation based on Charles Forgy’s Rete algorithm tailored for the Java language.”

Here at DSI we are using Drools. Currently rules can be written in Java, Python and Groovy. It supports the JSR-94 specification. This is not as important as it would seem as the specification only defines the interaction with a rule engine. So even though we can switch between rule engines by changing Spring configuration files, in pratice this would require a rewrite of the rules themselves to comply with the new engines rule syntax.

Drools adds another convenience to writing rules called Decision tables.

“Decision tables are a useful way to represent conditional logic in a compact format. This format is also readily readable and editable by non technical users (such as business analysts). Drools decision tables can utilise a spreadsheet (such as Excel) as the means to capture decision logic, in a user friendly way.”

We then take the spreadsheet and use a converter that converts these rules into drools-rules representation.

In conclusion
Declarative programming, for many, is a completely alien paradigm which should warrant a careful and thoughtful study before attempting to write “live” code. In some respects, Jess’s use of a LISP like syntax help people make that paradigm shift. Failing to do so can result in inefficient rules and seemingly unpredictable results. Debugging can be extremely difficult without an understanding of how the underlying system is working. Rule engines have many advantages, but on the other side they can be dangerous if you don’t know exactly what’s going on.

- Noel Keating
- Michal Bali