Subscriptions include a calendar year of issues (March - December) regardless of when you subscribe. When ordering after March, your subscription includes access to the previous issues of the current year. Each month, you will receive an email with a link to download the magazine PDF and associated code samples.
In this issue we'll begin a short series on the intersection of the SOLID principles of object-oriented design and programming with the functional programming paradigm. We’ll begin with a short discussion describing the motivation for this series, followed by a quick overview of SOLID and an in-depth dissection of the Single Responsibility Principle. In September, we'll look at the Open-Closed and Liskov Substitution Principles, followed by the Interface Segregation and Dependency Inversion Principles in October. Finally, in November, we'll go "meta" with the SOLID principles, examine their overall relationship to software complexity and discuss their applicability to the entire spectrum of programming paradigms.
Git is a version control system. We can look at it from that high level. Git is a content tracking system. Some teachers advise us to look at it from that lowered elevation. But let’s look at Git from the very bottom. The floor. The code. The algorithms. The directed acyclic graph of hashed bit sequences made efficient through zlib compression and deferred garbage collection determined by node reachability via hash relationships.
Modularity helps us design more flexible software systems — systems with resilient, adaptable, and maintainable architectures. In last month's article, we explored the benefits of modularity and started to lay the foundation for designing more modular software systems today. This month, we start by exploring the goal of architecture, the resulting paradox, and a simple example that explores just one of the benefits of modularity.
In many languages (even JVM languages), the release of a new compiler might require finding new versions of all your libraries.1 Luckily in Java, this does not happen because of a nearly invisible feature: binary compatibility. Fortunately and unfortunately because binary compatibility is hidden from us, few Java developers understand what is and is not binary compatible—and the answers are often surprising.
First, let me take this opportunity to thank you for your continued support of No Fluff Just Stuff. The emphasis of this magazine is all about quality content just like our software conference series. For those of you not familiar with the No Fluff Just Stuff Symposium series let me share a little history. I started NFJS in 2002 to offer high quality technical content in a conference format and offered in over 30 cities throughout the U.S. and Canada. The credo of NFJS is simply: Local Venue, World Class Conference. NFJS offers individuals the opportunity to attend an outstanding conference right in your own backyard whether you live in Milwaukee, or Denver, just to name a few. The NFJS conference series is focused on great technical content(stuff) and little to no fluff - advertising, vendors, etc...
NFJS, the Magazine is an eclectic mix of articles centered on software development and all that entails. Whether you are a developer, architect or manager, you should find all of the articles in NFJS interesting and enlightening. All of the article authors are speakers on the No Fluff Just Stuff Tour and published thereby insuring a great read. We want this magazine to be time efficient for the reader. To me, NFJS the Magazine is all about outstanding content that is easily consumable. The other great thing about the format of this magazine is that you can easily read articles out of sequence over the months and refer back to something anytime. Unlike traditional magazines, NFJS has a much longer shelf life and makes a great reference source.
We are very excited to bring you NFJS, the Magazine ten times a year. I hope you find NFJS, the Magazine to be a great informational resource. Drop me an email and let me know your thoughts.