Random Thought On The Internet

This is one of the random thoughts that usually pop right into my head when I least expect it.

I was on a work trip. One of those where you get to travel to exotic destinations but all you get to see is the office, the company cafeteria and the hotel. I was having dinner at the hotel and I started thinking of how come people have this strange need to aggregate in some area. How did people start living with other people, and how did they manage to eventually take this concept to such gigantic proportions as to create today's biggest cities, with millions and millions of individuals living close to each other.

The first reason I thought of was procreation and the continuation of the species: a certain gene pool needs a minimum degree of diversity in order to avoid extinction. Did humans in the upper palaeolithic or in the mesolithic really think along those lines? Probably not. So here I am, I'm not very good at running, hiding, or throwing spears. I can't hunt for food, but I'm good at growing legumes. If I find someone who's good at hunting, maybe we can trade food. Now, wouldn't it be easier if the two of us lived relatively close to each other instead of a half-day walking distance? I haven't studied anthropology, archaeology or any related branches, but that kind of makes sense to me.

Without going that far back in time, just think that a hundred years ago a grain of black pepper needed to travel for months to reach Europe, from south west India to Italy, but people could still find black papper in grocery shops, because they lived in human settlements where specialisation of roles could support a complex social infrastructure: different people can do different things and provide different needs, but they need to be in relatively close proximity in order to maximise their reciprocal advantage.

In physics, this is equivalent to a system trying to find its equilibrium by minimising its energy. An electron in an excited atom "prefers" to drop to a lower energy level if that level is not already full. This is what the electron thinks: what's the point in doing so much work just to keep running like mad in a "higher orbit", when I could just cruise casually around a "lower orbit"? So the electron "drops down" an energy level and sheds the excess energy in a flash of light. And no, I haven't studied much physics either, but that kind of makes sense to me.

Extrapolating the principle of minimising a system's energy, here's what a human might think instead: what's the point in spending half a day travelling to buy some food, load up enough food to last me a while (because it's not like I'll do this again tomorrow, or the day after), then carry all that food back home and manage its storage, when I could just move downtown and simply pop down to the corner shop whenever I need to?
The real achievement in moving downtown, in really fancy terms, is not that I have found a low-energy equilibrium. My half-day walk has become a two-minute stroll. The 20 kilometers between the shop and my house have become less than 100 metres. By moving downtown I have effectively compressed space and time.

Today, as a human living in the remote countryside, I don't actually need to move at all, but I can still compress space and time. How? With Internet, of course. I don't need to live in relatively close proximity to other humans and human structures: I need to move to wherever there is an Internet connection and a postal service, and these might well exist in the remote countryside as well as downtown. So will internet reverse the process of urbanisation, or at least will it make such reversal possible? I think so. Virtual offices, internet videoconferencing, voice-over-IP, news streaming, bla bla bla... it's all there already. The recent hype of "going green" even encourages to great extents to stay where you are, avoid travelling, avoid lighting up an entire office or unnecessarily loading the public transport system if you can work from home. The fascination for "going downtown", perhaps, will eventually be confined only to touristic attractions. I'm not saying people will have no more reasons for sticking together in organised physical conglomerates: I'm just saying, IMHO, that there will be a lot less of a motivation to do so in the future.

M.

Expressions in IceFaces Navigation Targets

I must write this lest I forget.

I've been working on an exception handling mechanism for a JSF-based application using IceFaces, and I was thinking... "why oh why can't we dynamically navigate to error pages using a navigation rule?"
Navigation rules in the faces-config.xml look like this:

<navigation-rule>
    <from-view-id>/somePage.xhtml</from-view-id>
    <navigation-case>
        <from-outcome>error</from-outcome>
        <to-view-id>/errorPage.xhtml</to-view-id>
    </navigation-case>
</navigation-rule>

That is fine but very limiting for my navigation purposes. What if I want to navigate to a different page according to the actual error code? In other words, I want to be able to do this:

<navigation-rule>
    <from-view-id>/somePage.xhtml</from-view-id>
    <navigation-case>
        <from-outcome>error</from-outcome>
        <to-view-id>/#{errorBean.errorCode}.xhtml</to-view-id>
    </navigation-case> </navigation-rule>

Well, it seems that I can't do that with the Sun JSF RI or IceFaces, so I decided to make it happen. I figured that if I wanted to add expression evaluation in a navigation target URL I needed to write a view handler. With IceFaces, the application view handler is com.icesoft.faces.facelets.D2DFaceletViewHandler, which is reponsible for setting up the direct-to-DOM rendering etc, so I needed to extend that class and find what methods I needed to override in order to get me to where I wanted to be. After a bit of experimentation I found there are two scenarios:
Scenario #1: Navigation Rule With Redirection
This is where the navigation rule has a <redirect/> tag. The method in D2DFaceletViewHandler that handles this is

public String getActionURL(FacesContext context, String viewId)

Scenario #2: Navigation Rule Without Redirection
This is where the navigation rule does not have a <redirect/> tag. The method in D2DFaceletViewHandler that handles this is

public void renderView(FacesContext context, UIViewRoot viewToRender)

The way I decided to process the expression is very simple, almost elementary:

1. Parse the URL/ViewId looking for a sub-string that begins with '#{' or '${' and ends with '}' 
2. capture the sub-string and create a value binding to evaluate the expression 
3. Replace the expression in the URL/ViewId with the actual value 
4. Process the newly evaluated URL/ViewId

Before I get any comments on step 1... no, I don't like regex because my brain just doesn't get it, and it takes me considerably longer to figure out a regex pattern to capture such a simple substring than to actually write a few lines of code to do the parsing.

So here's my (edited) code.

/**
* Constructor
*/
public MyViewHandler(ViewHandler delegate) {
    super(delegate);
}

/**
* Processes a view id that may contain an expression, by evaluating the
* expression and replacing the expression tag in the original view id with
* the expression result.
*
* @param context The faces context.
* @param viewId The view id to process.
* @return The processed view id.
*/
private String processViewId(FacesContext context, String viewId) {
    String processedViewId = viewId;

    int startExpression = processedViewId.indexOf("{") - 1;
    if (startExpression > 0) {
        char expChar = processedViewId.charAt(startExpression);

        // expressions start with # or $
        if ((expChar == '#') || (expChar == '$')) {
            int endExpression = processedViewId.indexOf("}", startExpression);

            if (endExpression > startExpression) {
                // viewId contains an expression
                String expression = processedViewId.substring(startExpression, endExpression + 1);

                try {
                    ValueBinding vb = context.getApplication().createValueBinding(expression);

                    if (vb != null) {
                        String evaluatedExpression = vb.getValue(context).toString();

                        // replace the expression tag in the view id
                        // with the expression's actual value
                        processedViewId = processedViewId.replace(expression, evaluatedExpression);
                    }
                }
catch (ReferenceSyntaxException ex) {
                    // do nothing: processedViewId = viewId;
                }
            }
        }
    }

    return processedViewId;
}

/**
* Used to process a URL that may contain an expression. If a navigation
* rule in the faces configuration file has a <redirect> tag, this
* method will be used to process the URL specified in the
* <to-view-id> tag
*
* @see javax.faces.application.ViewHandler#getActionURL(FacesContext, String)
*/
@Override
public String getActionURL(FacesContext context, String viewId) {

    String processedViewId = super.getActionURL(context, viewId);
    processedViewId = this.processViewId(context, processedViewId);

    return processedViewId;
}

/**
* If a navigation rule in the faces configuration file does not have a
* <redirect> tag, this method will be used to process the URL
* specified in the <to-view-id> tag
*
* @see com.icesoft.faces.application.D2DViewHandler#renderView(FacesContext,
* UIViewRoot)
*/
@Override
public void renderView(FacesContext context, UIViewRoot viewToRender)
throws IOException, NullPointerException {

    String viewId = this.processViewId(context, viewToRender.getViewId());
    viewToRender.setViewId(viewId);

    super.renderView(context, viewToRender);
}

To use my spanking new view handler I just have to change the application section in the faces-config.xml file:

<faces-config>
    <application>
        ...
        ...
        <view-handler>
            <!--
            com.icesoft.faces.facelets.D2DFaceletViewHandler
            -->
            myViewHandler
        </view-handler>
    </application>
</faces-config>

M.

Finding Kokkyu

This is about one of those amazing discoveries in my world of Aikido.

I'm walking fairly fast to reach home before the Simpsons start on TV. I get to an underpass to get to the other side of a large busy road. I have a 5-year-old sitting on my shoulders, let's say about 20 kilograms. I have my techno-backpack on my back, let's say another 10 kg, for a total of 30 kg concentrated on my neck and shoulders. I am also pushing a buggy with a 1-year-old, for a total of, say, another 10 kg. The underpass, by definition, routes me downhill at first, then across, then uphill, and it's during the uphill phase that I start struggling.

Instinctively, I simply stretch out my arms to push the buggy, and compensate the additional weight on my neck and shoulders by tensing the muscles in my upper body.

WRONG! That's hard work!

Then it just dawned on me: I relaxed my shoulders, dropped my weight towards my hips, energised my forearms, putting just a tiny bit of zanshin on each step... and there I was, cruising uphill without noticeable effort!

Aikido will never cease to amaze me.

M.

2309

sorridi come una volta al chiaro del mare ai sogni di luna su un volto solare		smile like you used to in the brightness of the sea to your moondreams on your sun-kissed face
canta ai colori del mondo alle amate colline alle palme incantate con la tua voce eterna di brezza d'estate		sing to the colors of the world to your loved highland to the enchanted palms with the eternal voice of a summer breeze
vola sereno oltre le mura di tutti i colori senza paura senza dolori		fly unworried over these walls of all colors without fear without pain
ecco un artista! un autore un sole un padre		here is an artist! an author a sun a father
adesso solo un pianto e un sussurro un ultimo ciao		and now only a cry and a whisper one last hello
luceran ancora le stelle		the stars will shine again

M.

Architectural Agility - Part 1

Software Engineering is a wonderful world full of surprises and challenges. We learn early on in life that any activity that floods your system with adrenaline is an addictive activity.
In the life of a ten year old, this might take the form of climbing a tree for the first time, ascending to seemingly unreachable altitudes with a non-zero probability of following that up with weeks of hospitalisation.
In the life of a programmer, this might be the result of producing thousands of lines of code under deadlines that you never considered even remotely realistic.

Let's face it: the feeling of impending doom is just great.

In the life of an architect, the main perverse sense of doom and destruction originates from the fact that you are supposed to shape the system in your head, then somehow implant that picture in the heads of over 50 developers, and pray that you've been clear enough with your specifications.
The uninitiated might rightfully ask "Why? Just write the darn specs and pass them on: if they're good developers, they'll work them out..." Alternatively, "Ever heard of agile?".

Well, I don't know about the rest of the world, but in my projects I've never managed to do either. Usually, the situation involves very vague or even yet-to-be-discovered requirements, and only one or two agile developers in a team of 50-plus. So how have I managed so far? Well, it's surely a continuous learning for me, and I still discover something new almost on a daily basis, but here are some points that I have picked up along the way and found very valuable.


#1 : Learn how to produce on-the-fly specs
Why? Because on one hand I have this very hazy and almost monochromatic picture of the requirements, on the other hand I have 50 developers expecting fairly detailed specifications of what they are going to produce, and somewhere in the middle I have a bunch of reasons for being unable to cultivate an agile team.

#2 : Learn how to be ALWAYS available for the team
Why? Perhaps it's just me, but on-the-fly specs are NEVER good enough.


#3 : Learn how to monitor progress all the time
This doesn't mean to become a control freak, but rather to understand the dynamics of the project and minimise the risk of producing the wrong thing due to sub-optimal specifications. Why? Because 50 developers, over (officially) 8 working hours in a day, makes 400 hours/day of code writing and testing time. In one week, that's at least 2000 hours, or about one developer/year worth of effort. That means that failing to convey an architectural concept for the system and leaving 50 developers alone for a whole week translates into seriously refactoring one developer/year worth of code, which is not something you usually do in your spare time. It's like steering the proverbial oil tanker: one mistake in plotting the route, and it will take considerable effort trying to get it back on the right track if you don't spot the mistake right away.


