I really enjoy reading books about java and software development. My favorite type of book is the patterns books. Patterns books are great because the chapters are usually short and very focused. So you can read a chapter over lunch, or before you hit the pillow and usually not put the book down in the middle of a 30 page chapter.

I am in the midst of reading and reviewing Pro Java™ EE Spring Patterns: Best Practices and Design Strategies Implementing Java EE Patterns with the Spring Framework. Reading this book got me thinking about all of the other patterns books that I have read and really enjoyed. Here are my favorite software patterns books.

Core J2EE Patterns: Best Practices and Design Strategies

I think this was my first patterns-based book. I got a free copy when I was enrolled in a week long java patterns and architecture class in 2002 or so. I now have two copies on my bookshelf. One for me and one to lend out to friends and colleuges.

Core Patterns starts by introducing the concept of software patterns, then takes a unique approach by describing common J2EE anti patterns and then discussing the refactored solutions. This allows a straight-through reading for those unfamiliar with patterns or use as a reference guide for experienced pattern users.

The Manager Pool: Patterns for Radical Leadership

Of all the patterns books that I have read, I think this book has the most chapters at a whopping 61. Its also my favorite. I think its my favorite because it sort of on the fringe of software development, so I don’t feel like I know as much about management. I also like it because I could relate to most every pattern either as a subordinate or as a manager.

This fun book identifies patterns such as Tribal Language, Leviathan, and Unique Place. The chapters are short and quick to read. This book will help you communicate more effectively, understand your subordinates, and make you a stronger software manager.

Pro Java™ EE Spring Patterns: Best Practices and Design Strategies Implementing Java EE Patterns with the Spring Framework

I am currently reading this book. The author has a poorly written java web application that uses no model-view-controller. He takes you through the refactoring of the project. He explains a pattern, and then discussues how the Spring MVC implements the pattern. It is common for the next pattern to build on the previous, so this book is a little harder to jump to an arbritrary chapter and start reading, unless ofcourse you know the patterns aready.

This book takes you though the presentation layer, business layer, and integration layer and discusses how Spring uses and implements patterns throughout each layer of the software. A great Spring reference or a great MVC reference. I am glad I got this one for my bookshelf.

Patterns in Java: A Catalog of Reusable Design Patterns Illustrated with UML

This book opens with background on pattern research, including the groundbreaking design patterns. It goes further, with 41 software patterns, all illustrated with UML diagrams and sample Java code. Early patterns, such as Delegation and Proxy, show how classes can work together without relying on inheritance. Next come creational patterns, such as the Factory and Builder patterns and the newer Object Pool pattern.

These pages turn out to be a great resource not only for patterns, but also for Java and UML. If you read this one and enjoy it, there is also a second volume.

Design Patterns: Elements of Reusable Object-Oriented Software

This book was a little more difficult to read. Its much more academic-oriented, rather than written to be a casual read. It also goes deeper into the pattern than most other books do. I guess that makes it a good reference. This is one of the only patterns books that I have read that delves into the user interface.

The downside with this book, in my opinion, is that its geared towards C++ software development, so as a java developer, I spent more time trying to understand the code examples than I did reading and understand the patterns.

Check out the table of contents.

Software Architecture Design Patterns in Java

Covering 35 patterns, a long introduction to UML, and a web hosting company case study, this book weighs in at almost 500 pages. This one is practially a design pattern encyclopedia, so if you can only have one design pattern book on your shelf make it this one.

This book relys big on examples and has become a fundamental book for newer and older developers alike. After reading this one I think you’ll find yourself using patterns names more often in discussing your software.

Anti-Patterns and Patterns in Software Configuration Management

To end, an anti-patterns book. And to be honest, This one I have not read, but its next on my book list becuase it is on a topic that so few developers are experts in or sometimes even carry a conversation in. This book is coming up on 10 years old

As I understand, most readers of this book can really relate to most every pattern because their organizations are so bad at configuration management. This could give you the leg up to show off you knowledge and help your organization become more successful in the art of software development. At least thats what I hope it can do for me.

Thanks for reading my list. Now I have to ask, have you read any of these? Do you have any comments on them? Have you read any great patterns-based books that you would recommend?

Related Posts

• July 10, 2008 — architecture-rules 2.1.1
• August 20, 2008 — Why not an Open Source contribution tax deduction?
• May 24, 2008 — Spring: OpenSessionInViewInterceptor & OpenSessionInViewFilter Examples
• July 29, 2008 — Open Source Revenue with Duel Licensing

© Mike for 72 Miles, 2008. | Permalink | 4 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

A great way to determine if you want to buy a book or not is to review the books table to contents.

Pro Java™ EE Spring Patterns: Best Practices and Design Strategies Implementing Java EE Patterns with the Spring Framework by Dhrubojyoti Kayal

• Describes a catalog of patterns used across the three tiers of a typical JEE application
• Provides implementation details and analysis of each pattern with benefits and concerns
• Describes the application of these patterns in a practical application scenario

And finally, an overview of each of the patterns that are reviewed.

Related Posts

• May 24, 2008 — Spring: OpenSessionInViewInterceptor vs. OpenSessionInViewFilter
• March 1, 2008 — Software Engineering Goals
• July 10, 2008 — architecture-rules 2.1.1
• May 29, 2008 — Exceptional Metadata

© Mike for 72 Miles, 2008. | Permalink | No comment | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

Search This Book

• Published by Apress, August 2008
• 416 pages
• ISBN 1430209739

The Good

• Numerous practical examples from the Netbeans API and the JDK.
• Each chapter introduces a concept that could profoundly change your code.
• Practical situations with concrete examples.
• Explanations for novices and experts.

The Bad

• System.out
  .println
• Have to read Theory before getting to the practical exapmles.
• Subtitled “Confessions” ?

• Purchase from Amazon.com

About the Author

