Today I’ve decided to improve my Github account settings a bit. I thought that it would be nice to add GPG key to it and sign all commits pushed from my computer. Everything worked great until I tried to commit the first change directly from my IntelliJ IDEA.
We are software developers. Our daily duty is to write programs. We spend a lot of time and effort into doing the right things and doing them right. At some point, the production launch day comes and depending on our level of confidence - we are calm and ready for the first wave of unpredictable users, or deadly terrified.
One of the most interesting Groovy features is its ability to configure advanced compiler options using DSL script. It becomes handy when you want to apply some global modifications to all Groovy classes. (For instance, you want to add
@CompileStatic annotation to all classes, without applying changes to the source code). In most cases, you want to add something to the existing source code, e.g., classes imports or useful annotations, but what if we want to remove one annotation or another?
The journey inside the exciting world of GraalVM continues. Today I would like to share with you results of running Ratpack on GraalVM experiment. You are going to learn how to build a native binary of a simple "Hello, World!" Ratpack application. In the end we are going to run some benchmarks to see if running GraalVM executable produces better results than running JAR on a regular Oracle JDK.
GraalVM 1.0.0-RC11 was released yesterday, and I thought it would be an excellent excuse to play around with it a while. I decided to create a simple Groovy script that uses Grape dependency management system to load an external library and create a standalone native image from it. I thought it wouldn’t be possible, but luckily - I was wrong.
This is the second blog post in "Programmer’s Bookshelf" category, and today I would like to share with you my opinion on the "Deep Work" book by Cal Newport. It’s not about programming, but it’s still beneficial to any software developer out there.
When I get the paperback copy of the "Programming Groovy 2" book back in the June 2017, I was wondering if I can find something new or exciting in the book that was written in July 2013. It took me almost 1,5 year before I have finally put the book on my desk and started reading and playing around with the examples. As a veteran Groovy developer, I have to say - it was worth it!
Spock Framework is one of my favorite tools in the Groovy ecosystem toolbox. It makes writing automated tests a few times more pleasant thanks to its opinionated syntax. From time to time I see some corner cases where Spock behaves unexpectedly. Today I would like to show you one of these corner cases and explains what happens under the hood.
Ignoring some of the unit tests when given conditions are not satisfied is a handy feature of a JUnit framework. I guess you have used many times constructions like
Assume.assumeNotNull(expr) in your test code. Today I would like to show you one pretty interesting corner case when the usage of
Assume.assumeNotNull(expr) throws NPE in the unit test written in Groovy.