[ {
                                "some" : {
                                    "nested" : {
                                        "json" : "with value",
                                        "anothervalue": 4,
                                        "withlist" : [
                                            { "name" :"name1"} , {"name": "name2"}, {"anothernested": { "name": "name3"} }
                                        ]
                                    }
                                }
                            },
                            {
                                "someother" : {
                                    "nested" : {
                                        "json" : "with value",
                                        "anothervalue": 4,
                                        "withlist" : [
                                            { "name" :"name1"} , {"name": "name2"}
                                        ]
                                    }
                                }
                            }
                        ]

$[*].some.nested.withlist[*].anothernested[?(@.name == 'name3')]

assertThat(json).array().field("some").field("nested").array("withlist").field("anothernested").field("name").isEqualTo("name3")

{
    "property1": [
        { "property2": "test1"},
        { "property3": "test2"}
    ]
}

$.property1[*][?(@.property2 == 'test1')]

assertThat(json).array("property1").contains("property2").isEqualTo("test1")

Features are not only functionalities

Let's define some facts: IT is paid by the business. Business wants features. IT has to deliver features to gain money. That's a fact and our reality. Even if you hear from your managers that "cleaning technical debt is a necessity" what they really think is:

And actually that's not bizarre - business has no understanding of the technical aspects of the IT work. Here we can discern two types of business people:

• they don't get technical aspects, but they trust the engineers
• they don't care about technical aspects and they won't listen to any of the programmers' advice

If you have the latter business people then most likely you're in this situation:

and actually you should be doing such a shift:

https://www.technalytical.com/2012/04/aesthetical-cable-management-before-and.html

In order to grow faster. What makes me really surprised that continuously the business picks the first option - just add more mess to the existing one without thinking of the consequences.

Now for the tricky part. Now change the word "business" to "developer" and everything is still valid.

"Delivering a feature" it's not only coding some functions in whatever language you are using. It's not taking a keyboard and pressing the keys to make the functionality work. If this is your approach then you're a key tapper. Tapping keys to get things done.

Programming is more than tapping keys

I don't have time for this - it's not my problem. I've delivered my business feature and this is what I'm paid for. What you're referring to is not of my interest.

Technical changes are not bringing money

Why do we want these changes to happen? Because they ease our work and enforce standards. Why are standards important?

"Pick a plug they said, it's gonna be easy, they said"

https://abdulinnewzealand.wordpress.com/2012/12/03/new-things-from-my-visit-to-new-zeland/

If every team in the company uses different:

• libraries
• approach to testing
• approach to deployment
• approach to running the application

Then you can tell your business that they will pay A LOT of money for the support. The learning curve will be gigantic for the newcomers. But hey! It's better to code a new functionality in the meantime right?

Seemingly all the developers would like to see the effect of those migrations and standardization. Everybody wants this to happen but who should actually do it? When asked about this you might hear:

I don't have time for this - it's not my problem. I've delivered my business feature and this is what I'm paid for. What you're referring to is not of my interest.

• the "coding team" writes a business feature and pushes it to master
• the "clean code team" rewrites the code according to the clean code standards
• the "technical team" introduces the technical standards for the written piece of code
• the "migration team" migrates the code from one approach to another

The outcome of the cooperation could look like this:

Good idea

Introduce... caring! Invest a lot of time and effort in educating business and developers that you have to take care of the code quality. Imagine where your company would be if every programmer would focus for 1 hour per day to manage the technical debt. If your managers don't understand the importance of clearing that debt, then you should consider changing jobs cause it's going to get worse with every single push to the repo.

You are an engineer!

Developing a feature is not just typing in code that compiles and makes the tests pass. Maybe the constant breathing of the project manager on your neck made you forget about this but you are an engineer. Following Wikipedia:

An engineer is a professional practitioner of engineering, concerned with applying scientific knowledge, mathematics, and ingenuity to develop solutions for technical, societal and commercial problems. Engineers design materials, structures, and systems while considering the limitations imposed by practicality, regulation, safety, and cost.^[1][2] The word engineer is derived from the Latin words ingeniare ("to contrive, devise") and ingenium("cleverness").^[3][4]

I don't have time for this - it's not my problem. I've delivered my business feature and this is what I'm paid for. What you're referring to is not of my interest.

My schedule is tight but I'll fix the issues that you suggested. I understand that delivering business value means writing a feature and making the technical progress as a company. This is what I'm paid for and what you are referring to is part of my duties. 

Are you an engineer that has a say? You're gonna get fired!

Epilogue

Additional reading

• For monolithic applications we had plenty of unit, integration and end to end tests
• The different types of tests covered the same functionality up to three times
• The tests took a lot of time to run

• A lot of unit tests executed during build time
• Some integration tests running on stubs of dependent services executed during build time
• Not many acceptance tests running on stubs of dependent services executed during build time (these can be treated as special case of integration tests)
• A handful of smoke tests executed on a deployed application to see if the app is really packaged properly

• No need to deploy dependent services
• The stubs used for the tests ran on a deployed microservice are the same as those used during integration tests
• Those stubs have been tested against the application that produces them (check Accurest for more information)
• We don't have many slow tests running on a deployed application - thus the pipeline gets executed much faster
• We don't have to queue deployments - we're testing in isolation thus pipelines don't interfere with each other
• We don't have to spawn virtual machines each time for deployment purposes

• No end to end tests before production - you don't have the full certainty that a feature is working
• Due to this certainty that the functionality is working decreases
• First time the applications will talk in a real way will be on production

• unit and integration tests are ran
• validity of declared stubs specifications is tested against the application itself

• excluded JS minification
• benefit: 13 countries * ~60 secs * at least 2 modules where minification occurred ~ 26 minutes
• optimized GWT compilation: 
• have permutations done for only 1 browser (by default it's done for multiple browsers)
• disable optimization of the compilation (-optimize 0)
• add the -draftCompile switch to to compile quickly with minimal optimizations
• benefit: about 2 minutes less on GWT compilation * sth like 5 projects with GWT ~ 10 minutes

package com.blogspot.toomuchcoding.spock.subjcollabs

import spock.lang.Specification
import com.blogspot.toomuchcoding.spock.subjcollabs.Collaborator
import com.blogspot.toomuchcoding.spock.subjcollabs.Subject

class ConstructorInjectionSpec extends Specification {

    public static final String TEST_METHOD_1 = "Test method 1"

    SomeOtherClass someOtherClassNotToBeInjected = Mock()

    @Collaborator
    SomeOtherClass someOtherClass = Mock()

    @Subject
    SomeClass systemUnderTest

    def "should inject collaborator into subject"() {
        given:
            someOtherClass.someMethod() >> TEST_METHOD_1

        when:
            String firstResult = systemUnderTest.someOtherClass.someMethod()

        then:
            firstResult == TEST_METHOD_1
            systemUnderTest.someOtherClass == someOtherClass
    }


    class SomeClass {
        SomeOtherClass someOtherClass

        SomeClass(SomeOtherClass someOtherClass) {
            this.someOtherClass = someOtherClass
        }
    }

    class SomeOtherClass {
        String someMethod() {
            "Some other class"
        }
    }

}