A few weeks ago I started publishing eye-catching images (created using Canva) on Twitter, showcasing many interesting features of the Micronaut Framework.The idea behind this project is to share a quick tips and hints with the people browsing their Twitter feed.If you like this short form of content, then here is the collection of all published Tweets in their chronologial order:

What do you think about this content form?Is it worth creating?Let me know in the comments' section below.Thanks in advance!

Groovy has always had much more powerful switch statements compared to Java. Class case values, regular expression case values, collection case values, closure case values, or at the end, equal values case. All these options made the switch statement a first-class citizen in the Groovy world. And now, following the latest updates in the Java programming language, Groovy also supports a switch expression. The main difference between a switch statement and a switch expression is that the latter introduces a syntax compatible with Java and returns a value. You can still use a variety of combinations as cases, but the new syntax will make your code a bit more elegant.

Records, a handy immutable "data carrier" type, were introduced in Java 16. Now, they are also available in Groovy. The same syntax, though Groovy also introduces a @RecordType annotation that you can use interchangeably. And even if this is not that a game-changer as it was for Java, it’s good to see Groovy heading up with the latest features introduced in its mother language.

Another feature influenced by the latest changes in the Java programming language. Sealed types allow you to restrict which classes (or interfaces) can extend the specific sealed type. It can be done either explicitly (using the "permits" keyword) or implicitly (without any keyword) if all relevant classes are stored in the same source file. Similar to records, Groovy also introduces the @Sealed annotation that you can use interchangeably if this is your preference. When to use sealed types? Maybe you don’t want to allow anyone to extend your class for security reasons. Or perhaps you want to add new methods to the interface in the future, and you want to have strict control over affected subclasses. If that’s the case - sealed types might be something you want to look at.

Even though Groovy is mainly known for its dynamic capabilities, it allows you to be much stricter in type checking than Java. The newly added groovy-typecheckers optional module introduces a regex checker that can help you catch errors in your regular expressions at the compile time. Just like in this example - we have a regular expression missing a closing parenthesis. Typically, the compiler cannot detect this kind of issue, so we either find it in the unit test or at the runtime. Here I run this script in the GroovyShell, so I can catch the expected MultipleCompilationErrorsException.

Macro methods allow you to access and manipulate the compiler AST data structures. The macro method call looks like a regular method call, but that’s not the case - it will be replaced by the generated code at the compile time. Here are a few examples of such macro methods. For instance, the SV method creates a string with variable names and associated values. The SVI one uses Groovy’s inspect method, which produces a bit different output - for instance, it does not unroll the range object as shown in this example.

If you are familiar with Groovy, you already know that every Groovy class implements the GroovyObject interface. There’s nothing to worry about if you only stay with your code in the Groovy ecosystem. But sometimes, you want to use Groovy to write a library code that can be used in a pure Java project as well. You can bring those two worlds together with the new ' @POJO ' annotation. Any class annotated with the @POJO annotation can be used without adding Groovy at the runtime. Just like the PojoPoint class shown in this example. Let’s compile it and run it as a Java program.

Groovy contracts might be a blessing if you are tired of writing defensive code. The @Invariant class annotation defines assertions that are checked during an object’s lifetime - after the constructor call, before, and after the method call. The @Requires annotation represents a method precondition - an assertion executed before the method call. And the @Ensures annotation works as a method postcondition - an assertion executed after the method call. Some may say that these annotations can be easily replaced by explicit assertions in the method’s body. And that’s true. But if you want to keep the contract and the business logic nicely separated, Groovy contracts sound like a good place to start.

Groovy-Integrated Query language. You will love this feature if you are a fan of SQL-like languages. GINQ allows you to query collections using a SQL-like syntax. Just like in this example. We have a JSON document containing the people field. We use GINQ to find all people that are 18+, in descending order, taking the first three results and modifying the returned data to be upper-cased and limited to the first two letters only. As far as I know, the Groovy team plans to extend GINQ to support SQL databases so that you can write a compile-time generated and type-checked SQL queries.

Groovy 3 added YAML format support, and now Groovy 4 adds TOML format support as well. Helpful if you are working with such a format in your codebase. It is worth mentioning that the output produced by the TomlBuilder class does not produce table headers but dot-separated field names instead.

The minimum Java version required to run Groovy 4 is JDK 8. You may ask - "but how does Groovy handle, e.g., records"? Let me show it to you. Here I have Java 17 and Groovy 4.0.1. I’m gonna compile this script to the class file, and when we open it in IntelliJ, we can see that it produces a Java native record equivalent as expected. Now I’m gonna switch to Java 8, and let’s do the same thing. When we open the class file in IntelliJ, we can see that now the generated class "emulates" a record behavior but does not use the native record syntax. And that’s the beauty of Groovy code portability - the same code and brand new language features that work even with a pretty old Java version.

Below you can find two exemplary JSON files we are going to merge recursively, including combining unique elements from all arrays.

And here is the jq code that does the job:

We define deepmerge(a;b) function that merges two JSON objects recursively.

