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.
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
A golden Zombie villager with a golden chicken, so I was told.
Going all kinds of Scratch
Scratching the surface
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?
|Specific IDE (GGTS or Eclipse) generated derivations.
|Specific IDE (GGTS or Eclipse) derivations and/or user settings.
|Generated derived classes from sources
|Specific IDE (GGTS or Eclipse) generated derived classes from sources
.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.
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:
Moving from the old
grails-app/assets was a breeze, but adding the correct
require statements, introducing an
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.
Then we could add the proper
requires statements to include 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:
locales in total
Consequently I had it to the manifest files:
- 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:
- 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.
<r:script> and even
<script> I had to replace most of them with
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
Uncaught ReferenceError: $ is not defined
make sure JQuery is present in the following locations
In a 2nd part I’ll describe some Grails 2.4/application-specifics I encountered.