Technology: September 2006 Archives
I was sitting in the San Jose airport catching up on my RSS feeds yesterday when I saw a post in Gizmodo about a guide to wireless in airports. "Wait a minute!", I thought, "that's our logo in that graphic!" You be the judge - here's what was in Gizmodo:
Here's our UW Wireless logo:
And here's what I wrote to Brian Lam, Gizmodo's editor:
Hey, Brian -
I was reading through my feeds in the San Jose airport yesterday, and came across the Gizmodo post that's at:
http://www.gizmodo.com/gadgets/wireless/airport-wifi-guide-atoz-200160.php
and I think you used (and modified) our university wireless network logo without either permission or attribution - surprised the heck out of me.
Take a look at our logo page at:
https://www.washington.edu/computing/wireless/wireless_logo/
and I think you'll see what I mean.
We'd appreciate you coming clean on it.
We'll see what happens from here.
Cyrus is talking about the CalDav scheduling draft.
CalDav scheduling builds on CalDAV access, but does not require it - so you could do CalDav Scheduling without having a CalDAV access server. Scheduling uses iTIP as its model for scheduling, which allows clients to reuse existing capabilities. There's a "Message" oriented Inbox/Outbox design, similar to how iMip functions with email. It's designed for fast (immediate) free/busy lookups, and there is fin-grained access control, including delegation.
Each user has an Inbox and an Outbox collection. An Organizer deposits an "invitation", into an Outbox with addressing details for attendees (using HTTP POST). The server delivers the invitation to the attendee's Inbox and returns delivery success/failure status for each attendee. The attendee responds by depositing response into their Outbox and the server copies that to the Organizer's Inbox.
With regular invites, the Organizer has to wait for the Attendee to respond. In the case of Free-Busy requests, the request is fulfilled immediately by the servers of the Attendees.
Access Control - there's a global CALDAV:schedule privilege which controls who can do schedule - on the Outbox it determines who is allowed to schedule on behalf of teh 'owner' - e.g. allows 'proxies' that can carry out the HTTP POST method on behalf of the owner. On the Inbox it determines who is allowed to send scheduling messages to the owner.
CALDAV:schedule is actually an aggregate of three privileges - CALDAV-schedule-request: who is allowed to book meetings with me; CALDAV:schedule-reply: who is allowed to respond to meeting invites I send out; CALDAV:schedule-free-busy - who is allowed to see my free-busy info.
One or more calendar user addresses are defined on the WebDAV principal for each user who can be scheduled. The CalDAV server will take care of mapping the ATTENDEE calndar user address in the iCalendar data to the principal using the principal property. The Calendar User is multivalued, so allows for multiple addresses for a single user.
The spec is close to last call. There are some implementations already (Apple), with more in progress (RPI).
Technorati Tags: CalDAV , Calendaring, scheduling
I'm in Cupertino, where Apple is hosting the fall CalConnect Roundtable meeting.
Gary Schwartz from RPI is talking about the proof of concept of federated free-busy information that was developed for the Open Group Challenge on the subject last spring. The idea of free-busy aggregation is that it solves the difficult problem of seeing when people have free time in common, even if they're on disparate calendaring systems.
The requirements of the challenge were to us open standards, could be implemented today, and cross timezones and geographic and network boundaries.
The proof of concept was constrained to a list of named attendees at a specified list of times, with all users having accounts on calendar servers.
The aggregator program provides the UI and business logic. A CaldAV compliant free-busy interface provides the interface between systems. Connectors translate from proprietary protocols to CalDAV. Systems that were interfaced included RPI's Bedework, Oracle Calendar, TimeBridge (via a CalDAV proxy), Exchange (via a connector written by Boeing), OSAF's Cosmo server, Lotus Domino (via a connector that IBM wrote), and Google calendar (via a connector that RPI wrote to the Google calendar API).
Users are registered with the aggregator by their email address.
Apple's iCal server is added for this demo today.
Gary notes that the advantage of the aggregator is that it takes an enterprise approach and doesn't require work on the part of the individual user, aside from just noting to the aggregator where their calendar is located.
Next steps include discovery, authentication and access control, and adding additional calendar systems. It would be nice to utilize the richer functionality of the new CalDAV Scheduling spec.
The aggregator toolkit is available at:
http://bedework.org/trac/bedework/wiki/FreebusyAggregatorOverview
Boeing is looking to "productize" their work to use with their partners.
Mike Douglas says that Boeing did a survey and found that it typically takes 20 hours of work to schedule a meeting, so clearly there's a business justification to make this happen.
Technorati Tags: Calconnect, Calendaring
James Morris from our engineering group reports that yesterday for the first time we processed more than 3 million external email messages at the UW (3,270,489 was the exact number), and that 72% of those messages scored a greater than 50% possibility of being spam.
That's 2,354,752 spam messages. In one day. At one university.
Hoo boy.
Technorati Tags: email, social-software
And speaking of hiring, Joel Spolsky has a great post on finding great software developers, which every technical manager, recruiter, and hiring official should read.
The great software developers, indeed, the best people in every field, are quite simply never on the market.
The average great software developer will apply for, total, maybe, four jobs in their entire career.
The great college graduates get pulled into an internship by a professor with a connection to industry, then they get early offers from that company and never bother applying for any other jobs. If they leave that company, it’s often to go to a startup with a friend, or to follow a great boss to another company, or because they decided they really want to work on, say, Eclipse, because Eclipse is cool, so they look for an Eclipse job at BEA or IBM and then of course they get it because they’re brilliant.
If you’re lucky, if you’re really lucky, they show up on the open job market once, when, say, their spouse decides to accept a medical internship in Anchorage and they actually send their resume out to what they think are the few places they’d like to work at in Anchorage.
But for the most part, great developers (and this is almost a tautology) are, uh, great, (ok, it is a tautology), and, usually, prospective employers recognize their greatness quickly, which means, basically, they get to work wherever they want, so they honestly don’t send out a lot of resumes or apply for a lot of jobs.
Does this sound like the kind of person you want to hire? It should.
Joel goes on to talk about how to find these people, and one of the things he talks about at length is bringing people in as interns while they're still students. One of the great joys of working at the UW is that we get the opportunity to work with lots of really great students - they're our most valuable natural resource. Students are smart, energetic, and frequently they don't yet know what supposedly can't be done. And often, when we're lucky, we get the opportunity to hire the best of our student employees as full-time staff when they graduate (unfortunately, we have more talented students than we have the ability to create open positions for them - but I guess that's good for Microsoft, Google, and the rest of the companies that go on to hire these folks).
Joel's article has me thinking about the possibilities of using some students for some of the projects that may be coming up for us in Emerging Technology.
Technorati Tags: jobs, management
I'm pleased to say that we've got a couple of jobs open in our little Emerging Technology group here within UW Computing & Communications.
One is a Project Manager, the other is titled Senior Strategic Integration Architect. The links to to the job descriptions on the UW's employment site, but basically the idea is that as we get involved in evaluating and germinating ideas for new applications of technology here at the UW, the Project Manager will be responsible for managing the flow of those projects and the interactions between our group and the rest of C&C and other UW units. The Project Manager will also play a role in the just now being invented process for doing regular planning for C&C's Service Lines.
The Architect will be involved in identifying new technology opportunities, investigating technologies that have possible application here at the UW, doing enough legwork to determine whether the technology is sufficiently useful and usable to pursue, and how that technology might interact and integrate with the UW's social, business, and technological environments. My hope is that when we organizationally decide that a new technology is worth serious pursuit, the Architect will have gathered and digested enough information to be able to work with the various engineering and support teams starting from a base of already established knowledge.
I did notice that in the process of getting the Architect job description listed it got edited, as often happens. I had included a quote about architecture that I thought was (at least metaphorically) relevant to the kind of person I hope to find:
In architecture, as in other arts, two considerations must be constantly kept in view; namely, the intention, and the matter used to express that intention: but the intention is founded on a conviction that the matter wrought will fully suit the purpose; he, therefore, who is not familiar with both branches of the art, has no pretension to the title of the architect. An architect should be ingenious, and apt in the acquisition of knowledge. Deficient in either of these qualities, he cannot be a perfect master. He should be a good writer, a skilful draftsman, versed in geometry and optics, expert at figures, acquainted with history, informed on the principles of natural and moral philosophy, somewhat of a musician, not ignorant of the sciences both of law and physic, nor of the motions, laws, and relations to each other, of the heavenly bodies.
- Vitruvius, circa 25 BC
If you're interested in talking about either of these positions, go ahead and drop me a line!
Technorati Tags: jobs, employment, UW
A couple of weeks ago I used my Gmail account to send someone an attached Excel spreadsheet file, and noticed when I viewed the sent message in Gmail that I was offered the option to view the attachment as HTML, and sure enough, I could view my simple Excel file right in the browser (Firefox, in this case).
I've also played around with Google's online browser-based spreadsheet and the Writely web-based word processor they now own.
I've long thought that Excel and Word offer far too many features for the average person (or at least me) to manage. I long for the original Word for Windows, which I thought was the best word processor ever - circa 1992.
All this activity at Google is obviously building towards something, and now Aaron Ricadela has an article in Information Week that lays it out:
Google this week will launch Google Apps for Your Domain, a software bundle aimed at small and midsize companies. The free, ad-supported package combines Google's E-mail, calendar, and instant messaging with Web site creation software. It will be hosted in Google's data center, branded with customers' domain names, and packaged with management tools for IT pros.
That's the first step. Later this year, Google plans to add its Writely word processor and Google Spreadsheets to the suite, build online collaboration features that work across its applications, and market the whole package to large companies for a fee. Google will include IT-friendly features such as APIs, directory-server integration, guaranteed performance levels, and telephone tech support.
Instead of trying to displace the hundreds of millions of copies of Office installed on business PCs, Google will try to snare users once they start sharing the Word and Excel files they've created. "The right way to view Writely and Google Spreadsheets, especially in the context of a larger business, isn't necessarily as a replacement for Word or Excel," says Matt Glotzbach, head of enterprise products at Google. "They're the collaboration component of that."
This is worth watching as it rolls out.
Technorati Tags: collaboration, google
Eddie Hargreaves writes a piece in the Apple Blog titled "Why I will (probably) not renew my .Mac account" that details changes made in iLife '06 that screw up the way longtime .Mac users interact with the online .Mac service, particularly for photo albums.
I've been using .Mac for our family photo site for almost three years now, because it's easy to publish photos from iPhoto and the software has taken care of linking the albums together, building the index, etc. But now it's gotten harder, and the new iPhoto '06 doesn't even know about the albums that already exist on .Mac as it sends you to the separate iWeb app to create a web page that it stuffs into an entirely new directory on .Mac.
Guess I'll have to look at moving my photo stuff to Flickr. What a pain.
And it makes me really glad I haven't yet upgraded the family room iMac to iLife '06.
But why now? If I’ve managed to rationalize the purchase in years past, what makes this year different? In a word: iWeb. You might think that the addition of iWeb to Apple’s iLife suite would be a reason for me to continue my .Mac membership. But instead it’s making me want to drop it.
Prior to iWeb, there was HomePage, Apple’s simple, online web page creation tool. The pages you could create with it were limited in their variety, but it was simple and easy to use. I could select a group of photos in iPhoto, hit the HomePage button and it would automatically create a new web page with those photos in the order I had made and with the captions I wrote. It would also link that page to all the others on HomePage and create a thumbnail link on the main menu page.
The benefit to me is that it’s easy to use and simple to keep updating. The benefit to Apple is that because it uses their proprietary software, it locks me into their system. And if I don’t renew my .Mac membership, my online storage disappears and all my online photo albums go away.
So imagine my surprise when I tried to easily accomplish this same task after installing iLife ‘06. The HomePage button has been removed from iPhoto and replaced with the iWeb button. I gamely give it a try, but the first test has failed: it’s not as easy as using the HomePage function. After publishing the page, I realized that it doesn’t link to my previously existing .Mac pages nor does it link from my previously existing main menu. In fact, it’s not even under the previously existing domain. It’s under the longer, more unnecessary web.mac.com/username/iWeb/Site/ instead of homepage.mac.com/username/
It is still possible to use HomePage on the .Mac site, and create photo albums, but it’s no longer a one-click operation. It involves exporting the photos from iPhoto to a new folder on the Finder, uploading them via the iDisk, creating a new page on .Mac, re-ordering them and re-captioning them. If I wanted to go through all of that, I could use any of a number of online photo-hosting services. And it wouldn’t cost me $99 per year.