There is one thing worth explaining.You can see that in the line , we check if params.AGENT is equal to "any".If this is the case, we put an empty string instead.(An empty string in this case is an equivalent of agent any - source.)Otherwise, Jenkins would search for the node with label "any" instead.

In the line , we define a list of available nodes.When you start the job and choose any from the dropdown, any available node will be used to run the job.If you choose docker, windows, or linux (or any other label you will define in your pipeline), the node with that exact label will be used to run the job.And that’s it.

Gradle (an open-source build automation tool) collected the most votes - 190 out of 308 (61.7%).

Spock Framework (a testing library for Java and Groovy applications) collected 157 votes (51%).

Grails Framework (a Groovy-based web application framework for the JVM built on top of Spring Boot) collected 116 votes (37.7%)

I was close to guess the exact TOP 3 - I thought it is going to be Spock, Gradle, and Grails (in this particular order.)The Groovy Console result surprised me, and especially when it’s compared to the groovysh - I definitely prefer to use a command-line tool instead of GUI-based one.

There is also a positive trend in the Jenkins Pipeline space - much more people use Groovy with pipelines instead of Job DSL plugin.

Also, Micronaut and Spring Boot are head-to-head when it comes to the number of users, but it’s hard to deduct anything from those numbers.

I was also surprised by the CodeNarc, Geb, and Picocli small numbers.The last two are used in the specific context, which may explain the number of votes.However, CodeNarc is a static analysis tool for Groovy, and I would love to see more people using it to improve their code quality.

There are my first thoughts after looking at the survey results.And what are yours?Let me know in the comments bellow. 👍

The survey was launched on August 28th, and it was collecting the answers up to September 11th.It contained a single multi-choice question with predefined options to choose from, plus a text input to vote for a thing that was not mentioned on the list.It was announced using many communication channels, including the Groovy mailing list, Groovy Community Slack, Twitter, LinkedIn, Reddit, etc.The survey link was clicked 520 times, and it was converted to 308 responses (59.23% conversion rate.)

(PS: I will run a similar survey next year so that we can study changes in trends. 😉)

First, you need to install jq in your operating system - https://stedolan.github.io/jq/download/

To convert JSON file to the CSV format we will need a JSON file that is represented by an array of objects.In this tutorial, I use Github’s Jobs API that returns JSON in that desired format.Below you can find a curl command that searches for open kotlin job positions and stores the result in the jobs.json file.

And here is how we can convert input JSON file to the CSV format.

Let’s deconstruct it piece by piece.

The easiest way to merge two maps in Groovy is to use + operator.This method is straightforward - it creates a new map from the left-hand-side and right-hand-side maps.The below example illustrates it clearly.

However, this method has one limitation - it doesn’t perform a so-called "deep merge" operation.Any nested map won’t get merged - it will only override the left-hand-side map entry with the one from the right-hand-side map.Just like in the example shown below.

You can see that the final map contains the z key.However, the value it stores comes from the right-hand-side map only.

It can be fixed by implementing custom merge(lhs,rhs) function.

It starts with the inject function, which is an equivalent (or close equivalent) of the reduce or fold functions from other popular programming languages.It takes two parameters - the initial value (the lhs.clone() in our case), and the two-argument closure that receives the current accumulator (the map variable from our example) and the current map entry from the iteration.

In the next step, we need to check what is the type of the specific map key.If the same key stores a map in both maps, we call a merge function to create a new value as a result of merging two nested maps.Otherwise, we just copy the value from the right-hand-side map.

It looks like we are ready to go, but what if maps we are merging contain e.g. a list of numbers?

Our current implementation does not support merging nested lists.Let’s fix it.

The solution to this problem is simple.We need to add one more condition.

It works!

Groovy supports runtime and compile time metaprogramming.We can use it to add merge(Map m) method to the Map interface.Let’s re-use the merge function we’ve already implemented.

In the final example, we use runtime metaprogramming to create merge(Map rhs) method in the Map interface .This way we can simply call a.merge(b) to create a new map using deep merge operation.

The last tip comes from the Reddit user /u/-jp- - thanks for the contribution!He posted a comment with an alternative solution that uses combination of Map.withDefault method with a method pointer operator that creates a closure from the Map.get method.It produces a slightly different solution than the one posted above.However, it’s very clever and creative way to use Groovy, so I want to share it with you as well.Here’s the original comment.

Let’s start with explaining what the stackoverflow-cli application may look like.Below you can find what the final application’s help page may look like, as well as a help page for the search command, and an exemplary search result.

The first thing we need to do is to create a new Micronaut project.We can do it using Micronaut CLI - mn.Here is how you can install it using SDKMAN! command-line tool.

Once SDKMAN! is installed, we can create a new project.We use create-cli-app to generate a CLI-based project with the Picocli support added.We can define the minimum JDK version with --jdk option.In this example I also set the testing framework to Spock, and I add two features: graalvm and http-client.

After importing the new project to IntelliJ IDEA, go to Settings and search for "annotation processing" and enable annotation processing option as shown below.

