myShoggoth

Foundations: Performance

Performance

This is a subject that most programmers believe they understand once they get past the O(n) vs. O(n^2) stage, but very few really feel in the bones.  Yes, it is true that for a simple chunk of code that is doing a bunch of work and is O(n^2), changing the algorithm to be O(n) or O(2n) is going to have a much bigger effect than tweaking a few lines within the code and leaving the overall complexity alone.  Right?  Isn't it?

Usually.

Locality Is King

Location	Latency	Data Size
CPU (Registers)	None	Teeny
L1 Cache	Essentially None	Tiny
L2 Cache	Little	Some
RAM	Some	Some - Lots
Page File (HD)	Lots	Lots - Tons
LAN	Tons	Lots - Boatloads
Broadband	Ouch	Yes

Think about latency in the terms of CPU cycles; what is the processor not doing while it is trying to access that memory.  In other words, if the memory you want to access is already in a register, there's no wait!  The CPU can just use it to do work.  If it is in the current cache line, that's just as good (and why serious hard-core down-n-dirty performance tuning can be all about tweaking cache line contents).  Once you start hitting L2 cache you're talking about giving up a bunch of CPU cycles, and you need to begin asking a very fundamental performance question:

Could I have recalculated this data during the latency it takes to fetch it?

Code Size

Locality is important for object code, too.  Imagine you have an exe with three small functions but they are each more than a virtual memory page away from the others.  In the worst case, these functions are very interdependent and called all the time, which would force all three pages to be in memory all the time.  Now change the code so they're either all in the same page, they aren't so interdependent, or they aren't called all the time.  Any of those solutions could allow two more pages to be swapped out.  The smaller your compiled code, the fewer pages it occupies, the smaller the chance of a page fault.

Related to this: Don't load a library unless you need to (investigate delay-load for DLLs your code may use but not every time your application runs), unload it as soon as you can.

Memory Usage

The worst case is having code on a page that is rarely but regularly called that would cause a page fault on a regular basis, or code that causes a lot of different places in memory to be touched and faulted in.  Some data structures (such as linked lists) can lead to situations where in order to traverse the structure you are roaming all around memory, something as simple as a pointer dereference can be deceptively expensive if it was pointing to memory that is paged out.

Reducing your program's working set reduces the number of memory pages your application occupies, which reduces the number of potential page faults you can have.  It doesn't solve performance problems itself but has a high correlation with things that do.

CPU Cycles

As you think about the best way to code your application, keep in mind that CPUs are going to get faster and faster.  Latency is unlikely to get enormously better anytime soon.  Code to guard against the bottleneck, meaning take advantage of the processor power and stop caching values that are quickly and locally recalculatable.  Let's say you calculate a relatively simple piece of data (it takes 2,000 instructions) and cache it in a global.  If at any time the memory that the global is in is paged out and you go to access it you will incur a much larger cost going to fetch it than you would to recalculate it from scratch.  Furthermore, as CPUs get faster the relative cost for your decision will increase.  If you had recalculated it your users would have seen better performance for their money, not the case if the processor is sitting idle waiting to be fed memory.

Responsiveness

Most GUI programs are not CPU-bound, so the feeling of a 'slow' program often result from operations that access hard drives, CD ROMs, and the network.  Any user-initiated operation that can possibly take more than half a second needs to be written in such a way that if it does the application provides:

1. In-progress UI.  The hourglass mouse cursor isn't enough, but I've seen applications that don't even use it.
2. ETA whenever possible, both specific information on how long the operation will take and some active UI so the user knows progress is being made.
3. A way to cancel the operation.

A really good application will allow the user to continue to interact with other parts of the UI while waiting for the operation to finish.

Here's the trick: If the operation can take more than half a second but won't necessarily do so you don't want to flash in-progress type UI up and make it go away immediately when things go fast.  You may have three levels (the times used are just examples):

