devs

Rossen Stoyanchev talks to Wesley Reisz about blocking and non-blocking architectures, upcoming changes in Spring including Spring WebFlux, the reactive web stack in Spring framework 5, due this summer.  He also discusses the differences between rxJava and Reactor.

Why listen to this podcast:

 - Spring Framework 5 is due to be released June 25 2017
 - Spring Web Flux provides a web programming model designed for asynchronous APIs
 - Back-pressure is important in a server environment; less so within a UI environment
 - It’s possible to use a Spring Web Flux client within a Spring MVC applciation
 - Managing sets of thread pools is more complicated than having a scalable asynchronous system

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2pPgq0G

You can subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2pPgq0G

InfoQ Podcast

Show Notes

Rossen Stoyanchev on Reactive Programming with Spring 5 and Spring WebFlux

Martin Fowler chats about the work he’s done over the last couple of years on the rewrite of the original Refactorings book. He discusses how this thought process has changed and how that’s affected the new edition of the book. In addition to discussing Refactors, Martin and Wes discuss his thoughts on evolutionary architecture, team structures, and how the idea of refactors can be applied in larger architecture contexts.

Why listen to this podcast:

 -    Refactoring is the idea of trying to identify the sequence of small steps that allows you to make a big change. That core idea hasn’t changed.
 - Several new refactorings in the book deal with the idea of transforming data structures into other data structures, Combine Functions into Transform for example.
 - Several of the refactorings were removed or not added to the book in favor of adding them to a web edition of the book.
 - A lot of the early refactorings are like cleaning the dirt off the glass of a window. You just need them to be able to see where the hell you are and then you can start looking at the broader ones.
 - Refactorings can be applied broadly to architecture evolution. Two recent posts How to break a Monolith into Microservices, by Zhamak Dehghani,  and How to extract a data-rich service from a monolith by Praful Todkar on MartinFowler.com deal with this specifically.
 - Evolutionary architecture is a broad principle that architecture is constantly changing. While related to Microservices, it’s not Microservices by another name. You could evolve towards or away from Microservices for example.

More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2QbdHej

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Check the landing page on InfoQ: https://bit.ly/2QbdHej

Martin Fowler Discusses New Edition of Refactoring, Along With Thoughts on Evolutionary Architecture

This week on the InfoQ Podcast, Wes Reisz talks to Tanya Reilly (Principal Engineer at Squarespace and previously a staff SRE at Google). Tanya discusses her research into how the fire code evolved in New York and draws on some of the parallels she sees in software. Along the way, she discusses what it means to be an SRE, what effective aspects of the role might look like, and her opinions on what we as an industry should be doing to prevent disasters. This podcast features discussion on paved roads, prevention, testing, firefighting (in software), and reliability questions to ask throughout the software lifecycle.

Why listen to this podcast:

- Teams increasingly   are responsible for the entire software lifecycle. When this happens, they think about the software differently because they know their the ones that will get paged if it fails. This idea is at the core of the “You Build It, You Run It” philosophy in DevOps.
- The role of SRE is to define how to do things in a really reliable way. The focus is to make the majority of the operations work go away, and, for the things that can’t go away, it’s as easy as possible.
- At the very start of a project (when you’re writing the initial design), you should be thinking about the dependencies for a system and how will those that follow with be able to determine that. A great way to do this is to offer an API that people will want to use and then instrument it.
- We can learn a lot from the growth of fire safety regulations as metaphors for software, including: fireproof interior walls, socializing best practices, software inspections, and circuit breakers are all examples.
- The work SREs do varies in many places. SREs range from making recommendations on patterns to library creators in other areas. Occasionally, SREs are firefighters of last resort. In these cases, they’re the last resort though.
- We use error budgets and SLOs to quantify how many much risk we’re comfortable taking. It’s used to inform how much less (or more risk) we’re willing to take on.
- We need to consider software reliability throughout the full cycle of software development. When you build systems. Think about as if there will not be someone on call for it .

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq

Tanya Reilly on Site Reliability Engineering and the Evolution of the New York City Fire Code

On this week’s podcast, Wes Reisz talks with Brian Goetz. Brian is the Java Language Architect at Oracle. The two start with a discussion on what the six-month cadence has meant to the teams developing Java. Then move to a review of the features in Java 9 through 12. Finally, the two discuss the longer-term side projects (such as Amber, Loom, and Valhalla) and their role in the larger release process for the JDK.

* The JVM’s sixth-month cadence changed the way the JDK is delivered and planned. While it definitely provides more rapid delivery at expected intervals, the release train approach turned out to also improve flexibility and efficiency.
* Oracle JDK and OpenJDK are almost identical. Most of the JDK distributions are forks from OpenJDK with different bug fixes and backports applied. So the difference between the distributions now is largely which bug fixes are picked up.
* Local Variable inference (which was released as part of Java 10) illustrated the tension on making changes to the language. Many people wanted the change, but many others felt it would enable people to write bad code. Oracle had to balance the two views when making the change.
* The number of Java versions allow finer grain decision making on what is appropriate for an application. With the adoption of containers, applications are bundled with an exact JDK version rather than having to use one from a systems level. The different versions give developers more options.
* Incubating features are new libraries added to the JDK. They were offered starting with Java 9 as a way for people to test and offer feedback more rapidly. With Java 12, preview features will be released. Preview features are similar but are core platform and language features.
* Shenandoah and ZGC are both low latency garbage collectors. They originally came from different sources. While both garbage collectors are similar, each has different performance characteristics under different workloads. The two garbage collectors represent options available to JVM developers.
* Most non-trivial JDK features take more than six months to develop. Longer term side projects like Amber, Loom, Valhalla are where these features are developed prior to being released with a version of the JDK. The projects range from language enhancements to concurrency work.

devs

Álvaro Salazar