The application created with create-cli-app comes with a single unit test we can extend to test our final expectation.

We use this test to achieve two things.Firstly, we want to print the output of the command to the standard output.And secondly, we want to test if the output matches given regular expression.

In the next step, we can implement HTTP client that communicates with the Stack Exchange REST API.We are going to use Micronaut’s declarative HTTP client to do so.We create an interface called StackOverflowHttpClient and we annotate it with the @Client(url) annotation .The client’s URL is taken from the configuration property defined in the application.yml file.Next, we create the search method annotated with @Get(path) annotation .This annotation defines HTTP method (GET in this case) and the request’s path.We also use @QueryValue annotations to map querystring parameters with the method arguments.

And here is the application.yml file that defines stackoverflow.api.url configuration property.

Next, we need to implement ApiResponse<T> and Question classes.We use them to deserialize a raw JSON response into an instance of ApiResponse<Question>.We can implement both classes as a regular Java POJO’s with getters and setters, or we can use public fields keep as simple as possible.In both cases, however, we want to add @Introspected annotation to instruct Micronaut to use a reflection-free Jackson module to handle serialization and deserialization.It’s a nice boost, but it is also a mandatory step if we want to use those classes in the final native executable file.

Here’s an implementation of the ApiResponse<T> class.

And here’s an implementation of the Question class.

Keep in mind we used @JsonProperty over the fields that didn’t match the same naming convention between POJO class (camelCase) and the JSON body (snake_case).Alternatively, we could use @JsonNaming(PropertyNamingStrategy.SnakeCaseStrategy.class) over the class to get the same result.

Once we implemented the HTTP client, it’s time to implement the search command of the stackoverflow-cli app.We start with creating a new class - SearchCommand.Picocli requires, that the command class implements either Runnable or Callable<T> interface.The main difference is that the first one does not return any value, so if you want to return an exit code, you may want to use Callable<Integer> instead of a Runnable interface.

Next, the newly created class has to be annotated with the @Command annotation .We use it to define the command name search, its description, and we also use the standard help mixin to instruct Picocli to generate a default help page based on the command’s options.

Speaking of options, we define them as class fields and we add @Option annotation that specifies each option name (or names if you want to use short and long option name formats).

We also inject previously created StackOverflowHttpClient .

The desired business logic of the search command happens in the run method .We call client.search(query, tag, limit, sort) with the parameters retrieved from the command line.Once the data is fetched from the REST API, we display format each question the helper formatQuestion method, and then we print it.One thing worth mentioning is the usage of Ansi.AUTO.string() method with the ANSI colors and styles applied .

After implementing the command class, we need to register it as a subcommand in the main application class.We do it by adding SearchCommand.class to the subcommands array of the @Command annotation in the main class .

After that, we can run the unit test to see the results.

The last step is to compile the application to the native executable file.Before we do so, we need to install GraalVM and the native-image tool.Below you can find step by step guide using SDKMAN!.

Once we installed GraalVM, native-image, and we switched the Java to the GraalVM’s one, we can firstly assemble our application to the JAR file.

Next, we can run native-image compilation.It takes some time, and may utilize all available cores on your laptop, so be aware of it.

Once the native binary file is created (54 megabytes, it’s not mistaken), we can run a final test to search questions matching stream foreach phrase inside the java tag, and we can limit the output to 4 most relevant questions.

I guess you may ask this question: "why to bother with curl while there is Java or Groovy HTTP client I can use in the pipeline script block?".This question might look reasonable.However, there is one important fact you need to consider.Any Groovy (or Java) code you put into the script block is always executed on the Jenkins master server.No matter what agent/node you use to execute the specific stage(s).Now imagine the following scenario.Let’s say you have a dedicated node in your Jenkins infrastructure to run some REST API calls to perform a production deployment.And let’s assume that only this specific node can make such an HTTP call for security reasons.If you implement the deployment part by using some Groovy code (e.g., something as simple as java.net.HttpURLConnection), it will fail.The server that de facto makes an HTTP call, in this case, is not your dedicated node, but the Jenkins master server.The same one that is not allowed to make any connection to your production server(s).However, if you use the pipeline’s sh step to execute the curl command instead, the HTTP request will be sent from the designated Jenkins node.This way, you can design a topology where only a specific node can perform strategic REST API calls.

Now when you know "why", let’s take a look at the "how" part.

The way to execute curl command is to use sh (or bat if you are on the Windows server) step.You need to know that the sh step by default does not return any value, so if you try to assign it’s output to a variable, you will get the null value.To change this behavior, you need to set the returnStdout parameter to true.In the following example, I use my local Jenkins installation to get the build information of one of my Jenkins pipelines using the JSON API endpoint.

The endpoint I was trying to call in the previous example requires authentication.We can extend this example by adding -u username:password option and using Credentials Binding plugin to store those credentials.

In this example, I use the user’s API Token instead of a real password.It works like a regular password, but it can be easily revoked, and the new one can be re-generated if needed.Also, you can use usernameColonPassword to bind username:password to the specific variable easily.