1. Up until .5 of  a second don't do anything.  If the operation completes in this time it will feel instant without flashing any UI.
2. At .5 of a second if the operation isn't done, switch in hourglass cursor.
3. At 2 second if the operation isn't done, switch to in-progress UI which will stay up at least another 2 seconds even if the operation completes before then.

Once you've committed to your cursor change or in-progress UI you need to stick with it long enough for the user to not be annoyed by flashing or unreadable UI.  Of course if you can determine ahead of time how long the operation will take do the right thing from the start.

Threading

All of this assumes that you can have interactive UI while your program is doing other things.  For this, you need multiple threads.  This is a major danger area of computer programming, only a small percentage of programmers seem to really wrap their heads around the concepts and are able to extract themselves from the pitfalls (I don't know of any who have never fallen in them).

Here are some ways to simplify the problem.

Single UI Thread

Only have one thread that shows, modifies, manipulates, and interacts with the UI.  This thread should be totally event-driven and never do heavy lifting itself.  No file I/O, no network I/O, no I/O of any sort whatsoever.  If you're making API calls from it they must either be asynchronous to begin with or have no chance of blocking.

Thread Pool

To do any heavy lifting or any I/O at all you want to have a pool of pre-created threads, any of which can do any piece of work.  They should never have to interact with each other, the only communication they ever do is with the UI thread in very specific and well understood ways.

They are pre-created for two main reasons because of the cost of creating and destroying threads, which is significant.  One aspect of the cost that isn't always well understood goes back to the locality stuff I talked about earlier:  Every time you create or destroy a thread it calls into every DLL you have loaded to tell it.  This is so the DLLs can do any per-thread processing or cleanup they need to. These DLLs may have been paged out forever, you're almost guaranteeing that you'll begin a page-fault fest.

By creating a pool of threads all at once you solve a set of problems nicely:

1. You're allocating all this data all at once in a tight section of memory (locality!).
2. You will be accessing the same code in all these DLLs for each thread in a brief span of time, so at worst all the pages will only be faulted in once per DLL and you get the extra threads for no additional cost.
3. If any of the DLLs do allocate information per thread, it will also have locality relative to related information about the other threads, making your worker threads more interchangeable.

Now your thread synchronization load is simplified to a smaller number of pitfalls:

• Assignment of work items (probably in a queue) to threads in the pool.  The UI thread should be the only writer, and either one thread can be designated the reader and assign out the tasks to the others in the pool or you can write some interesting sync logic so they can wake themselves and the first one to take an item wins.
• Signaling job completion and status to the UI thread.  Once each worker finishes their task, they need to store relevant information and final status/error information in a well known place and signal the UI thread.  When the UI thread receives the signal it knows where to find the information and assumes ownership of all the memory involved (and is responsible for cleaning it up).

These aren't trivial problems, but they are well understood ones.  By reducing the possible surface area of your code that deals with threading issues (by avoiding having worker threads be able to add work items to the queue, for instance) you minimize the amount of code and the amount of debugging that will need to be done to get it right.

How many threads should be in your pool?  That depends heavily on what your application does, but  I recommend starting with very few (maybe one or two) and doing testing to see if you need more.  You probably won't.  Marginal utility will drop quickly, so for each thread you add you will get less of a performance boost for the same incremental cost.

COM

All I can really say here is that if you are using COM heavily and/or using COM-based APIs, you had better thoroughly understand how the different threading models work, how they interact, and all the fun pitfalls you're going to encounter.  Generally I would lump COM calls in with I/O for the purposes of this discussion.  Don't do them in the UI thread unless you know it won't block and understand why (and furthermore understand why you are probably wrong and have a very good reason to think you aren't for this specific case).

UI Performance

• Debug UI painting/flicker/etc. type problems using Remote Desktop across a slow connection.
• Spend the CPU cycles to calculate the minimum amount of redraw you need.
• Use common controls whenever possible, let Windows do the work for you.

Network Performance

• Debug using a very slow or purposefully slowed connection.
• Capture the traffic associated with your connection and go over it.
• Batch requests and responses to mitigate latency.
• Byte count isn't as important as latency in most cases.

