I’m pleased to announce that I’m working as an instructor for the new Adaptos training company, which is offering a different style of course from the normal intensive ones.
While intensive courses are good for getting started with a particular topic, they are weak in terms of information retention — how much do students remember a few weeks after the course? — and they often don’t allocate sufficient time to allow students to practise what they’ve learned. They can also result in information overload, particularly for less experienced students.
The Adaptos approach is based on a process of guided self-learning across several weeks. The students are provided with a roadmap of topics and a series of related exercises. It’s then up to the students to allocate time to work through the exercises and learn about the various topics through the supplied learning materials or through books, video courses, blog posts or any other source that they choose to use. The more time a student allocates to the training, the more that they learn. What’s even better is that they can learn at their own pace.
The biggest value of the course comes from the instructor, who reviews the work, offers feedback, and can help students understand particular topics that they may be struggling with. Students can also discuss the topics between themselves through Slack and a forum.
Adaptos are initially offering courses for Groovy and Grails, the first one starting on 15th February. If you’d be interested in other subjects or have any questions or feedback about this initiative, let me know in the comments.
We’ve now reached the time of year when I need to think about initiating the Groovy & Grails eXchange call for papers, so I thought I’d take this opportunity to both resurrect the talk submissions app I created a while back and try to upgrade it to Grails 3. Up until now, I hadn’t properly used Grails 3 for anything, so it seemed like a good opportunity to learn how it differs from previous versions.
Here’s what happened next…
Welcome to the start of an intermittent series of blog posts where I just talk about various bits of technology that I’m in the process of discovering. Don’t expect much in the way of teaching, but do expect much in the way of erroneous comments as I discuss stuff I don’t yet properly understand.
I’m starting the series with Kotlin, one of a new wave of languages for the JVM. I say wave, but the only other one I can think of is Ceylon. Still, Kotlin and Ceylon are important because, as I understand it, they both aim to provide a solid alternative (AKA replacement) to Java. As you’d expect if you follow me, this post has a definite Groovy flavour with most of the comparisons between that and Kotlin.
So why am I looking at Kotlin anyway? Partly to expand my horizons, partly in search of a statically-typed alternative to Java that I’m happy with, and partly because I think it has a reasonable chance of picking up a sizeable following. It seems like a pragmatic evolution to Java that respects the need for good Java integration and doesn’t introduce anything that’s terribly hard for an older programmer like me to understand. It does include a whole bunch of features I like.
After I’d finished the first edition of Grails in Action with my co-author Glen Smith, I told myself I’d never write another book. Then people asked whether a second edition would be forthcoming. “Hmmm”, I thought, “it can’t be that much work to do an update.” After a long period of time, we managed to finish that and I once again promised myself never to write another book, new editions included.
But it seems I’m a sucker for punishment. I’ve decided to have a go at a self-published introduction to Groovy as I feel this is a weak area at the moment. The idea is to give developers from other languages a smooth ramp-up to the language without crossing into the kind of depth that Groovy in Action has. The working title is Practical Groovy as I’m hoping to orient it towards learning through practical examples.
To aid in this endeavour, I’m making the early drafts of the book available publicly on GitHub so that people can provide feedback through GitHub issues. The first drafts of the first two chapters are currently available as both HTML and PDF (you’ll find the links in the GitHub project’s README). Later drafts will bring more structure.
Hopefully either you, your colleagues or your friends will find this helpful in the process of learning our favourite language!
Gradle fans have been discussing a recent article on Gradle and the halting problem. The premise is that a program (such as an IDE) can not reason about a Gradle build without first executing the build script. And since the build script is written in a Turing-complete language (Groovy), it may never complete execution and you won’t even be able to discover a build’s dependencies.