Tuesday, March 18, 2014

Review: Making Java Groovy

I can say that this book is special. It's not a Groovy "cookbook". You won't find tons of tricky recipes around Groovy. You won't learn black art of Groovy meta programming. Strange, doesn't it. :-) Then why you should read it. Or who should read this book?

The answer is very simple - Every Java programmer who wants to be productive in daily work must read this book. The author (Ken Kousen) did really great job showing different aspects of Groovy as a language, tool and ecosystem. The reader will understand that there are tons of different appliances of Groovy:
  • Groovy scripting (@Grab)
  • Gradle, Maven/Ant automation
  • Groovy as prototyping language: REST, DB, etc.
  • Web micro-frameworks
  • Testing: Spock, mocks
  • Java/Groovy integration
  • JSON/XML manipulation
The most important thing is to understand that Groovy should NOT be used only with Grails. Java programmers must re-discover Groovy as super pragmatic language. Everything which is written in Java can be written in Groovy. Save your time and automate with Groovy.

Sunday, January 26, 2014

About Learning New Programming Languages

This post is very subjective and reflect the my current point of view.

There are tons of different programming languages. Few of them you are using daily, few of them from time to time. And huge amount are touched "accidentally" (via playing and writing "big" hello world).
Now the question is: Should we spend our time playing with every hipster/hype language? Maybe it's better to invest own time in something really important. In something which can improve our productivity and range of task which can be solved by our "major" language(s).

In general to "learn" a new language is not a big deal. But, nowadays we can't use language itself in isolation. "Learn a new language" means not only language, but also its related areas:
  • ecosystem (libraries, frameworks, IDE, tools)
  • problems which can be solved with this language (some languages are well suited for the particular set of problems: Erlang, Prolog, SQL, etc.)
  • community
  • best practices and idiomatic code
  • etc.
Now, if you calculate and recall your experience You will notice that language related areas take huge amount of time to master.

Here is some general sample: Imagine that language X is your major tool for making money. Now, you've switched, temporary, to language Y, for reasonable amount of time (several months). Then you switched back to language X and stick there for long-long period of time. You will notice how you are loosing those minimal knowledge (required to accomplish the tasks) gained for language Y. You can recollect the syntax, but related areas of language Y have been evolved and updated. Even more, some related areas are obsolete, etc. And now it will be much hard to get the same knowledge in language Y quickly. You must be adequate to understand this.

So, what does it mean from me:
  • Select minimal required set of programming languages which makes you as productive as possible. Master these languages
  • It's a good idea to spend time playing with other languages. But it's bad idea to switch from one to another language regularly. You are losing focus.
  • Master ecosystem
  • Be active in language community
I don't want to say that learning new languages is a bad idea. No. I don't think so. But the reality has some influence on us. It might happen that "new" language and related areas are cool, you are happy using all these stuff working on pet-projects. But you have some objective constrains and can't use it at your work: e.g. a) there are no projects where you can use this language or b) you can't change the company because of geographical constrains. Keeping all these in mind you should spend your time effectively and learn really valuable stuff. 
Try to avoid hipster bandwagon effect.