This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: On-line Reading Notes... Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

Here's some recent URL's I've come across...

• Innovation as a business, an IDEO article:

  By moving among so many small worlds, it has acquired more than just a lot of good objects and ideas. IDEO has also acquired links to a range of vendors, suppliers and manufacturers that are particularly innovative or easy to work with, to research scientists with deep knowledge of emerging materials, to product companies that are central to particular markets. IDEO has realized it is not just in the business of combining existing objects and ideas in novel ways, but also in the business of building communities around those recombinant innovations.

• Agile Architect:

  Among the architect's key responsibilities are management of change and complexity. Allowing for and managing future change is a fundamental part of well-designed complex systems, but anathema to agile methods such as eXtreme Programming. Neither is it easy to strive for simplicity. Complexity and simplicity are relative terms, and simplicity for one stakeholder means complexity from a different viewpoint, like the frantic activity underwater to power a duck's elegant glide.

• Semiotics: A Primer for Designers:

  Semiotics and the branch of linguistics known as Semantics have a common concern with the meaning of signs. Semantics focuses on what words mean while semiotics is concerned with how signs mean.

  . . .

  Semiotics teaches us as designers that our work has no meaning outside the complex set of factors that define it. These factors are not static, but rather constantly changing because we are changing and creating them. The deeper our understanding and awareness of these factors, the better our control over the success of the work products we create.

• Why extends is Evil:

  In general, it's best to avoid concrete base classes and extends relationships in favor of interfaces and implements relationships. My rule of thumb is that 80 percent of my code at minimum should be written entirely in terms of interfaces. I never use references to a HashMap, for example; I use references to the Map interface.

  . . .

  Designers have applied the moniker "the fragile base-class problem" to describe this behavior. Base classes are considered fragile because you can modify a base class in a seemingly safe way, but this new behavior, when inherited by the derived classes, might cause the derived classes to malfunction. You can't tell whether a base-class change is safe simply by examining the base class's methods in isolation; you must look at (and test) all derived classes as well.

  Interestingly, this is a subtle application of part of the semiotics ideas above: the "symbol" of the base class can't be fully understood on it's own, it has to be viewed in it's context, it's use.