History

Back Story

Long ago (~1999), I began work on a codebase that would eventually become what is now Codeprimate Elements (a.k.a. cp-elements). Over the years, this codebase has been known by many different names (jjb-toolbox, com.codeprimate, cp-commons). It has been reorganized (repackaged), redesigned, re-written, re-thought from the ground up, multiple times. I basically fussed about everything, never being quite satisfied with the result.

Finally, in October of 2003, I settled on cp-commons with 3 main goals in mind, vowing never to rewrite this massive, time-consuming effort again (well, until I did, sort of). These 3 goals can be summarized as:

1. Keep It Simple Stupid (KISS) - only add/do what is absolutely necessary;
2. Use Software Design Patterns (follow "best practices"), and...
3. Write Tests!

Years of experience and practice undoubtedly have a way of changing your thinking and reasoning about the quality of a codebase, and of software development in general. Programming languages change, different APIs/frameworks appear, new design patterns are created, architectural models evolve and new concepts are introduced, best/recommended practices change, the standards change, everything changes, all the time, and it is important to embrace new ideas and concepts to continuously learn and improve.

As of October 2011, I began to rework the cp-commons project and from that, created the cp-elements project (cp-elements was born). Therefore, cp-elements was not a entirely a complete re-write, but since cp-commons inevitably became an unwieldy project to maintain collecting some bad habits along the way, I basically began yet again.

This time would be different. After over 10 years of using different APIs/Frameworks, studying API design and creating different APIs, I came up with a recipe that would forever change how I viewed software development.

1. Yes, "Keep It Simple" (KIS);

-- Only introduce a class/component if it is needed and useful. The API of the class/component must be minimal and viable, just enough to maximize it's usefulness and effectiveness without introducing unnecessary fluff.

2. Don't Repeat Yourself (DRY), ever;

-- Introduce appropriate and effective abstractions as necessary; never do the same thing twice.

3. Yet, be consistent.

-- Apply SOLID OO principles, use applicable Software Design Patterns and follow recommended practices.

4. Test!

5. Refactor

-- Essentially, reduce (less is more), reuse and recycle. The API/Framework should build on itself (reuse) and class/components should be repurposed if the intent or requirements change (recycle), or flat out removed altogether (reduce). Less is obviously easier to reason about and maintain.

With these new goals guiding development, the objective was to avoid the amount of rewriting from the ground up to get things just "right". Of course, "right" vs. "wrong" is highly subjective, but there are certainly "good" and "bad" ways to do things, and I used the above guiding principles along with a few known tools (e.g. Checkstyle, FindBugs and PMD) to apply objective criteria with tangible measurements on the quality and effectiveness of the project's design. Additionally, I thought, if I did not have the overwhelming desire to rewrite a class/component from scratch (i.e. I could easily maintain the class/component by refactoring it), that I must be on the right path.

While there is much work to do to carefully port my codebases of old into cp-elements and complimenting APIs/Frameworks, I am pleased to say that I really believe cp-elements is a Minimum Viable Product (MVP), a collection of really useful, high quality classes and components that can effectively simplify the development of software applications engineered in Java.

This project represents a culmination of all my best experience, knowledge and skills in what works and what does not when engineering software.

So, why the name, "cp-elements"?

cp-elements is aptly named after the Periodic Table of Elements to signify the basic, indivisible building blocks of software, much like the Periodic Table represents this basic, fundamental elements found in nature that constitute (makes up) all matter in the Universe.

While many of the classes and components of the class library are original ideas, quite a few also have been influenced from other libraries, APIs and Frameworks that I have used or studied in my career.

That is the thing about really good software, that stands the test of time... it borrows ideas from others, iterates on those ideas, improves on them, contributes back, which then leads to feedback and ideas for others and thus the cycle continues, always evolving, always improving. In essence, nothing is original it is is influenced by experience.

Conclusion

In closing, I hope you enjoy using this Java class library as much as I have enjoyed developing it over the years.

As always feedback is welcomed. My goal is to make this this the best it can be as it represents me.

Thank you.