Tuesday, August 18, 2009

Cheering on our innovation & thought-leading partners. Vote for Ecommerce/Vizuri in the Innovator of the Year awards -- http://bit.ly/5gBxj

Thursday, July 16, 2009

Java the Platform - Home to all Languages http://ping.fm/iPdOH

Tuesday, June 23, 2009

Monday, June 22, 2009

Sunday, June 07, 2009

Watching Food Network Star and rooting for Granville Moore's own, Teddy Folkman. #foodtv

Tuesday, June 02, 2009

Shameless self-promotion - GOSCON Schedule is out and I'm on the docket. http://ping.fm/amXIA #GOSCON

Thursday, May 28, 2009

Registered for JBossWorld/Red Hat Summit in September - http://ping.fm/SreM1 #JBossWorld #RHSummit

Monday, May 18, 2009

Reading an interview with Dr. Kahn about the Handle System and the Digital Object Architecture...http://ping.fm/6Y5WQ

Friday, May 15, 2009

Google outage takes out 5% of the internet traffic. http://asert.arbornetworks.com/2009/05/the-great-googlelapse/
Downloaded Spring Tool Suite and added some plugins & immediately broke it. Spring looks to be the lipstick on the Eclipse pig here.

Friday, May 08, 2009

The summer program planning session for DC ACM is underway, which means Happy Hours! Vote your preference: http://ping.fm/745BN #DCACM

Tuesday, May 05, 2009

Back from JBoss Gov Users Conference @Carahsoft. Audience seemed pretty engaged in the Metamatrix session http://ping.fm/3OjvU

Thursday, April 23, 2009

Signaling the end of free web hosting? Geocities shutting down. http://ping.fm/ZgJCl

Tuesday, April 21, 2009

May Event-Sascha Meinrath,"The M-Lab: An Open Research Platform for Testing Internet Performance" #DCACM http://ping.fm/JKOHX

Friday, April 10, 2009

Git'R Done. Making the leap from SVN to Git thanks to git-svn and http://www.jgit.org/

Thursday, April 09, 2009

Queuing server-side jobs in Puppet. Now this is a feature that I could use. http://ping.fm/rlLUt #puppet

Wednesday, April 08, 2009

DC ACM is seeking candidates to run for next years term (July 2009-July 2010). http://ping.fm/xLVIQ

Friday, April 03, 2009

Thursday, April 02, 2009

Just back from SocialMatchBox DC #SocialDC event. Great chance to meet the innovators of today and future millionaires of tomorrow...

Wednesday, April 01, 2009

Curious about how many times my office mates are going to tell me to check out Google Autopilot. However, I'm still trying to figure out that Google paper thing...

Tuesday, March 31, 2009