Jaroslav Tulach is the founder and initial architect of NetBeans, later acquired by Sun. As creator of the technology behind NetBeans, he is still with the project to find ways to improve the design skills among all the programmers who contribute to the success of NetBeans open source project.

Intended Audience

Apress.com, the publishers, describe this book as being recommended to every API architect who prefers a bit more engineering design over a purely artistic one. but this book is really much more for anyone who writes code that anyone else consumes - and who doesn’t do that? This book is for any developer who is not brand new to software development.

Selected Chapter Highlights

There are 19 chapters. There are a couple of dull chapters, but by far the majority are very interesting, applicable, and well laid out with introductions and examples of most every concept.

Chapter 1: The Art of Building Modern Software

The first chapter was tough to get through, but it does introduce a key concept of API design and a focus of many discussions throughout the book: cluelessness. Jaroslav suggests that cluelessness supports “the most promising development style.” The pragmatic use of the bulldozer approach: reuse components that are already available, compose applications form big chunks of premade libraries, glue them together, and make sure it works even without fully understanding how it works.

Chapter 2: The Motivation to Create an API

Chapter 2 is important in that it lays out, as the titles states, “The Motivation to Create an API.” This chapter is interesting and fun to read because it lays out exactly why you are reading the book. The biggest point that I took away from this chapter is that APIs are for human beings - for other software developers like yourself - not for computers. And also that not all projects need an API, or at least not a high quality API.

Chapter 5: Do Not Expose More Than You Want

This chapter is the first of many that represent the reason that you bought the book. This chapter starts Part 2 of the book titled, “Practical Design.” Here, Jaroslav begins describing some practical API designs and even some design patterns. We get into applicable sections like “A method is better than a field”, “A factory is better than a constructor”, and “Do not expose deep hierarchies”. This is one of those chapters that you will come back to and read a few times and will refer to in conversation.

Chapter 8: Separate APIs for Clients and Providers

Chapter 8 was one of my favorites. I lead an open source project with both an internal and external API under development and this chapter was right on point for our efforts. This chapter explains the differences between, and how to package APIs for clients and APIs for providers. Jaroslav explains how if you mix your API and SPI together within a single class, then you can never modify the class, stating that adding a method is forbidden because of the contract for SPIs and removing a method is forbidden because the contract for the APIs.

Chapter 10: Cooperating with Other APIs

Chapter 10 discusses how to work with third parties in your application. The key concept that I took away was never to export third party classes through your API. When you do this, you lose control. If the third party changes their API, then your API has changed without you doing anything. A change in a third party could even break your software, or your end-user’s implementation of your software.

Chapter 15: Evolving the API Universe

Chapter 15 introduces methods for changing an API without breaking backwards compatibility. This chapter also describes some tools and techniques that you can use to break compatibility, but to still provide your users with support for the old API by using libraries that provide bridges. Being able to provide new APIs that break backwards compatibility can be very powerful.

Comments

First, my complaints. They are pretty trivial for the most part.

I have to complain about the subtitle, “Confessions of a Java Framework Architect”. Confessions? A confession is “an admission of misdeeds or faults.” The author does describe a few mishaps from the NetBeans API, but I would hardly consider this a book of naughty confessions.

I also have to complain about some of the code examples, but I think this complaint is pretty common among software books with code. Sometimes, commonly accepted software development practices are ignored or left out for the sake of brevity and keeping the example small enough to fit on the page. One of the very first code examples comes on page 47 and in it (and throughout the book), Jaroslav hits us with a System.out.println. Wouldn’t this be like reading a web design book where all the examples used table-based layouts? Doesn’t everyone use some form of logging abstraction. I hate when books don’t follow best practices.

My last complaint is the first four chapters that make up Part 1 “Theory and Justification.” They are all theory are pretty boring. They are tough to get through when you know that if you just skipped a couple chapters you could be reading practical examples with code. There are a few good points and a few things that are good to know before you get to the practical part of the book, but I wish Jaroslav would just make the points and move on the Part 2 “Practical Design”.

I had a few complaints but they are mostly trivial. This truly was a good book. The best part is that the author, Jaroslav Tulach, is the founder of Netbeans and the leader of its API. He has dozens of great examples of good and bad API design from his experience with Netbeans. He describes situations where their API got out of control and how they dealt with it, methods for monitoring your API as a community or team with an API review, and how to avoid API mishaps. Jaroslav has also been around long enough and is so intimate with the evolution of the JDK that he is able to site specific examples in the JDK where changes to the API broke software around the world. Jaroslav is very knowledgeable on the topic and his writing shows it.

The book is full of practical examples. After reading many chapters, I went right to my open source project, Architecture Rules, and either changed code or emailed developer mailing list to suggest changes to code to encourage a better, more malleable and extensible API. I now realize how not only are my interfaces and methods part our API, but so are our file outputs and inputs. Even our exceptions messages are part of our API.

This is without a doubt a book that you need to put on your bookshelf. This is the first book of its kind and the tips and tricks that it provides is timeless - a key attribute of any pragmatic software development book. I encourage you to flip though this book at your local bookstore or just download Chapter 1:

Download the Excerpt

Bookpool.com offers this excerpt: Chapter 1: The Art of Building Modern Software.

Resources

• Purchase Practical API Design: Confessions of a Java Framework Architect
• Interview: Jaroslav Tulach, Author of “Practical API Design”
• Confessions of API Designers Blog
• http://blogs.apidesign.org

Related Posts

• September 1, 2008 — “Practical API Design: Confessions of a Java Framework Architect” Table Of Contents Preview
• March 22, 2008 — architecture-rules-2.1.0 on the Horizon
• April 16, 2008 — Gumby and Architecture Rules
• June 15, 2008 — Greatest Barriers to Open-Source Adoption

© Mike for 72 Miles, 2008. | Permalink | 4 comments | Add to del.icio.us
Post tags: api, book, book review, review

Feed enhanced by Better Feed from Ozh

