Talk - Polyglot Persistance with Spring Data

I gave a talk on Polyglot Persistance with Spring Data as the J-SA conference.

Slides

Polyglot persistence with Spring Data from Corneil du Plessis

Sample Code

https://github.com/corneil/spring-data-demo

Video

Spring Data in 10 minutes

Spring Data in 10 minutes is a presentation I gave a few months ago at Jozi JUG as part of a series of lightning talks.
The source code samples at Github.
The Spring Data project can be found at http://projects.spring.io/spring-data

Spring Data in 10 minutes from Corneil du Plessis

Slides- Gradle: The Build System you have been waitng for!

I gave a talk at Devconf SA on Gradle.

Devconf was very well organised and the attendance was surprising. I think next year will need a large venue.

Gradle: The Build System you have been waiting for! from Corneil du Plessis

Dynamic Manifest with Gradle

Gradle makes it very easy to add dynamic information to the manifest of jar packages.

If you didn't know a jar is a zip file and the JVM will read the manifest from META-INF/MANIFEST.MF to determine the main class of an application or the classpath requirements of the specific jar and more. It is also useful to include version information to the manifest.

Let's look at an example:

jar {
    manifest {
        def buildId = System.getenv('BUILD_ID')
        if (buildId == null) {
            def hostName = System.getenv('HOSTNAME')
            def df = new java.text.SimpleDateFormat('yyyy-MM-dd\'T\'HH:mm:ss.SSSZ')
            def buildDate = df.format(new Date())
            buildId = "$hostName-$buildDate"
        }
        attributes('Manifest-Version': '1.0',
            'Implementation-Vendor': 'ACME Corp',
            'Implementation-Title': 'Road Runner Tracker Application',
            'Implementation-Version': buildId
        )
    }
}

The code in blue is the portion creating a buildId. In this case we are starting with the BUILD_ID environmental variable as supplied by a Jenkins build. If it is not present we want to use the hostname and the current timestamp.

You end up with a file that looks like this:

Manifest-Version: 1.0
Implementation-Vendor: ACME Corp
Implementation-Title: Road Runner Tracker Application
Implementation-Version: WILE-E-COYOTE-2016-02-03T12:00:00.000+0200

If you have a project with multiple sub-projects you notice all projects are repackaged during a build. This may not be big deal if your project has 5 or even 10 modules, but if your project has 300 modules and a repackage also means a publish to a remote binary repository the time penalty could be huge.

The solution is a simple one. Delay the evaluation of the manifest until the actual package task is executed. Gradle allows you to define closures with doFirst and doLast that are added before or after task execution.

jar {
    doFirst {
        manifest {
            def buildId = System.getenv('BUILD_ID')
            if (buildId == null) {
                def hostName = System.getenv('HOSTNAME')
                def df = new java.text.SimpleDateFormat('yyyy-MM-dd\'T\'HH:mm:ss.SSSZ')
                def buildDate = df.format(new Date())
                buildId = "$hostName-$buildDate"
            }
            attributes('Manifest-Version': '1.0',
                'Implementation-Vendor': 'ACME Corp',
                'Implementation-Title': 'Road Runner Tracker Application',
                'Implementation-Version': buildId
            )
        }
    }
}


The manifest is only evaluated when the closure doFirst is executed. The manifest model is used and the file created for packaging.

You will not be able to delay evaluation of all DSL this way. There are parts of the model that cannot be changed after the projects have been evaluated. 

Android security and permissions can be improved

Declaration of Love

Let me start by saying I love Android, I really do. As someone that uses it everyday I am constantly thinking about how I could improve on Android.

A little ranting

I believe there are some things about Android permissions and security that can be improved.
When it comes to permissions I have on occasion avoided installing an application because I could not understand why it would need a specific permission. If there was more information and control over the application use of permissions I would be more likely to try an application.

How do we improve the information? 

When you install an application you are presented with a list of permissions from the application manifest and you have to decide if you want to continue with the installation of update. If the manifest contained an optional description attribute that elaborates the reason it needs the permission displayed along with each permission is will be a lot easier for the user to make a choice instead of some description elsewhere.

How do we improve control? 

