About Adam Young

Once upon a time I was an Army Officer, but that was long ago. Now I work as a Software Engineer. I climb rocks, play saxophone, and spend way too much time in front of a computer.

The overhead of Java

A programming language is a tool. When choosing the right tool for the job, you want to have good information about it. I’ve worked with both C and Java, and have dealt with a lot of misconceptions about both. I’m going to try and generate some data to use in helping guide discussions about the different languages. Consider this, then as the next instalment of my comparison of programming languages that I started in my IPv6 days.

Continue reading

Map Reduce is kinda like “Normalize on the Fly”

One undervalued aspect of Data modeling is that you actually get time to consider the form of the data before you get the data. In a Map reduce job, you kow that your map phase is going to get the data, and that it is not going to be normalized . I could have said, not likely to be normalized, but the reality is that if you are using Map-Reduced, you are not going to get structured data.

Continue reading

Code Review Checklist

What follows is the results of a brainstorming session on items that should be in a code review checklist.  As you can see, it needs refining and grouping.  Please feel free to add comments with any items you think should be on it, with any organizational approaches, or any criticism.  Right now, I want to focus on inclusive instead of exclusive, so please don’t recommend removing things:  that willl happen later.

Continue reading

The Wrestle Off

The members of the team had rolled out the resilite mats in the back gym. The air was barely heated, so they had been hard to the touch as the boys rolled them in three straight sheets. The kinetic energy of a pair of teenage boys transferred to the friction of the shoes applied a sheering force that would separate untaped mats. That was acceptable during a normal practice, when the mats would be shared by a half dozen pairs at once. During a real match they would be taped together, to prevent them from separating during the bouts. The tape was an expense that the cash strapped athletic department wouldn’t waste on a practice. But there was no risk of separation during the opening half of this practice. The mats were rimmed with spectators, the members of the team focused on the two participants in the center. During a normal practice, the mats might be rolled out with either side up. The lesser used side had five circles, laid out like the dots on a die showing 5.

Continue reading

Facelets Taglibs

These are my notes on how to reverse engineer what tags are doing in a JSF application. In this case, I am trying to figure out what are the classes behind the Configuration tags in the RHQ.  I am trying to figure out what is being done by the tag

onc:config

This tag is activated with the following value at the top of the page:

xmlns:onc=”http://jboss.org/on/component”

To Figure out what this tag means, I look in WEB-INF/web.xml.  The web.xml value

facelets.LIBRARIES

Lets me know where the file is that defines the acceptable tags I can add to an xhtml page for this component.

/WEB-INF/tags/on.component.taglib.xml

This taglib defines the values

tag-name config
component-type org.jboss.on.Config
renderer-type org.jboss.on.Config

Note that these are JSF component names, and not Java class names.  To resolve these to Java classes, we need to find the mappings.  The mapping files are defined in web.xml under the entry:

javax.faces.CONFIG_FILES

In particular, I found what I wanted in

/WEB-INF/jsf-components/configuration-components.xml,

The values I care about are:

component-type org.jboss.on.Config
component-class org.rhq.core.gui.configuration.ConfigUIComponent

and the renderer for Config and ConfigurationSet components

component-family rhq
renderer-type org.jboss.on.Config
renderer-class org.rhq.core.gui.configuration.ConfigRenderer

This render extends javax.faces.render.Renderer.  This is a Flyweight that parses and generates HTML.  It has two main methods: decode an encode. decode parses the request that comes in, encode injects html into the response that goes out.

Decode appears to be called only on a post.  Encode seems to be called even on a get.

Backwards Alphabet

To Learn the Alphabet backwards, you need to have a mnemonic.  The mnemonic for learning it forward is Twinkle Twinkle Little Star.  We can use that same song to sing it backwards.  Here is the grouping

ZYX

WV

UTS

RQP

ONM

LKJ

IHGF

EDCBA

Now I’ve said my  my Z to A

Think I’ll go outside and play

Hers how the phrases of the original map to the backwards

ABCD  -> ZYX

EFG->WV

HIJK->UTS

LMNOP->RQP

QRS->ONM

TUV->LKJ

WX->IHGF

YZ->EDCBA

Don’t be surprised that some of the phrases are longer or shorter than you sing in the orignial, They don’t even have to match the number of syllables.  In many cases, you either drop the last note of the phrase, or double up on nodes.   For instance, the note where you sing ‘D’ does not have an analogue in the backwards one, as it is really a grace note between the BC phrase and the EFG phrase.

Swamped

Tyrone you are an artist of the ultimate degree
Your work I say if the truth be told
Is awesome, terrible a marvel to behold
Unfortunately I haven’t even one half hour free

So much to do but yet so little time
trying to plan all of the festivities
the country of Florin’s anniversary
Ensuring the wedding will just be devine
I can’t do everything I want
I’m Swamped

In the parade all the nobles will march
and if Duke follows baron the unrest will spread
And all these decisions will fall on my head
Which villain to hang from the victory arch
Everybody has something they want
I’m Swamped

Then theres the seating inside of the church
Ensuring we have the right food for the feast
Who will get Salmon or Chicken or Beef
None of the Nobles can be left in the lurch

