Archive for May, 2010

Right level of sophistication

May 7, 2010 5 comments

"Each program has an appropriate level of care and sophistication dependent on the uses to which it will be put. Working above that level is, in a way, even less professional than working below it"

Gerald M. Weinberg, The Psychology of Computer Programming 

via Joshua Kerievsky’s When Sufficient Design meets Poor Design Part 2 of X

Categories: Quote

Sharepoint Platform slides from PDC Session “Overview of SharePoint 2010 Programmability” by Mike Ammerlaan

May 5, 2010 Leave a comment

I was watching Mike Ammerlaan’s “Overview of SharePoint 2010 Programmability” from PDC ‘09.

This Sharepoint Platform slide gave a good idea of what is in the platform and what’s been added in Sharepoint 2010.

So I have just uploaded the slide as images in a photo album.

Categories: Sharepoint

What is Windows SharePoint Services (WSS)?

May 4, 2010 2 comments

A while ago I posted an entry on What is WSS?. Needless to say I couldn’t sustain my effort to learn Sharepoint last time. This time again I am trying to learn Sharepoint again. Here is my next take on ‘What is WSS?’

Categories: Sharepoint

Code, data and metadata in the light of Shearing Layers

May 4, 2010 Leave a comment

I haven’t written anything on my own in this post. I have just quoted Brian Foote and Joseph Yoder ‘s Big Ball of Mud essay. As someone building and maintaining metadata driven applications / frameworks, this article was a slap in the face for me. A clear reasoning behind metadata.

The notion of SHEARING LAYERS is one of the centerpieces of Brand’s How Buildings Learn [Brand 1994]. Brand, in turn synthesized his ideas from a variety of sources, including British designer Frank Duffy, and ecologist R. V. O’Neill. Brand quotes Duffy as saying: "Our basic argument is that there isn’t any such thing as a building. A building properly conceived is several layers of longevity of built components"…

  1. Site (geographical setting), they say, is eternal.
  2. Structure (load bearing elements, such as the foundation and skeleton) may last from 30 to 300 years.
  3. Skin (the exterior surface, such as siding and windows) lasts for around 20 years, as it responds to the elements, and to the whims of fashion.
  4. Services (the circulatory and nervous systems of a building, such as its heating plant, wiring, and plumbing) succumb to wear and technical obsolescence more quickly, in 7 to 15 years.
  5. Commercial Space Plans (walls, flooring, and ceilings) may turn over every 3 years.
  6. Stuff (lamps, chairs, appliances, bulletin boards, and paintings), is, of course, subject to unrelenting flux

In a software system,

  • Different artifacts change at different rates.
  • Therefore, factor your system so that artifacts that change at similar rates are together.

"separate that which changes from that which doesn’t"

  1. In object-oriented languages, things that will change quickly are cast as black-box polymorphic components.
  2. Elements that will change less often may employ white-box inheritance.
  3. The abstract classes and components that constitute an object-oriented framework change more slowly than the applications that are built from them.
  4. Languages change more slowly than frameworks.

Wide acceptance and deployment causes resistance to change. If changing something will break a lot of code, there is considerable incentive not to change it. For example, schema reorganization in large enterprise databases can be an expensive and time-consuming process. Database designers and administrators learn to resist change for this reason. Separate job descriptions, and separate hardware, together with distinct tiers, help to make these tiers distinct.

Code changes more slowly than data, and is the realm of programmers, analysts and designers.

Part of the impetus behind using METADATA [Foote & Yoder 1998b] (data about data) is the observation that pushing complexity and power into the data pushes that same power (and complexity) out of the realm of the programmer and into the realm of users themselves. Metadata are often used to model static facilities such as classes and schemas, in order to allow them to change dynamically. The effect is analogous to that seen with modular office furniture, which allows office workers to easily, quickly, and cheaply move partitions without having to enlist architects and contractors in the effort.

from Big Ball of Mud

Categories: Architecture