Baby Led Development

With a baby in the house, one has little time and energy available for side-projects.  It is, therefore, important to be efficient with your time in order to make any progress when you do find yourself with a spare moment.

Recently, I have begun a side-project and found a couple of ways that my development has been ‘baby led’.  Firstly, I knew I needed a database for the project. As I was familiar with it, I decided to use Liquibase for the schema definition. Once up and running, and with a basic model in place, I began to think about adding in an ORM, but very quickly ruled it out. At this stage, I decided, it would add little benefit.

I’m not saying an ORM would be wrong for this project, but the interesting thing to me is how quickly I decided I could live without one.  In the past, or if I had more time, I probably would have included one without much thought (and then gone on to add Spring too ;)).  I can always add one later on if I feel it’s necessary and by then the model is likely to be more stable anyway.

Another tactic I have used is to do all my workflow prototyping in unit tests. This allows me to quickly experiment and refine the model and functions without polluting my src/main area.  I can then promote code from src/test when it is ready or more mature.

I don’t claim to have any ground breaking thoughts or ideas in the above. I just think it is interesting how I adapted my development in,  what I think is, a good way and that I might not have done so without being a Daddy.

ActivePivot: Member Properties and Analysis Hierarchies (together at last).

Analysis Hierarchies

Analysis hierarchies^* are one of the key features of ActivePivot.  They allow data, aggregated in a compressed/OOP form, to be expanded dynamically at query time from a single aggregated Object to display its components individually against derived MDX Members.

A classic use case is a set of VaR scenarios that are aggregated in an array object, but are displayed with an MDX member for each scenario.

Member Properties

A standard feature of the MDX language is Member Properties.  These allow meta-data to be included with a member.  On a Pivot Table in Excel, these member properties can be displayed in a tool-tip when the user selects the member cell.  For example, a product name could be the member value, with its serial number as a member property.

In ActivePivot, Member Properties are implemented as extended plugins and then instantiated as defined for hierarchy levels in the cube schema, e.g.:

<level name="Product">
    <memberProperties>
        <property name="Serial No." pluginKey="ProductSerialNumber"/>
    </memberProperties>
</level>

Together at last

Unfortunately, this will not work for Analysis Hierarchies^**, because their levels are created programmatically based on the plugin implementation of the hierarchy with no reference to the cube schema file.

To add member properties to an analysis dimension, one can override the createLevels() function in their class that extends ActivePivot’s external class AAnalysisHierarchy, and use reflection^*** like so:

@Override
protected List createLevels() {
    List levels = super.createLevels();
    levels.stream()
            .filter(l -> !ILevel.ALLMEMBER.equals(l.getName()))
            .forEach(l -> {
                    l.getLevelInfo().getMemberProperties();
                    try {
                        Map<String,IProperty> analysisMemberProperties = new HashMap<>();
                        analysisMemberProperties.put(
                                "memberPropertyName",
                                Registry.createExtendedPluginValue(ICustomProperty.class, AlternateFormat.PLUGIN_KEY, new Object[]{"alternativeFormattedValue"})
                            );
                        FieldUtils.writeDeclaredField(l.getLevelInfo(), "memberProperties", analysisMemberProperties, true);
                    } catch (IllegalAccessException e) {
                        throw new RuntimeException("Unable to set level member property for analysis hierarchy", e);
                    }
                });
    return levels;
}

^* Known as Analysis Dimensions in verions prior to ActivePivot 5.
^** At least not in versions 5.1.5 or lower.
^*** The field is type final.

[Reblog] 10 Modern Software Over-Engineering Mistakes

I have seen all of these and plead guilty to quite a few of them too…

10 Modern Software Over-Engineering Mistakes

Few things are guaranteed to increase all the time: Distance between stars, Entropy in the visible universe, and Fucking business requirements. Many articles simply say “Dont over-engineer” but don’t say why or how. Here are 10 clear examples.

Violated

I have, at different times, had various opinions on how to treat static analysis violations.

Using Find Bugs and Sonar Way rules, I initially saw any violation as an insult to my code and would do my best to fix all of them.  I realized, however, that this sometimes led to repetitive safety checks (null pointer) or additional code that I didn’t really want.

It’s better not to have violations, of course, but on the other hand, one doesn’t want to add too many lines of code unnecessarily or use additional libraries to fix issues that aren’t really there.

I now have a more pragmatic view and believe that the all violations should be treated as advisory.  It’s better not to have them, but it’s not always necessary to fix them.

The evolution-of-a-software-engineer joke comes to mind.

When working as a team, I think it is enough to have the following principles:

• Try to avoid introducing new violations
• For existing violations, have periodic reviews of the reports together as a team and identify those that should be fixed.

 

 

 

 

[Reblog] Write code that is easy to delete

Great article here…  Write code that is easy to delete, not easy to extend.