I would like to be able to set default options for different kinds of permissions like Allow Always, Prevent Always, Prompt for various permissions. I would like to override these permissions for each application.
If the option is Prompt and the application tries to use the permission the system will show the user a dialog asking for permission and displaying the description from the manifest with options like: Allow, Prevent, Allow Always, Prevent Always.
This way I can decide if this is something I want to allow and if the application was truthful in it's request for permission.

How do we improve installation security? 

The only current secure installation option I know of is the Play Store. I believe we need a mechanism where an enterprise can publish a descriptor/key to be installed on the device which will allow the device to trust a store hosted by the enterprise. This will allow an organisation to provision to limited audience from it's own repository without requiring 'Unknown Sources'.

And finally...

I believe these enhancements would not require an enormous amount of work. With sensible defaults the user experience should be excellent and intuitive. I really think these improvements will allow wider adoption of Android within corporate environments and improve the visibility users need to make sensible decisions regarding application permissions.

Why should you sign the Oath of Non-Allegiance

Alistair Cockburn has once again found a meaningful way to bring clarity to the software development lifecycle.

Read about the Oath of Non-Allegiance

Values in Design: Reduce Complexity

Why is software development so difficult? 

Why does software tend to become complex?  Seemingly clever humans revel in complexity.

How do you reduce complexity?

You need to measure the complexity and then make appropriate changes that will reduce the complexity.
Then you measure again to verify the results.

 Do we need measurements that are seemingly artificial and contrived?

Yes we need all the metrics we can get as long as we understand the meaning and application of the metric. Most software developed today has requirements to solve problems created by humans. The problems are already artificial and contrived. The problem space does not contain a set of coherent natural forces. Some developers are lucky enough to be working with a problem space that is to some extent more natural.

What do I mean by natural? 

Natural problems come from nature and where around before humans appeared on the scene. A natural problem space is a lot more testable than a human-made problem. It is simpler if mathematical models exist that can be simulated or used to measure outcomes. It is more complex if we need to discover those mathematical models. Not all aspects of software development have a neat underlying mathematical model. Thus we need to come up with mathematics and metrics to help measure the impact of various forces. We need to reduce complexity and so improve the design.

Measure, refine, refactor and verify.

Values in Design: Flexible Service not Flexible Interface

What values are important to you when designing a Service and an Interface? 

A lot has been written about the design of services. I would like to touch on why you design an interface and the values that I feel is important.

What am I talking about when I refer to an interface?

I am referring mostly to an interface that may be exposed by a service. I will use a web-service as an example.
When you design a web-service you are trying to produce an artefact that someone else will be using to communicate with the specific service. Chances are, the interface specification or WSDL will be all they have to describe the service.
This leads to the requirement that the interface specification be as simple and unambiguous as possible.

Why simple? 

We should be striving for simplicity in everything we do. Einstein said: Everything should be made as simple as possible, but not simpler.

Why unambiguous? 

Ambiguity is not required in an environment where people like to assume. Ambiguity is worse than complexity because complexity can be reverse-engineered.

So, where are the problems?

Consider that we want to communicate a model to someone who will be interacting with the model and providing it with content. We use a meta-model to do the communication. The WSDL specification is the meta-model. A WSDL file describing our interface is the model. The actual SOAP messages is the content.

Why then do so many interface try to describe a meta-model and not a model? This would not be too bad if it had some mechanism for discovery or the model. The problem lies in the fact that you need to understand the meta-model and model in order to interact with the interface. If the meta-model used is a standard specification you have removed a lot of ambiguity. If you build your own meta-model you have to provide a lot of extra information so that the consumer can understand your meta-model and then model.

The reason so many interfaces try to describe a meta-model is because the designer believes the interface needs to be flexible and may be expensive to change. It may be true that flexibility is required. However it will have to be flexibility that is required by the end-user of the system and will become a core asset of the system. The consumer of the service will have to be design so that it can adapt to the changes in model that is possible through this kind of flexibility. The flexibility argument does apply if you can envision the need but are only going build a specific case.

A flexible interface is a misnomer. 

It leads to ambiguity and the perceived simplicity is only a lie. The actual model still have to be communicated and understood unless the consumer is designed to extract the model and be flexible according to the model. This second option is not a flexible interface but a flexible service.

This potential impedance mismatch between an interface and the actual model is a challenge we face daily.

We will be rewarded if we get the design right!