This was a wonderous site to see, and one a long time coming. After long months of working to build a sense of importance for the build, we finally got every one of our 199 projects in CruiseControl to build successfully. Good work team.
One obstacle we faced along the way was knowing exactly how many of our projects were failing. That’s what lead me to submit this patch to CruiseControl. It was accepted and has since been improved upon by others, I believe. It’s finally nice to see the “Failed” count down to 0. 
UPDATE: I’ve posted a more complete version of this code in More Ruby Exporting of Groupwise to iCal.
I’ve wanted to export my Groupwise calendar to iCal format for a long time. Every time I try to do it, I ended up running into the same few pages. They sorta worked, but were clumsy.
So I threw this little beauty together in under 10 minutes and 2 google searches. It seems to be a start, though I expect to improve it. Groupwise Object API Docs (PDF format; the web version keeps blinking — arrrgh) from Novell were useful, as was this Ruby gem.
require 'win32ole'
require 'icalendar'
groupwise = WIN32OLE.new("NovellGroupWareSession")
account = groupwise.Login("your-username", "")
path_to_host = account.PathToHost
cal = Icalendar::Calendar.new
account.Calendar.Messages.each do |message|
next unless message.ClassName == "GW.MESSAGE.APPOINTMENT"
event = cal.event event.user_id = "tims@asrs.state.az.us"
event.timestamp = DateTime.now
event.summary = message.subject.PlainText
event.description = message.BodyText.PlainText
event.start = message.StartDate
event.end = message.EndDate
end
puts cal.to_ical
Every day I find more reasons to love using Ruby. Enjoy!
I like to challenge barriers. I think part of it is that I’ve had so many of my own challenged and under scrutiny, they fell. That opened up worlds hitherto unexplored.
Design is like that. Many people hold to current limitations or artificial constraints that bolster the status quo. Challenging those assumptions almost always leads to greater knowledge. Either I learn something about the system that I didn’t know. Or new vistas open up and widen our range of viable design options.
True knowledge engenders design freedom.
Phil Windley has some interesting pointers on URLs as identities over in this post. This isn’t the first time I’ve heard of this, and I expect it won’t be the last. While I think the idea is good, and I hope to see it continue to grow. I am concerned that I don’t readily see a consensus on how to handle URLs changing hands over time.
Certificates have CRLs, and expiration dates. You have to get new ones, and no one can get your old certificate.
I, like many of you, have purchased several domain names over time. Some I held for a time and have let go. How can you assert who owned a URL at a point in time in the past? For example, this comment will still be visible for times to come. If I need to let my domain die, and someone else picks it up, do they now inherit the credit for all my deeds scattered across the internet? Does everyone simultaneously stop asserting that my identity is good, or can they still assert that the identity was good at the time the action was taken?
Time is something I’ve continually wrestled while developing internal systems at many companies. Most things have a period of validity. Many things require an occasional check that something was valid at a particular point in the past. Most software I’ve seen that deals with certificates doesn’t quite act this way. For example, if a person’s email certificate expires most S/MIME clients I’ve used will refuse to certify that the email was properly signed and sent and the certificate was valid as of the date it was sent. That’s what I care about when reading signed email. I don’t care that the person uses a different certificate today.
Similarly, if I leave a comment on a site, author an article that’s signed, or use a digital identity in some other way. I want my use of that identity, at that point in history, to be considered valid for all time.
Perhaps the real breakdown in this structure falls to locating a trusted time source. Perhaps it doesn’t matter so much if you’re willing to trust your own site’s time source, and some authoritative source’s answer to “what range of time is this identity good for.”
URLs as identity are useful. I used one at the beginning of this post to casually identify Phil Windley. I think that straightforward ideas like this have big potential to do good and be widely adopted. But, while I’m no expert on digital identity, in my opinion time does matter. Ignoring it will exhibit pain in the future. But right now, just about everything that deals with time in the OpenID Spec is crossed out.
Hopefully I’m clueless about a big piece of the pie.
