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.

If you haven't yet, you will...it's just a matter of time. :)  When you do, Getting good with Google Reader is a very valuable overview of the key keyboard shortcuts that you'll need to make the most of Google Reader.  As with most peeps, these are my keys:

j - next
p - previous
v - view in window
ga - All Items
SHIFT-n - next folder
SHIFT-o - open folder

I'll definitely be trying to get used to some of the others outlined in the aforementioned article as well.  The gu keyboard shortcut is definitely the snazziest that I didn't know about.  I think Reader is the most Ajax-irific app I've used thus far, how 'bout you?

Harry Pierson has an interesting post that outlines how he learned to stop worrying and love WCF. In the post, Harry talks about the concerns that he's had regarding the lack of support for long running services in Indigo, and then discusses how a talk with Shy Cohen helped clarify some of the misunderstandings that he had. The primary of which, is that WCF's solution to long running services is Duplex Channel. In fact, Shy confirmed Harry's feelings that WCF doesn't have a real answer to long running services in v1.0.

I found the post particularly interesting since we've been talking about how best to support long running services within our application. One option that we've considered is Duplex Channels, however, we've had some concerns with whether or not the Security folks at our clients would be ok with us opening up a callback channel from the desktops running our software. At any rate I'm interested in what others think would be the "Reese's Peanut Butter Cup of service messaging". Harry's would be "something that has the programming semantics of SSB and the interoperability of WCF". And you?

As someone who spends most of his time in VS.NET I often times desire a nice lightweight text editor. While VS.NET is very powerful, it also tends to fall over when you have a solution with a reasonable number of projects. As I read about Rails, one of the things I often hear is how much people like working with TextMate. Apparently it's a pretty kick ass text editor. It's one "flaw" is that its an OS X only application. I heard a rumor (I don't remember what blog) that the folks over at Intype are creating a Windows text editor that's inspired by TextMate. If it lives up to the hype, it could replace Notepad2 as my preferred text editor in Windows.

DomXml has a nice post that breaks down consulting rates in the IT industry. Prior to joining my current company I worked at a consulting company. During my time there I learned a lot about how consulting companies work. In general, as Don points out, they try and get "more affordable" consultants and employees so that the markup that they receive is higher. I must say that the place I worked was probably much much better than most, however, I was often amazed at the rates that we'd end up charging clients knowing who was going to be working on the projects. For some reason everyone always seem to think that having cheaper, more inexperienced, developers is the way to go since they result in higher margins. While in theory that sounds reasonable it always seemed very shortsighted in my mind. Sure you pay less for a more inexperienced developer, but it also takes that inexperienced developer longer to get things done. Often times much longer. The solution developed is also more likely to be "sub-optimal". What often happens in these situations is the senior developers end up cleaning things up, and making sure "shit" doesn't get shipped.

It's my opinion that having a small, experienced team is the way to go. Unfortunately, in the consulting world this often doesn't work. The way consulting companies make money is by increasing head count. As you increase head count it becomes more and more difficult to find good people. As you hire more and more people, who are no longer as good as you probably would like, you end up putting yourself in situations that are destined for failure. I think most people realize that it's important to hire great people but everyone seems to fall into similar traps. All the sudden a big project falls in your lap. Since you don't have the resources to staff it, you hire a bunch of people. Since you need your resources quick, you drop your quality bar and hire whoever you can. Since you've hired more people, you start making more money. You chase more money, and hire more people. Eventually you have a bunch of people, most of which you have no clue if are any good. You do Ok, ship some stuff and have decent success. You get blinded and all the sudden make the same mistake you originally made and hire more people. Afterall, more people means more money. The majority of big consulting companies have a large pool of resources who are inexperienced, inefficient, yet quite good at making your projects going longer than you'd like. It just so happens that longer projects means more money, and potentially more people. We all know what more people means don't we?

Anyway, I've gone off on a bit of a tangent that I didn't intend. The original point of this post was supposed to be to remember that you get what you pay for. While it might seem strange to pay twice as much for something, whether it be a consultant, a product, or a bag of groceries, you most often times get what you pay for. Or do you?