In many cases, you want to react to different HTTP response status codes.For instance, you want to check if the response returned 200 or 400 status code.Let’s extend the previous example to fit into such a use case.We can pass -w' \n%{response_code}' option to change the output format to the one that contains the response body in the first line, and the status code in the second line.Then we can split the output by the new line character, and we can use {multiple-assignment}[Groovy multiple assignment] feature to assign the response body and the status to the two separate variables.

Once we have the response body and the status code extracted, we can parse the JSON body and extract the value we are interested in.The Jenkins build’s JSON API response contains a list of different actions.Let’s say we want to extract the value of executingTimeMillis stored as an action of type jenkins.metrics.impl.TimeInQueueAction.

If you know Groovy, I’m guessing you might already think about using groovy.json.JsonSlurper to solve the problem.It is not a terrible idea, but it has two downsides you need to take into account.Firstly, it makes Jenkins master server involved in parsing the JSON response, even if the stage gets executed on a different node.And secondly, groovy.json.JsonSlurper produces a lazy map which is not-serializable.The first thing might or might not be a problem - it mainly depends on your Jenkins topology architecture.If you use multiple agents to execute stages and have a lot of different Jenkins jobs on your server, it makes sense to utilize Jenkins master server resources more effectively.Using groovy.json.JsonSlurper to parse small JSON documents might not be a bottleneck.Still, if hundreds or thousands of Jenkins jobs start to parse large JSON documents, it may become an issue.The second problem can be solved easily - instead of using groovy.json.JsonSlurper, use groovy.json.JsonSlurperClassic.This class produces a regular hash map that can be serialized, and that way, you can avoid pipeline serialization problems.

There is an alternative, and it is usually a more recommended way to parse and extract values from the JSON data - the jq command-line tool.All you have to do is to make sure that the jq is installed on the Jenkins node that executes the pipeline.

Let’s take a look at how we can use it to extract the same information from the JSON response.

The list of all available options and parameters that the curl command supports is enormous.You can find all of them in the man curl manual page.Below you can find a few more useful options you may want to use in your Jenkins pipeline.

I guess you heard it many times before.Almost every piece of advice on "how to set goals" or "how to build a habit" contains: "set S.M.A.R.T. goals," "make a plan," "stick with it," and so on.However, there is one thing that almost no advice takes into account - the Resistance, better known as procrastination.In his book "The War of Art," Steven Pressfield describes Resistance as a destructive force that keeps you from doing the right thing.He explains that for him, as a professional writer, all that counts is to sit down and write.The amount of pages or their quality does not matter that much.The most important thing is to overcome the Resistance, so at the end of the day, the score is 1:0 for Steven.The Resistance loses, but it will try the next day.And the next.Again, and again.

However, not all knowledge workers can apply the same pattern to their work - obviously, as a software developer, I can’t just write down any code that comes to my mind and expect my career to flourish.So even though Pressfield aptly defines the enemy, he does not provide the ultimate solution to my biggest problem.But it seems that I have finally found someone else who does.

It’s difficult to summarize "Atomic Habits" in a single sentence, but if I had to try, I would pick one of the subtitles from the first chapter: "Forget about goals, focus on systems instead."James Clear explains that goals are outcome-oriented, and what is obvious, yet still surprising - both winners and losers have the same goals.What makes the difference is the system, a process of introducing small incremental changes that eventually manifest themselves in a new habit.The rule of getting 1% better every day illustrates it very well.As James Clear states, "Habits are the compound interest of self-improvement."You won’t see drastic progress from day to day.But still, this 1% accumulates to a significant result over a couple of months or a year.Learning one small thing or one new idea doesn’t make you a genius, but, as the author states, "a commitment to lifelong learning can be transformative."

If this is so obvious, then why do we keep failing in building positive habits?James Clear explains that we often expect progress to be linear, but it almost never is.We make small changes, we don’t see the expected results, and we instantly get discouraged and stop.However, to make a habit stick, it needs to persist long enough to break through the so-called Plateau of Latent Potential.

This is where implementing atomic habits makes a significant difference.If your goal is to read 12 books in a year (the outcome), you should focus on becoming a reader (the identity) who reads every day for 30 minutes.If your goal is to have a popular blog (the outcome), James Clear suggests focusing on becoming a writer (the identity) who writes daily for an hour or two.If you want to become an outstanding software developer (the outcome), you should focus on becoming a lifelong learner (the identity) who finds a way to learn something valuable daily.

When you start tracking the progress of those small habits, you feed your brain with the dopamine it asks for.And at some point in time, probably later than you expect, you are going to break through the Plateau of Latent Potential.You will then realize that it wasn’t the goal that helped you do so, but rather the system of consistent small improvements that you have successfully adopted.

While the first part of the "Atomic Habits" explains the power of systematic improvements (the "why?" part), James Clear does not stop there.In the remaining parts, he introduces "The Four Laws of Behavior Change."

The inversion of those laws for breaking bad habits is the following:

This is what makes "Atomic Habits" stand out from other books on the subject, even the iconic ones, such as "The Power of Habit" by Charles Duhigg.It provides a framework that is ready to implement, and a guidebook to navigate through the process of change.But no manual, not even the best one, makes the desired impact if it is not put into real action.And the best way to practice any habit is to do it through repetition.

If you’re like me, you value quality over quantity.However, chapter eleven opens with a story that proves that the quantity is your best ally when it comes to building a habit.It tells the story of Jerry Uelsmann, a professor at the University of Florida, who divided students into two groups on his first day of the film photography class.One group was the "quantity" group.Their final grade was based solely on the number of photos they submitted.The second group was the "quality" group.They were asked to submit a single photo they thought the best.At the end of the semester, it turned out that all the best photos were submitted by the "quantity" group.They felt safe to fail, experiment, and learn from every mistake.And eventually, they learned much more effectively through repetition.The "quality" group, on the other hand, was busy speculating what the perfect photo looks like, and they didn’t have time to learn through experimentation.

This brings us back to Steven Pressfield and his way of dealing with the Resistance by creating a routine of writing.As it turns out, it all comes down to repetitively exercising what you want to excel at.If Pressfield spent most of the time overthinking his results, he wouldn’t be able to produce any good story - just like the students from the “quality” group weren’t able to take the perfect photo.It helped me realize that most of my failures in the area of building new habits were caused by overcomplicating the process.I focused mostly on doing things right, instead of doing the right things.As James Clear tries to convince, the right thing doesn’t have to be spectacular right away.Doing small things consistently day after day is the way to build a habit that sticks, and to produce results that can change your life.What we need to understand and appreciate is the importance of small steps that we consciously decide to take - they eventually lead to success.

I would strongly recommend reading “Atomic Habits” to everyone.The book is full of both scientific research and anecdotal evidence, which makes reading it fun, and applying the framework simple.I haven’t covered all the examples and ideas in this blog post, but I hope it encourages you to experiment with your own atomic habits.I strongly believe that everyone will profit from applying the tips included in this book into their own lives.

In this blog post, I will use openlibrary.org public Search API.The reason for that is simple - it returns quite complex and interesting data we can process, and it still mimics a real-life example.I want to use this API to run a full-text search query.I’m going to use my last name as a search term - it is not a very popular Polish last name, so there shouldn’t be many results associated with it.

Once we have the JSON document to process, it’s time to invoke jq processor.The simplest way to do it is to pipe the output from the curl command to the jq input.

This simple pipe doesn’t do much, and jq just prints the JSON "as is."However, there is one difference when compared with the plain curl response.jq by default prints JSON document using "pretty" format, and it adds some basic colors.

Using pipes comes with huge benefits - it doesn’t matter what command produces the input.It means that we can forward the curl command output to a file, and then use this file to produce input for the jq processor.This might be very useful when we do experiments, and we don’t want to download the same JSON document over and over again.

Once we captured the input, we can e.g., pipe commands cat and jq to produce the same result, but this time without involving the call over the network.

However, using cat is not necessary if we want to read the input from a file - jq takes a file as an argument as well.In the all upcoming examples, I will use this syntax to save a few characters.

Let’s start processing the data with some real filters.The document we took from the openlibrary.org Search API has a list under the docs key.This list contains all documents matching the search term.Every document is described using multiple fields, but we are interested in the title, author_name, and publish_year only.

The first filter we want to use is called array/object value iterator .[].This filter extracts values from the given array (or object), so the next filter in the pipeline gets applied to each element.In our case, we want to apply .docs[] filter to extract documents.

The next step is to extract only specific fields.jq filters support piping to apply new filters on top of the results from the previous ones.It uses the same | symbol, but pay attention to one significant difference - piping filters happens inside the jq argument string.

Looks good.Every document got extracted to the new one, containing only three fields.However, author_name and publish_year seem to be arrays.We can update the filter to extract the first value from those arrays and store them as scalar values instead.

I guess you already noticed that we can transform objects either by just referring to the field name (e.g. title) or by constructing the new field explicitly (e.g. author_name: .author_name[0].)

When I looked at the response, I noticed that some documents were missing either author_name or publish_year.We can exclude such documents from the final result using the select(expr) filter.

Now let’s say we want to get the result in a specific order.What if we want to sort the final result by publish_year?jq offer the sort_by(expr) filter, but before we apply it, we need to make one modification.The sort_by(expr) filter works on arrays, and our current output is not an array.If you look closely, you will see that this is just a set of JSON documents printed one after another.We can transform it into a JSON array by wrapping our current long filter with square brackets - an array constructor.

Compare the following example with the previous one and spot the difference.

Once we have a JSON array constructed, we can pipe sort_by(.publish_year) into our filter.

By default, sort_by(expr) sorts objects in the ascending order.To sort objects in the descending order, we can pipe reverse filter after the sort_by(expr) one.