A great way to determine if you want to buy a book or not is to review the books table to contents.

Practical API Design: Confessions of a Java Framework Architect by Jaroslav Tulach

• Teaches you how to write an API that will stand the test of Time
• Written by the designer of the NetBeans API at Sun
• Based on best practices, scalability, and API design patterns

Related Posts

• April 13, 2008 — What is “Architecture”?
• February 10, 2008 — architecture-rules-2.0.3
• August 20, 2008 — Why not an Open Source contribution tax deduction?
• November 13, 2008 — Favorite Software Patterns Books

© Mike for 72 Miles, 2008. | Permalink | No comment | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

Have you heard of the Artists-Museum Partnership Act? Probably not. It didn’t even have a wikipedia article until I wrote it. In a few words the act would:

amend the Internal Revenue Code of 1986 to allow taxpayers who create literary, musical, artistic, or scholarly compositions or similar property a fair market value (determined at the time of contribution) tax deduction for contributions of such properties, the copyrights thereon, or both…

The artists put a lot of time, creativity, experience, and thought into their work, and then they donate it to museums so that the public can share in this art at a free or deeply reduced cost. This bill allows those artists to be justly compensated for their work. So its good for the public and good for the artist right? Maybe, depends on your political views I’d suppose. And just to be straightforward with you, this is only a proposed bill. It has not been made law yet despite the fact that it was introduced two years ago and has made it through the senate.

So the question is, if artists can work on their art only to donate it and receive a tax deduction, then why don’t open source project leaders and contributors deserve equal rights? Well first, there are some issues to consider.

Art is Understood

Actually art is quite subjective, but that’s not what I meant. Art has been around since the beginning of time, so when it comes to writing and developing federal laws, congress has time and experience on their side. There are hundreds if not thousands of laws governing art. Computers, software, and information technology on the other hand is still very new. Most of it is still not regulated, and the geezers who are writing the regulation don’t know the difference between broadband and a pickup truck. It will still be many years before they get a handle information technology.

Fair Market Value

How do you determine the fair market value of open source software? Lines of code? That is a pretty lame metric. How about prevalence in the market place - is more users equal to a great worth? What about cutting edge software? Usually those to enter the market first make a little extra something for the risk and the know how. Forget about the code. What about documentation? And the size of the community. It’s going to be extremely hard to apply any type of accurate value to most open source projects.

Many contributors

Open Source software typically has many developers. From the project leaders and major contributors to the developers who simple submit a patch or two. But also consider issues that are reported, documentation, mailing lists, and other support channels. They are in some way or another contribute to the software as a whole and are important to making the software useful. So how do you determine each individual contributor’s value and thus determine their share of the deduction?

Long development periods

With art, you have a creation period, then a final release. With software, we have  creation periods that can last years, with many intermittent releases - some of which add value to the software others of which may actually make the software less valuable. So you could take the value of this release less the value of the last release to come up with this releases value. Careful. If you introduce too many bugs, the value could be negative, and could owe the IRS. Wow.

Difficult to track

Artists produce a single artifact that is sold or donated. Software is reproducible and is almost free to do so an infinite number of times. The usage of the software is very important in determining its value. For example, a project with a couple of users probably is not worth as much as a project with hundreds of users. Your Pumpkin Path is no where near as prominent as Apache’s Web Server - or is it. How do we know? There needs to be some way to determine an exact user count or at least to determine what grade you might be in, be int 1-10 users, 10-100, users, 100-1000 users, etc. I run Architecture Rules and I honestly don’t know if I have 10 users, or 100. You could look at download counts, but maven downloads aren’t tracked. And what about when one user downloads the artifact and puts it in their organization repository. There could be 100 users from that one download. This would be a hard number to come up with, and even harder the more successful a project becomes.

Your Next 1040EZ

The bill is not law yet, but if artists deserve tax deductions for their donations, then so do open source contributors. But we are along way away from properly regulating the computer and software industries. I have also outline a number of major hurdles before us before we can even begin to determine how big that deduction might be. So next April when your filling out your tax forms (yeah, April, because you waited until the last minute) think about how much value you have created with your open source projects and how long its going to be before you see any of that value put back into your wallet.

The one thing that we can do from here is to keep an eye on this bill. If it goes into the books, then we have something to start fighting for and it might be time to call your less-than-computer-literate congressman or woman and start pressing them for your fair share.

Related Posts

• June 26, 2008 — If You’re Feelin’ like a Pimp go on Brush your Asterisk* Off
• March 22, 2008 — architecture-rules-2.1.0 on the Horizon
• April 5, 2008 — Configuration Method Chaining
• July 29, 2008 — Software Development Standards

© Mike for 72 Miles, 2008. | Permalink | 3 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

• added API package
• added Listeners
• added Configuration Properties
• added default-architecture-rules.xml

OK, lets lay out a road map for 3.0. I sent this message to the architecture-rules-user mailing list and the architecture-rules-dev mailing list tonight. I have a few things that I want to see put into it, and I’d also like to hear what you want in it.

org.architecturerules

First. The big change is the groupId which is finally going to be moved to org.architecturerules for the core project and the maven plugin. I don’t have the domain yet. I have a fund raiser page where I was hoping to get about $30 to secure the domain for 3 years. So far no contributions : \ Maybe if any of your work for a company that uses the project, and the company has donated money in the past, you could ask your boss for a small $30 contribution to this project. Regardless, we’ll get it eventually and the project needs to get off of com.* and the maven plugin needs to be the same groupId.

architecture-rules-ant

I want to refactor the ..architecturerules.ant package to its own jar so that:

• User’s who want to use the ant interface and include this jar.
• By including the jar, you get the Ant jars and dependencies. If you don’t use Ant, you don’t need the jar or the ant libraries.
• As we add new functionality to architecture rules someone else could take on the task of keeping the ant task up to date on their own schedule.
• This module also acts as an example of how to extend the core project.
• Allows us to develop new ant features and fix ant issues without doing a major release of the core. There are a couple of open ant-related issues in the issue list.

