Book Review: Professional Node.js Building JavaScript-Based Scalable Software

Overview
As a result of the recent explosion of JavaScript's popularity, partially led by Node.js, I decided to spend some time updating my JavaScript skills. I started reading a lot of articles and posts and then came across a recommended approach to learning Node on JavascriptIsSexy.com and decided to give it try.

Contents
The book is broken up into 6 parts(listed below), with a total of 25 chapters covering 350 pages, written by Pedro Teixeira.

1. Introduction and Setup
2. Node Core API basics
3. Files, Processes, Streams and Networking
4. Building and Debugging Modules and Applications
5. Build Web Applications
6. Connecting to Databases

The book is not an introduction to JavaScript, nor does it spend the first couple chapters attempting to ramp up readers on the JavaScript language, which I appreciated.  Readers should already have some basic JavaScript knowledge before reading this book.

Pros

• Well written and easy to follow along with the code examples
• The chapters covered the material without getting too long.  Easy enough to spend about 1/2 hour reading a chapter and working through the code examples for the chapter
• The book got me excited about the possibilities available using Node.js and started me down a new path to help build my "full stack developer" skills.

Cons

• The code examples were good, but I think it would help early in the book to point out where to find the Node API documentation, otherwise the reader is sometimes left wondering, "How did they know what methods are available, what to call and what to pass to that API?"
• For all the positive impact NPM has had on Node.js, the coverage of NPM in the book seems a bit light, although that could just be lack of Node knowledge showing!

Conclusion
I was very happy with the book and would recommend it for anyone with some basic JavaScript skills looking to learn about Node.js.

I usually stick to Manning or O'Reilly books but when I started my quest for Node knowledge, neither of those publishers had books covering Node.  This has since changed and I may try one of those out as well.  

Not all JSON created equal, at least from Java implementations!

Setting the stage
I have spent the majority of my career on the 'server-side' of applications. When I have worked on the client side, it has been Java Swing, so up to now I haven't worked much with JSON.   My (incorrect!) assumption was that all JSON is created equal.

We are creating a new REST API for our product at work and plan on supporting both JSON and XML for both the requests and responses.  We are using RESTEasy from JBoss and the process has been fairly straight-forward.

Below is a screen shot of two sets of JSON generated from our CustomerResource using RESTEasy with the exact same code from our perspective. The only difference is how I configured RESTEasy to generate JSON.  In one case, I used Jettison and in the other case I used Jackson.  I expected that both tools would generate exactly the same output - WRONG!  See below for some of the differences.

Results

The results above show a simple customer entry with a set of 1 phone number and a set of 1 address.

I have noticed following differences (there may be others…):

• Jettison has a name entry for the object whereas Jackson does not (Customer,Addresses, Address,PhoneNumbers, PhoneNumber) 
• Jettison appears to force all values to a String, using the double quotes, whereas Jackson does not for number fields, like customerId, where it does not double quote the value
• Jackson is currently showing null fields, like addressLine2 & addressLine3 whereas Jettison is not. This may be configurable. Jackson uses JAXB annotations to assist with its marshaling/serializing and also contains some of its own annotations as well which might be used to help adjust the output.

Hope this helps!

Groovy moonlighter mistake: Not all "method chaining" does what you might think

Setup
I am using Spock to help inject Groovy into our project and currently that means testing our new RESTful API.   We need to be able to send and receive both XML and JSON.    To test our POST method, I created a default Cart object and get the JSON representation.   I decided to try to use curl to call some of the methods, so for this POST method call, I needed to save the JSON to a file.  Later, I wanted to make sure the file was created.

Problem Code
The code below gets a NullPointerException calling the exists() method.

public void "POST Creates New Cart with JSON"() {
   when:
   File f = new File("cart.json").write(getDefaultCartJSON())
   
   def response = '''curl -X POST -i -d @cart.json --header "Content-Type:application/json"
          http://localhost:7001/restservices/carts'''.execute().text
  
    then:
    f.exists()
    response.startsWith("HTTP/1.1 201 Created")
  }
}