Foundations: Window Handling

Prologue

There is a lot of software out in the wild, and a lot of programmers.  GUI applications in particular have a lot of variation in quality, and the difference between a polished program that has been out for a long time and had a lot of iterations, sold in many markets, and been very successful, and the first version of a program even by a good company is startling.

My 'Foundations' series will be a set of articles on what constitutes the foundations of a solid, world-class GUI application.  In other word, what is the minimum bar to be considered serious software?  That minimum bar is higher than most people think, which is why most successful companies and projects have very ugly growing pains after they go from "Good enough to get to market and make some money" and head towards "Competing against the big software houses in global markets".

These articles are in no particular order (other than what I feel the most like writing about when I sit down), and by no means will be exhaustive on their subjects.  I'll point at good reference material when I know of it, but you can think of this more as a checklist to think about when designing and implementing.

Lastly, these foundations are the stuff that you just plain must get right no matter what your program actual does, which is why I've heard them referred to as 'taxes' or 'basics' on different teams I've worked on (although for those who have worked on them, this is a different list of my own that doesn't necessarily reflect the lists for those projects).  On top of these you must get things right for what your program does.

Let's start.

Window Handling

This is an area that is nearly always bug-driven in my experience.  A seamless user experience involves managing an application's windows, and many programs don't do a good job at it.  It makes the experience clunky and awkward at best and can make the program completely unusable at worst.  While the OS does the bulk of the work for the application for free, there are a number of pretty simple things that can be done that make a huge difference and make your product much more professional.

Desktop Awareness

There are a lot of details to get right, but getting them all right makes an incredible difference.

• Don't confuse screen coordinates with non-client coordinates with client-coordinates.  This is important enough to make it worth doing a string search through all your program's source code for the Win32 functions that deal with such coordinates and sanity check to make sure the right coordinates are being used with the right call.  See Raymond Chen's article on "Why does the taskbar default to the bottom of the screen?" for prototypical example of how getting this wrong has annoying and subtle consequences.
• Is this new window going to be on the screen at all?  If not, maybe you'd like to move it to actually be on the screen.  There are a few reasons that this may happen, some examples (some of which might be handled by the OS itself) are:
• • The user has just changed the display resolution.  New video card, new monitor, different user with better or worse eye site (or more or less tolerance for smaller stuff on their screen), the assumption that this is so rare that it shouldn't be worried about is wrong.
  • Using a laptop that connected to or disconnected from an external monitor, either to give a presentation on a conference room's monitor or because they like to take advantage of a bigger monitor at their desk
  • The user is using Remote Desktop to connect to a machine with a large monitor from one with a very small one.
  • The user has resized their taskbar to be big enough to cover the window.
  • Some other application has registered an appbar and when it comes up it takes over desktop space.
  • The user has changed the monitor from portrait to landscape mode.  This is a cool new feature of Tablet PCs and some LCD monitors, doing the right thing in this situation is slick.
• Menus/popup/tooltips/etc.  There are a few cases to keep in mind here, some of them newer or more important than before:
• • If the new window is going to either be obscured by the taskbar or an appbar or will go off the window in any direction. you should try to go in the other direction instead.  Most menus open down and right (at least, in LTR languages...), can you make it open down and left or up and right or up and left to keep it visible?
  • Is the new window going to go across multiple monitors?  Multi-mon is getting more and more popular, the most professional applications will do as above to avoid drawing across the monitor boundaries.
  • Tablet handedness!  For Tablet PCs, the user can tell the OS if they're right-handed of left-handed.  Why is this important?  Let's go back to the fact that most menus open down and right.  If I'm using a Tablet stylus and I'm right handed, the menu will pop up under my hand, which sucks.  The OS will take care of this for you if you're using standard menus, but if you're doing it yourself you need to think about it.
• Changing the UI layout for the screen size and form factor.  I'm very happy to say that my primary example of this is Microsoft Outlook 2003.  They didn't get this right in one of the beta versions, but the version I run now detects when you switch a Tablet PC from landscape to portrait mode or back and changes the location of the "Reading Pane" (which is the new and much better version of the Preview Pane) to optimize for the screen layout.  I cannot tell you how cool that is.  Other examples would be to change the layout for smaller window sizes or resolutions to try to give the most usable experience for the user possible under the constraints.

User Awareness

The first step in this area for most applications is to remember the location and size for their window when it is closed, and make it that size against next time one is created.  It gets a little more complicated than that to do it right, though.

• When do you save those preferences?  The best practice here seems to be when the user closes the last open window of that particular type.  If I have five different copies of an application running and have them moved all over the desktop and made them different sizes for displaying different content, do I really want my next window to come up the size of the last one I closed?  Hard to say.  It depends on the application, but many successful applications only save that information on the close of the last window.
• Do the right thing for the user, no matter what was saved.  If the saved position will be off-screen, or halfway off-screen for the reasons described above, you might want to move it fully onto the current screen.  Then you need to decide if the user would prefer that you save those new coordinates on close, or if you should preserve the original ones so the next time they run in a 'normal' resolution (assuming the resolution change is temporary) it appears where they really want it, and not where you had to put it under special circumstances.  If they actually move it after you place it on screen, that might mean that's where they really want it.  As you can see, changing resolutions, multi-monitor setups, laptops, etc. all make doing the right thing a very interesting problem. 
• Keep in mind how your users use your application, and save preferences accordingly.  I don't think there are universal solutions, it depends on the application and how the application is used and what it does.  Do you have several modes?  If so, you might want to keep these preferences per window type per mode instead of just per window type.  Most importantly, think about it from the user's point of view:  When this window comes up, what will make the user trust that the application just knows the right thing to do?  Maybe you save a different set of preferences for landscape and portrait, or external vs. laptop monitor, etc., and maintain them completely separately.

When I switched from landscape to portrait on my Tablet PC while using Outlook 2003, and it moved the Reading Pane accordingly, I said (aloud) "Wow!  Perfect!"  Handle your windows to try to get the same reaction from your users.  Surprise them with the details.  I guess in many ways that's the theme for this entire series of articles.

Focus Awareness

First and foremost, don't grab focus just because you can, or as a simple workaround for a real bug.  There's little more annoying that trying to do something, having a window pop up and grab focus, continuing typing and hitting return on what you were working on and instead having answered a random dialog.  Be respectful of the user, and be subtle.  In the paraphrased (and made much less profane) words of a friend of mine, "Don't be a focus-stealing hunk of crap".

In the same vein, don't attempt to steal attention either.  One of the major abuses of Windows XP these days is 1305915 programs that all get Shell Notify Icons (the ones in what everyone calls the 'Tray') and pop-up balloons to tell you all sorts of things you don't actually care that much about.  Unfortunately, many of them even belong to the OS.  The last thing anyone wants is another balloon that says "Hi!  Just popped up to say everything's fine!"  If you're going to have one of these icons and/or balloons please make it very easy and obvious for the user to turn it off if they want to. Your program comes across as much more professional if the user wants to do something (even uninstall it or turn off a feature or behavior) and they find it easy and obvious to do.

Lastly, non-modal dialogs are almost always better than modal ones.  It is often more difficult to write the application in such a way that the user can interact with a given non-modal dialog, interact with main windows, switch back and forth, bring up other dialogs, etc.  It also makes the user experience more powerful and easier.  They can set up their screen for maximum productivity and not have to exit out of one piece of UI, switch to another, and then exit from that to get to another.  Instead of setting up dead ends, you're creating a powerful overall experience.  It is worth the difficulty, especially if you use the opportunity to write your application in a more robust way so you can handle different things going on in different non-modal dialogs or windows simultaneously.

A Blog Entry About Blog Entries About Blog Entries

The old advice for writers is to write what you know.  I guess it thus makes perfect sense that if most of what you know, or most of what you're known for, is blogging... then your blog will tend to be written mostly about blogging itself.

But in reality blogs aren't a fundamental paradigm shift, but rather a formalization of a web site design pattern.  There are a few ways available to you to create new web sites, starting from notepad/vi/emacs/your plain text editor of choice to complete content management systems.  Blogging is a style of web site that has evolved as one of the most effective, and now that people are realizing that it is effective there are tools and products being created around the pattern.

The pattern itself is straightforward but not rigid, giving lots of room still for experimentation and tweaking.  So far I've seen the following styles (and combination of them) of blogs appear:

Personal Diaries

This is what I think of when I think about with LiveJournal.  People recording information about their lives mostly for the benefit of themselves and their friends.  The pattern is used as a way for me to structure information about my life for your consumption.  The additional concepts that LiveJournal adds are the notions of the Friends network, which serves at least two primary purposes.  First, it creates an 'RSS aggregator' style way for you to see all the posts from your friends.  Second, it allows permissions-based filtering on who can and cannot read particular posts.

'Value Add' News Aggregators 

My favorite example of this is Gizmodo.  The news they have is oriented at a particular vertical market (gadget geeks like me), but for that market it is news in the sense of a trade magazine.  Although there are news organizations that have created RSS feeds, their web sites themselves tend to follow a different but similar pattern to blogging, that of the portal site.

"Me Also" News Aggregators

These are blogs/blog entries that give links to news stories with very little other content or value.  If you read enough blogs and some news item comes across that pushes the right buttons, you're assured to see the same link about twenty times with maybe slightly different text surrounding it.

Technical Drilldowns

I think the best tend to have a mix of subjects, shorter articles, and a unique approach.  My favorite belongs to Mr. Raymond Chen , and I know I'm not alone in that.  The other end of the spectrum tends to be book chapters in blog form that use the pattern more as a way to organize and publish, but has the bonus of allowing comments and conversations to create a feedback loop between the author and the audience.  No, my site doesn't have this (for a variety of reasons I can go into at another point), feel free to email me with feedback.

Blogger on Blogger Action

The point of this article, in fact.  When all the posts are about other high profile bloggers or the nature of blogging, when the point becomes to gain status in the blogging social group, the fact that the whole thing is really a technology design pattern gets lost and the true lessons and potential for using it as a tool rather than a means to an end get muddied.  That reminds me, have I mentioned that Gregory is a cool guy, with a cool website, and a great DJ?  Not sure why that came up, but it is all true.  No relationship with this article.  Really.  *cough*

Photos

This is an interesting trend on blogging, either the photo blog or the moblog.  I'm still undecided if it is an abuse of the pattern (see below) or an interesting twist on it.  One pattern for web pages/sites with photos is the album or gallery, where you can take the set of photos from an event or 'roll' and create one or more pages with the photos and often some commentary.  The main difference for photo blogs seems to be the number of photos posted at a given time.  When they're done for artistic reasons, the comments lose their value and/or go away completely.  When they're created in more of the 'personal diaries' style, the comments are made even more important and given more focus than in the photo album pattern. 

Misc. Ranting

If it isn't in the realm of a technical drilldown, and isn't meant mostly for my friends, it isn't really news, and isn't about other bloggers... it is most likely a rant.  I'm not saying ranting is inherently bad, but there's a good chance I'll have a very long, meandering blog entry about it at some point to try to convince you all that my feelings on the subject are absolutely correct and undeniable.

Abuses of the Pattern

When many people have a hammer, all web sites are nails.  The blogging pattern is very successful for a number of different styles and types of web sites, but it won't be the right one for all.  As I said above, I'm still undecided whether we'll find that the photo blog is an abuse of the pattern or a clever departure from previous patterns such as albums to emphasize the information in a different way.  I'm completely convinced, however, that audio blogs are just dumb as hell. 

For the record, this entry falls into the following categories:  Personal Diary, Technical Drilldown, Blogger on Blogger Action, Misc. Ranting, and quite possibly an abuse both of the pattern and in general.  I feel kind of bad about leaving out photos, so I'll just add one of those as well.  Almost scored the blog entry hattrick!

Brewing the Best Coffee

I'm not the worst that I know, but I'm definitely a Coffee Geek (but not the Coffee Geek).

I buy my coffee green, roast it myself, and am very particular about how it is brewed.  That said, I'm not a total snob, I will drink coffee from Starbucks, some restaurants, some cafes, etc.  It just takes special circumstances, since the stuff I make myself is generally leaps ahead of any of the above.

I started a 'coffee club' at work, and besides supplying the beans and the brewer I occasionally will give people info on how to make better coffee and other tips.  Since I have this forum that has no particular purpose anyway I might as well put some of them down.

Grind Late

For those who are buying specialty coffee instead of instant the first mistake is often to get it ground at the store.  When you open a bag of ground coffee you know that wonderful smell that comes out that makes you think, "this is going to taste soooooo good"?  When you grind the beans, it takes all the compounds in the coffee that make it taste and smell so good and releases them.  They don't last long.  When you open the bag the compounds that are already free have just escaped forever (they weren't in the beans anymore), and that wonderful smell was them waving goodbye to you on the way out.