The downsides is that the API is broken, but I think that is OK given in the release  the packages are all changing to org.architecturerules so the API will be broken anyway.

Issue 59: DependencyConstraintException should report the violating class

This is sort of a tough issue. We utilize jDepend which only looks at packages. However, Mykola brought Classycle to my attention (which I included on the alternatives page) which looks at class dependencies rather than package dependencies. We could move off of jDepend and switch over to using Classclye to find dependencies, or we could continue to use jDpend, and when a rule is broken, we can jump over to Classycle to figure out which class is breaking the rule. Another benefit to Classclye is that it is able to detect static dependencies which jDpend is not. I actually got an email from SonarJ, a commercial competitor listed on the alternatives page who congratulated us on developing a good open source architecture risk mitigating project but pointed out that jDepend could not detect static dependencies. I think in the long term we need to support detecting static dependencies so this Classycle might have been an important find.

Looking to get involved? We’re looking for contributors for this task.

Issue 60: XML reports

The only other current issue that I would like to tackle somehow is the output of the XML reports. I sent out a pretty detailed email on this to the user and dev mailing list. I got little response. I put a copy of the email in the issue which includes a prototype for the XML output. The premise would be that the execution of architecture rules results in the output of an XML file that describes all of the rules, the packages that were investigated because of that rule, the dependencies of each package that match that rule, and a list of each violation. One major change would be that instead of throwing an exception when a rule is broken, the rest of the packages would be investigated first and then the XML output is written, and then an exception could be thrown describing all of the rules that were broken - not just the first rule.

The reason for this XML output is two-fold: first, it provides output for other developers to start processing and developing new tools for which could be good for this project. second: it provides a data source for our maven 2 plugin to use to generate a site report for. Or this could be a new project: maven-architecture-rules-report-plugin. Either way, this is a good stepping stone to new functionality and growth for this project.

Looking to get involved? We’re looking for contributors for this task.

FindBugs

We added the FindBugs report recently to the maven-generated site. We should be able to clear this list for all of our code.

Remove 3rd party org packages

I had created an Issue to remove unneccessary dependencies to cut down on the number of libraries that we depended on. But I think this was implemented poorly to the point where it caused a reported bug. Also, we have a pseudo maven repository so that makes this issue almost moot.

This list encompasses most of the open issues in the issue tracker that I want to see implemented. There are a couple of issues that I am going to leave on hold (such as inverting the project to expect the user to define the accepted packages rather than the exceptional packages) and some that I can not fix with out money (continuous integration server).

All of these tasks are up for discussion. And most any of them are open to user contributions. If you are interested in taking on one of these tasks, just reply to this email, tell us what you want to work on, what questions you have, and maybe describe how you plan on implementing it. If its a small task, you can submit a patch, if its bigger, we can make you a contributor (for a short term or longer term depending on circumstances)

UPDATE: Issue 68: Listener Support

Adding support for event listeners gives us a few different things that we either need or that would benefit us in the future.  This will hopefully invite other developers to begin extending the project. For example someone someday might make a GUI tool or an IDE plugin and want to provide real-time feedback to the GUI as packages are investigated. This also enables us to develop the XML report in a very modular fashion, without littering the services with code that is not related to performing the service that the class is named for. Listeners provide a great point for adding new functionality from too.

UPDATE: Introduce API Package

Interfaces will be moved to a new org.architecturerules.api package so that developers who wish to extend the project have someplace to start from. This will break backwards compatibility. But so will migrating to org.architecturerules, so if this is going to be done, it should be done now. Sorry everyone.

UPDATE: Issue 64: default-architecture-rules.xml

The initial state of the Configuration entity will be created by reading default-architecture-rules.xml. This essentially just allows us to define the default values via XML rather than defining them with java constants which is what we are doing now. This XML file is easier for the user to read to figure out the default values, is easy to add new default values to as we develop new features, and may be used to demonstrate a sample XML configuration or how features are configured.

UPDATE: Issue 67: Configuration Properties

The listeners require some configuration. Some other tools that have yet to be written may also require configuration. We’ll be adding support for arbitrary properties. These allow you to define a set of keys and a values that can be handed off to the Listeners and to other features that may be created in the future. This provides a pretty robust mechanism for providing configuration values for classes that extend the project.

Maven 2 Plugin SNAPSHOT

And while I have your attention, Mykola has released a 0.0-SNAPSHOT of the maven 2 plugin. Has anyone tried it yet? Anyone want to try it out?

Thanks everyone.

http://72miles.com/architecturerules (and someday architecturerules.org)

Related Posts

• July 10, 2008 — architecture rules on delicious
• July 10, 2008 — architecture-rules 2.1.1
• July 4, 2008 — architecture-rules-2.1.0 released
• June 26, 2008 — If You’re Feelin’ like a Pimp go on Brush your Asterisk* Off

© Mike for 72 Miles, 2008. | Permalink | No comment | Add to del.icio.us
Post tags: Architecture-Rules, Road-Map

Feed enhanced by Better Feed from Ozh

It’s true. Open source is is fascinating. Consider these questions (which have been asked by many):

How does open source work?
Why does open source work?
What motivates the developers?
Who is making money and how?
What are the open source business models?
How ubiquitous is open source?
What is the future of open source?
Whats with all of these licenses?

The questions are asked and answered every day. In books, in podcasts, and in hundreds if not thousands of blog posts. I have been looking for these blog posts and I have found a lot of them - but certainly not all of them. Since I was looking for them and finding them, I figured I might as well share them with everyone else who is interested in what makes open source tick. I setup OssSpyglass.com.

OssSpyglass.com

Each day I go out and find these new posts and quote them and link to them on this site. But there is so much out there, I had to find a focus. Here is what i came up with, from the about page:

