Friday, September 12, 2014

Migrated to another blog engine

Hi All.
I'm not going to publish any new post in this blog. 

I've completely migrated to halyph.com. All new posts will be published there.

Wednesday, August 13, 2014

Groovy Notes: Pretty print JSON from the command line

JSON pretty print it's common task while working with JSON from command line. There are many ways of doing this via Python, Ruby, node.js, but here I'd like to concentrate on Groovy one-liner:

$ echo '{"foo": "lorem", "bar": "ipsum"}' | groovy -e 'import groovy.json.*; println JsonOutput.prettyPrint(System.in.text)'

{
    "foo": "lorem",
    "bar": "ipsum"
}

We can slightly improve this one-liner via adding shell alias:
$ alias pp="groovy -e 'import groovy.json.*; println JsonOutput.prettyPrint(System.in.text)'"
$ echo '{"foo": "lorem", "bar": "ipsum"}' | pp

Also, we might use Groovy script which might be handy for simple JSON validation also:

$ cat prettyJson.groovy 
import groovy.json.*

try {
  println JsonOutput.prettyPrint(System.in.text)
} catch (JsonException e) {
  println "ERROR: Not valid JSON"
  System.exit(1)
}

$ echo '{"foo: "lorem", ' | groovy prettyJson.groovy
ERROR: Not valid JSON

Tuesday, August 12, 2014

How to disable Tomcat session serialization


Suppose you have the next error while restart/stop Tomcat (in my case Tomcat 7.x):
WARNING: Cannot serialize session attribute SPRING_SECURITY_CONTEXT for session 54DBA076EDC9B7A24C1AF76824DFD1EF
java.io.NotSerializableException: com.MyClass
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1180)
 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
 at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
 at java.util.ArrayList.writeObject(ArrayList.java:710)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:975)
...
It means that Tomcat is trying to persist non-serializable objects which were added into the session. Tomcat uses Manager component which is used to create and maintain HTTP sessions for web application.

By default manager implementation configured to perform session persistence across restarts and we want to disable this functionality.
To disable this persistence feature, create a Context configuration file (context.xml) for your web application and add the following element there:

<Manager pathname="" />

You can add this context.xml file to:
  • App.war:/META-INF/context.xml
  • TOMCAT_HOME/conf/Catalina/localhost/App.xml file
  • TOMCAT_HOME/cont/context.xml
References

Wednesday, July 23, 2014

Review: Programming Groovy 2: Dynamic Productivity for the Java Developer

Programming Groovy 2: Dynamic Productivity for the Java Developer
Programming Groovy 2: Dynamic Productivity for the Java Developer
This book is well balanced around Groovy language. I would say there is minimal required knowledge regarding the language. The author (Venkat Subramaniam) fluently covered every important aspect of Groovy. But this book is for experienced developer. The accents were made only in scope of Groovy language and totally avoided any "intro" programming talks, which is actually cool.

Here is the book's structure:

  • Beginning Groovy - this part is dedicated to Groovy language features, especially from Java perspective. Reading this part I was building the parallel to Ruby trying to compare these languages. The main difference which I found it's only syntax "sugar". I.e. conceptually these two language are very similar. 
  • Using Groovy - this is a pragmatic part where were highlighted the next topics: Groovy GDK, XML Processing, working with DB,  working with Java.
  • Dynamic features (MOPing Groovy) - here were highlighted two main metaprogramming approaches: run-time and compile-time metaprogramming. Very interesting part. For me Groovy metaprogramming facilities are much clear comparison to Ruby metaprogramming.
  • Using Metaprogramming - it's pragmatic part where were highlighted the applications for Groovy metaprogramming features. It's very important to note that Groovy contains many pre-bundled classes/modules which are really nice samples of metaprogramming Groovy's features.
I highly recommend this book to everybody who is interested in Groovy language. This book highlights Groovy dynamic features.


References:

Monday, May 26, 2014

JEEConf - Kiev, 2014 - Report

I attended the forth JEEConf, May 23-24, 2014. The situation in my country (Ukraine) is difficult that's why I was amazed to see so many foreign speakers. The organizers did really tremendous work.

This year I divided topics by the next directions:
  • Spring
    • Spring 4, Java EE 7 or Both? by Ivar Grimstad
    • The main idea of the talk was to show similar and different parts of Spring 4 and Java EE 7. And have an ability easily identify when to use one or another. There are trade-offs and we should be aware of them.
    • Spring configuration: how to do it right (experience report), Mikalai Alimenkou
    • Mikalai shared his experience related to Spring configs. Nice talk. I'm going to borrow some ideas ;-)
    • Spring the Ripper, by Evgeny Borisov
    • It was the most dynamic talk at this conference. The presenter shown Spring life-cycle internals in action. Well done. It should be seen by every Spring dev :-)
  • Frameworks
    • Apache Lucene/Solr Internals, by Anatoliy Sokolenko
    • I had no experience with these technologies. And it was really nice intro. Now I have some clue how it works.
    • Streamline your processes with jBPM 6, by Jiri Svitak
    • It was an into talk into jBPM 6. I had small experience with competitor framework Activiti. It's always interesting to see the similar framework's features.
  • Java/JVM/Compiler
    • Java8: Stream Style, by Sergey Kuksenko
    • It was Java 8 Stream introduction. There were shown different stream features and approaches.
    • What Heap Dumps Are Lying To You About, by Aleksey Shipilёv
    • It's a very special talk related to Java "internals". Actually, this talk was about Java object size calculation and what happens under the hood.
    • Reflection Madness, by Heinz Kabutz
    • The presenter told us about Java reflection magic, when to use it and why it's dangerous.
  • Miscellaneous
    • Tooling of a Test-Driven Developer, by Paweł Lipiński
    • There were highlighted two very interesting libraries for TDD on top of JUnit: AssertJ and JUnitParams.Very interesting libraries
    • Web Apps in LISP!? EWW!, by Anatoly Polinsky
    • Here was shown different aspects of web development in Clojure for beginners. It's was real intro, but very interesting, especially when you'd like to spread your mind into alternative JVM-related communities.
It was very productive conference for me. I've got new portion of inspiration, new knowledge and passion to ordinary things.

See:

Saturday, April 19, 2014

Thor notes

Some time ago I used Thor for one CLI application. I investigated several tools, but picked Thor because of its simplicity and easy to star. In general you would need only the official documentation. But, I used Bundler as real sample of Thor usage also.

Here is the list of articles, notes about Thor which might be helpful:

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.