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…
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!
With the recent revelation that Pivotal will stop sponsoring the Groovy and Grails projects after March of this year, I want to give some of my own thoughts on where this leaves the two projects and what their future might hold. I’ll do this across two blog posts, starting with Groovy.
It may come as a surprise, but I feel pretty sanguine about Groovy. That’s not to say that I don’t sympathise with the teams for the situation they find themselves in, but Groovy itself is in a strong position. First and foremost, it’s stable with a solid set of features already there. Recent additions include:
- Static type checking and compilation
- Dedicated Android support
As far as I’m concerned, Groovy doesn’t need any major changes in the near term and so it’s not a big deal if its development slows down. It supplements Java well and provides enough differentiation that it’s worth you using Groovy over Java. It’s great for scripting, Spock is fantastic for unit testing, and Groovy works really well with Spring Boot, Ratpack, Grails, Griffon and other application frameworks. And those are just a fraction of its potential use cases.
The language also benefits from an existing open development process, probably because it originated as a collaborative project between people from different companies. So even if the Groovy team is broken up – something I hope can be avoided – I can’t see there being significant disruption. You’re seeing one of the key benefits of open source software: it survives beyond the withdrawal of a key sponsor. You can’t really say that about commercial software. And while Groovy satisfies a need among developers, you can be sure it will thrive and prosper.
To sum up, Groovy has reached a stable place that puts it in good stead whatever the future might hold. It should still be an essential part of every Java developer’s tool chest. Development may or may not slow down, but it will continue. And I have my fingers crossed that Guillaume, Cédric, and Jochen will find new homes swiftly and I hope they manage to stay together as a team.
One final thought: on the last Groovy Podcast (audio-only version) I half-jokingly said that Google would sponsor Groovy. Of course, I don’t know whether that will happen, but in light of Swift for iOS development, I think it’s something that Google should definitely consider. I’m sure a more productive and expressive alternative to Java would be more than welcome within the Android development community and it fits nicely with their use of Gradle for the build system. Let’s see what happens!
The Grails post may take a bit longer to appear as I think there’s more to say for that.
I gave a talk at the last Spring One 2GX on the effect of Java 8 on Groovy. It’s a long presentation (well over an hour), so I think a nice summary is in order for those that don’t have the time to watch the whole thing.