There has been a lot of talk about LINQ as well as LINQ to SQL.  People seem to be genuinely interested in what they're going to offer.  LINQ to XML on the other hand doesn't seem to be getting much love.  I for one think it deserves it.  In the coming weeks I'm going to start a marketing campaign for LINQ to XML that will aim to convince you that LINQ to XML deserves some love as well.  Before getting started, let me ask the question, why aren't you giving LINQ to XML any love? 

I had a jolly good fun time tonight updating my code samples to the March CTP of Orcas.  Well, actually, I'm not quite finished as of yet because of the wonderful error in the title of this post.  It appears VS.NET Orcas doesn't want to let me recreate my data connection for my database that I'm using for some LINQ to SQL examples. Woot!  Hopefully I'll figure out what the dealy is shortly because I've got chapters I need to finish. :)

Simple, use the acts_as_enterprisey plugin!  It doesn't get any easier than that does it?

Let’s face it, we all want the big bucks. And we all know Consultancy Law No. 1:

    Your Rates Are Proportional To Your App's Enterpriseyness

Or, as Shakespeare would have said:

    Enterprisey Apps Invite, Nay Demand, Enterprisey Rates.  Verily, Sunshine.

Rails make life easy for us but — and it’s a big but — we don’t want it to look easy. acts_as_enterprisey is your friend.

How does acts_as_enterprisey make webapp development look hard? Well, the only way your client can judge your app is by playing around with it. What better gives the feeling of heavy weights being lifted behind the scenes than slow response times? Exactly. That’s what acts_as_enterprisey does.

So while your client clicks, …waits…, and then gets the page, you can blather on heroically about wrestling with clustered indexes, cache expiration strategies, n log n seek times, etc ad nauseam.

http://agilewebdevelopment.com/plugins/acts_as_enterprisey

On a more serious note, the http://agilewebdevelopment.com/ site has a lot of good information on Rails plugins.

Aaron just recently mentioned this TextMate screencast that shows how you can use TextMate as a blog editor via the Blogging Bundler. This is an attempt to see if it actually works! :)

As you may have noticed, I spend my mornings and evenings going to and from work on a train.  I usually use this time to read, unless I have a pounding headache in which case I stare out into space until I hear the call for my stop.  Anywho, I recently finished Everyday Scripting with Ruby: For Teams, Testers, and You by Brian Marick. 

A while back when I was learning about Ruby on Rails Migrations I got a chance to learn a bit of Ruby.  This was mostly due to the fact that the SQL Server adapters for Rails Migrations wasn't exactly up to snuff, and in order to get a proof of concept going Aaron and I needed to write some Ruby code.  The experience gave me a pretty good understanding of Ruby as a language. 

Fast forward a year, and all the sudden there I am forgetting everything that I learned.  That is...until Everyday Scripting with Ruby.  Brian has put together a really nice introduction to the Ruby language that should be approachable for programmers, testers, and anyone else who likes to dabble in scripting.  I don't think I fit exactly within the target audience, but I still found the book a worthwhile read and would recommend it to anyone who would like to learn Ruby.  Along with Programming Ruby you should have all you need to master the Ruby language.  Brian does a good job introducing the Ruby language, as well as offering valuable insight into his world and how he goes about writing scripts.

In summary, Everyday Scripting with Ruby is a great edition to your bookshelf if your interested in learning Ruby.  Those with many years of experience in the industry will likely find parts of it "skippable" or "skimmable", but no matter how much experience you have your bound to find a couple nuggets of wisdom that make it worth the twenty (or so) bucks you'll plop down for it.

I'm not sure what's up next but I just made a mass purchase of books from Amazon.  One of the following will make it into my work "briefcase" shortly.

Anyone care to guess what I've decided about the right time for a new technology? :)

Kevin Barnes has an intersting article that talks about Why great coders get paid far too little.  My new career goal is to strive for greatness and land a $3M contract, I probably shouldn't hold me breath :)

I'm always amazed by the editable grid.  Everyone wants it, everyone loves it, why wouldn't they....it's just like Excel!  I don't know why, but I always have and always will hate the editable grid.  Grid's are good at displaying information, not editing.  Checkout Chris Stevenson post, "The Editable Grid Antipattern" for reasons why you should always ask 5 why's when someone asks for an editable grid.  Here's to hoping I never see another one in the UI designs for the apps I work on! :)

Over the last couple of weeks I've been reading Naked Conversations on my train ride to and from work (when I didn't have other things, such as RESTful Rails Development :))  For those of you unfamiliar, Naked Conversations was written by some guy who claims to be some big named blogger.  His pen name is "Robert Scoble".  Scoble's co-author is Shel Israel. 

