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.
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.
When it comes to software development, product teams are better than project teams. I’ll explain why.
Have you noticed a pattern that most organizations use to build software? They assign a project manager to prepare the project charter that broadly defines the scope, cost and schedule. Senior management approves the charter, and then they assemble a team. Developers, analysts, QA testers join the new team even though they may be winding up other projects. Management assigns an architect. They might also assign a DBA, network and middleware experts on a part-time basis.
Problem: You are developing a Grails application. You are using scaffolding to build out your views and controller actions. Yet for some mysterious reason Grails is not rendering some properties in the views.
Solution: Did you designate some properties as transient? If so, then by default Grails does not generate transient fields in views. To fix this you need to install the template plugin, and change the value of the persistentPropNames variable:
Thanks to lo_toad for pointing this one out. This solution saved me so much time.
This describes how to use Subversion on a day to day basis. If you have inherited or been assigned to a software development project that uses Subversion, but are unfamiliar with how it works and how to use it, then this post is for you.
So What is Subversion?
Apache Subversion is a Source Configuration Management (SCM) system that has one central repository, usually located on a web server. Each of us works on our own copy of the Subversion-controlled project. When post our changes back to the central repository, Subversion merges them with the existing code and increments the Revision number. Anyone who then updates their local copy of the project will now see the changes we just made. As long as everyone performs frequent updates to their local copy, it all works fine.
What’s So Great About It?
Subversion uses the copy-and-merge philosophy, in contrast with the Lock-Modify-Unlock method used by older SCMs such as RCS, and Microsoft Visual SourceSafe (VSS). In these systems, only one person can change a file at a time, while everyone else is locked out. Veterans of RCS or VSS may point to a risk of running into conflicts and other problems when using Subversion’s copy-and-merge. While the risk of conflicts is still present when two or more people are working on a file, in practice this is only a concern when these people are changing then same part of a file.
Spending time on software design is important because it helps you solve the big problems up front. Without this effort, developers can get bogged down, or worse, build something that doesn’t meet an important customer requirement. What you want to avoid is spending too much time in the design phase. After all, our objective is to deliver working software to our customer early and often. At some point we need to “get on with it”. The trick is to recognize that point
When do you know when to take a break from design and start building something? Well, one clue is when you find yourselves bouncing back and forth from one design option to another. Ask yourself, might this vacillating be due to a lack of information? If you’re speculating on what may be important to the customer, talk to them. Clarify what their needs are. Ask them what would exceed their expectations, and what would disappoint them.
If you have design options that would equally satisfy your customer, are you lacking some technical information? Specifically, how well do the capabilities of the technology stack support each of your design options? If this is the case, then it’s time to see what will work. Decide what metrics are important enough to help you decide on a design, then go and make a prototype. Take one of your design options, and build it out enough for you to benchmark it. Show it to your customer and get their feedback. Then take your other option, benchmark it, and get customer feedback. Repeat this for a
third option if you have it. Now you have some empirical data to help you with your decision.
