Devoxx4Kids

Today we had great fun at First8! With the ladies of JDuchess we organized Devoxx4Kids, a programming event to introduce software programming concepts to kids in a fun way.

In a few workshops we had a pack of 40 children create dazzling games in Scratch, make Jave modifications to the Minecraft source code in order to have creepers explode 30 times bigger than usual and make LEGO robots dance and walk the line.

Following photo’s give an impression of today.

Full house

Attaching the LEGO robot

Having the LEGO robot detect the color of the ball

These robot shoes are made for walking

You don’t want to know what this does to the LEGO robot 🙂

Making some Minecraft code changes to the Creeper

Helping eachother

A golden Zombie villager with a golden chicken, so I was told.

Going all kinds of Scratch

Scratching the surface

What Grails files should end up in version control?

You don’t need to add all files in a Grails application- or plugin project to version control, because some of the files are derived (this means they can be re-created from source files) or they are generated for you locally as developer (and have nothing to do with the team) if you use IDEs such as Eclipse or Groovy/Grails Tool Suite (GGTS).

You should ignore the following files in version control:

File or folder	Why not in version control?
.project and .classpath	Specific IDE (GGTS or Eclipse) generated derivations.
.settings	Specific IDE (GGTS or Eclipse) derivations and/or user settings.
target	Generated derived classes from sources
target-eclipse	Specific IDE (GGTS or Eclipse) generated derived classes from sources

Generated files .project and .classpath contain developer-specific local paths which should not end up in version control. Former versions of Eclipse or GGTS could not deal with the absence of these files, and consequently failed to import any project without these.

Nowadays GGTS is able to detect this and fix it. You’ll get next dialog in this situation:

By answering Yes, aforementioned files will be re-generated.

Upgrading to Grails 2.4.3 Part I – Asset Pipeline

I recently upgraded from Grails version 2.3.6 to 2.4.3. In this part I’ll describe some dealings I had with the new Asset Pipeline plugin, in the 2nd part of this post I’ll describe some Grails 2.4/application-specifics.

Basically the upgrade was a mix between:

• reading about what’s new in Grails 2.4 on the Grails website
• creating a brand new Grails 2.4.3 application and doing a diff with our application afterwards, to see if we missed anything

Asset Pipeline

Moving from the old grails-app/web-app to grails-app/assets was a breeze, but adding the correct require statements, introducing an application.css and application.js as ‘manifest’ files, caused some headaches:

• we used the Grails kickstart plugin which already included the correct Bootstrap styling, but we tossed it out the window because we couldn’t get it to work with the Asset Pipeline plugin. So we manually had to add the Bootstrap CSS framework resource files plugin.
  grails-app/conf/BuildConfig.groovy

  compile ":twitter-bootstrap:3.2.0.2" compile ":asset-pipeline:1.9.6"

  Then we could add the proper requires statements to include Bootstrap.

  grails-app/assets/stylesheets/application.css

  /* *= require bootstrap */

  Also we had to add JQuery explicitly as JavaScript dependency:

  grails-app/assets/javascripts/application.js

  //= require jquery //= require bootstrap

• The kickstart plugin came with a Bootstrap-styled Date Picker – included from an external Github project. Manually I downloaded the .zip (1.3.0) and added the following resources to our application:

  assets/stylesheets/datepicker3.css assets/javascripts/bootstrap-datepicker.js assets/javascripts/locales/bootstrap-datepicker.ar.js assets/javascripts/locales/bootstrap-datepicker.az.js assets/javascripts/locales/bootstrap-datepicker.bg.js ...and 51 locales in total

  Consequently I had it to the manifest files:

  grails-app/assets/stylesheets/application.css

  /* *= require bootstrap *= require datepicker3 */

  grails-app/assets/javascripts/application.js

  //= require jquery //= require bootstrap //= require bootstrap-datepicker

• Somehow our date pickers (inputs with the class .datepicker) didn’t get transformed into actual datepickers anymore. So in our own application.js I had to add the following:
  grails-app/assets/javascripts/application.js

  ... //= require_self $(document).ready(function() {   // enable datepicker components   // see http://eternicode.github.io/bootstrap-datepicker   $(".datepicker").datepicker({   }); });

• Our Bootstrap Combobox was pretty easy to add to the manifest files 

• The look-‘n-feel afterwards caused minor subtle differences, basically due to some convenience CSS classes the Kickstart plugin had, which we didn’t have anymore, such as the .footer class on <footer class="footer" /> we had in …eh, the footer-template. I manually added some styling in our application.css to have at least some padding back on top.
• I had all kinds of JQuery errors due to all kinds of JavaScript-snippets using it. Our code was littered with <g:javascript>, <r:script> and even <script> I had to replace most of them with <asset:script type="text/javascript"> and put

  <!-- Deferred JavaScript code --> <asset:deferredScripts/>

  at the bottom – just before </body> – in the outer main template. If your browser console shows all kinds of JQuery errors, such as

  Uncaught ReferenceError: jQuery is not defined // or Uncaught ReferenceError: $ is not defined

  make sure JQuery is present in the following locations

  grails-app/conf/BuildConfig.groovy

  runtime ":jquery:1.11.1"

  grails-app/assets/javascripts/application.js

  //= require jquery //= require bootstrap

  and you’ve located and updated all aforementioned JavaScript snippets.

In a 2nd part I’ll describe some Grails 2.4/application-specifics I encountered.