We aggregate open source news and analysis from the blogosphere. You’re not going to learn about the next FireFox release here, but you might read about their open source distribution model, or how they transparently develop cutting edge software.

We are interested in how open source works, why it is successful. We are interested in its past, and its future. We want to know whats going on in the open source communities, and what open source users think. We are interested in analysis and development of the open source movement, culture, and process.

So hopefully these are topics that interest you or that you find important for the future of your career. If so, come check out the site, and consider bookmarking it or subscribing to the feed.

OSS Job Base

A second project that I setup off of OssSpyglass is OSS Job Base, using the open source job board JobberBase. The premise is that there are thousands of open source projects out there looking to find development help be it with coding, documentation, or even testing. There are also developers looking to get onto a project, but don’t want to scour bug lists to find issues to fix.

This job board is setup for leaders of open source projects to post a task. A typical task post should consist if a couple lines to introduce the project, followed by the description of a task. Then developers can subscribe to these job lists and finally find a worthwhile project to put their time into.

If you’re an open source project leader, come post a task or two. You might be surprised at how many people want to help you, but just don’t know that you’re looking for help. I am aware of sourceforge’s job list but they are anything but free, and if you have a job listed there I invite you to also post it on the OSS Job Base.

So come check them out. Comments are are appreciated.

• http://OssSpyglass.com
• http://jobs.OssSpyglass.com/

Related Posts

• July 10, 2008 — architecture rules on delicious
• July 29, 2008 — Open Source Revenue with Duel Licensing
• April 2, 2008 — Architecture Rules 101
• March 1, 2008 — Software Engineering Goals

© Mike for 72 Miles, 2008. | Permalink | No comment | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

It all comes down to this.

When I put this depiction in to word, I would say it as “Industry Standards > Organization > Team > Personal > No Standards“.

It is that simple. Everyone has standards. However, some standards are more important than others. When developing your own standards you should consider those standards that are greater than you first. So your standards should extend those standards that are defined above your position.

As an example, consider a Java developer working for a major US Bank.

Industry Standards

Most developers have two industry-level standards to consider. First, the language that you are developing in. Our example developer is a java developer. Sun publishes a Code Conventions for the Java Programming Language. This document provides a broad range of guidelines for various facets of the language. Next, consider the financial sector’s software development guidelines. You may or may not be able to find such guidelines, and when you do they will probably not be specific to your language. I’d imagine there are rules for how many decimal places into dollar amounts you should keep, and how to store currency types are all documented somewhere.

Organization Standards

Now that you’ve adopted the industry’s standards, look to your organization. You might be a member of a huge multinational corporation, or a small 2 developer shop. Whenever the industry does not cover a specfic aspect of your software, your organization has the opportunity to define standards. These standards may be how to name your SVN repositories, or how many characters long your variables must be. These are things not covered by, for example, the Sun Code Conventions for the Java Programming Language.

Team Standards

Your organizaiton may not care about some aspects of their software, but your project manager or project team may still have rules that they follow. These are standards that you and the other developers on your software project or team follow.

Personal Standards

Finally, you have a situation where there is no defined standard anywhere. So you get to decide how you will perform some task or format some code. Whatever you decide to do, think it though, and do the same thing the same way next time. Personal standards are important weather you are working in the office or working at home on your own project. You are the same developer on both projects. Your code should reflect that fact.

No Standards

Why would you code in one style in the office only to drive home and code differently on your home project. This is chaotic. This can prevent you from effectivly transfering experience from your office projects to your home projects.

Documentation

De Facto standards are those that tend to happen not because they are law, but more out of practice. There are no such things as de facto standards. Standards should be and must be documented and developers must know where to find this documentaiton in order for the standards to be effective. This documentation should be easy to find, easy to access, and even easy to update.

It is sometimes hard to define a standard that covers all situations. When developing your doucmentaiton, you might consider defining the typicial situations that those standards fit into. These leaves the hands of your developers untied so that they can focus on producing high quality software and not be bogged down by unneccesary blanket rules.

Wikis are great tools for maintaining software development standards for a small organizaiton or development team. They allow team members to update the documentation as new standards are developed and as new situations are encourntered. Other developers can usually subscribe to the wiki to be notified of changes so that everyone is always up to date.

Why are standards important?

Following standards are not about making software development harder or more tedious. They are about making development easier and cheaper. InfoQ recently posted an article called Better Best Practices which listed a few great reasons for developing best practices, but it turns out the same reasons for developing best practices hold true for following standards too. Their list is titled “The motivation for Best Practices” but I could easily title this list “The motivation for following Standards”:

They ensure consistency. We are introducing [insert initiative] and we want to ensure that everyone goes about it the same way. We don’t want to abandon people without offering them any direction and the alternative would be chaos.

They support learning. We are trying to get everyone up to speed on this new approach with the minimum of fuss, and having a standard set of well-structured material means people can see exactly what they have to do, and ideally how well they are adapting.

They help limit (potential) impact or damage. (Now we are starting to see their true colours.) In any organisation there’s a bell curve of people’s abilities, and we know that a small but significant number of people will be at the wrong end of it. Implementing this program badly could leave us exposed to significant financial or legal business risks, so we’re going to need very clearly defined practices to protect ourselves. They are called Best Practices because they are tried and tested so I can be reasonably sure they are going to work.

They help to build a more mobile and flexible workforce. In these fast-moving times, projects can materialise or be cancelled almost overnight. People move between project teams, projects move between offices, countries or timezones. With all our people trained up to use the same Best Practices we - and they - have many more options in terms of career mobility. We call it “commoditising resources”.

They allow us to enforce control. In a large, hierarchical organisation, this is the real crux of the matter. A division manager or vice president may well be responsible for thousands of people. The only way to provide accountability on that scale is to have a system of clearly-defined and strongly-enforced Best Practices.