• “Projects either fail or become legacy code eventually anyway. Failure happens more than success. It’s quicker to write ten big balls of mud and see where it gets you than try to polish a single turd.”

 

Testing Dojo Modules that need the DOM

This is a short post to summarize how I test Dojo 1.x modules that need the DOM.  In the future, I plan a more detailed post along with a Dojo 1.x playground repository on BitBucket with real examples, but for now I will just outline the steps I took.

The testing framework that Dojo 1.x uses is not adequate (at least as far as I could tell).  I wanted to be able to run all my tests in a build script, even those that require the DOM.

The following two articles gave me what I needed:

1. Testing react with jsdom.
2. Dojo and Node.js

 

From the first article, I borrowed the test framework and the use of jsdom to set global DOM variables.  From the second article, I borrowed the method of loading node modules with the Dojo loader.  That allowed me to load the should.js assert library in my dojo tests, which report to mocha.

define([
    "main/foo",
    "dojo/hash",  // we are going to use the DOM.
    "dojo/node!should"  // import node module, should, which will report to mocha.
],
function(
    foo,
    dojo_hash,
    should
) {

 

To run the tests, mocha calls the following bootstrap file.  Note that, unlike in the linked article, dojoConfig sets “dom”:1.

// ---------------------------------------------------------------
// Create a DOM object and set global variables.
// ---------------------------------------------------------------
var jsdom = require('node-jsdom')
document = jsdom.jsdom('<!doctype html><html><body></body></html>')
window = document.defaultView
location = window.location;


// ---------------------------------------------------------------
// Configure dojo
// ---------------------------------------------------------------
// Array of test modules to run
dojoTestModules = ["test/main/foo", "test/main/bar"];

dojoConfig = {
    baseUrl: "../../..", // Where we will put our packages
    async: 1, // We want to make sure we are using the "modern" loader
    hasCache: {
        "host-node": 1, // Ensure we "force" the loader into Node.js mode
        "dom": 1 // Ensure that the code assumes we have a DOM
    },
    // While it is possible to use config-tlmSiblingOfDojo to tell the
    // loader that your packages share the same root path as the loader,
    // this really isn't always a good idea and it is better to be
    // explicit about our package map.
    packages: [{
        name: "dojo",
        location: "dojo-src-full/dojo"
    },{
        name: "dijit",
        location: "dojo-src-full/dijit"
    },{
        name: "dojox",
        location: "dojo-src-full/dojox"
    },{
        name: "bootstrap",
        location: "app/bootstrap"
    },{
          name: "main",
          location: "app/main"
    },{
         name: "test",
         location: "app/tests/mocha/"
     }],
     deps: dojoTestModules 
};


// Now load the Dojo loader
// This will run all the tests in dojoTestModules
require("../../../dojo-src-full/dojo/dojo");

GW150914: First results from the search for binary black hole coalescence with Advanced LIGO

I’m humbled to be a co-author on this companion paper to the GW150914 detection paper.

http://arxiv.org/abs/1602.03839

As I said before, many congratulations to all involved.

“Proxy Aspects and @ManagedResource do not work together”

Mucsij!  You had the exact same problem as me (only nine years ago).

There I was, in my day job, with a classic case of XKCD‘s Wisdom of the Ancients.

In this instance, the forum was dead, so I couldn’t even try to track Mucsij down.  Fortunately, I was able to solve my issue after some time of pain and head-desk interactions.

In my case, the problem was that my @EnableAspectJAutoProxy  annotation needed proxyTargetClass set to true (default is false) – see stackoverflow.com/questions/10664182/what-is-the-difference-between-jdk-dynamic-proxy-and-cglib for an explanation on the difference.

If you are out there Mucsij, I hope you also found a solution.

 

LinkedIn Confidential

“Your name has been referred to me confidentially as someone I should be speaking with…” – A. Recruiter.

Hmmm, you could say that to everyone.

Gravitational Waves

A huge congratulations to the LIGO team on their recent announcement of the direct detection of a gravitational wave signal.  It is an amazing achievement and thoroughly well-deserved.

I had the privilege of working in a sub-team of the Ligo-Virgo Science Collaboration that analyzed six months of the initial LIGO (and Virgo) data, as part of my PhD at Cardiff University and, hence, I know many of the people involved in the collaboration today.

They are a fantastic group, whom I have huge respect for, both personally and professionally.  Many, such as my former supervisor Bangalore Sathyaprakash, have dedicated their careers to this work.  No doubt, many of my younger former colleagues will do likewise, only their focus will now be on new discoveries and observations with this new window on the Universe.

Interestingly, the history of gravitational wave ‘detection’ announcements is a little bit dodgy and there have been one or two false-starts (though not from the LIGO collaboration).   This history had led the LIGO group to be extremely cautious and thorough in terms of detection criteria and public statements.

Consequently, as a former ‘insider’, so to speak, I was well aware that when a press conference was announced, it could only mean one thing… a very significant detection result, that had been rigorously analyzed and vetted.