I recently wrapped up attending the SpringOne Platform conference in Las Vegas. This was my first time attending SpringOne; it was an experience listening to talks and having conversations with some of the top experts in software development.
If you didn’t attend SpringOne, you’ll definitely want to read this post. We’ll go over these four themes and how to potentially apply them in your endeavors going forward.
- Reactive Design
- Making Testing Easier with Spring Boot 1.4
- Shortening the Development Feedback Loop
- Contributing to the Open Source Community
Reactive Design
The inclusion of Spring Reactive into the core Spring framework is on the roadmap for the Spring 5 release. As a result, many sessions at SpringOne were devoted to covering what reactive design is and how to utilize it.
Node.js developers should already be familiar with the pattern, indeed it’s the raison d’etre of node.js. Reactive design is based on the principle of non-blocking I/O that is event-driven. If all that sounds confusing, feel better knowing you are not the only one having trouble with the concept – I, too, am still working on absorbing it.
What it means in simpler terms: in the “standard” (imperative) way of writing a program a call to an external source, be it a database or service, would have the calling thread wait for a response before continuing to execute. Reactive design changes this by creating a promise (i.e. an event) and reading the back result later (non-blocking).
This dramatically reduces system resource usage as the number of threads required to do the same amount of work is vastly reduced (each thread takes up memory and database and services can only serve only a finite number connections simultaneously).
Another key concept of reactive design that was frequently touched on during talks is back-pressure. Back-pressure creates an inversion between subscriber and producer. Whereas often a producer would dictate the size of a return, usually the entirety of a result set, to the subscriber, back-pressure allows the subscriber to define how much it wants to receive at time as well as when (i.e. a subscriber would only request more from the producer once it has finished processing the previous return). This helps prevent subscribers from being overwhelmed by a large data set and reduces the demand on producers by only sending work that a subscriber ready for as well as distributing load over time.
Together these features of back-pressure helps to create more reliable services. In my opinion this is where the real benefits of reactive design are going to come from for the industry-at-large.
For a more formal introduction on reactive programming, David Syer of Spring wrote an excellent three-part series on programming with spring reactive: Part 1 / Part 2 / Part 3.
Making Testing Easier with Spring Boot 1.4
Pivotal recently released Spring Boot 1.4 which comes with host of new and fun features (like auto-generating ascii banners from a picture on classpath!) along with bringing in Spring Core 4.3 that make the life of a developer even easier.
Of all the features added, what I am most excited about is all the new testing support. A common criticism of IoC/DI containers like Spring is that it can make the testing of code more difficult due to all the context setup a developer will have to write in order to test their code (though much of this can also be alleviated with better code design). Luckily Pivotal and the community have responded and added a suite of new features to reduce the burden of writing unit tests. A full article of all the new testing features can be found here.
Making code easy to test is one of the most important enabling features in shortening the feedback loop which I will get to more here in a second. For the full release notes of Spring Boot 1.4 check out this link.
Shortening the Development Feedback Loop
Previous conferences and talks I have attended often focus on a new tool, pattern, or technology. While the benefits might be obvious, often the process of introducing them into an organization is difficult. However, I was happy to see Pivotal devote large portions of two keynotes to one area I have been reading into lately; Continuous Delivery.
The key tenet of continuous delivery is that every commit should start a series of an automated processes (testing, deployment) that ends with the delivery of the code to at least a production-like environment, if not production itself.
To accomplish this goal, continuous delivery relies heavily upon automation; unit testing to verify code meets a quality threshold, integration testing to ensure an application behaves properly in an environment, and deployment scripts to prevent configuration issues when deploying to an environment.
Within these processes are features that enhance the development cycle such as unit tests that allow developers to verify changes more quickly, the ability to fully audit changes/deployments, and making the process of rolling back a deployment vastly easier. All of these processes intrinsically help reduce risk, but together with frequent deployments to production reduce risk by shrinking the deltas between deployments.
While there are no panaceas in the development world, continuous delivery, the ability to quickly and confidently deploy to production (in some cases hundreds of times a day), is probably the defining characteristic that separates good software companies from bad ones. And, any organization that writes so much as one line of code is a software company.
Contributing to the Open Source Community
Following on with the theme of shortening the feedback loop, a core reason why open source projects have taken over the software world from our operating systems (Linux), frameworks (Spring), and platforms (Cloud Foundry), and so many other areas, is because open source offers a feedback loop that a closed source project can’t: the users of a tool can contribute back to it!
This is what has enabled Spring to grow from being an IoC/DI container to a nearly all-encompassing ecosystem (https://spring.io/projects). Contributing to open source projects is an excellent way of building your knowledge base, learning new ideas, and build connections outside of your organization or immediate geographical region. Contributing to open source projects can range from fixing issues to adding new features.
So if you are interested in contributing, there are plenty of more opportunities to do so.
Final Thoughts
Attending SpringOne Platform was a great experience. It’s amazing seeing the progress the Spring community has made over the past several years in adding new projects to the platform and expanding on the capabilities of projects they already have.
For continued updates on Spring, check out the blog at: https://spring.io/blog. Also make sure to keep up with our blog here at Keyhole by subscribing in the right-hand sidebar!
The new features coming in Spring 5 – as well as the conversation I had with the Pivotal employees – have me very excited about the future of Spring and Java!
| Reference: | SpringOne Platform 2016 Retrospective from our JCG partner Billy Korando at the Keyhole Software blog. |
Nothing new
Thank you for this interesting post ! :)