Bitcoins? Nope.

Voordat je gaat geloven dat bitcoins echt geld kan zijn, het volgende.

Redenen waarom bitcoins (nu) geen goed alternatief zijn:

- schaarste wordt gesimuleerd via energieverbruik: nu al meer dan een land als ierland

- enkele grondleggers hebben erg veel macht door het meeste-stemmen-geldt principe

- de transactieverwerking is veilig, maar mensen zijn niet goed in wachtwoorden en sleutels. Er is geen goede manier om normale gebruikers te beschermen tegen verlies van eigendommen

- beveiliging is gebaseerd op encryptie die per definitie op den duur onvoldoende zal zijn (al dan niet door quantum computers), er is geen mechanisme om het netwerk te voorzien van nieuwe standaarden zonder paniek/dumpen

- ook voor problemen rondom de snelheid van verwerken van transacties is geen duidelijke oplossing die het bestaande netwerk in stand houdt.

Wellicht zijn voor bepaalde problemen technische oplossingen mogelijk, maar of die doorgevoerd kunnen worden zonder dat de boel instort is maar zeer de vraag.

Misschien kunnen problemen rondom encryptie en snelheid via een veilig upgrade protocol opgelost worden? 

Misschien kan het systeem van energieverbruik voor schaarste ingezet worden voor goede doelen? Algemene computer processing die dan netto geen exra verbruik kost?

Wellicht is het probleem van grote bitcoin bezitters geen probleem bij een nieuwe munt met (heel) veel initiele deelnemers?

Bij elk van deze mogelijke oplossingen kom je uit op een nieuwe electronische munt, en dus niet bitcoin.

0 berichten

Jenkins pipelines tested

Checkout a full working setup of running tests on a Jenkins Shared Library using grails (which can be run using...... jenkins! yay)

Firefox is back!

Firefox is back. It is truly a relief to see that Mozilla with Firefox Quantum has managed to get the browser up to speed again.

Recent versions were plagued with excessive ram consumption, high cpu load, and very slow javascript loading.

It always used to be my favorite browser (open source is the only way), and now it will stay that way for even longer.

To get Firefox quantum you will, for now, need to download it as a beta release. This means there should be flaws, but it's actually so much better than other browsers that you will probably not notice the imperfections!

Strangling pipelines

A practical example about the strangulation pattern, as explained by Martin Fowler, applied to pipelines.

Read more here:

0 berichten

Thanks for the good times Eclipse, IntelliJ it is

Eclipse, starting with GGTS from SpringSource used to be the best editor for working with grails projects. During the switch to Grails3 though things have changed. The GGTS Eclipse plugin is no longer being maintained.

All this was not such a problem the first months or year even. After that Eclipse, Java, Groovy and Grails kept upgrading, but the plugin did not. This lead to more and more tiny problems and failing features. The last few months the experience of using Eclipse degraded so much that effectively using it became virtually impossible.

This has lead me to use IntelliJ (Ultimate), and getting a license for it. The experience is great. I can work on grails like I used to including auto suggest, refactoring, etc.

The downside, which kept me a long while from switching, is that IntelliJ is proprietary and this does not do much good for the open source community.


For Grails3 projects, using Eclipse is fine since most of the features will be offered by either the Groovy Eclipse plugin and the Gradle Eclipse plugin, both of which are supported really well.

For Grails2 projects, Eclipse is no longer.


Eclipse Oxygen and the Grails IDE

Eclipse Oxygen M1 (june) and Grails IDE now work together!



Below are the update site urls required to get the Grails-IDE archive (old!) working in the latest of eclipse IDE versions:

<?xml version="1.0" encoding="UTF-8"?>
<site url="" selected="true" name="AJDT"/>
<site url="" selected="true" name="Eclipse EPP 4.7 (Oxygen)"/>
<site url="jar:file:/opt/bwijsmuller/!/" selected="true" name="GGTS"/>
<site url="" selected="true" name="GrEclipse"/>
<site url="" selected="true" name="Oomph Latest Milestone"/>
<site url="" selected="true" name="Oxygen"/>
<site url="" selected="true" name="The Eclipse Project Updates"/>

