Devoxx4Kids

Devoxx4KidsToday 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.

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:

GGTS Convert to Grails project

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:

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
      $(".datepicker").datepicker({
      });
    });
  • Our Bootstrap Combobox was pretty easy to add to the manifest files¬†(smile)
  • 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>(smile)¬†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.