VenkatSubramaniam

Learning about design patterns is not really hard. Using design patterns is also not that hard. But, using the right design pattern for the right problem is not that easy. If instead of looking for a pattern to use if we decide to look for the design force behind a problem it may lead to better solutions. Furthermore, with most mainstream languages supporting lambda expressions and functional style, the patterns appear in so many more elegant ways as well.

Creating code is easy, creating good code takes a lot of time, effort, discipline, and commitment. The code we create are truly the manifestations of our designs. Creating a lightweight design can help make the code more extensible and reusable.

Why talk about resilience when thinking of scale? It turns out all the effort we put in to achieve great performance may be lost if we're not careful with failures. Failure is not only about unavailability of parts of an application to some users, it may result in overall poor performance for everyone else as well.

GraalVM is a polyglot environment that can execute your code, written in multiple languages, in multiple different platforms. With version 1.0 released this year, this technology has the potential to make significant impact on both development and deployment.

Java Modules are the future. However, our enterprise applications have legacy code, a lots of it. How in the world do we migrate from the old to the new? What are some of the challenges. In this presentation we will start with an introduction to modules and learn how to create them. Then we will dive into the differences between unnamed modules, automatic modules, and explicit modules. After that we will discuss some key limitations of modules, things that may surprise your developers if they're not aware of. Finally we will discuss how to migrate current applications to use modules.

The world we live in today is changing rapidly, both in terms of hardware and in business demands.

Once considered lightweight, threads in reality take up significant memory and thus turn into a limitation for true scale. The JVM is heading towards creating fibers which are lightweight compared to threads and have the potential to be truly non-blocking. Mixed with continuations, which are data structures that can preserve state between calls, we can create highly effective asynchronous applications that can scale to a much greater extent than threads.

Big data comes in two flavors high volume and high frequency. How we process the data depends on both the nature of data and the type of applications.

It's common knowledge: software must be extensible, easier to change, less expensive to maintain. But, how? That's what we often struggle with. Thankfully there are some really nice design principles and practices that can help us a great deal in this area.

It's common knowledge: software must be extensible, easier to change, less expensive to maintain. But, how? That's what we often struggle with. Thankfully there are some really nice design principles and practices that can help us a great deal in this area.

Big up front design is discouraged in agile development. However, we know that architecture plays a significant part in software systems. Evolving architecture during the development of an application seems to be a risky business.

Transitioning from a monolith to a microservices based architecture is a non-trivial endeavor. It is mired with many practices that may lead to a disastrous implementation if we're not careful.

Design patterns are common place in OO programming. With the introduction of lambda expressions in languages like Java, one has to wonder about their influence on design patterns.

Many developers aspire to become architects. Some of us serve currently as architects while the rest of us may hope to become one some day. We all have worked with architects, some good, and some that could be better. What are the traits of a good architect? What are the skills and qualities we should pick to become a very good one?

Before spending substantial effort in refactoring or altering design, it would be prudent to evaluate the current quality of design. This can help us decide if we should proceed with refactoring effort or a particular alteration of design. Furthermore, after evolving a design, using some design metrics would help us to evaluate if we have improved on the design front.

Before spending substantial effort in refactoring or altering design, it would be prudent to evaluate the current quality of design. This can help us decide if we should proceed with refactoring effort or a particular alteration of design. Furthermore, after evolving a design, using some design metrics would help us to evaluate if we have improved on the design front.