As a follow-on to my previous post, here’s a word specifically on building and using Library EARs in gradle. What is a Library EAR? WebLogic allows you to create a Library EAR, which basically acts like a third-party library dependency in other contexts. A single location for some shared code. I won’t get into what … Read more
I recently wanted to convert an old Ant WebLogic build to use the Gradle build tool instead of Ant. The main driving force behind that change was that the Ant build.xml file housed many different responsibilities, from building and testing the source code, to maintaining property files, to deploying and running the application, along with many tasks … Read more
When is it acceptable to cut corners when moving from one architecture to another? I’m talking about things like architectural requirements, such as a requirement that all services integrate with an APM monitoring tool. When is it all right to cut corners when trying to get a service migrated from one architecture to another, and … Read more
How do you keep a legacy application up, running, and maintained all while trying to refactor it to a new architecture? We all know that the world isn’t going to stop and let you go off for x months/years to rewrite a legacy system in the new shiny architecture and language/framework. Even if you do … Read more
Sometimes, fixing a bug in legacy software requires quite a bit of reverse engineering. In order to figure out why a bug is occurring, you may first need to learn how a whole subset of the system works at all. Most of your time is spent following method usages and stack traces. You have to … Read more
Some people view certain code quality practices, especially code formatting standards, as very nit-picky things to enforce. Somehow, these always seem to only apply to the practices that we don’t agree with though. It’s not nit-picky to require braces on a new line, but it is to require spaces instead of tabs. Why do we … Read more
Quite often, when working with legacy code, there is a tremendous abhorrence to change. Usually this does have good reasoning behind it. If a system has been working for x number of years, you don’t want to just come in and starting changing things without cause. You will constantly come across bits of code that … Read more
We recently came across a piece of our application that hasn’t been working for two years or more. I would say, that since it hasn’t been working for so long, and obviously it hasn’t been a high enough priority to fix, that we should just remove that crusty old code. However, instead of doing that, we are … Read more