Root Cause:
The problem wasn't obvious immediately to me (hey I wrote it!).  The problem is the write() method returns a void, not the file object.

 File f = new File("cart.json").write(getDefaultCartJSON())

Corrected Code
Below is the corrected code.  So you don't always need to assign the result of a 'new' into a variable, even though that's how many of us learned to program.

public void "POST Creates New Cart with JSON"() {
   when:
   new File("cart.json").write(getDefaultCartJSON())
   
   def response = '''curl -X POST -i -d @cart.json --header "Content-Type:application/json"
          http://localhost:7001/restservices/carts'''.execute().text
  
    then:
    new File("cart.json").exists()
    response.startsWith("HTTP/1.1 201 Created")
  }
}

Wrap-up
Obviously this was not some major problem or break-through, just something to keep in mind as you write your code.   Maybe this will help prevent others from making the same mistake(s) I made. :-)

Hope it helps!

Groovy moonlighter mistake: Spock requires JUnit to run inside Eclispe

Setup

I was rushing a bit the other day to get a new project setup in Eclipse.   The project is for some RESTful API work we are doing.  Naturally, I started looking for a way to inject Groovy into the process (regardless of how much resistance I continue to encounter from my colleagues).  :-)    Why not include the Spock testing framework I thought.  Great, if the team doesn't want to use Groovy, they can still write their test cases the old way, but I am going to inject Spock to the project!

Now I am off and running:

• Eclipse project created: check
• Added Groovy Nature to the Eclipse project: check
• Included the Spock jar in the build path: check
• First test case written using Spock and it compiles: check
• Run my test case from within Eclipse: WTF, Eclipse where's the JUnit menu option (screenshot below)

Resolution:
Spock requires JUnit to run inside Eclipse (duh!).   So I added the JUnit jar to my build path and now as you can see in the screenshot below - all is better with my world - now I can run my Spock tests within Eclipse!

I have to thank danveloper for the tagline "Groovy moonlighter".  We were exchanging emails about one of his projects when I complained that my Groovy practice is limited to nights and weekends.  At that point he called me a 'Groovy Moonlighter".   Thanks Dan!

Hope this helps!

Book Review: Making Java Groovy

Overview
This review might be considered 'jumping the gun' a bit since this book has not been officially released yet.   Only the last chapter (Chapter 11) remains but honestly, even if that last chapter said "This chapter intentionally left blank", it would not adversely affect my review.   I signed up for the MEAP program for this book after hearing Ken Kousen present some of this material at my local Java Users Group.

Contents
The book is broken into 3 parts:

1. Part 1 - Up to speed with Groovy includes 3 chapters that discuss why adding Groovy to Java, Groovy examples and Code-level integration.
2. Part 2 - Groovy Tools covers Build processes and Test Groovy and Java projects.   These chapters in very handy and timely.  While reading these chapters I was introducing Groovy into our Java project and the discussion on how to handle builds mixed with Java and Groovy resolved one of my outstanding questions.   The next chapter helped answer other questions about how to handle testing in this 'mixed' environment.
3. Part 3 - Groovy in the Real World covers integration with Spring, databases, SOAP and REST 

This is also an Appendix that does a very high-level overview of the Groovy for the folks new to Groovy, without stepping on the toes of "Groovy In Action"

Pros:

• Great reference that hits all the high points like builds, testing, web services, Spring and databases
• Covers most of the scenarios that you will encounter when including Groovy to your Java projects

Cons:

• Footnotes have a different context when reading Ken's book.  For the most part, the footnotes in the book are there to:
• apologize for a bad joke or pun or
• explain a joke or reference from the earlier in the text

Summary
This is an excellent book for Java developers wanting to get started with Groovy.  This books helps answer some of the possible nagging questions like "How do I handle the builds/compiles?" or "How do I test Java and Groovy code together?".

This book is a definite BUY, and I am still waiting on Chapter 11 - The Future.

Book Review: Getting Started with NoSQL

