matt.griffith

"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.

Button b = <Button>
        <Text>Click Me</Text>
    </Button>;

creates an instance of the standard Button class and sets its Text field to the string "Click Me".

That stopped me dead in my tracks. You should read this now. Thanks for the link Jeff.

Basic functions of HTML doctitles:

Search engine results display

Search engine results weighting

Bookmark display

[Jon Udell]

The very first change I made to BlogX was to fix the titles on the permalink page. I'm still waiting for the solution to many other BlogX problems though.

For heavy authoring and graphics and so on, you need a native application. But a huge majority of business data processing is you interacting with a database off on a server somewhere, and as far as I can see, a Web Browser is still the best way to do that. WinForms? Pshaw! [Tim Bray]

Since Tim spends 8 hours a day doing business data processing he should know. Sorry, there are many things that a browser does best but that is not one of them.

If the browser is the best environment for data processing and if users prefer the browser why aren't Quicken, Money, TurboTax, and other consumer data processing applications browser based? Sure they borrow heavily from the browser - they have links and back buttons and flow layout - but when it comes time to do the actual data processing they all have features that are impossible to achieve in the browser. Heavy data processing is no different then heavy authoring and graphics.