Upcoming DC ACM Lecture - Donald Gotterbarn, "Software Development: More than Just Programming" (http://ping.fm/YTHBm)

Monday, March 30, 2009

Sunday, March 29, 2009

Researching how to run Apache Shindig (http://ping.fm/XthB1) in a clustered JBoss Portal instance

Saturday, March 28, 2009

Isaac is now updating his LinkedIn, Twitter, Facebook, WordPress, and Blogger status thanks to Ping.fm. (http://ping.fm)

Thursday, February 12, 2009

Information Systems and the Sisyphus Syndrome

In Greek mythology, Sisyphus was condemned to an eternal punishment of hard labor in which his task was to roll a boulder uphill only to have it roll back down before reaching the summit.

Variations on the "Sisyphus Syndrome" have been applied to several arenas such as the healthcare industry, education, business, and even Software Development.


The Information Systems Sisyphus Syndrome is another prevalent and common example in many of today's IT Systems. Too often data is pushed through the system, only to never arrive at its final destination. The multiple hops across routers in networks, the aggregation of data obtained from multiple data systems, and the Basic Information Theroem (B.I.T.) that Information Decays are all examples of problems with pushing data through the system.


So why design your systems to push information uphill thru the system? Systems always tend to obey the the Systems Law of Gravity (S.L.o.G.) in which always information flows better downhill through the system. Obviously this is easier then it sounds, but when designing a system, this must be one of the basic foundation in its architecture.

Information Systems and the Sisyphus Syndrome

In Greek mythology, Sisyphus was condemned to an eternal punishment of hard labor in which his task was to roll a boulder uphill only to have it roll back down before reaching the summit.

Variations on the "Sisyphus Syndrome" have been applied to several arenas such as the healthcare industry, education, business, and even Software Development.

The Information Systems Sisyphus Syndrome is another prevalent and common example in many of today's IT Systems. Too often data is pushed through the system, only to never arrive at its final destination. The multiple hops across routers in networks, the aggregation of data obtained from multiple data systems, and the Basic Information Theroem (B.I.T.) that Information Decays are all examples of problems with pushing data through the system.

So why design your systems to push information uphill thru the system? Systems always tend to obey the the Systems Law of Gravity (S.L.o.G.) in which always information flows better downhill through the system. Obviously this is easier then it sounds, but when designing a system, this must be one of the basic foundation in its architecture.

Thursday, February 05, 2009

What Ails You Information System?

1. Sisyphus Syndrome

System always engaged in menial, mundane tasks. System can't change; cursed to continue the same tasks


2. Generational Loss

Loss of quality of data between subsequent copies of data. Typically each copy only retrieves the information needed at that time and results in the 'excess and unnecessary' information being filtered out.


3. Information Bulimia

From James Governor: "A disorder common amongst information intermediaries, characterized by episodic binge data collection followed by uncontrollable vomiting and purging, leading to information leakage and theft."


4. Anorexic Data

Possibly due to hardware constraints or some other resource constraint, systems will refuse to load data, essentially starving itself for the sake of keeping an ideal size and neglecting its inherent need for information.


5. Data Binging

With no apparent need or request for information, the system will experience periodic data collections while losing control over what information it is collecting. This is different from Information Bulimia as there is no purging of the information.


6. System Sloth

System is slow to respond to requests. Usually due to current system load or the delay in correlating multiple sources of data before being able to respond to a request.


7. Information Decay

Also known as the Basic Information Theorem (B.I.T.). Over time certain values of data will decay with regards to its accuracy. Examples of this are stock prices, phone numbers and addresses, and/or inventory/stock on hand.

What Ails You Information System?

1. Sisyphus Syndrome

System always engaged in menial, mundane tasks. System can't change; cursed to continue the same tasks


2. Generational Loss

Loss of quality of data between subsequent copies of data. Typically each copy only retrieves the information needed at that time and results in the 'excess and unnecessary' information being filtered out.


3. Information Bulimia

From James Governor: "A disorder common amongst information intermediaries, characterized by episodic binge data collection followed by uncontrollable vomiting and purging, leading to information leakage and theft."


4. Anorexic Data

Possibly due to hardware constraints or some other resource constraint, systems will refuse to load data, essentially starving itself for the sake of keeping an ideal size and neglecting its inherent need for information.


5. Data Binging

With no apparent need or request for information, the system will experience periodic data collections while losing control over what information it is collecting. This is different from Information Bulimia as there is no purging of the information.


6. System Sloth

System is slow to respond to requests. Usually due to current system load or the delay in correlating multiple sources of data before being able to respond to a request.


7. Information Decay

Also known as the Basic Information Theorem (B.I.T.). Over time certain values of data will decay with regards to its accuracy. Examples of this are stock prices, phone numbers and addresses, and/or inventory/stock on hand.

Sunday, February 01, 2009

Software Engineering's Holy Grail?

Every new IT buzz-driven concept (i.e. SOA, Grid, Cloud) seems to sell itself as if the ideas of Reuse, Incremental Development, and Interface development are the most revolutionary ideas of the 21st century. (All 5 years of it.)

Almost 20 years ago, Frederick Brooks wrote in his "No Silver Bullet: Essence and Accidents of Software Engineering" essay that enterprise systems needed to be grown, not architected.

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.

Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built.

So it must be with our software-systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development. [10] That is, the system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below.


And to think, I used to groan when my Computer Science course made me read some boring essay instead of writing cool programs.

Oh and by the way, when talking about incrementally developing a system, the idea actually traces back to 1971. An idea that's 34 years old and counting.

Software Engineering's Holy Grail?

Every new IT buzz-driven concept (i.e. SOA, Grid, Cloud) seems to sell itself as if the ideas of Reuse, Incremental Development, and Interface development are the most revolutionary ideas of the 21st century. (All 8 years of it.)

Almost 20 years ago, Frederick Brooks wrote in his "No Silver Bullet: Essence and Accidents of Software Engineering" essay that enterprise systems needed to be grown, not architected.
The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.

Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built.

So it must be with our software-systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development. [10] That is, the system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below.

And to think, I used to groan when my Computer Science course made me read some boring essay instead of writing cool programs.

Oh and by the way, when talking about incrementally developing a system, the idea actually traces back to 1971. An idea that's 34 years old and counting.