What do you think? Are standards a waste of time? Or do they create time? What good or bad experiences have you had with some enforcer pushing standards down your throat. Were those enforcers in the right or the wrong?

Related Posts

• May 24, 2008 — Spring: OpenSessionInViewInterceptor & OpenSessionInViewFilter Examples
• April 2, 2008 — Architecture Rules 101
• September 11, 2008 — “Pro Java EE Spring Patterns” Table Of Contents Preview
• November 13, 2008 — Favorite Software Patterns Books

© Mike for 72 Miles, 2008. | Permalink | No comment | Add to del.icio.us
Post tags: standards

Feed enhanced by Better Feed from Ozh

Introduction

The aim of this post is to explain how open sourcing a proprietary tool under a duel license can be more profitable than a solely proprietary venture. With such a license you could generate more revenue and share your code and software with the world.

Dual licensing is a strategy that combines open source distribution with proprietary licensing. I don’t want to spend too much time explaining duel licensing and would rather point out its benefits and how it makes money. But if you don’t know what duel licensing is, wikipedia describes it as

In this model, one option is a proprietary software license, which allows the possibility of creating proprietary applications derived from it, while the other license is a copyleft free software/open-source license, thus requiring any derived work to be released under the same license. The copyright holder of the software then typically gives away the free/open source version of the software at no cost, and profits by selling licenses to commercial operations looking to incorporate the software into their own business.

So, in order to use the free half of this duel license, the using organization would have to contribute back anything they develop using your product. This means their proprietary trade secrets are potentially being made available to the public. Many organizations would rather pay a small fee to protect their competitive advantage.

So lets review some of the ways that duel licensing grants an advantage to business that release their products under two or more conditions.

Low Cost Distribution

Open source software depends on the Internet for distribution. The internet is cheap, ubiquitous throughout the world, and fast. There is no need to mail a product to the other side of the world, there is no packaging, Usually the customer uses 100% of their own efforts to get the software. That is to say, the find your site, they download it, and they install it. It doesn’t get any cheaper than that.

Product Marketing

First, your product is potentially free. That’s some awesome marketing. So right away you have eyes looking at your tool so you’re way ahead of your proprietary competition. You’ve got the Internet which is almost free to promote your software tool on. And with a good product, you’re going to have advocates around the internet talking up your tool.

High Margin

Duel licensing provides a means for producing a very high margin for your product. With a service based offering, in order to offer more services, you need to spend more money - for tools, personnel, time. Duel licensed software requires no additional resources, just enough time to generate and mail out a new license. Once the code is created and ready for public consumption its all profit from there.

Market Entrance

You may be able to capture users that you never would have had a chance with if they have not found your product to be free, and then determined that they needed to change it, and thus buy a a license to protect their proprietary information.

Learn More

I learned all about duel licensing open source products from a great book called Open Sources 2.0. From amazon:

“Open Sources 2.0″ is a collection of insightful and thought-provoking essays from today’s technology leaders that continues painting the evolutionary picture that developed in the 1999 book “Open Sources: Voices from the Revolution” .

These essays are very well written, cover a very broad range of topics, and is written by open source contributors that we have all grown to know and love. Buy the book and check out Chapter 5:Duel Licensing.

Related Posts

• June 30, 2008 — Fairy Tale of the Fruit Tree

© Mike for 72 Miles, 2008. | Permalink | 5 comments | Add to del.icio.us
Post tags: licensing, Open Source

Feed enhanced by Better Feed from Ozh

I try to keep an eye on what Internet users are saying about Architecture Rules. I checked del.icio.us for architecture rules. Its bookmarked by 60 people, which is pretty cool.

I read one description which concerned me. Chris suggested in his description that architecture rules as “way to ‘test architecture’, although it seems to be limited to detecting cyclic package dependencies”. Whoa, hold on. That’s not what we are about. Detecting cyclical dependencies is something that we can do, because we wrap JDepend, but the whole point of the project is to assert that the Rules that you have defined are not violated.

So, I tracked down Chris’s email address, which I found in his resume, which I found on his site. I emailed him.

I started by apologizing for the unsolicited email. Next I explained that I found his comment delicious, I reiterated his comment to him, then briefly explained and showed (with XML) how architecture rules was about asserting architecture through the definition of rules. I sent off the email assuming that Chris probably wouldn’t read it, and certainly wouldn’t respond favorably. Fortunately, I underestimated Chris.

Chris wrote back to me and thanked me for taking the time to write to him. He also pointed out that it is “always a good sign to me when an open-source project is interested in what people are saying about it.”

I just wanted to share this experience. I have no great analysis of it yet. I hope that it might encourage you to think about reaching out to your user base weather they be paying customers or users of your open source tool.  After all, thats why we write the code, right? To satisfy the end users, to make their jobs easier, or to change the way that people do business.

Related Posts

• August 3, 2008 — Architecture Rules 3.0 Roadmap
• July 10, 2008 — architecture-rules 2.1.1
• July 4, 2008 — architecture-rules-2.1.0 released
• June 26, 2008 — If You’re Feelin’ like a Pimp go on Brush your Asterisk* Off

© Mike for 72 Miles, 2008. | Permalink | 2 comments | Add to del.icio.us
Post tags: Architecture-Rules

Feed enhanced by Better Feed from Ozh

It is an open source project. That means our failures are out there for everyone to see. Read about our major release that contained a major problem. Hopefully can learn from our mistake (and we get some of those users back).

2.1.0 Release not so Good

Architecture Rules 2.1.0 was released this past weekend. It was going great. The project was getting a lot of attention on dzone, freshmeat.net drove some good traffic, it made the front page of The Server Side’s news section. All of these sites brought in a huge 128 downloads over the weekend while the previous version was out for seven months and only claims 222 downloads (by the way, I hope there are many times more users using the maven repository, which we don’t yet track for downloads). So it was a good weekend. And then it was pointed out that wildcards don’t work…