Seating my Uncle Near my Aunt
I’m swamped

Rugen:
It certainly is hard waiting to be king
If I might be so bold as to suggest
set aside some time to get sufficient rest
If your’ve not your health you don’t have anything

You look just a little gaunt
You’re swamped

Refactoring: Introduce Builder

As I move more and more towards Immutable objects, I find myself extracting the building logic out from the usage of an object on a regular basis.  The basic format of this pattern is

mutable object =>  immutable object + builder

There are two aspects to using an object: creating it, and reading its state. This pattern splits those two aspects up into different object, providing a thread safe and scalable approach to sharing objects without restoring to locking. Modifications of the object are reflected by creating a new object, and then swapping out the immutable

There are two ways to go about making the builder. If the object is created as part of user interface or networking code, it make sense to use a generic map object, and in the build method, confirm that all required properties are there.
so code like:

if (inputStringKey.equals(‘x’)) obj.setX(inputStringValue);

becomes

builder.set(inlutStringKey, inputStringValue)
obj = builder.build();

If, on the other hand, the original object tends to be modified by other code, it makes sense to split the object so that the setters are on the builder object.  Thus the above code becomes:

builder.setX( x);
obj = builder.build();

The immutable object shouldn’t have getters, you should use public properties for them, make those properties public and immutable themselves. In Java, this means tagging them as final, in C++ make them const.

It the immutable object is fetched from a data store, there are two approaches to updating that datastore.  The simplest and least flexible is to have the builder update the store as part of the build function.  This mixes functionality, and means that you can only update a single object per transaction, but it does increase consistency of viewing the object across the system.  The more common approach is to have a deliberate call to store the immutable object in the datastore.  Often, this is a transactional store, with multiple immutable objects sent in bulk as an atomic commit.

Here are the steps to perform this refactoring:

1. Append the word builder to the class name

2. Create a new internal class for holding the immutable state of the the object and give it the name of the original object.  Give  the builder and instance member field of the internal type.  The internal class should have a no-args constructor.

3.  Push all fields down to the new class by  moving the fields .

4. Add a method called build that returns the internal type.

5.  Replace all calls of the form getProperty()  with

x=  builder.build() ;

x.property;

It is important to use the local variable, and to share it amongst all the places in the code that reference the local object.  If you don’t you will end up with one instance per reference, probably not what you want.

6.  Remove the getProperty methods on the builder.

7.  Give the internal class a constructor that takes all of its fields as parameters.  It should throw a standard exception if one of the parameters is null.

8.  Change the build method so that it returns a new instance, that gets all of its fields set via the new constructor.  This instance should just use the fields in the internal instance of the (soon-to-be) immutable inner object.  You will have to provide dummy initializers for the newly immutable fields.  The build method should thrown an exception if any of the values are missing or invalid.  It is usually required that you return all errors, not just the first one.  Thus this exception requires a collection of other errors.  These can be exceptions, or some other custom type, depending on the needs of your application.

9.   For each setProperty method on the builder, provide a copy of the field in the buidler object.  Make the corresponding field in the inner object immutable, and change the build method to use the field in the builder instead.

10. When you have finished step 9, you should have an immutable inner object. Provide an appropriate copy constructor.

11. Remove the no-args constructor from the immutable object.

12. remove the default values for the immutable fields.

You can now create a new builder object based on a map.  The keys of the map should be the names of the fields of the builder.  The Build method pulls the elements out of the map and uses them as the parameters for the constructor. This approach showcases one of the great limitations of Java introspection:  Parameter names are lost after compilation.  We only have access to the types and the order of the parameter names.  Thus, maintaining this map would be error prone.

A more performant approach is to extend the builder object above with a setProperty(String, String) method that sets the values of the builder fields directly.

Any Java object can act as a map if you use introspection.  Thus, you could do what the Bean API does and munge the key into the form “setX” by changeing the case on the first letter of the key name, and then calling

this.getClass().getMethod()

You could also use  property introspection like this:

this.getClass().getProperty(key)

Since you are using introspection, even though you are inside the class that should have access to private members, Java treats you as an outsider.  You can either drop permissions on the fields at compile time by making them public, or do so at runtime using one of various hacks.

This is one case where it makes sense to make the member fields public.  There is no information hiding going on here.  There may actually be some client codethat is better off calliing

builder.property = x

Than

builder.setProperty(x)

In C++, we have fewer choices, as there is no way either at run time nor at compile time to provide an iteration through the fields of a class.  The best you can do is to create a map of functors.  The keys of the map are again the fields of the builder, the values are functions which set the fields.  You end up with a setProperty function on the builder that looks like:

void setProperty(String& key, Strin& value){

propsetmap[key](value);

}

although with logic to handle erroneous keys.

A builder is a short lived, single threaded, mutable object.  It is up to the calling code to provide enough data to populate the builder.  The builder pattern works nicely with  inversion of control frameworks.  Code that uses an object should not call the builder directly, but rather fetch the object from the framework, where as code else where builds the object and adds it to the container.

If your code has interspersed sets and gets of properties, it is going to be really difficult to introduce the builder.  Chances are you are going to want to do additional refactorings to separate the concerns in your code.