matt.griffith

I'm thinking out loud here about a new Web Service for people who use aggregators and have more than one computer. The problem: I subscribe to a feed at home but my aggregator at work doesn't know about it. It's actually kind of tricky to solve the problem, but I think I know how to do it. This is my scratchpad for thinking about it. Please don't deploy. Thanks. [Dave Winer]

If it doesn't synchronize which items I've read it won't do me any good as a user.

I added a User Personas document to the Satyr workspace. It describes several hypothetical Satyr users. The goals and needs of theses personas will guide the design and development of Satyr.

I will also use these personas in the other documentation. This should improve the readability since instead of referring to "the user selects" or "the project administrator adds" I'll be able to say "Lisa selects" or "Susan adds".

Post a message to the User Personas thread if you have any questions, concerns, or suggestions.

Sam Ruby and Jon Udell are two of my professional role models. They are both class acts. I have learned as much from watching them online over the last year and a half as I have from anyone else in my professional life. Keep up the great work guys!

I've added some User Stories to the Satyr Workspace. I'll add more as I get them done. In the mean time I'd love to hear your thoughts. Each User Story has a thread in the Satyr Message Board. Please post any questions or comments there.

As the stories settle down I'll add a page for each one on the yet to be create Satyr web site. Until then they'll be available primarily through the Satyr Message Board.

"Satyrs were male creatures who inhabited woodlands and forests in Greek mythology...the satyrs as a group were passionately fond of females - especially nymphs..." [Loggia.com]

Today nymph refers to the immature stage of insects with incomplete metamorphosis. Since Satyr - the application - is designed to help you catch bugs before they have a chance to multiply I thought the name fit perfectly.

Hmmm...Clearly I spent too much time thinking about this ;-)

Satyr is licensed under the Academic Free License because I want you to be able to use the code if you choose to. But, and this is important, you won't have to change the code to customize Satyr. If I do my job right you'll be able to add functionality and data to Satyr using a combination of simple configuration changes, dynamic code compilation, and compiled add-ins. I'll have more to say about extensibility in the future so stay tuned.

I started a bug tracking project because every development team needs a good bug tracking application. Since I'd like to sell two things - myself and .NET smart clients - creating an application that development teams use every day seemed like a natural fit.

Besides, I agree with Joseph Jones, nobody has gotten bug tracking right yet - primarily because every development team wants something different. I also agree with Joel Spolsky. You shouldn't make your bug tracking too complex. But a lot of teams build their own bug tracking application because they want the option to add features. Those are the teams I created Satyr for. I'd like to give them a solid foundation to build on.

However any team that chooses Satyr to save money is deluding themselves. Building your own bug tracking application - even if it is based on a solid foundation - will not be cheaper than buying a professionally developed and supported solution. Before you decide to build your own make sure you understand the tradeoffs.

I started the Satyr project for a lot of reasons. Some of them are documented below.

• To Learn
• What does it take to create, deploy, and maintain a real world smart client application?
• I hope to discover the strengths and weaknesses of the various P&P application blocks.
• Is the 20+ MB framework really a roadblock for compelling applications.
• I'm curious about the kinds of interoperability problems I will face doing Xml/WSDL design first.
• What are the costs and benefits of choosing Xml purity over serialization simplicity?
• What is the right balance for TDD in a real world application?
• What is the best way to deploy HttpHandlers and HttpModules?
• To Experiment
• There are many ways to add extensibility hooks to an application and I'd like to try a few ideas that are rattling around my head.
• How can I provide simple Slash-Dot APIs[1] over well specified, extensible, and easy to validate Xml documents using the tools available today? How will tomorrow's tools - X# and Yukon - make this easier?
• What is the pragmatic balance between Xml and Relational models? What affect will Yukon and other Xml aware databases have on that balance?
• To Sell
• Satyr will be a living resume.
• Demonstrate the power of smart clients, extensible Xml, and web services to development teams. Many developers would love to develop smart client applications. Many users prefer smart client applications when they have to use an application frequently to manage non trivial data. Decision makers aren't convinced though because they haven't seen a successful smart client application that solves the deployment nightmares that drove them to the "all web apps, all the time" mentality.
• To Teach
• With any luck one or two other people might learn something from Satyr.
• To provide a useful foundation that others can build on
• I have no desire to compete with the big boys. I'll never be able to provide the same level of support and I'll make that very clear from the beginning. I would like to provide a clean foundation that others can build on though.

[1] http://www.douglasp.com/2003/05/12.html#a284

What is Satyr?

Satyr is a bug tracking application. Satyr borrows heavily from the ideas Joel Spolsky describes in his Painless Bug Tracking article.

Satyr defines an extensible bug tracking data model. Satyr also defines an interoperable API for managing the bug tracking data.

The Satyr server is built on ASP.NET and SQL Server. The Satyr client is an extensible .NET smart client.

If you would like to get involved join me at Satyr's GotDotNet workspace.

I asked myself at 1 am. For a project I'm working on I want complete control of the WSDL, XSD, and XML that my service produces and consumes. Until 1 am this morning I thought using XmlElement with ASMX would do what I want.

Today I reread Tim Ewald's article. Tim asks "Why Access Raw SOAP Messages?" For me the question is: Why should I use ASMX? Wouldn't it be easier to create my own HttpHandler?

Tim answers that question at the end of the article:

You may wonder why I didn't just go all the way and implement my own Web Service endpoint using a low-level HTTP handler (an approach I've taken in the past). The main advantage of working inside (for the most part) of the ASP.NET Web Services infrastructure is that you can also take advantage of the object abstraction when it makes sense, a feature that a plain vanilla HTTP solution wouldn't provide.