Searching for my lost shaker of salt

http://www.red-gate.com/products/SQL_Prompt/index.htm

http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=388

This is a wonderful interview with the CTO of Amazon.com that I'd recommend for every developer, architect, or IT manager.  A lot of interesting perspectives on architecture, the driving of requirements, development paradigms, and general developer nerdiness.  There are a couple of items I found particularly interesting:

• "No direct database access is allowed from outside the service, and there's no data sharing among the services."  I've long held that the best way to design and scale an application is to break it down into its composite function points, or aspects, then isolate the heck out of it from the rest of the application.  It must stand on its own and all interfaces must go through this interface.  But I've never implemented something that strict, mainly for performance reasons; is it realistic to not use a simple SELECT statement for read-only data?  Then again, Amazon.com may have a few more servers, high end switches, and other mojo that can make this happen above and beyond us mere mortals.
• "...in your thought process, you start with the customer and work your way backwards until you've found the simple and minimal technology that you need to satisfy..."  Big giant duh!  Glad its more than just me saying this, as I've long held the best way to build requirements is begin at the end; what do you want OUT of your system.  This is true no matter what size organization you serve.  I feel so vindicated!
• "You need a strong sense of ownership..."  If a developer doesn't own the code, the process, or the responsibility for the outcomes, where is the motivation to go above and beyond?  Worse yet, have one team start development, another pick up at some point, pass off to yet another developer, and so forth.  Coding in isolation is boring as anything, and inheriting someone else's code isn't much fun either.  Real quality comes from having the same folks end the project they started, with minimal interruptions, and a process that lets them explore, not regurgitate requirements.  But that's just me...

My ranting aside, this is a great read...

http://sourceforge.net/projects/filezilla/

I'm very impressed by this open source project.  Connection management is simple and straightforward, as is transfers, queuing, and status information.  You get a lot of status information, which is great for troubleshooting.  Congratz to this team for designing and executing a great app!