#4 : Functional refactoring is inevitable
Why? Well, due to all of the above. However, I tend to view refactoring as falling into one of three categories: architectural, functional, and schematic.
Architectural refactoring is serious: that is what happens when we change parts of the architecture , for example when half way through the project we realise we need a caching framework for our web application.
Functional refactoring is somewhat less serious and could be considered a minor version of architectural refactoring: that happens when we change some of the application's behavior, for example when we move hard-coded values to some configuration file, and surely when we are bugfixing.
Schematic refactoring is standard routine: that is when the application's functionality is unaffected while changing its internal structure, for example when we abstract common functionality from several classes into one parent class, or formalise common class contracts into interfaces. I'm now learning to shape functional refactoring into an agile project in its own right, and probably write some considerations on that in another post.

M.

The Eternal Beginner

Recently, I've been thinking about my learning journeys in the wonderful world of Takemusu Iwama Aikido. In particular, I've been trying to understand the changes in my "learning methodology", for want of a better term. In other words, how do I actually manage to learn a technique, and how has that approach changed over time?

I could go on for days trying to explain this, but I'll try to summarise the main ideas here.

When I first started practising Aikido, I would try to learn a technique by thinking only of my own body movements. I would look at my sensei offering his right wrist, moving his right foot a little on the side, settle his hips, then turn 180 degrees and face the other way, before adjusting his left foot into hanmi. I would then try to replicate the exact movements, step by step, with clumsy results at first, but then progressing to make my moves smoother and more efficient. The whole process would be based on the mindset of "how do I move my body so that I end up in this or that position?".

I later figured that analysing my own would only be stage one (out of many) for learning a technique, and nowadays I try to learn a technique by going through as many stages as possible, as I'll shortly explain.

Stage two is when I start to look at my training partner's movements instead of mine. Different people have different body shapes, different statures, different degrees of mobility, and so on. It wouldn't make much sense to me to learn a technique through one sequence of my own body movement, and expect the same sequence of movements to work without fail on any training partner. Stage two would therefore be based on the mindset of "how do I move my body so that my training partner ends up in this or that position?".

Stage three is when I start considering the communion of the situation. It's not about my own body, or my training partner's. It's about the combination of both: what shapes they make, what balance they achieve, and so on. This is where my mindset goes somewhere along the lines of "how do I move my body to induce my training partner to move in such a way that we both end up in this or that position?".

The next stage is about direction and redirection of energy. This is when I usually focus on the "path of least resistance": if it's hard to move around my training partner in a particular way, then chances are it's the wrong way. For example, if my training partner is pushing, why should I push back? It's a lot easier to follow his/her lead and pivot around that energy vector, modifying (even if only slightly) the vector's components. This then leads my training partner to follow the new vector, so my mindset would then be "how do I move my body to redirect my training partner's energy in such a way that we end up in this or that position?".

I noted that there is a very clear similarity between the last two stages of training awareness, but there is also a very important different: the former is static, whilst the latter is dynamic. I have also noted that all of the above stages are still focused on my own body movements, albeit with very different mindsets, and I find this extremely interesting because, at the end of the day, that's what I think is the actual nature of a martial art: mind over body.

I am sure there are many more stages of training awareness, but that's pretty much where I am at the moment. For example, for anyone knowing this terminology, all of the above are my consideration on ki-hon forms. I haven't even started considering the type of mindset involved in ki-no-nagare forms. Who knows, maybe one day...

M.

Hi There

Call this a warning, a disclaimer, or whatever you like.
I'm starting this blog to share my personal views on different subjects.
In other words, these are my experiences, and these are the ways I've travelled my own path.
It's just a bunch of information that someone might or might not find useful.

In the end, if only one person finds any of this stuff useful in any way, then I will have done something good with my time.

Enjoy.

M.