Overview
Unless you've been living under a rock, you have at the very least,  heard of NoSQL.  You may not know much about it, what types of NoSQL databases exists, what the functionalities they provide or even know the names of some NoSQL databases.  If this is true, then Getting Started with NoSQL is for you.  The book will help guide you thru an evaluation process of NoSQL databases, considering a set of requirements and use cases with which to help evaluate each type of database.

Contents

• Overview of NoSQL
• Characteristics of NoSQL
• NoSQL storage types
• Advantages and Drawbacks
• Comparative Study of NoSQL products
• Case Study

Pros:

• Quick read, only 142 pages
• Provides a good comparison of the NoSQL database types vs the RDBMS, and what NoSQL is and is NOT.

Cons:

• Lots of hyperlinks within the text - this was my first time reading an e-book on a Kindle so I don't know if that is typical of not.  I expect that is not the case.
• Comparatively light coverage of Graph databases vs more popular types, for example Document store
• Described as appropriate for "technology decision makers - be it architect, product manager or CTO".   I would agree this book is appropriate for developers, architects and possibly product managers.      

Conclusion
The book takes an analytic approach to comparing different NoSQL database types based on a specified set of criteria.   It walks you thru the comparisons, evaluating how each database type rates in terms of the criteria and merely suggests which database type they feel would be most appropriate for the use cases being evaluated.

Book Review: Gradle Effective Implementation Guide

Overview
The choice of build tools in the Java space has basically been Ant or Maven since the early days of Java.   Ant was the first tool to arrive and then Maven was created to help provide standardization, assuming you drank the Maven Kool-Aid, meaning that you could live with the standards set out by Maven.

Now a new build tool has arrived, Gradle.  Gradle adoption started slowly at first, but has definitely been picking up momentum as more and more projects migrate from either Ant or Maven over to Gradle. Gradle can't be ignored!

Gradle is built on top of the Groovy.  The tool provides a rich Domain Specific Language (DSL) based on Groovy. The DSL is the key component of Gradle.

Contents

• Starting with Gradle, creating and working with build scripts 
• Gradle for Java projects
• Dependency management
• Testing building and publishing artifacts
• Multi-project builds
• Gradle with Groovy and Scala
• Maintaining code quality with tools like Checkstyle, PMD, FindBugs, JDepend, CodeNarc and the Sonar plugin - one of my favorite chapters since I recommend using code static analysis tools for improving code quality
• Using Gradle with Continuous Integration - covers Jenkins, TeamCity and Bamboo
• IDE support - provides excellent coverage of Eclipse and IntelliJ IDEA support

Pros

• Very good reference guide
• Sample source filled with a lot of complete examples
• It's by Mr. Haki, creator of Groovy Goodness, Grails Goodness and of course, Gradle Goodness blog postings!

Cons

• I started out running and verifying every example, but after submitting 6-7 errata for just the first chapter, I stopped running all of the examples and dropped back to just executing examples that peaked my interest.
• The book contains only a single reference to Ant and no discussion on Gradle's integration with Ant.  In all fairness, Ant integration is not listed in the bullet points on the back of the book that shows "What you will learn", but I think that is a mistake.  Readers are going to be coming from either Ant or Maven and will be looking for help in migrating to Gradle or for help on how to do things in Gradle that they are already doing in Ant or Maven.
• The book is 356 pages but a lot of pages are 'eaten up' by showing the output of all the example build scripts,  and screen shots from Chapter 11, Using Gradle with Continuous Integration and Chapter 12 IDE support.

Summary
The book is a very good reference for using Gradle and I would definitely recommend it for anyone interested in learning more about Gradle.

Gradle thoughts (not specific to the book)
This the second book I have read on Gradle.  I have read the User's Guide a couple times over the last two years in an attempt to get a firm grip on Gradle.  One of my challenges is that I don't get to use Gradle in my day job, just at night and on weekends.   This limited use seems to extend the learning curve, which I think for Gradle is larger/longer than other tools.

"Convention over configuration" is great for reducing the amount of code in projects, BUT somewhere the user needs to know where the conventions are defined.   I think one of the keys to learning Gradle is to get a firm grasp on the Gradle DSL.  Without a grasp on the DSL,  a new Gradle user just keeps wondering "Where are these properties/methods coming from?"