I wish that the Challenger Space Shuttle never went down and created the concept of the Challenger memo. Because of the Challenger memo, our culture was forever changed. People feel that if there is some little complaint that forms in their head – they are duty-bound to blast the complaint out as loudly as possible in case it “saves the next space shuttle crew”.
As a result, since the Challenger went down there have been literally billions of people who have written critical messages feeling all the while that they were saving the world. Mostly what they really want is the satisfaction that when something goes wrong – they get to point back to their memo written *before* the event happenned.
The problem with this is that events like the Challenger explosion happen very seldom and these memos get written many times per day in many organizations so the losers writing the memos are ready for the next disaster.
But these memos cause far more damage than simply wasting paper or E-Mail in boxes.
What if you were the person who was handed the Challenger memo, and then ignored it, and then the crash happenned, and then the memo writer points out that (a) they were so brilliant that they knew what was going to happen in advance of the event and (b) their idiot boss was handed the memo and ignored it.
So this creates a culture where we can’t just tell the Challenger memo writer to “go back and actually work on the solution rather than just bitching about the problem”. Each person handed the Challenger memo (remember that they almost never come true) must listen intently to the memo and engage in a long and useless disucssion with the memo writer that does not really get closer to the solution (remember the writer is not motivated by fixing the problem – just showing their brilliance in identifying the problem).
The purpose of the long discussion is so that when the one in a million chance hits and the problem actually happens, not only does the memo writer get credit for their brilliance, the boss of the memo writer can claim that there was a long involved discussion about the issue when it came to light and appropriate measures were taken.
Of course this does not apply to really bad things like sexual harassment or abuse or some other really bad thing – these should be brought to light and handle with care by all involved.
I am talking about the run of the mill Challenger memo which takes the form of, “If we switch from 45 pound paper to 40 pound paper, I predict dire consequences.”
I once had a boss named Lew who had a phrase – “Don’t bring me problems – bring me solutions.” He shared this with me years before the Challenger incident.
This “bring me solutions” is the essense of how we break the endless cycle of wirting Challenger memos and then covering the exposed parts of the anatomy which result. All of this chatter drains ones energy and removes people’s focus from the problem at hand and actually makes it more likely that some dire consequence will occur.
The sad thing is that the dire consequence is usually not the one the (hoping to be brilliant) Challenger memo writer predicted. Although perhaps some lucky person elsewhere wrote a challenger memo and can gain some benefit from the tragedy.
Sakai Portlet v0.2
I went to Bloomington, Indiana in December and with Marlon Pierce’s help, started working on the Sakai JSR-168 portlet again. A really great steak from Zagreb always gets the juices flowing – Marlon said I could not have any steak until I had an initial version done – so motivation was high.
Now four days later, I have an even better release with a bunch of usable features. I attach some PowerPoint and source for you to take a look at. Here is a set of new stuff:
– Added Gallery Portlet
– Added a tree view portlet that shows all of your sites and tools
– Moving the code into SVN (when I get a good network connection)
– Configuration flexibility
– Added proxy portlets for common Sakai tools:
Announcements (sakai.announcements)
Assignments (sakai.assignment)
Chat Room (sakai.chat)
Discussion (sakai.discussion)
Gradebook (sakai.gradebook.tool)
Email Archive (sakai.mailbox)
Membership (sakai.membership)
Message Forums (sakai.messageforums)
Preferences Tool (sakai.preferences)
Presentation (sakai.presentation)
Profile (sakai.profile)
Resources (sakai.resources)
Wiki (sakai.rwiki)
Tests & Quizzes (sakai.samigo)
Roster (sakai.site.roster)
Schedule (sakai.schedule)
Site Info (sakai.siteinfo)
Syllabus (sakai.syllabus)
This basically means that you can drop a Samigo into a JSR-168 portal after a few details have been handled.
Sakai Board: More Principles
These are some more Sakai principles that were discussed by a few other folks.
The Sakai Foundation Board directs resources that belong to the Sakai Foundation or have been given/loaned to the Sakai Foundation. With limited resources, the Foundation tends to focus on investments which build and sustain the community. The Sakai board also provides some support for community-wide design and technical activities like project management, release management and quality assurance in the best interest of the community.
Nearly all of the work of designing, developing and producing Sakai releases is done by volunteers. These volunteers may be individual contributors or may work for an organization that is involved in Sakai and is making a voluntary organizational contribution. That said, one of the Sakai Foundation’s goals is to inform and guide volunteers making contributions how they might maximize the benefit of their efforts for the entire Sakai community.
Sakai’s direction is driven by contributions from the community. In order for an organization to effect the direction of Sakai it is best done through contributing resources to that aspect of Sakai that the organization feels is important.
Sakai efforts are organized into a number of separate projects, roughly modeled after Apache. Each project has a set of committers who self-manage their commit list. Generally the path to becoming a committer in a project is for one to develop an understanding of that element of Sakai and begin contributing through an existing committer. Once it becomes clear that the new contributor has achieved the appropriate skill level, they can then be granted committer status. The Sakai Foundation Board delegates operational authority for appointing appropriate committers to the leadership of the technical community.
Sakai is software which must maintain 100% production capability over its entire lifetime. Maintaining the performance, quality and reliability of Sakai releases is the founding principle of Sakai software engineering.
Sakai Board: Basic Principles
This is a set of guiding principles that we wrote down at the first meeting of the Sakai Foundation Board. This is really a brainstorming session more than anything else – but the nicely capture some of the truths about Sakai.
They are not “adopted” – just discussed.
Compiling VUE
In my ever expanding quest for places to integrtate Sakai into, I have decided to start playing with VUE (http://vue.tccs.tufts.edu/). VUE is pretty cool – it makes context maps.
In my crazy design thoughts, I want Sakai to hand VUE maps over web services. Those maps will contain information about sites the user has access to on the Sakai Host, and pages within those sites.
This is a long term fun thing for me. Thanks to Jeff K and Anoop K for their help on this.
But I figured I would share how I got VUE to compile on my Mac in case you want to be a cool VUE developer too.
It is (yet another) Chuck C-Schell script that I wronte because I have a terrible memory!
It grabs source, does a bit of fiddling with the source, compiles, and runs VUE.
Echos of Year 2000 / Y2K
It is January 1, 2006, and sitting watching Television last night – I thought back to 2000 and thought about the fear that we all held watching the ball drop and half-expecting the sewers to back up on Times Square as midnight kicked over.
Also today I am “cleaning out my closet” and pitching some old stuff and came across a Powerpoint Presentation that I made in 1999 about Y2K – at the time, I was the CIO of the College of Engineering at Michigan State University and I got a bit of flak about this talk.
Now six years later I am going to throw away the printout of my slides as I clean my closet so I figure that before I pitch them, I would type them in in case anyone in the future decides to ever look back at this point in time. Kind of a time capsule.
Here are images of this talk
Web Services in Objective C Part 3
This is my caller file. It is a .mm file not a .m file so I can micx C++ and Objective C. Sorry for my newbieness.
This is SakaiServer.mm – look in the doLogin method.
Again, Creative Commons Public Domain blah blah.
Web Services in Objective C Part 2
This is the SoapUtils.h – you include this.
Again if someone knows how to make this a set of utilities in a separate file that are linked together – let me know. I am an Xcode Newbie :)
Doing Web Services in Objective C
The examples for web services in Objective C in Xcode 2 are pretty lame. I am surprised that things are not cleaner – the WebKit is very sweet and cool.
I took one of the examples and refactored it to make it really cool. I will post code in the blog in my next two posts.
This is a mix of C++ and Objective C. I am not an expert in either in Xcode2 having learned Xcode 4 days ago. If someone smarter than me wants to redo this Apple event code using purely Objective C – that is fine with me. I would actually like that refactored code.
This is all Creative commons public domain – sample code stuff. Use, tear up reuse, don’t sue me.
This is the meat of host things are used again – note my weird dialect where I switch back form C, C++, and Objective C. I am still a newbie and fall back to things I know like fprintf from time to time :)
Doing a Modal Dialog in Objective C
See this URL:
http://developer.apple.com/documentation/Cocoa/Conceptual/Sheets/Tasks/UsingAppModalDialogs.html
This is a better modal dialog than in the Hillegass book pages 306-311. The Hillegass book is great showing the wiring of such a sheet – but the code below is better for the actual showing of the dialog. The Hillegass book uses the selector (nifty pet trick – but overkill for most modal dialogs).