We've had several internal discussions about how we should allow our customers to extend and customize their data.  We considered a lot of different options and thought about a lot of the tradeoffs that need to be made for each approach.  It's because of this that I'm very interested in people's opinions, and as such would like to direct you to Jeremy Miller's "How do you extend and customize a database" post.  Please go and drop him a comment describing what approach has worked best for you so that we can all learn from your experiences! :)

I'm sure you all know about RESTful web services by now, but what about RESTful databases?  Gary Bernhardt's "wildly ambitious database project" currently named RESTDB is "a database server and client implemented as a RESTful HTTP service in Python".

This past week, while working on a couple updates to some existing code I had to update the corresponding unit tests to ensure the stuff I added didn't cause massive problems.  As I started exploring the unit tests for the existing functionality my head started to spin.  Either I was going nuts, or the tests were less than ideal.  After examining the code for a little while I started to see why my brain wasn't working so well when it came to examining this particular chunk of code.  While the tests were testing the functionlality that they needed to, they weren't nearly as readable as they could have been.  Some of this is a result of attempting to reduce the amount of duplication within the test class.  You see, several things needed to assert the same things, so they were seperated out into a method that you could pass some stuff to, and it would magically assert everything that you could ever want asserted upon the so said "stuff".  While nice in concept, it led to code that was very hard to follow.  In order to see what an individual test was doing I needed to jump around to 3 or 4 methods that contained the asserts.  Once I finally tracked down the asserts that were being used I was able to see what was expected.  It just so happens that I could also see that we were testing the same thing 3 or 4 different times in an individual test.  For good measure, we also appeared to test the same exact logic in multiple tests!  All of this has led me to the following conclusions:

• You should prefer readability over well factored code for unit tests.  If you need to jump all around to figure out what you're testing something's wrong.  If duplication helps with readability, duplicate away!
  
• Make sure your unit tests are only testing one thing. 
  
• Make sure you don't re-test the same thing over and over and over again.  Taken with the above point, you should begin to see that you shouldn't have that many tests that need to assert the same thing, if you do, you probably have multiple tests testing the same thing.
• Only tests one class per unit test class.  If you're testing ClassA and it leverages logic within ClassB and ClassC, don't test ClassB and ClassC's logic within your test for ClassA.  Create seperate classes for ClassB and ClassC.  Trying to test them all in one place will lead to unit tests that are too hard to read and doing too much.  This is particularly hard to keep in mind since often times as part of the process of doing test driven development ClassB and ClassC might be created.  It's tempting to leave the existing tests that test the logic that used to be in ClassA but has since been moved to ClassB and ClassC within ClassA's tests.  Don't do it, move the tests to the suite of tests that you're creating for ClassB and ClassC.  You'll thank yourself when you come back to change that logic, since it will be where you expect, rather than in a test class for a related class.

I've gotten distracted by Lilo and Stitch so I'm going to stop with my conclusions there, and go play some indoor basketball with my son who is throwing a basketball all over our house. :)

