Parrot Compiler

I posed the question of what the importance of the Parrot Compiler groovy is (ELI5) on the groovy slack channel http://groovy-community.slack.com.
And got an answer direct from Guillaume Laforge

the syntax of Groovy hasn’t evolved in a long time

the current / old parser is a bit complicated to evolve

and is using a very old version of the parsing library

so any change we’d want to make to the language (a new operator, for example) becomes very complicated

So we’ve been wanting to upgrade the underlying parser library for a while, but since the library evolved a lot, that also required a rewrite of the grammar of the language

But there’s another thing to consider

Groovy’s always been adopted by Java developers easily because of how close to the Java syntax it’s always been

so most Java programs are also valid Groovy programs

it’s been important to Groovy’s success to have this source compatibility

Java 8's been out for a while already

and we’ve been asked countless times if we’d support this or that particular syntax enhancement from Java 8

for “copy’n paste compatibility”, if you will

We decided to upgrade to a newer version of our parsing library (from v2 to v4 of Antlr)

to allow Groovy’s syntax to continue to evolve

to also support new operators and things like that

but to also support Java 8 constructs, for continued compatibility

And that’s about it :slightly_smiling_face:

Would a 5yo understand my explanation?

Spam email

Sometime spam email is so bad it is pure comedy genius. The amount of things wrong with this opening statement.

It is my pleasure to inform you that Diplomatic Agent Terry has arrive in yournearest Airport today with your package worthy $5.5million you have to contacthim at this email address (diplomaticagentfredjames33@gmail.com) 

Side effects with not having decent UNIT tests

This is not Grails/Groovy specific but in general.

Grails/Groovy is certainly more reliant on tests, as it is dynamically typed, so code needs to be executed to pickup errors. The Java world seems to rely on static typing while Groovy on tests. Tests are always better than typing, period.

Besides the obvious, if it is not tested how do you know it works? There are some interesting side effects I see with poorly unit tested code.

Makes your Code Better

• Having to write unit tests for a class/method makes your code structurally better.
• It leads to better separation of concerns. 
• Starts enforcing the law of Demeter. 
• Easily tested code is generally easier to understand. 

Documents Code

• Documentation falls out of date and quickly becomes irrelevant. Properly written tests (Spock helps) is a great way to document code. 

Makes changing existing code possible

• I cannot change existing if I have no idea if it works, or how it works. 
• In larger systems knowing if existing code works without tests becomes increasingly difficult.
• It can be very difficult to execute see what code is doing if you need to stand up the whole system just to test a method.

Quicker to Change and Safer to Change

• If your code has a unit test you can execute it immediately.
• You can see changes, and what they do to existing tests immediately
• 100's of times an hour.

Intellij Color Schemes

Found a neat little site with colour schemes for Intellij

http://color-themes.com/?view=index

Once you have downloaded the jar, just go to File->import settings and load that jar.

Grails3 GORM running MongoDB

Had some issues getting Mongo to work with Grails3 based on this doc, ended up creating an example project of it all working

Feel free to download, have a look

Spock data driven testing with interactions (Mocks)

You can do data driven testing with Mocks and interactions, the key is that your interaction should be in the setup: block For Example

    @Unroll
    def "createOtherField test to see if label override works #fieldName override(#fieldLabel) == #resultName"() {
        setup:
        FormFieldMapManager formFieldMapManager = Mock()
        String onlineFormId = '1'
        List<LabelValue> otherFields = []
        1*formFieldMapManager.getMappedFields(onlineFormId, false) >> [new FormFieldMap()]

        expect:
        List<LabelValue> result = ProcessorUtil.createOtherField(formFieldMapManager, onlineFormId, otherFields, fieldName, 'fieldValue')
        result[0].label == resultName

        where:
        fieldName   | fieldLabel    || resultName
        'fieldName' | null          || 'fieldName'
        'fieldName' | ''            || 'fieldName'
        ''          | null          || ''
        'fieldName' | 'OVERRIDE'    || 'OVERRIDE'
    }

Intellij H2 Database viewer

For some reason to be able to see you tables in the Intellij H2 DB viewer you have append the following mv_store=false in your application.yml so the connection string looks like so:

jdbc:h2:file:./devDb;MVCC=TRUE;LOCK_TIMEOUT=10000;DB_CLOSE_ON_EXIT=FALSE;mv_store=false