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.
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.
Back in my youth, programs used to come as listings in magazines that you copied into the ZX81’s BASIC editor and then ran. How times have changed. Building software has become more complex as the underlying runtimes and platforms have evolved. As a result of that, we have seen an evolution in build tools. I started my working life using Make (for both C++ and Java), before progressing onto Apache Ant and Apache Maven 2. For a brief interlude I even worked with CMake, which I found to be one of the more challenging tools to learn and understand.
Gradle is a recent entrant to the field, and my current build tool of choice. What lifts it above the more established tools, Ant and Maven? This is a question that anyone involved in building Java software in particular should be asking themselves.
It seems to me that one of the big questions around micro services at the moment is how to share code between the services that make up the overall system. This is important because you should be able to deploy individual services independently of others. So what can you share and how should you do it?
I don’t have a straight answer, but I do have a suggestion for how to think about the problem. Imagine that each service is implemented by teams in different companies, each with their own private source repositories. How would you share code then? For me, the answer is through shared dependencies (JARs of compiled classes in the case of Java). And those shared dependencies should probably only contain utility code such as that provided by commons-lang and Guava (Java examples again).
I guess shared client API JARs could work too if you don’t want to code against JSON/XML directly. The key code that _shouldn’t_ be shared is that related to the internal model of the service. The public API though is not internal.
So, is this a reasonable or even helpful way to look at this issue?
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.