[Disclaimer: It should be noted that I'm pretty sure the code I was looking at was code I wrote...whoops :(]

One of my favorite classes in college was Photography. I enjoyed learning about how to operate an old 35mm manual camera, as well as learning about the various factors that go into controlling how the "scene" you've framed in the viewfinder becomes a photograph.  While I don't get to "shoot" much, I do enjoy the opportunity when it arises. 

I've recently been looking into the various photo sharing sites that are out there.  Everyone knows Flickr, but some not so known alternatives have caught my eye as well...most notably Zooomr and SmugMug.  I haven't done an in depth evaluation of the three services I'm considering thus far, but I've explored them enough to know what I do and don't like about each. This post is an attempt to get me closer to figuring out which one I want to go with.

Flickr
Flickr has a ton of users, and as such a very strong community.  I'm a big fan of their interestingness feature, and more so FlickrLeech which allows you to see all the interesting photos in one page without having to page endlessly.  There has been a lot of noise made lately about the various changes that are going on as Yahoo tries to integrate Flickr into their other web properties and vice versa.  While there are advantages to having someone as big as Yahoo behind you, it also can be a drawback.  I wonder if Flickr still has the passion and innovation it had when it first started. As I've explored some of the other sites I've felt like they were more innovative and forward thinking in their approach.  At $25/year for a Pro account their pricing seems very reasonable.  For more details on what that $25/year gets you checkout the Flickr upgrade page.

SmugMug
Ironically, what drew me to SmugMug wasn't their kick ass product, but their CEO/Chief Geek Don MacAskill who has blogged some interesting details about how they're using Amazon S3 to save lots of money.  In addition to having a very interesting CEO who blogs about cool technology, SmugMug also happens to have the nicest interface I've seen thus far for browsing photos.  They recently released an update that is flowing with magical Ajax love, which results in a very nice photo browsing experience.

In addition to having a killer product, SmugMug also is right up my alley as far as companies.  From what I've read, we share many of the same philosophies on how to run a business. Additionally, I like their company story.

SmugMug is slightly more expensive than Flickr at $39.99/year.  To get the scoop on what they include checkout the details on their website.

Zooomr
I was introduced to Zooomr through Scoble's Photowalking series with Thomas Hawk.  Zooomr has some unique features that I haven't seen in other photo sharing sites.  One of the more interesting features is portals, which let you link photos together and provide interesting ways to navigate between the linked photos.  Zooomr is/was (?) also giving away free Pro accounts to bloggers, which is actually why I have that photo at the top of this post.  Zooomr has some nice Ajaxy photo viewing features, that while not as nice as SmugMug's are towards the top of my list.  I'm hoping that some of the things I've wanted from their interface will be coming in Mark III, which is supposed to drop in early March.

I've never been able to find out what a Pro account costs on Zooomr.  Perhaps they just give all their accounts away to bloggers and don't change a thing? :)

Anyway that's about it for my very unofficial run down of the sites I'm considering.  Let me know if you have any recommendations.

Let's face it, .NET is meant to rule the world. :)  With that out of the way let's get onto business.  Will someone from Apple please talk to the folks that run the engineering team and get them to dedicate some peeps to work on Cocoa#, or perhaps something completely Apple'ish such as iDotNet.  While Mono has made some great strides on the Linux and Windows sides of the world, it's still severely lacking when it comes to the Mac.  More specifically, Mac GUI's.  As Uncle Mac points out, running GUI applications on the Mac simply doesn't feel right.  Everything is very polished on a Mac, and X11 apps just aren't cutting it.  Since I'm asking for things I want that I have more or less no shot of getting, I might as well add this onto my list right?

I'm with Mike, C# 3.0 needs the Visual Basic 9 XML Syntax.  Maybe "needs" is a strong word, since the functional construction model used for building XML with LINQ to XML is head and shoulders above what we have available in today's XML API's, but it sure would be nice!  Since the VB guys already have it done it should be a piece of cake to move over.  Those Microsoft guys have mad skills, I expect it to be in the next CTP! :)

I'm a big fan of books.  I love reading about technology and business.  An amazing amout of knowledge can be gained from a good book.  Whether it be how to program in a new language, or how to run a company, books provide an amazing amount of information and experience. 

A while back, after being asked by a colleague for a list of books I recommend, I put together my list of Recommended Reading. A few months ago, I started migrating my recommendations over to an aStore on Amazon.  While I still don't have everything added, I figured I'd share my store in hopes that someone might find a book or two interesting, which in turn might lead to me getting one of the many books on my wish list for a discounted price (since my aStore earns me money, and oh how very much money it is!) 

Anyway, have a look at my list of Recommended Books and let me know if you think I'm missing any!

One of the things that draws me to Ruby on Rails is the passion that I see from those who use it day in and day out.  Ryan McMinn from Unspace, falls squarely in the passionate for Rails camp. He recently gave a short talk about the approach that Unspace uses to build software.  They don't do specs, they don't do contracts, and they don't "conform".