As the next step, we may want to limit the size of the result.Let’s say we want to get the newest three publications as a result.We can use limit(n;expr) filter, but we need to be aware of one thing.To limit the size of an array using this filter, we need to use an expression that extracts values from an array for iteration - .[].Once limit(n;expr) limits the number of objects, it produces the output in the same format.It means that we don’t get an array but rather a set of separate results instead.

If we want to represent the result as a JSON array, we need to wrap limit(n;expr) filter with [] to construct an array again.

Let’s say we want to find out how many publications each author created.jq offers built-in group_by(expr) filter we can use.In our case, we will use group_by(.author_name) to group all publications by their authors.

As you can see now, group_by(.author_name) produced an array of arrays.It’s hard to say how many publications each author did from this document, so we might need to transform this output a bit.

The next filter we need to apply is .[] to start iterating over the grouped arrays.We will pipe this iteration with a transformation that extracts author_name field from the first result using {author_name: .[0].author_name} filter.And as we seen before, .[] | {author_name: .[0].author_name} combination produces a set of results, so we need to wrap it with [] to construct an array.

That’s a good step forward - now we have author names extracted from the grouped result.The next step is to update the transformation filter to also produce the count field - a field containing the number of publications.There is a simple way to do it.The current transformation filter, [.[] | {author_name: .[0].author_name}], iterates the nested arrays that contain all documents associated with the same author.It means that . (identity) in this filter refers to a list of objects, and that is why we extract the author name using .[0].author_name expression, which means: take the first object from the array and return its author_name value.We can use this array to count its size.In the jq, we have a filter called length that can be piped with an array to return its size.So in our case, an expression . | lenght used in the context of this transformation will return the size of an array, which represents the number of publications.

Voila!

Let’s finish this experiment by putting all commands we have learned today together.We can add sort_by(expr) and limit(n;expr) to the latest query to produce the final result - an array of three authors that published the most documents.

And that’s it for today.In the next episode, we will dive deeper into more advanced filters and functions that jq offers.Stay tuned!

Let’s start with a simple example.In this demo, I use a pipeline with two stages, A and B.

As you may expect, running this pipeline causes timeout in the A stage, and the remaining stage B does not get triggered.

In most cases, this is OK.The remaining stage of the pipeline depends on the success of the previous one.But what if we want to treat A stage as optional and keep the pipeline running even if it times out?Let’s see if we can use catchError workflow step to handle the exception for us.

In this example, we wrapped steps that potentially may timeout with the catchError .We want to mark the stage as ABORTED, but we want to keep the build status as SUCCESS.This way, we don’t want to affect the final build result with the timeout of the A stage.Let’s look at what happens when we run the pipeline now.

Looks good, but there is one small issue.We can see that stage B was executed, however, the job status is set to ABORTED.It turns out that, according to the documentation, we cannot set the build result to SUCCESS from results like UNSTABLE or ABORTED.

Let’s see if replacing catchError with good old try-catch can help us in this situation.

In this example, we want to catch any potential exception and force the SUCCESS build status .Keep in mind, that we had to put the code into the script step to be able to use try-catch block.Let’s run the pipeline and see how it goes.

We can see the expected build status, but there is one issue with this approach.The A stage is marked as SUCCESS which might be confusing.It hides the information about the timeout, so we need to click on the stage and check if there was a timeout or not every time we run the pipeline.There should be a better way to handle it.

Luckily, there is a better solution.We can combine both catchError with the try-catch.Let’s take a look at the final example.

In this example, we use catchError to control the stage result in case of an error .The code that may potentially timeout is wrapped with the try-catch so we can control the exception.We can be very specific - in this case we catch the FlowInterruptedException to mark the current stage as ABORTED , but we also store any other exception as caughtException.If any exception other than FlowInterruptedException occurs, we execute error step with an exception message to fail the A stage.Let’s run and see the final result.

And here is what happens if the code that may timeout throws a different error (for instance, some shell command may return exit code 1.)

Voilà!Now it works just as we expect.The A stage gets executed, and it is acceptable to timeout.The pipeline continues in such a case, and its final result depends on the remaining stages.

My YouTube channel just reached 200 subscribers.Is it a lot? Not necessarily.It’s not even round number, like 256, or 512.But it means a lot to me.There are two hundred people who found my videos, either useful or entertaining.I hope you are one of them.I didn’t plan to write a blog post about it, but then I thought that my fellow subscribers deserve big and honest THANK YOU!

I’ve seen many times people thanking the follower who made their 1k, 10k, or any other milestone.This is a very gentle way to welcome someone who just joined your subscribers or followers group.But every time I see it, I ask myself: "Why they don’t thank their, let’s say, first 10 followers?"Social media are a game of numbers.Those numbers work as social proof - it’s easier to keep growing when you already have an audience.Anyone who starts and grows more or less organically needs to be patient and stay consistent, probably more than ever.And don’t get me wrong - I don’t try to blame it.I accept and agree with it.

