2014-09-15 Tweets

Groovy Validator: Better Than Cowbell

There are more updates to the Groovy Validator project.

I got regular expressions working for StringAnnotation in POGOs and immutable objects.

IntAnnotation and LongAnnotation now have an optional argument called “divisorSet”. If you want your number to be even, you can add the set [2]. If you want it to be divisible by 3 or 7, you add [3, 7].

I also changed the exception messages and did some refactoring. There was some repetition I moved into methods. Handling doubles and floats was pretty much the same, and integers and longs were almost the same.

I think the README and groovydocs explain things pretty well.

You’re welcome.

2014-09-08 Tweets

Regular Expressions in Groovy Validator

There is another update to the Groovy Validator project. I added regular expressions to the StringAnnotation class. I have not added it to the class that performs validation for immutable objects.

Before, all you could do is validate a String by length. Now you can also use regular expressions:

import info.shelfunit.properties.annotations.ImmutableValidator
import info.shelfunit.properties.annotations.StringAnnotation

class ImmutableRegEx {
    @StringAnnotation( minLength = 10, regEx = /^.*?[Gg]roovy.*$/ ) 
    String groovyString
    @StringAnnotation( regEx = /\d{4}?-\d\d-\d\d/  ) 
    String yearWithDay
    @StringAnnotation( minLength = 6, maxLength = 10, regEx = /^(?=.*[0-9].*[0-9])[0-9a-zA-Z]{8,12}$/ )
    String password

The default is the catch-all “.*”, so the annotation will still work with no regular expression provided by the user. This can be used with POGOs and processed by AnnotationProcessor.process, and it can be used with ImmutableValidator. If you are going to use regular expressions with ImmutableValidator, you must delimit the regex string with slashes. If you are using regular expressions with AnnotationProcessor, you can delimit the regex string with slashes or quotes. But, as always, if you use quotes, you have to do a lot of escaping yourself.

The regular expression has to be unbroken on one line. This means you cannot use comments to document them.

I also beefed up the annotation AST transformer for immutable objects. I put annotations on every field in the immutable objects I was testing, and it was only now that I realized that it choked on a field in an immutable object that did not have any validation annotation. I think I fixed that.

I keep thinking I am done, but I have one more change I think I can make.

You’re welcome.

Update On Grails Constraints and Clojure

I am still going through the Grails constraints and seeing if any of them are put into a database schema out of the box, or how to do them with triggers.

I have not spent as much time on it lately. It is also a bit more tedious than I thought.

I am also looking more at Clojure. I think that functional programming will become more prevalent. Plus it also handles concurrency pretty well.

I would like to use Groovy or Clojure full-time at some point. Until that happens, I can only look at one. So I am thinking about going more with Clojure for a while.

On one hand, I think the Clojure community is stronger here in Austin than the Groovy/Grails community. The Clojure meetup happens every month. Sometimes the Groovy/Grails meetup skips a month, as it did in August. The organizers don’t want to be the only ones presenting. I have presented a few times, but I don’t think I am the town favorite.

The irony is that in general I think the Groovy/Grails community overall goes about things better. They are largely copying Ruby and Rails. Sometimes when you ask some Clojure people about web frameworks, you get this answer that they don’t like frameworks, they like to pick and choose amongst different libraries. “That’s the Lisp way.” Given that Lisp has spent several decades going nowhere, maybe “the Lisp way” is not the way to go.

That said, I keep getting the feeling that is where things are going. Here is something I posted last year:

When Ken Kousen was here for the Groovy meetup, he said that he had a boss who kept saying, “Oh, we could do that in Lisp 20 years ago.” He thought it was really annoying. He said it was more annoying when he realized his boss was right.

It seems to me that over time languages are becoming more like Lisp or Smalltalk, and less like C.

I still have a few small changes to add to Groovy Validators, and I want to look a bit more at the Grails constraints. But I might get more into Clojure soon. I am on the fence about this. I have spent a lot of time on Groovy and Grails (and money going to GR8Conf), but I don’t want to commit the sunk cost fallacy.

2014-08-25 Tweets

Spring Boot Presentation at AustinGUG

On June 12, Vasu Srinivasan spoke at the Austin Groovy and Grails User Group about Spring Boot. Here are my notes from the meeting.

Video: Battle of Software Languages
What is wrong with current Spring?
Scalability is an issue
Stateless services are better
Do we really need WebSphere for everything?
Rampup time can be pretty high to get things going

Why Spring Boot?
xml for configuration: verbose, bloated, error-prone
Many web app frameworks that started after Spring do not use XML
Ramp up time is important
Opinionated frameworks are becoming fashionable
Spring has to compete with Ratpack, DropWizard, Sinatra, Scalatra, micro-services architecture
Spring has a lot of libraries and components, it needs a way to tie them together

Convention over configuration

What is it?
It’s a container project for creating new Spring projects
It comes with Tomcat or Jetty
It has a lot of starter POMs for lot of libraries:: web jdbc, log, data
It has actuators (health, metrics, beans info, etc)
It supports XML, Java annotated and Groovy bean configuration (not much doc on Groovy)
Supports many databases
Can be used for web/non-web (batch) functionality
Supports many views (jsp, thymeleaf, groovy template engine)

Tradition Spring apps usually Java, what about Groovy?
spring-cli lets you use Groovy, then spring run app.groovy
You can use Groovy as THE language:
apply plugin:’groovy’

You can use Groovy bean instead of xml
GroovyBeanDefinitionreader, likd Grails resources.groovy
Groovy Template Engine
You can use GORM
Annotate with @Entity

Immediate advantages with Groovy
Practical and time-saving annotations: @ToString, @Log, @EqualsAndHashCode
Groovy 2.3 has fast JSON conversions
Groovy Strings
Spock testing
You can compile with @CompileStatic to get faster performance

Go to http://start.spring.io/ to create project

You can use logback, that is what Spring team recommends
The command is gradle bootRun
The for prod, gradle buildJar

Good, Baffling, Unexpected
REST is easy, deployment is easy
Java annotated config is good
Gradle support is good

So many ways to do properties
Decide early, YAML is recommended
Too many logging frameworks
No out of the box support for profiles
Lots of annotations
I mean a LOT of annotations
Many places to put views

Not all xml config an be done with Groovy
No way to directly convert Grails domain objects to JSON
Some things are broke in 1.1, like Gorm

With IntelliJ, you must run in IDE, not with Gradle
Sometimes port is not released
You need to associate template files with Groovy

Nice to have: Groovy config support
Expose entities as REST entities
Maybe it’s in the works

Is it for you?
Are you using Spring?
Do you want better deployment, you want to scale


Another Update For Groovy Validators

I made an enhancement to the Groovy Validator project.

I added a boolean called “throwException” that will throw an exception if one of the fields does not validate. It is optional, and defaults to false. If an exception is thrown, it will print out the value and the constraints.

You can use it for POGOs with the AnnotationProcessor class like this:

AnnotationProcessor.process( Book, true )

You might get a message like this:

"Hey" is a String with a length outside the range of 5 and 10"

You can also use it with immutable objects annotated with the AstImmutableConstructor annotation. This would be a second boolean after the Map with your properties, since the first boolean controls validation:

def thirdImObject = new ImmutableObject002( 
[ firstString: "Hi Once Again", firstInt: 123456789, firstLong: 22L ], 
true, true )

In that case, you get a message with a line for each field. So you might get a whopper message like this:

Groovy validation exception: 
"eeeeeeeeeee" is a String with a length outside the range of 5 to 10 characters 
"NNNNNNNNNNNNNNNN" is a String with a length outside the range of 0 to 15 characters 
101.0 is a double outside the range 10.0 and 100.0 
101.0 is a float outside the range 10.0 and 100.0
101 is an integer outside the range 10 and 100 
101 is a long outside the range 0 and 100

If “thowException” is true for a POGO, the field will either retains its pre-existing value (if it had one) or be set to null. If “throwException” is true for an immutable object, the object will not be created.

You’re welcome.

2014-08-11 Tweets