With all the talk of being Agile, one has to wonder if anyone cares about shipping.  We focus a lot on the methodologies and practices that go into creating software, but we don't talk all that much about shipping.  Software doesn't exist until it's shipped.  No money is made from a great piece of software that isn't available.  No money is made from having a really kick ass Agile process if you don't ship.  It's not all about money, but without money we don't get to "play another game of pinball".  As Sam reminded me today, it's all about getting that next game.  It's all about shipping.

Those of us living in the world of software need to remember why we're in this business.  It's not about process, it's not about methodology, it's not about how Agile you are. It's about creating kick ass software that users love.  Users can't fall in love with something that isn't shipped.

In this day and age Agile seems to be where it's at.  If you're Agile, you're good.  If you're Agile, you have no bugs.  If you're Agile, you respond quickly to change.  If you're Agile, you'll build what your customer wants. 

It's easy to say you're Agile.  It's even easy to think you're Agile.  I wonder though, are you really Agile?  Are we Agile?  Am I Agile?  What does it even mean to "be Agile"?  Is it even possible?

What does it take?  Do you have what it takes?

Over the last several months I've grown to have an amazing amount of respect for people who write technical books.  It's an amazingly time consuming process that involves a lot of staring at the screen wondering what the heck to write next.  There are an infinite number of ways to phrase every sentence, and your choice has a huge impact on whether or not the reader will get what you're trying to say.  On top of that, for me, writing is nowhere near as interesting as actually using the technology you're writing about.  I can't tell you how many times I've wished I could get the heck out of Word and into Visual Studio.  Layer on top a busy work and family life and you have something that I've found amazingly difficult.  Since I have a full time gig I have to write in the evenings and weekends.  With a wife and two young kids I'm not exactly oozing with tons of free time.  Writing is amazingly difficult. 

Rather than end this post and leave it as a paragraph of me complaining about how hard I'm finding writing, let me leave you with some tips that I've found to help in the writing process.

• Find someplace quite to work.  Unlike programming (and other tasks) where a little bit of background noise and/or music can be beneficial, writing needs quite and needs thought.  Find someplace you can think.  Don't try and get a little bit of writing done while you try and do something else (such as watch after the kiddos).
• Start with an outline of what your going to write.  Include the key goals that you have for each section and make sure you address each goal before you finish the section, or chapter.
• With your first draft don't worry about how terrible things sounds, how rough around the edges your points and/or description are, and how utterly crappy things flow.  Get your thoughts on paper.  Once you get everything out, go back and revise mercilessly until things sounds the way you want.
• Always think about the reader.  How will they expect to consume the information you're presenting?  What will they arleady know? What might they need to be reminded of?  How can you leverage what they know to help them learn what you're writing about?
• Don't be boring.  This might sounds obvious but I've found it very hard to present everything you want the reader to learn without having things turn into an unending flow of technical details, which results in boredom.  It's important to remember the reader needs breaks, encouragement, and direction.  And they also need to not be bored.
• Instead of writing blog posts about how hard writing is and then spewing off a bunch of writing tips (as if you have any clue what you're talking about) stay focused on your book and the deadlines you have....doh! :)
  

I'm a big believer in Domain Driven Design (DDD).  I have to admit that I've lost a little focus of late, so I think I need to get back to the basics.  As such, I've just printed out a bunch of experience reports from the Domain Driven Design website.  As with anything, DDD takes practice. What better way to get a jump start than by reading about how someone else has used DDD to create better software?

Over on the XML Team's blog, Avner outlines some VB 9.0 XML changes that will be showing up in the February CTP.   As I've mentioned in the past VB 9's XML features are very compelling, so much so that they have me wanting to write code in VB which I haven't done since I started working with .NET.  The major changes in the February CTP include:

• Attribute axis property is string
• Global Xml namespace syntax has changed
• Added auto-completion
• Xml names are VB symbols
• Improved error handling

For the full details checkout Avner's VB 9.0 Xml in Visual Studio "Orcas" February CTP post.