The beginnings in any discipline are tough.We learn new things, we experiment and measure results, and then we try to improve if something doesn’t work.It is the time when we keep making mistakes, keep gaining confidence, and keep building trust.This is why, in my opinion, early adopters, people who trusted you when you just started (and don’t have much to offer), deserve acknowledgment.I don’t know all your names.YouTube notifies only about those of you who keep their subscriptions public.I keep all emails received when the new subscriber shows up.Marcin, Søren, Paweł, Tucker, Naresha, Robert, Anton, Jay, Marouane, Kenneth, Jason, Sergiy, Giulio, Federico, Scott, Łukasz, Diego, and all the rest of you - I’m happy and grateful you trusted me and shown your support.It motivates me to keep doing the work, and I hope I won’t disappoint you.I don’t know if I ever grow my YouTube channel to 10k, 100k, or more, but I know one thing - I will never forget that you were the early adopters.I salute to you!

Some of you know that I love recording, editing, and producing videos.I spent countless hours in Adobe Premiere to learn the video editing craft, and I can tell you, it became my favorite hobby.I prefer quality over quantity, and I know that sometimes I put probably too much attention and effort into polishing some small details.Just like with the "型 Programming Kata" series, where I spent around two and a half hours to produce 40 seconds intro that I am so proud of.From the economic stand of point, it was probably not the best time investment, but hey - I don’t care.I enjoyed creating it like a child in Disneyland.

So, what is the future of the YouTube channel?I will keep posting videos weekly.You can expect both long and short ones.I want to use the short form to share with you some useful tips and tricks that are ready to apply.This way you can learn something new without dedicating a lot of time.In the long-form videos, I will try to go a little deeper into some specific problems to solve.And everything is going to more or less Java oriented, with a strong accent on the Groovy ecosystem.But not only that.So, consider subscribing if you haven’t already.And remember - any kind of engagement (likes, comments, subscriptions) helps.I want to thank you for that!

I know how difficult it is to start a YouTube channel and see its slow growth.I know how disappointing it is to publish a new video and see just a few views in the first hours.If you’re going through the same struggles - you’re not alone.

In this section I would like to share with you a few tips that made a significant difference in my early days of the YouTube channel development.I learned them the hard way, and I still keep applying those tips up to this day.I hope you will benefit from them as well.

Let’s start with a simple example.

Here is a Groovy class with a PLAYERS map.Its type was defined as Map<String,String>, but for some reason (maybe by accident), someone assigned a list of strings to each key.If you open such a file in the IDE like IntelliJ IDEA, it will show you a warning like this one.

But the fact is, we can run SomeClass.main() method and get the following output.

It doesn’t make much sense, right?Not necessarily.

Java generic types gets erased at the compile time.It means that the Java Runtime Environment loses information about the generic type, and essentially, the PLAYERS map from our example becomes something similar to Map<Object,Object>.

Java also allows assigning "raw" types to the parameterized type.For instance, you can create a raw List, add some values of type String to it (or even mix different types), and assign such a list to the List<Integer> variable.

Your IDE will throw a few warnings, like Unchecked call to 'add(E)' as a member of raw type 'java.util.List', but it won’t stop you from doing so.The above code compiles and runs without any issue.

Now when we know about generic type erasure and raw types, we can take a look at what happens in the Groovy use case under the hood.We can compile SomeClass.groovy file with the Groovy compiler.

And then we can open the SomeClass.class file in the IntelliJ IDEA to see its disassembled form.

The disassembled code shows what the Groovy class looks like from the Java perspective.We can see that PLAYERS map is the same Map<String,String> type.It gets initialized in the static constructor by assigning a map created by ScriptBytecodeAdapter.createMap() function.It returns a raw Map type and accepts Object[] - an array of any objects.What it shows is that in the dynamically compiled Groovy, it doesn’t matter what specific map we define on the right side of the assignment expression.The bytecode it produces takes all entries and treat them as they were of Object type, and produces a raw Map as a result.

Groovy also does all the necessary casts for you.If we have to rewrite Groovy’s SomeClass to its Java equivalent, we would need to either treat anything that is returned by the PLAYERS.get() as Object, or make all required casts by hand.

Groovy handles all that.It uses AbstractCallSite.callGetProperty() method that accpets Object parameter and returns an Object.Also, if we do the following in our Groovy example:

it would get compiled to the following Java equivalent:

As always - it depends.With great power comes great responsibility.Luckily, Groovy also offers solutions if you are looking for some more secure type checking or even static compilation.

If you want to take advantage of Groovy’s dynamic compilation, but you want to improve type checking, you can consider using @groovy.transform.TypeChecked annotation.When we add it to the SomeClass, IDE will mark PLAYERS variable red and say Cannot assign LinkedHashMap<String, List<String>> to Map<String, String>.Also, when we try to compile the class with groovyc, we will end up seeing the following error.

Alternatively, if you don’t use any of the Groovy’s dynamic features, you can enable static compilation with @groovy.transform.CompileStatic annotation.It enables static type checking and produces the bytecode that is much closer to what Java compiler produces.

The @groovy.transform.NullCheck belongs to the category of annotations that trigger specific AST transformations at the compilation time.This specific annotation can be added to class, constructor, or method.When it is present, it adds if-statement that checks if a variable (or variables) is not null, and throws IllegalArgumentException otherwise.

