Programmers have long been taught that validating inputs is a wonderful thing to do. While there is some truth to this, the flip side of it is that going overboard with this philosophy and validating data everywhere makes software unmaintainable in the long run.
I suppose you could call this one of the most fundamental misconceptions about software — it isn’t really about “telling a computer what to do”. Sure, that’s a small part of it, but when you come to think about it, that’s the easy part. Once you know what you want, it isn’t hard to instruct a computer to do it.
Curiously, there is no 5-minute guide for a standard Ant + Ivy setup available on the Internet, despite the fact that there are no more than one-and-a-half ways of doing it.
I have created a “skeleton” configuration (tar.gz, sha256sum, sig) that can be used to quickly get started with the process of writing code and tests, rather than setting up build targets, folders and packaging instructions. The configuration assumes you want to write code in Scala, but it is easy enough to replace that with good ol’ Java if need be.
What’s interesting about this setup is that it assumes that you have Ant and a JRE installed, and nothing else. Ivy is downloaded directly from the repository as part of the build process, and so is the Scala compiler. The only file that needs to be customized is build.properties, which includes details such as the name of the project and the entry-point to your application.
The architecture of large-scale systems is befuddled with an abundance of terms, methodologies and philosophies: services, clients, libraries, communication protocols, workflows, persistence, caching, service-oriented architecture, RESTful services and so on. As a result, discussions pertaining to the design of systems often tend to be slightly confused. Even with smart, experienced engineers having many “pearls of wisdom” at their disposal, there is a tendency to compare apples to oranges, with no easy way to quantify the benefits of specific choices.
You could conclude from all of this that perhaps there are multiple valid approaches to solving the same problem of system design — this is what I’ve dubbed “the multiverse myth” — but this conclusion would be wrong.
In the world of applied computer science, every decision that you make is a trade-off between multiple, competing interests. For instance, any computer-science student worth his salt would be aware of the trade-off between time-complexity and space-complexity. In layman terms, you can usually find an algorithm to do any job faster if you are willing to allow it to make less efficient use of space.