So what is dependency injection? What does it do for the design of your application? What are the benefits (and drawbacks) of dependency injection? In this post I’ll explain what it is, and provide some Java code examples to show you how to use it.
Dependency Injection is one of the five principles of object oriented design. These principles help you design and develop cleaner code that is easier to read, understand, maintain, and is more robust and more maintainable.
As we grow our application portfolio, we soon discover common bits of code used by two or more applications. Often our first reaction is to break these common bits out into shared libraries. If you’re still using an application server, you might even put these libraries in the server itself so other applications can pick them up. After all, why repeat yourself? Certainly there are situations where that makes a lot of sense. Improved application startup time is one benefit. But not always. Sometimes these shared libraries actually hinder your team’s ability to deliver working software. Here I’ll explain why there is such thing as too much sharing.
I had heard about functional programming since Java made it available in 2014 with the release of version 1.8 of the JDK. I had been to several user group meetings where the speakers spoke glowingly of pure functional languages such as Scala and Haskell. It sounded promising, but I didn’t give it much thought until around 2018. That’s when I started seeing Java Streams being used more often in code examples. Recently, I was writing a simple integration solution, and the resulting code looked horrible. That’s when I gave functional programming an honest try. To my amazement, it indeed made my code cleaner. I’ll share my experiences with you and show you how you can make your code more readable with functional programming.
Git has become the ubiquitous source code management since its introduction in 2005. Along the way, a number of branching strategies (“workflows”) have evolved. As with anything in software architecture, there is no one right way to do anything; it all depends on context. In this post I’ll describe three common workflows to help you choose the simplest Git workflow for your team.
As a software development team grows and adds more members, what worked with one or two people no longer works as effectively. The team realizes they need to set up some sort of standard process for developing software. It need not be complicated, just a lightweight process will do. All they need is a way to get organized with a simple development approach. Here is what has worked well for my teams. Adapt it according to your team’s circumstances.
The other day I read a Pluralsight article titled Leadership guide: Your first 60 days as a CIO (registration required), and it made me think. While relationships are a big deal for CIOs, they also matter for everyone in IT. They matter to varying degrees based on your job role; nevertheless who you know and how well you know them makes a difference in your job and your career. Here is why I think in your career or your business, the further you go, the more those relationships matter.
Application deployments have usually meant deploying a new version of an artifact to Production, with stops along the way in Test, Staging, etc. All the new features and bug fixes become active when you deploy this new version. Although you’ve thoroughly tested the application with automated unit tests, functional tests, load tests, and performance tests, you’ve only reduced the risk of something going wrong in Production. If and when something does go wrong, you may need to rollback to the previous version. But what if the fix wasn’t as dramatic as a rollback? What if you could revert the one mis-behaving feature? Even better, what if you could select which features to activate? In this article I’ll explain how you can control your deployments with feature flags.
Suppose your client or your employer comes to you and says “We need you to help us understand how to set up a continuous delivery pipeline.” They assure you they are committed to the goals and benefits of Continuous Delivery, also known as Continuous Integration/Continuous Deployment (CI/CD):
They have acquired all the tooling, and all they need is your guidance and leadership for how to set up a continuous delivery pipeline.
How would you approach this? What sequence of steps or phases would you use? In this article I’ll present some of my thoughts and suggestions.
Roy Fielding coined the term Representational State Transfer (REST) in his 2000 doctoral thesis Architectural Styles and the Design of Network-based Software Architectures. In essence, he argues an API should use the existing HTTP verbs, and it should focus on representations of business objects rather than backend implementations. An example might be to model a Customer object the way the business knows and interacts with it rather than how it’s stored on the customer database table. In this post I’ll describe how to design an effective REST API using some of the concepts Fielding pioneered.
Most software development teams have one person with the role of Architect. Small teams of one or two people may not, but someone is thinking about architecture. This person’s title may be Solution Architect, Application Architect, Data Architect or Systems Architect. For now let’s consider all of them under the collective name of Software Architect. In this article I’ll talk about the characteristics of a good architect, and I’ll explain what a software architect does. I’ll also address the evolution of the role of software architect, and where it is today. By the end I hope you’ll have an answer to the question “so what does a software architect do anyway?”