Nicolas Fränkel is a Developer Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). Usually working on Java/Java EE and Spring technologies, but with narrower interests like Software Quality, Build Processes and Rich Internet Applications. Currently working for Exoscale. Also double as a teacher in universities and higher education schools, a trainer and triples as a book author.
Java Daily: Which 3 books would you recommend?
Nicolas: Enterprise Integration Patterns (a.k.a. EIP)
I consider this book a classic. The EIP is an inventory of basic building blocks with regards to messaging. Blocks are organized around a dedicated role, such a routing, transformation, endpoints, channels, etc. For example, the Content Enricher is a transformer, while the Splitter and Aggregators are routers.
This inventory you to compose any kind of architecture, whether software or enterprise, with those blocks. The EIP is not a book you would read from beginning to end, but it’s a great reference to browse through every now and
Then. Kubernetes in Action
I’m currently reading this one, that obviously focuses on Kubernetes. I find it a great read to learn Kubernetes from the ground up. It walks you through an exhaustive array of subjects:
- Basic Kubernetes objects, Pods, Service, Volumes, ConfigMaps, etc.
- More advanced objects, such as Deployments and StatefulSets
- Security-related concepts
- Automated scaling and scheduling
I believe the book’s greatest asset comes from its thorough and progressive approach to the subject.
This is a shameless plug, but the last book I’d recommend is my own. I decided to write it because I found no other book tackling the subject, although there are tons of books on Unit Testing. Unit Testing has a pretty limited scope, and a quite straightforward approach can be adopted; Integration Testing has a much wider scope, with a lot of context-dependent solutions.
I believe every developer and software engineer should learn more about it.
Java Daily: Why did you choose Java?
Nicolas: I didn’t actually find Java, but Java found me instead!
I don’t have a traditional training regarding software development. First, I studied architecture, and then civil engineering. There were no courses on Java there: I could only study a bit of C, then C++.
My first job was at an outplacement company: my assignment was the maintenance of a legacy application, that had been developed using a proprietary language. After several months, I asked to be re-assigned, and I was given (or more exactly, lent) a Java book to learn by myself. Soon afterwards, I started my first Java mission, and I never stopped working with the language.
Java Daily: What inspires you to keep doing this?
Nicolas: That’s a great question. I do sometimes ask myself the same. I do believe that being a
developer/architect/DevOps/whatever is one of the best jobs in the world: one never stops learning, not only because there are lots of things to learn, but also because new technologies appear nearly every day!
I guess being constantly challenged is also another reason.
As for me, I also like the fact that I’m able to do so many different things: developing, teaching, writing blog articles and also speaking at conferences!
Java Daily: What should we expect from Java in the next 5 years?
Nicolas: I must confess I’m very bad at forecasting. Some years ago, I thought Flash would save us from rendering quirks of different browsers.
Some things, however, are quite already on track within Project Valhalla (https://wiki.openjdk.java.net/display/valhalla/Main): value types (http://cr.openjdk.java.net/~jrose/values/values-0.html), generic specialization (http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html), Reified Generics… The later would be a game changer for other JVM languages such as Kotlin and Scala, because it requires a VM-level change.
From a bird’s eye view, the very recent trend points to the fact that Java is going to be more and more like Kotlin, with a big difference: because Java has been established for so long, it must cope with a lot more weight regarding backward compatibility. As an example, you might look at this OpenJDK thread (http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-January/000945.html) that evaluates how to bring in more keywords into the language. There’s no perfect solution, just options with pros and cons.
Java Daily: What were the steps you took to reach the point where you are now?
Nicolas: It might sound very unoriginal, but work is the first ingredient. I spent lots of evenings in my office working on my computer, when my family were sleeping. For years now, I also publish a weekly blog post. All of that takes time… I was also fortunate to get opportunities, first of them being able to learn Java as mentioned above. There are two other items that I believe were quite beneficial to my career.
In my experience, I learned a lot when I failed. It’s not a reason not to plan, but when you fail, you should embrace it and learn from it instead of instantly jumping to another subject. Note that it’s a when, not an if. In the DevOps world, the Blameless Postmortem is a great practice that should be spread.
Not many people in our industry are ready to admit their lack of knowledge or understanding. As for me, I don’t know all, and far from it: networking, databases, infrastructure are all areas I never worked much on, and that I don’t have much knowledge about. Pretending one knows/understands everything is counter-productive: by asking, one can actually get the missing pieces. I understand it’s easier to behave like that after some years of experience, when one already has some measure of credibility, but it’s important nonetheless.
Java Daily: What would you change in Java to better suit your needs?
Nicolas: The main feature I’d really love to see in the coming years is reified generics, the ability to write generics type in the bytecode. In Java 5, reified generics were sacrificed on the altar of backward compatibility. Since then, we had to cope with adding extra class parameters to get the type. Of course, I also expect the Reflect API to evolve to be able to access that information at runtime.
On the other hand, I started learning Kotlin a few years ago, and I’m pretty sold to it. I would really like for Java to adopt extension properties/functions and non-nullable types. I imagine Kotlin as a laboratory for Java, the former being adopted reactive organizations, while the later used by more stable kind of organizations.
Do you have more questions for Nicolas Fränkel? Do you think you may have something to add? Feel free to leave a comment below. Let’s give back to the Java community together!