A very general rule of thumb is green coffee beans can last for years (1-2 is probably the longest they should be kept, but I've done longer and they just start getting flat), roasted coffee can last for weeks (more than two and you better have it vacuum sealed, even then four is really pushing it and you're probably drinking stale beans), and ground coffee can last maybe an hour, tops.  Past these times, the perishable good you are partaking is... well... not so fresh.

A couple things I have to add here: Don't buy flavored coffees.  Flavoring coffee is fine, there are plenty of ways to do it after you've made the coffee, but don't buy the pre-flavored beans.  Chemicals are added which can gum up your grinder and make it nasty.  Second, be careful about how you grind.  Burr grinders are better, but the whirly-whacker ones can be used as long as you're careful not to let the grounds get heated and start cooking.

Buy Early

The fresher the beans you buy the longer they will last and, except for a few points I'll address in a moment, the better it will taste.  You'll notice how very few coffee roasters date their coffees, by either crop year or roast date.  If you find one they will be worth further investigation, since it is likely they care deeply about quality and take pride in their craft.

You want the beans in contact with as little oxygen as possible, that's what makes them go stale.  Additionally, the beans will give off a lot of carbon dioxide for a few days after roasting, and it is best if it can be kept away.  Foil valve bags have been developed specifically to allow you to vacuum out the air, seal it, and allow the carbon dioxide to vent.  This is ideal, and roasted coffee will stay fresher for longer this way than any other.