What Happend?

We implemented wildcards a few weeks ago and released a 2.1.0-SNAPSHOT for users to test out. Unfortunately, we don’t have a huge number of early adopters who are pulling down snapshots. So It seemed worked well and we planned a release for the weekend of July 4th.  On June 29th, I got a friendly email from Andrew Swan. He had graciously taken the time to review the 2.1.0 code before the release. He discovered that the JPackage equals method delegated the work to the JPackage matches method. This broke the contract of the Java equals method because, in his words, “if a.equals(b), then b.equals(a) should also be true.” We all know that he is absolutely 100% correct. He even pointed me to Effective Java. We were excited to have Andrew reviewing the code and of course wanted to fix this problem. So we modified each reference to JPackge.equals to use JPackage.matches, ran our tests, and got a green “tests pass 82 of 82″.

I quickly followed that up by creating the binaries, committing everything to SVN, updating the documentation, and promoting the 2.1.0 release. However, one reference to .equals remained in the AbstractRuleService. This is the service that itterates over each package defined in each rule and checks to see if a given package is dependent on a package that it is not allowed to depend on. So now, if a package is defined using wildcards, it tries to match “com.company.application.*”, the String, to fully qualified String such as “java.util”. Of course, no package is ever going to be named with an asterisk character, so now if a package is defined with a wildcard, its not looked at. So wildcards are busted.

What Now?

Now, we released a 2.1.1 just to fix this bug and pray that the 128 (and hopefully many many more though the maven repository) java developers who are rightfully concerned with mitigating architectural risk take some time to come back and grab the 2.1.1 release.

We have fixed the problem and quickly put up 2.1.1. Please download it, or update your pom.xml, give us another try, and Assert your Architecture.

Related Posts

• August 3, 2008 — Architecture Rules 3.0 Roadmap
• July 10, 2008 — architecture rules on delicious
• July 4, 2008 — architecture-rules-2.1.0 released
• June 26, 2008 — If You’re Feelin’ like a Pimp go on Brush your Asterisk* Off

© Mike for 72 Miles, 2008. | Permalink | No comment | Add to del.icio.us
Post tags: Add new tag, Architecture-Rules

Feed enhanced by Better Feed from Ozh

Architecture Rules announces today that version 2.1.0 is released.

This was a fun release for two reasons: the new features, and the timing of the release.

Features

This was a major release in that it finally allows the users to define packages with wildcards. We’ve had a handful of users asking for this functionality for a while. We thank them for sticking with us despite having to ask us for this feature a few times. Read about how we implemented wildcards, how to use them, and some open issues with them on our previous post If You’re Feelin’ like a Pimp go on Brush your Asterisk* Off.

We added method chaining to the domain classes to improve the feel of programmatic configuration. We talk about this change when we introduced the development goals for 2.1.0 and we talked in depth about method chaining when we started researching weather we should support it or not in our post Configuration Method Chaining.

We also made some positive changes to the project’s exceptions. We have a lot of exceptions for reporting different issues with architecture rules configuration and with the project that the tool is inspecting. We added some references to the packages that cuase the exception to be thrown, and we tied all of the exceptions together under one higher level exception, the ArchitectureRulesException.

Release Date

Architecture Rules 2.1.0 is officially released on Friday, July 4th, 2008. This is a great date for a milestone release not because it is an American national holiday, but because it is one year from the day that development started on the project just about to the day. The first release, 1.0, was made just a couple weeks after development started, on July 17th, 2007. So happy anniversary Architecture Rules. With wildcards, a new domain name, and the upcoming maven 2 plugin, this next year is going to be bigger than the last.

Upcoming Releases

There will be a 3.0.0 release soon. Today, the maven 2 plugin that has been in development and the architecture rules project have different package names. One com.seventytwomiles and one info.manandbytes because I developed most of the core project as 72miles.com and Mykola developed the plugin under his domain mandandbytes.info. Before I can see developers using the plugin, we need to normalize the domain names. We’ll purchase ArchitectureRules.org any day now, update the site, update the documentation, and update the packages. This will be a major change to the users, warranting the 3.0.0 release. If you can afford a couple bucks to help get the domain, we would really appreciate the monatary support.

Once the packages are straigned out, we can push out the plugin. We need to write the documentation for the maven 2 architecture rules plugin. Mykola has been working hard on the plugin for months now. Its actually been ready for public consumption for a while, we just haven’t had the time to document it for the public. I will make this my next task and get the plugin out for everyone to start using. It makes Architecture Rules even easier to use by allowing the user to skip writing a silly little Test class and lets you move Architecture Rules right into your everyday build process. Awesome.

2.1.0

For a complete list of the changes, check out the 2.1.0 release/download page. You can get the update by downloading the new jar, or by updating your pom.xml to version 2.1.0.

Related Posts

• August 3, 2008 — Architecture Rules 3.0 Roadmap
• July 10, 2008 — architecture rules on delicious
• July 10, 2008 — architecture-rules 2.1.1
• June 26, 2008 — If You’re Feelin’ like a Pimp go on Brush your Asterisk* Off

© Mike for 72 Miles, 2008. | Permalink | No comment | Add to del.icio.us
Post tags: Architecture-Rules

Feed enhanced by Better Feed from Ozh

This is a reprint of a fantasy authored by Yutaka Kachi and translated by Mikiko Kachi. Originally from http://www.catch.jp/openoffice/whats_oss/index_en.html.

I am reprinting it because it is only available through PDF. I want to share it and make it easier to read and comment on. I found it in 2005 and saved the PDF. I found the the file this morning and thought it would be good to share and discuss.

Long long time ago, there was a tree in a field of grass near a village. One day, this tree bore a lot of delicious fruit.

The fruit were very delicious. So villagers soon harvested all of the fruits.

There was no end to the number of people who cut branch of this tree and take them home.

Because of this, the tree died in a few years.

