Travis Continuous Integration Fails

My Travis builds worked nicely until I start to add a java/groovy Swing view or GUI to my projects. The gradle tests run and pass locally, but Travis throws a java.awt.HeadlessException as soon as it tried to run the test suite.

The Travis docs suggest using a tool called xvfb (X Virtual Framebuffer) to simulate a windowing system and run headless tests, but also warn “you need to tell your testing tool process” exactly how to use it.

The solution is simple: just add a few arguments to .travis.yml file. Mine looks like this:

language: java
before_install:
  - "export DISPLAY=:99.0"
  - "sh -e /etc/init.d/xvfb start"
jdk:
  - oraclejdk7
  - openjdk7
  - openjdk8

IBM360

Nice 😉

Is GPars on My Groovy Classpath ?

Since i use sdkman to manage my Groovy and Gradle installs, was wondering what jars it gives me in my groovyConsole classpath.

This script reveals all:

—-

def printClassPath(classLoader) { println "$classLoader" classLoader.getURLs().each {url-> println "- ${url.toString()}"}

if (classLoader.parent) { printClassPath(classLoader.parent) } }

printClassPath this.class.classLoader
-------

and the results are here:
------
Screenshot 2016-03-14 09.27.00

Drag and Drop Visuals in your Interactive Dashboard – Gridster & D3.js

This is a treat for quicker mock ups !

Anmol Koul

Greetings Folks,

As part of my continued interactions with the open source stack, i came across a very nice library: Gridster.js. Gridster is a really cool and awesome JavaScript library that enables drag and drop as well as re-sizing features for your html placeholders (div’s).

I have had my fair share of experience with self service modules provided by various BI tools like Spotfire, Qlik, Tableau etc. The main aim of these modules as i inferred is to allow the business user to focus on the business aspects of visuals rather than on creating and designing the visuals.
At the same time, These self service modules reduce the dependency on IT as opposed to the traditional reporting structures where the businesses have to rely on IT for report generation.
And lastly, these modules allow faster time to insights as the dependency on the IT is reduced and the business (analyst)…

View original post 763 more words

List of Groovy Annotations

Don’t know where i found this list but have always wondered what annotations can we use when coding groovy scripts ? This list may not include more recent annotations – sorry.

Yeah, know you always wanted to understand groovy annotations but were afraid to ask, so just to give you the scoop, yo can watch this Paul King video where he explains how it all works – enjoy 🙂


Groovy AST Transforms
Groovy AST Transforms by Paul King

For those who don’t know, annotations are metadata tags we provide to the groovy compiler. These annotations are not directly turned into byte code, but more typically generate a small set of add-on logic to support specific stuff.

One typical annotation i use a lot is

@ToString class Fred{}

which asks the groovy compiler to produce extra code to create a toString() method for my class rather than hand-code one myself – cos i’m a lazy bugger like that ;-}

The list so far is :

// Abstract Syntax Tree
- in memory transform of your groovy script before bytecode generation
- it's a macro-like compiler hook allowing further mods to post-xlate /  pre-generate stage
- Code generation
@ToString
@EqualsAndHashCode
@Canonical
@TupleConstructor
@InheritConstructors
@Category
@IndexedProperty
@Lazy
@Newify

- Class design
@Delegate
@Immutable
@Memoized
@Singleton
@Mixin

- Logging
@Log
@log4j
@Log4j2
@Slf4j

- Safe Scripting
@ConditionalInterrupt
@ThreadInterrupt
@TimedInterrupt

-CompilerDirective
@Field
@PackageScope
@AnnotationCollector
@DelegatesTo
@TypeChecked - throws error if typo in var.s ane method names, bad return types, wrong type assigns -- allows fine-grained type inferences for DSLs or dynamics
@CompileStatic - generates same bytecode as javac w/same performance whe used with @TypeChecked
@CompileDynamic

- Swing
@Bindable
@ListenerList
@Vetoable