You might think that the best time to brew a coffee would then be immediately after it was roasted, but this turns out not to be the case.  As the beans exhaust carbon dioxide and recover from being cooked, their flavors change and develop for a while.  The process is conceptually similar to letting a roast rest after cooking, and in fact letting it sit is also called 'resting'.  It varies greatly by origin, crop, and roast, but a good guess would be 24 - 48 hours is the peak for flavor.  I've had at least one coffee that was incredible at its peak, but otherwise just kinda 'eh'.  There's an idea, maybe a Brigadoon Blend.

Yet another good reason to know when the beans you bought were roasted.

Drink Quality

This may seem obvious, but it is very difficult in practice.  Coffee is a crop, which means that variations from year to year make regions, brands, and even individual farms taste different with each crop.  If you really loved the coffee from a particular farm in their 2002 crop, you may find the 2003 crop to be even better, or much worse.  No way to tell until you taste.  Even worse, you can have the same coffee from the same farm harvested at different times of the same season and get very different results.

How do the big coffee producers get around this problem?  Blending.  They buy from a lot of different places all the time, roast the beans, and mix them to produce a taste profile that is consistent from year to year.  Because of the variations in the crop the contents of the blend will vary as they adjust to get back to the taste they are looking for.

Another technique is to roast darker.   With lighter roasts, the individual flavors of the beans are more vivid (for better or worse), but as the roasts darken the taste of the roast level itself becomes stronger and that of the beans weaker.  By roasting darker coffee producers can achieve a more consistent taste.  This is one of the reasons that Starbucks coffees tend to all taste the same, even when they're from different origins.