Here is Groovy =<2.5 class example that does all null checks manually.

When you run such a Groovy script, you will see IllegalArgumentException as expected.

When using Groovy 3 (and higher) and @NullCheck annotation we can get replace all explicit checks with a single annotation.The AST transformation that runs at the compile-time produces the same bytecode as in the explicit Groovy 2.5 use case.

Running the following example in the command line produces the expected result.

Starting from Groovy 3.0.2, the @NullCheck annotation offers includeGenerated option.This option allows to use the annotation in combination with other AST transformations like @Immutable or @TupleConstructor.

Output:

If we skip setting includeGenerated to true, the @NullCheck annotation won’t be applied and we will see NullPointerExceptioninstead of the IllegalArgumentException.

Let’s start with the first one - takeRight.This method allows you to extract n last characters from a given String (or all characters if the number is larger then the string length.)

This method allows you to extract the text that exists after the first occurrence of the str.Keep in mind that it is case-sensitive, so it looks for the exact match.

It is similar to takeAfter, but here it extracts the text that exists before the first occurrence of str.

This method allows you to extract the text that exists between the first occurrence of from and to.It can be used with a single parameter, then to becomes from.There is also a third optional parameter - occurrence which defines which occurrence should be taken into account (default: the first occurrence of from and to).

This is an equivalent of String.drop(int) method, but in this case it produces a new String that drops n characters from the right side.

Groovy also adds "ignore case" variants to three popular String methods:

But let’s start with the following question - why are there two pipeline types in the first place?The scripted pipeline was the first implementation of the pipeline as a code in Jenkins.Even though it uses the underlying pipeline subsystem, it was designed more or less as a general-purpose DSL built with Groovy.^[1]It means that it does not come with a fixed structure, and it is up to you how you will define your pipeline logic.The declarative pipeline, on the other hand, is more opinionated, and its structure is well-defined.^[2]It may look a bit limiting, but in practice, you can achieve the same things using the scripted or declarative pipeline. So which one to choose?

If you ask me this question and expect an answer different from "it depends," I would say use the declarative pipeline. And here’s why.

Here are my top 4 differences between the declarative and scripted Jenkins pipeline.These are not the only differences, and I guess your list may look a little different.What is your choice?Do you prefer the declarative pipeline, or the scripted one?Please share your thoughts in the section down below.

Let’s start with the number of unique visitors.In 2019, the blog was visited by 113,802 unique visitors.The month with the lowest number of visitors was February - 2,581 unique visitors.The month with the highest number of visitors was December - 17,443 unique visitors.

The blog has a very high bounce rate of 91,61%, which means that only 8,39% of visitors continue browsing the blog after opening the first page.This number does not surprise me - a vast majority of people find the blog using a search engine, and they visit it to find a specific solution to their problem.They find what they looked for, and they get back to their business.However, I would like to lower the bounce rate in 2020 to something like 80-85%.

There is no surprise here.The Google search engine is responsible for 91,8% traffic on the blog.The second top channel is direct traffic with 4,5% efficiency.The third top channel is the Social Media traffic with just 1,6% efficiency.

There is one interesting observation.The most engaging traffic comes from referrals - the bounce rate, in this case, is 78,04%.The least engaging channel is, of course, Organic Search with 92,22% bounce rate.

Now let’s take a look at the most popular blog posts in 2019.Here is the TOP 3:

There is one honorable mention - Jenkins Pipeline Environment Variables - The Definitive Guide which generated 5,334 pageviews, but this blog post was published on November 2nd, so it is one of the candidates for the 2020 TOP 3 ranking winner.

And here is a summary from the Search Console.At the beginning of 2019, the blog was not ranked high in the Google index.It started changing in the middle of the year, and I started seeing more and more traffic coming from Google.

And here are the TOP 10 search keywords for my blog:

Almost 20% of the traffic comes from the United States.The second country in that ranking is India with almost 9% score.The third place belongs to Germany with 6.5% score.

And here is the TOP 10:

And last but not least - the web browser ranking.Google Chrome wins with almost 80% score.Firefox is used by 12% of readers, which means that the first two browsers are used by ~92% of readers.Here is the full ranking.

Don’t expect any revolution.I want to keep blogging about the things I’m genuinely interested in.I want to blog more often, but the quality of the content is more important to me than the quantity.There is one thing I can guarantee you - the blog remains ad-free.I love the User Experience I’ve built here, and I don’t want to change that.There will be some alternative (and optional) ways to support my work, but ads are not in this category.

My goal for 2020 is to put more content on my small YouTube channel.I recorded a few new videos already, so you should see a video posted every week.(Consider subscribing if you’re not doing it already. )

And that’s it for today.I wish you a fruitful year 2020!Define your own rules and live according to them, and everything will go smoothly.Take care, and see you in the next blog post!

PS: If there is something that surprised you most regarding the 2019 performance of this blog, please let me know in the comments section down below.