January 2008 Archives
Neither have I, but check this shit out! This guy plays "Bohemian Rhapsody" with hand farts!
I ran across this blog post considering the idea that OSAF had a hard time making Chandler Desktop materialize because it's written in Python. I don't have any thoughts on that subject, but down at the bottom of the post I found this gem that addresses both Desktop and Server:
Chandler Server was built in Java because the first (and at the time, only) protocol it supported was CalDAV, which is an extension of WebDAV for calendar access. In early 2005, the Apache Slide project was the most viable existing WebDAV implementation that we could find. Slide was written in Java. The decision was made to hire a Java programmer to build the server on top of Slide, and thus I was hired.
Would it have been possible to write a WebDAV implementation in Python? Sure - Wilfredo Sanchez did just that a year or two later for Apple's calendar server. Why did OSAF choose not to do that? I'm not quite sure, but I think it was probably just the whim of the hiring manager, who I believe had more personal experience with Java and had come to OSAF from a startup doing WebDAV in Java.
In any event, there was no schism between me (the lone Java developer) and the Python guys (every other developer in the organization). There were just different starting points and the differing requirements between a single-user application and a server meant to support many more orders of magnitudes of users.
I'm sorry that we didn't produce the specific pieces of software he wishes for, but we had very specific goals, and neither "a flexible UI that can slice and dice data" nor "a reusable storage engine for unstructured data and communication" were priorities for our project.
I always wanted the core Cosmo calendaring engine and storage system to be shipped as a separate component which could be embedded directly into an application, but not having had that idea until a year or so into the project, it would have taken a massive effort (relative to the size of the team) to refactor the code and the build system to make it possible. I did some weekend projects to get a sense of the effort, and it was clear that we had too many other higher priority things to do instead. At the end of the day, we were trying to build a server for lightweight collaboration, not a toolset for other peoples' application development.
In regard to "I've downloaded the client and server, and it looks like a prototype that a competent developer could coble together in a couple of weeks" ... it's hard to formulate a polite response. All I can say is, the Cosmo web UI has one of the most mind-blowingly sophisticated implementations I've ever seen. I challenge anybody on the planet to replicate that body of code in a couple weeks, or even a couple months. And as for the rest of the server, well, either this guy hasn't actually looked at the code and has no real idea of what it does, or he's just got the hugest ego on the planet.
It's indeed strange that these two components use different storage engines. If I were to invoke Conway's law, it appears that the project had a schism between the Python and Java developers. I'm curious as to how the decision was arrived at to not develop the server side code in Python. Even if the project's requirements were in constant contention, the least the developers could have done was to build a solid and useful framework. I certainly would have loved to see a flexible UI that can slice and dice data or even a reusable storage engine for unstructured data and communication. I've downloaded the client and server, and it looks like a prototype that a competent developer could coble together in a couple of weeks. It's not something one would expect from a high visibility and heavily funded open source project.Desktop is a single-user desktop application. Server scales to thousands of users and beyond. Desktop's repository was built with features like versioning and access control that seemed like they'd be useful years ago, when the sharing model was envisioned to be P2P, but by the time OSAF came around to client-server sharing, those features were no longer necessary, and we didn't bother to add them to the server's storage system.
Chandler Server was built in Java because the first (and at the time, only) protocol it supported was CalDAV, which is an extension of WebDAV for calendar access. In early 2005, the Apache Slide project was the most viable existing WebDAV implementation that we could find. Slide was written in Java. The decision was made to hire a Java programmer to build the server on top of Slide, and thus I was hired.
Would it have been possible to write a WebDAV implementation in Python? Sure - Wilfredo Sanchez did just that a year or two later for Apple's calendar server. Why did OSAF choose not to do that? I'm not quite sure, but I think it was probably just the whim of the hiring manager, who I believe had more personal experience with Java and had come to OSAF from a startup doing WebDAV in Java.
In any event, there was no schism between me (the lone Java developer) and the Python guys (every other developer in the organization). There were just different starting points and the differing requirements between a single-user application and a server meant to support many more orders of magnitudes of users.
I'm sorry that we didn't produce the specific pieces of software he wishes for, but we had very specific goals, and neither "a flexible UI that can slice and dice data" nor "a reusable storage engine for unstructured data and communication" were priorities for our project.
I always wanted the core Cosmo calendaring engine and storage system to be shipped as a separate component which could be embedded directly into an application, but not having had that idea until a year or so into the project, it would have taken a massive effort (relative to the size of the team) to refactor the code and the build system to make it possible. I did some weekend projects to get a sense of the effort, and it was clear that we had too many other higher priority things to do instead. At the end of the day, we were trying to build a server for lightweight collaboration, not a toolset for other peoples' application development.
In regard to "I've downloaded the client and server, and it looks like a prototype that a competent developer could coble together in a couple of weeks" ... it's hard to formulate a polite response. All I can say is, the Cosmo web UI has one of the most mind-blowingly sophisticated implementations I've ever seen. I challenge anybody on the planet to replicate that body of code in a couple weeks, or even a couple months. And as for the rest of the server, well, either this guy hasn't actually looked at the code and has no real idea of what it does, or he's just got the hugest ego on the planet.
As a postscript to his comments on OSAF's kerplosion, Scott Rosenberg dredges up an old story about my involvement in the first version of Salon's Table Talk discussion software:
To set the record straight, I was the only developer on that disastrous project. I didn't even code in a proper language but rather used a silly RAD tool called Tango. It was as far from a professional project as we could get, and I was completely responsible for its failure.
I am humbled before my peers. My shame is but a quick search away for prospective employers. Oh Scott, couldn't you have waited until I have another job, at least? :D
My only consolation is that the failure was just as much Salon's fault. What exactly were they thinking, hiring frat boys to write software for them? Self-fulfilling prophecy, imo!
Funny footnote: Moseley and I crossed paths a decade before we met at OSAF; he was part of a small development team of Cornell students who wrote the first, somewhat disastrous version of Salon’s Table Talk in 1995. He’s plainly become a very different developer in the interim. His colleagues went on to fame and fortune during the dotcom boom before going bust.Ouchie! While I appreciate the implied compliment on Cosmo, I could have lived my life without this horror story resurfacing ;)
To set the record straight, I was the only developer on that disastrous project. I didn't even code in a proper language but rather used a silly RAD tool called Tango. It was as far from a professional project as we could get, and I was completely responsible for its failure.
I am humbled before my peers. My shame is but a quick search away for prospective employers. Oh Scott, couldn't you have waited until I have another job, at least? :D
My only consolation is that the failure was just as much Salon's fault. What exactly were they thinking, hiring frat boys to write software for them? Self-fulfilling prophecy, imo!
Another great hack from the young and fertile mind of Travis Vachon: chandler.el. Using the Atom API, you can save and edit notes in Cosmo. This could certainly be handy for folks who live in Emacs and like to drop stray notes into various buffers and text files. Travis, you should expand it to include a full-on collection browser and a microformat publisher.
SFGateParents, teachers and education advocates up and down California reacted with outrage Friday to Gov. Arnold Schwarzenegger's proposal to cut nearly $5 billion from public schools over the next 18 months.
The news that millions of dollars could be cut from categories such as class-size reduction, textbooks, preschool programs, after-school tutoring and hot lunches led one father to ask why a state that ranks among the top 10 global economies educates its children in the manner of a Third World nation.
Olivia dug up this oldie but goodie for me. Please don't click that link if you're a prospective employer and you'd be offended by me using off-color terms in the office ... on second thought, go for it.
OSAF is restructuring, and I'm moving on. They had to get rid of most of the staff, and I just wasn't feeling it anymore, so I raised my hand for the axe. Good luck to those who remain. Now that I'm no longer beholden to the person signing my paycheck to direct my work on Cosmo, I may be able to get around to some of the interesting things I'd been looking forward to, like CalDAV scheduling.
Dunno yet what's next on the job front. I've been checking out craigslist for the past few days, and I feel a scream build deep inside every time I see a posting about a social networking startup. I want to work on something that has real benefit to all society, not the fad of the week for geeks. Where's the intersection of renewable energy and web services?
Tangential rant: I guess I'd better go buy a computer science book so that I know how to reverse a linked list for job interviews. Not that implementing a basic data structure has ever had any bearing on any of the projects I've worked on in thirteen years, but for some reason this is the standard that computer science nerds set for potential hires. Don't get me wrong - I have no problem with whiteboard coding and think it's valuable to observe how a person breaks down a problem and works toward its solution, but how about asking me to demonstrate knowledge of an algorithm or design pattern that's relevant to the level of the stack where I'll be working? There's more to evaluating intelligence than determining if the interviewee sat through CS 200. For instance, asking for details about previous work and forcing me to defend choices I made. Metaweb has the right idea.
To be honest though, I'd really rather do something that doesn't involve sitting in front of a computer all day. Maybe I should join the Peace Corps. While I'm mulling that one over, if you want to talk to me about employment, here's my info.
Dunno yet what's next on the job front. I've been checking out craigslist for the past few days, and I feel a scream build deep inside every time I see a posting about a social networking startup. I want to work on something that has real benefit to all society, not the fad of the week for geeks. Where's the intersection of renewable energy and web services?
Tangential rant: I guess I'd better go buy a computer science book so that I know how to reverse a linked list for job interviews. Not that implementing a basic data structure has ever had any bearing on any of the projects I've worked on in thirteen years, but for some reason this is the standard that computer science nerds set for potential hires. Don't get me wrong - I have no problem with whiteboard coding and think it's valuable to observe how a person breaks down a problem and works toward its solution, but how about asking me to demonstrate knowledge of an algorithm or design pattern that's relevant to the level of the stack where I'll be working? There's more to evaluating intelligence than determining if the interviewee sat through CS 200. For instance, asking for details about previous work and forcing me to defend choices I made. Metaweb has the right idea.
To be honest though, I'd really rather do something that doesn't involve sitting in front of a computer all day. Maybe I should join the Peace Corps. While I'm mulling that one over, if you want to talk to me about employment, here's my info.
Fixed tons of bugs in this one.
http://blog.chandlerproject.org/2008/01/04/chandler-server-cosmo-011-released/
http://blog.chandlerproject.org/2008/01/04/chandler-server-cosmo-011-released/