I buy my coffee beans (usually green, but he does offer a limited amount of roasted coffee) from Tom at Sweet Maria's.  He does blind taste testing of coffees and only caries the ones that meet with his high standards, I've never bought anything from him I didn't like.  I give the same advice to others that I took myself six years ago or so; find a shop, roaster, or someone else whose taste you agree with and trust, ask questions and let them know what you like and don't like.  They'll be able to help you better, and you'll get a better idea of what you like and don't like.

Brew Well

All of the above is for naught if you don't have a brewer that can deliver the goods.  The important factors are temperature, time, and water quality.  The water needs to be high quality but not distilled, it needs to be close to but not at or above boiling, and it can't hang around in the grounds too long.

• If your water temperature is too low, the water is distilled, or it moves through the grounds too fast, you won't extract all the great flavors and you should expect a flat, bland cup.
• If the temperature is too high or the water moves through the grounds too slow you will over-extract and get a lot of the bitter and nasty flavors from the coffee.
• If the water quality is low, you'll have a bunch of tastes that will interfere with the coffee, never in a good way.

My personal favorite way to brew is the one I use at home, the Cona Vacuum Brewer.  No filter (which can add a papery taste to coffee), the temperature is self-regulating, and it just plain looks cool.  At work I have a brewer more suitable for a small office, the Solis Master 5000 Digital.  Only had it a few months but we've already made over 1200 coffees with it (it keeps track).