- Dependencies
@Grab
@GrabConfig
@GrabExclude
@GrabResolver

- Testing
@NotYetImplemented
@ASTTest

More

Let me know if you find more annotations we can add to this list.

StackEdit.Io – A Live Mark-Down Editor

StackEdit.IO

This is a sample markdown edited tool. It uses the live-console approach. It’s like an immediate WYSIWYG editor – quite interactive. And this editor has two features that are really keen :
1. Direct upload of document to wordpress
2. Dropbox backing store for persistent document retention.
3. Go to read more of the doc.s meself !

If you want to try it out and have a Dropbox account, please see this link: https://stackedit.io/editor# as it will give you a live taste of what this tool can do. Enjoy 🙂

Written with StackEdit.

README2.md

Groovy Koans Project

The Groovy Koans project is a collection of small exercises in the form of unit tests, designed to get Java developers up to speed on Groovy features and common idioms. It starts by teaching you basic Groovy building blocks, and gradually builds your knowledge towards metaprogramming, slurpers, and all the goodness Groovy has to offer !

Getting Started

  1. Make sure you have JDK 1.6+ installed
  2. Download and unzip the Koans (or clone the GitHub repository with $ git clone https://github.com/nadavc/groovykoans.git)
  3. Remove the solutions from the Koans using $ ./gradlew removeSolutions
  4. Execute Koan01 with $ ./gradlew koan01 and fail (or any other Koan using $ ./gradlew koan##)
  5. Fix code, and execute again
  6. Keep going until you’re fluent at Groovy 🙂

Q&A

I like IntelliJ. How can I use it to debug/edit the Koans?

I am forced to work behind a proxy. Can I still run the Koans?

The gradlew script downloads Groovy and Gradle for you, so you don’t have to set up anything by yourself.
To allow gradlew to work through your proxy, simply add the following parameters:

$ ./gradlew koan01 -Dhttp.proxyHost=[http proxy] -Dhttp.proxyPort=[http proxy port]

The answers are already there! What’s the point?

One of the perks of learning through Koans is that once your Koan is solved, you can compare your solution with
the ‘official’ solution and perhaps learn from that comparison as well. It is also a way to make sure that the Koans
are indeed solvable by filling in the blanks.

For optimal learning experience, however, you should first try to solve the Koans without those solutions as reference.
To remove the solutions, run $ ./gradlew removeSolutions from the root of your unzipped Koans.

Are there more Koans planned? How will I know?

These are the Koans that are currently planned:
* Embedding Groovy
* Creating your own DSL
* Creating your own builder
* Transformations
* GPars

Follow me on Twitter or GitHub for updates.

Credits and License

The Koan concept started way back in Zen practice. It was then adapted by the good folks of
rubykoans.com and perfected by Neo4j. The Groovy Koans project is licensed under the
WTFPL.

Please feel free to leave comments and pull requests 🙂

Enjoy!

Groovy 2.3 Json Parser Improvements

Using notes from guillaume’s presentation @devoxx France https://speakerdeck.com/glaforge/groovy-in-2014-and-beyond-at-devoxx-france , i liked these improvements to be able to read framework configuration files using the new json parser. It is tricky if your json payload is not constructed with unquoted keys and quoted strings (but unquoted integers). so tried this sample:

// https://speakerdeck.com/glaforge/groovy-in-2014-and-beyond-at-devoxx-france
// JSONSlurper for config files using groovy 2.3.0

import groovy.json.*
import static groovy.json.JsonParserType.*
def parser = new  JsonSlurper().setType(LAX)
def conf  = parser.parseText '''
{
    // no quotes for keys, single quote for values but not integers
    environment:'production'
    server: 5
    name:'fred'
    age:21
}
'''

assert conf.environment=='production'
println "Number of servers:"+conf.server
println "Server age:"+conf.age

/*
Number of servers:5
Server age:21
*/