In the village, there was a clever merchant. He grafted the tree before the tree died.

And he fertilized the tree, cut off branch when it’s too much. He took care of the tree for a long time.

Then the tree bore fruit. He sold it and made big money.

He was a real worrier. He fenced around the tree and was always watching the tree.

This merchant was not just an worrier, but also a hard worker.
His effort made the fruit more delicious and a lot of people bought it.

Some people delivered it to busy villagers, and some people made jam from the fruits and sold it.

The merchant monopolized the fruit tree.

When someone said to him “ there are many worm holes ” , he heard nothing of it and said “ It’s cheap so you can’t complain that.”

When someone asked him “ do you use any harmful fertilizer?”
he said “ it’s company secret” and wouldn’t answer that question.

When someone offered him “ I’d like to buy branch”, he said “ I don’t want to have competitors” and rejected the offer.

More and more people started to sell the fruit and more and more people bought it.

Then the merchant increased the price and made a big profit.

In this village, there was a young man who really loved this fruit. When the merchant increased price of the fruit, he couldn’t afford it any more because he was very poor.

So, he got interested in another tree near the village. This tree also bore a lot of fruit, but its taste was not so good and no one had cared for it. The young man started taking care of it with his friends.

Therefore, the tree bore more fruit than they could eat. So they put up a sign board that said “ Free”. There were some people who take the fruit away although they didn’t take care of the tree, but the young man didn’t mind at all.

The young men kept making effort for years to improve taste of the fruit as much as possible. Some people who took the fruit said “ I will help you”, “I will help you too because we don’t want to kill this tree like the first one” and helped doing time-consuming works.

The more people helped, the more people took the fruit. When the fruit run short, the people grafted the tree to grow more. They put up “ Free” sign boards on new trees also.

Some people delivered the fruit, and some people made jam from the fruit. They were very cooperative and sometimes they pay for agricultural equipment, fertilizer and inviting specialists to get advise.

So they reduced warm holes, improved the taste of the fruit, and their fruit became much more popular.

Years later, many fruit trees were planted around the village and bore a lot of delicious fruit.

The villagers started delivering the young men’s fruit together to far-off town. In that town, many people said “I’ve never had such a delicious fruit !” and the fruit became popular. It sold like hot cakes.

And not only the young man but also his friends and villagers all became happy.

By the way, what happened to the merchant who monopolized the fruit tree?

His business was also going well. For only a short while he had a fewer customers, but he expanded his business by hiring many people, shipping the fruits to far-off town, buying up fruit trees which had grown in other villages, etc.

There was no difference between the young man and the merchant in terms of making delicious fruit.

This is a great, simple explanation of how open source works and why the model it is successful. Growing a fruit tree is relatively easy compared to writing software, but as software development tools get easier to use, and more people learn to write code, it was and is inevitable that the number of open source tools and the quality of those tools will increase.

There are two more PDFs that talk around open source licensing at http://www.catch.jp/openoffice/whats_oss/index_en.html.

Related Posts

• July 29, 2008 — Open Source Revenue with Duel Licensing

© Mike for 72 Miles, 2008. | Permalink | No comment | Add to del.icio.us
Post tags: Open Source

Feed enhanced by Better Feed from Ozh

Architecture Rules is proud to announce that it now support wild cards.

Benefits of Wildcards

Wildcards bring the ability to match multiple packages with one Rule entry. This falls inline with the original goal of the project, which was to simplify the usage of jDepend and to define rules in a way that is very readable, understandable, and modifiable.

With wildcards, users can now define a package or violation in one line with the ability to match many packages. This means you won’t need to update your Rules each time you add a new package and your XML configuration file will be much shorter.

Wildcard Patterns

We identified a few different Wildcard Patterns. Some we don’t support and don’t plan on supporting, others we do support, and there are still a couple that we want to add.

Here is a description of what we now support:

Example

Now creating a rule to assert that the web layer does not interact with the DAO (or integration) layer is as easy as:

<rule id="web-layer">
 <comment>web and dao mix like oil and water</comment>
 <packages>
  <package>com.company.app.web..*</package>
 </packages>
 <violations>
  <violation>com.company.app.dao..*</violation>
 </violations>
</rule>    

Prior to wildcards, you might have needed to define ..web.controllers, ..web.filters, ..web.views, ..web.forms, ..web.tags as the packages, and then you would have had to defined every ..dao package as a violation. Now its easy!

Implementation

Architecture Rules uses Regular Expressions to compare the packages with wildcards against the inspected packages. The regular expression needed to be able to handle exact packages, one package deep, and one or more packages deep. We accomplished this by modifying the given package with wildcards (such as com.company.project.*) to apply regular expression characters.

Thank you to Ryan Stewart for helping us hash out this expression. This is what we came up with:

final String regex = this.path
    // foo.bar exactly foo.bar
    .replaceAll("\\.", "\\\\.")
    // foo.bar.1 or foo.bar.1.2 and so on...
    .replaceAll("\\\\.\\\\.\\\\*", "\\\\.\\[A-Za-z_0-9.]")
    // packages only
    .replaceAll("\\.\\*", "\\.[A-Za-z_0-9]*");       

The break down is this: The third line of code looks for ..* combination and replaces it with the regular expression to allow for any string with any number of periods.

The fourth line of code looks for the remaining .* combinations and replaces it the an expression to match package name but no more periods.

If you consider yourself a regular expression wizard, please consider taking a moment to review this and offer any feedback or suggestions that you might come up with. Thank you.

Outstanding Issues

One usability issue that we have uncovered is the matching of the package prior to the wildcard. For example, some users think that com.company.project.* should match com.company.project in addition to the packages under project. Others aren’t sure it should match ..project. As of right now ..project is not included as a match. We are open to comments on this and welcome feedback from the early adopters.

Roll Out

Wildcard support has been slated for the 2.1.0 release which should happen any day now. We are just waiting for a couple of our e