Finally, don't let the brewed coffee sit on a burner and continue to cook.  Better to put it in a thermal insulated container and let it cool (slowly).

RSS vs. The Web

I spent some time tonight fighting CityDesk a bit to get it to do what I wanted.  I more or less expected that this would happen, and I haven't made up my mind yet on whether or not that makes it a deal-breaker.  I'm leaning towards no, simply because one of my initial reservations about the program was that it introduced its own new scripting language.  That means on one hand they can optimize it for the task at hand (making the language crafted for the use), but on the other hand they're going to have the growing pains that every new language has, and users are of course going to try to push for it to be more and more general purpose.  I knew what I was getting into, and I fully expect the language capabilities to expand from version to version or for the Fog Creek guys to punt and take a different approach (unlikely after a version 2.0).

So as I worked to get cool menus, add categories, and reorganized the templates to create a set of 'include' files to minimize redundant code, it struck me that of all the work I was doing, only the category stuff might be visible to anyone who subscribed to the RSS feed (I know there's at least one of you out there, probably only one).  This was fueled also by my thoughts around whether I should include entire articles in my RSS feed or only the teasers that I have now.

This is not my debate alone, the basic question is, is an RSS feed a replacement for the website or an entry point to it?  Should I optimize for making the RSS feed the best I possibly can, or put my work into the website itself instead?

A prime example of this for me is the article I wrote on CSS recently.  The whole point is to show CSS content that either would not show up in an RSS reader or potentially should not, depending on your opinion of how they should operate.  Should I really be sending full HTML content over the RSS feed for my entire page?  If you start to say yes, try subscribing to Chris Brumme's feed someday and suck down 11,000 word entries as single blog entries.  That's not including the security implications of rendering some random feed's HTML with script, ActiveX controls, etc.  Brrrrr.

Personally, I'm leaning towards the RSS as an advertisement model, and a tool for people who may not be interested enough in what I have to say to browse my website, but might come read if they knew there was something new.  There's also the fundamental difference between the pull and the push model, with RSS as a pull (you can determine who you subscribe to, how often you care to notice they've made entries, and you can take or leave it at any time) and email as a push (mailing lists, etc.).

There are plenty of things, like this website, which make absolutely no sense as a push model and tons of sense as a pull model, so my goal with the RSS is to make it easy for people to find out when I've updated and decide whether or not they care.  With that in mind I'll try to make the teasers better, the format I add better, and respond to feedback.