The two have put together a great book on the business of blogging.  They talk about what does and doesn't work, as well as talk in depth about many of the concerns people have with blogging within corporations.  Throughout the book Scoble and Israel provide examples of those who have done it right, and those that have not.

Naked Conversations encourages companies to use blogs to be more transparent, to engage customers in conversations, and to listen.  While there are a handful of comapnies that seem to "get" blogging, there are countless others who haven't a clue.  As blogs become more and more mainstream we're bound to see the way they're used within corporations change dramatically.  I'm sure we'll see people try and fail, as well as people try and succeed.  We'll also see others who build their entire business with nothing more than a blog.

Sam is getting to have all the fun at work exploring Windows Workflow :(  It looks like he's making some good progress so perhaps I'll get a chance to experiment some in the near future as we look to find ways to incorporate it into our application. 

While I've done very little real work with Windows Workflow I have read Essential Windows Workflow Foundation and Presenting Windows Workflow Foundation to give me a good background for what it includes.  I certainly see a lot of potential uses for workflow within our application so now it's just a matter of figuring out how to incorporate it into our architecture and frameworks.  Since it doesn't exactly plugin right out of the box, we have a good amount of work ahead of us.  As I said in my "The the right time for a new technology" post, I'm about ready for something new anyway so it should be fun!

While installing Rails and friends using something like MacPorts may prove to be a little less time consuming and less error prone, I think installing from source is the way to go.  Dan Benjamin, over on Hivelogic, has an excellent tutorial that steps you through all the steps to pull down and compile the source for Ruby, Rails, MySQL, Subversion, and Mongrel.  Over the last couple hours, in between a bunch of other things I've been doing, I walked through Dan's install guide and I'm happy to report everything went very smooth!  If you do decide to go the MacPorts route, I've been told, that James Duncan Davidson's tutorial is where to go.

In addition to being reminded that readability is more important than "clean well factored code" in unit tests, I've also recently been reminded how wonderful small, focused classes can be.  As designs evolve, classes tend to grow.  If you don't keep a close eye, they can grow out of control and take on way too many responsibilities.  As classes grow, they become harder and harder to manage.  All the sudden, it becomes harder to find things, and harder to figure out what the code is intended to accomplish.  By breaking classes apart into small, focused classes it's much easier to understand the things that each class is responsible for.  Rather than taking on a handful of different responsibilities, your classes should have a single responsibility. This will help keep them focused on doing one thing, and doing it well. 

On the train ride to and from work today I read RESTful Rails Development.  I've already done a fair bit of reading on REST and I've worked with several RESTful APIs lately (Amazon, Flickr), however, I found the RESTful Rails Development article a good introduction to what is at the heart of REST API's.  Namely, the idea of resources, and more specifically URI addressable resources.  The support for REST within Rails 1.2 adds a lot of nice features, and looks like a great way to support multiple output formats (html, xml, javascript, rss/atom, etc.) for applications that are oriented around resources.  Anyway, if your interested in REST or Rails, it's worth a read.

I've been thinking recently that I need to learn something new. Whether it be a new technology on the .NET side of the house, or a new language, or a new web framework. I'm not sure what, but, I definitely feel like I need something new that will cause me to stretch my mind a bit.

I've had the itch to dive into WPF for a while, but don't have a whole lot of time at the moment to do anything on that front.  While I do have several ideas for little WPF apps I'd like to see built for myself I have concerns it'd be a wasted effort since my design/UI skills have diminished over the years, and what sense is building a WPF app if you can make it look slick as all get out? 

I've also been thinking a bit about trying my hand with a new language.  The top contenders would be Ruby, via Rails, or Python (with IronPython).  I'm leaning more towards the Ruby/Rails track since it would involve me stepping almost completely out of my comfort zone. 

I have a few things on my plate that I could choose to do using non .NET technologies.  Of course the problem is that I could undoubtedly do them much faster using my bread and butter technologies.  The benefit of the .NET appraoch would be that I could get more things done and perhaps have extra spending money due to being able to do more of the little projects I've been asked by peeps to lend a hand on.  The downside is that I'd still feel like I need to learn something new, and stretch my brain a bit.  I've run into this same scenario many many times in the past, and always went with the approach that would get things done the fastest since I never seem to have enough time available for anything else.  The problem, of course, is one of the main reasons for doing little side projects outside of work is to stretch yourself in ways that you might not be able to otherwise.

When confronted with such dilema's how do you choose?  Do you go safe, and stick with what you know, or do go with the more difficult, and potentially more rewarding path of trying something completely new?

I'm sure Linux users across the world are going crazy about the fact that they can now run Visual Basic .NET, courtesy of Mono!  Or not.

In all seriousness, it is pretty cool that the folks on the Mono project have added support for Visual Basic.  I wonder how good the WinForms story is these days on Linux.  I know the last time I checked it out for the Mac, it wasn't a pretty picture.