Debugging a grails3 app with eclipse

Debugging applications in eclipse is easy if you're able to run them as java application main class.

Grails3 can be started by using the Application.groovy main class, thanks to spring-boot.

I tried this, but it failed. I added the 'build' scoped libraries by adding the 'dist' folder from the grails installation to the run job classpath. It still failed (in my case) because the application.groovy was not being loaded.

The application.groovy is optional, the default application.yml was loading just fine.

The fix was to add the grails-app/conf folder also to the classpath. This makes the source file available to the running process instead of the compiled class. Spring-boot loads it and everything works ok!

Getting rid of the nulls in your life

There's nothing so annoying as having written some pretty cool code, but then somewhere in the surrounding code suddenly a nullpointer exception appears.

Nullpointers are evil, I think that's pretty clear, but you as a developer can actually reduce the amount of possible nullpointers!

From the experience in projects I've worked on, it helps to:


1. Use final (immutable) fields on your class where possible. For hibernate entities this is often not possible or very inconvenient, but in other classes this prevents accidentally setting the field to null.


2. Apply the 'fail early'  principle. Don't let the troubles of inner components affect the outer ones. If bad things happen that cannot be resolved, such as invalid input on one of the public methods at the component, it usually means throwing a runtime exception. Don't just return null and make others do the dirty work.


3. Always describe the null case for non primitive return types on methods, in javadoc. If a method needs to return null, it is probably meaningful and worth to explain. If it never does, just say so. Clients of the component can then safely assume that the return value is nullpointer safe.

More reading:


0 berichten

Grails skipping unit tests

Every now and then the Grails (2) framework surprises me. Sometimes in a good way, and sometimes in the worst possible way.

It turns out that when the path your Grails project is in contains a percentage sign, the build does not work correctly. I've seen two effects (depending on various settings):

  1. Grails starts, but the compilation of plugin classes fails (classes not found)
  2. Grails starts, compiles, starts testing, but then does not actually run any tests.

The really annoying part in this is that there is no error message, no build failure, no warnings. Just silence, and unit tests are not being run. Sigh.

The Grails build system (not Gradle) does not handle paths very well. Always make sure that the path to your project is 'simple'. This means no funny characters and staying clear of common grails artifact names (and possibly even 'conceptual' names).


0 berichten

Outer joins and domain classes

When working with GORM domain classes and using DetachedCriteria (for example the 'where' method on domain classes), you will notice at some point that all joins will be inner joins!


If the database setup requires an outer (left) join, then the default ,GORM api has no way to specify this, so you will need a workaround.


This workaround works by looking into the GORM system at the moment just before the detached criteria become actual hibernate criteria. At that moment it is possible to use the Hibernate api itself that does allow specifying the relation join type.


The reason of the lack of support for outer joins seems to be that the detached criteria system is an abstraction not only over hibernate, but also over other NoSQL solutions that do not support this at all.

Here's the actual workaround (groovy code obviously):

List<?> listWithOuterJoin(DetachedCriteria criteriaBuilder,
    Map resultParameters, Map<String,String> outerJoinAssociations) {
       return criteriaBuilder.withPopulatedQuery(resultParameters, null) { Query query ->
           Criteria criteria = query.@criteria
           outerJoinAssociations.each { key, value ->
               criteria.createAlias(key, value, org.hibernate.sql.JoinType.LEFT_OUTER_JOIN)


  1. Create a detached criteria instance using any of the GORM api methods
  2. Use aliasses for the relations that you need an outer join for (example: for Person.children, their name can be referred to with 'c' as an alias meaning a reference would become in your criteria query)
  3. Feed the detached criteria to the helper method below together with a map of outer join aliasses in the form of ["children":"c"].
  4. The result (in this setup) is a list of results from the criteria

More info on detached criteria here.

0 berichten