Thursday, August 16, 2007
I just registered for Ruby East, which is being hosted by Chariot Solutions a hop, skip, and jump from my house!  Hopefully it will be a good time!  They appear to have a number of good speakers lined up to talk about some interesting topics.

 | 
Friday, August 17, 2007 12:30:26 AM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Saturday, August 11, 2007
Not sure why, but after months and months of hearing people talk about Twitter, I decided to create an account.  Considering I've been averaging a whopping 7 posts for the last couple months on this here blog, perhaps the intrigue of not having to write anything of value is what's sucked me in?

http://twitter.com/steveeichert

Saturday, August 11, 2007 4:53:35 PM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Wednesday, August 08, 2007
A couple days ago I posted about a nice video on InfoQ of Fred George talking about Appling Agile to Ruby.  The video on InfoQ was my first exposure to Fred, however, I recently came across his blog (via Jeremy and the ThoughtWorks feed).  Fred has a bunch of great content, such as:
And some choice quotes:
Agile succeeds when you write code that is easy to change. The Secret Assumption of Agile

Okay, so it may not be true that all programmers are equal. But it is it approximately right? In my experience (many, many years)
on real projects with real delivery deadlines, there is an order of magnitude difference between programmers (that is, 10x difference). Even after throwing out the incompetent programmers (who produce zero), the really good programmers are ten times better than the really mediocre programmers. So even in approximate terms, all programmers are not equal. - All Programmers are NOT Created Equal (People Topic)

Thursday, August 09, 2007 2:45:42 AM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Saturday, August 04, 2007
Keeping with their trend of publishing great Ruby content, InfoQ recently published a video of Fred George from Thoughtworks, talking about "Applying Agile to Ruby".  In his talk, Fred talks about how important many of the core agile practices are when working in Ruby.  Since Ruby is a dynamic language and doesn't offer some of the "safeguards" that statically typed languages provide, agile practices such as test driven development (TDD), continuous integration, and simple design become even more important.  Fred closes his talk with the following statement: "I wouldn't work on Ruby without Agile".  I wonder if he'd work on C# or Java without Agile.

Sunday, August 05, 2007 2:34:03 AM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Thursday, August 02, 2007
While working on our LINQ book I've come to really enjoy LINQ to XML. I've worked with a lot of XML API's over the years, however, the LINQ to XML API is my favorite...by far. In addition to providing all the nice query facilities made available by LINQ, it also provides a lot of other great features that many people overlook. As I promised long ago, I'm going to begin to talk about the things that I enjoy about LINQ to XML in hopes that it will help you realize that the red headed step child of LINQ has some things to offer the world as well. :)

One of the most common things that we need to do when dealing with XML is transform it. We're usually transforming it into an alternate XML format, or transforming the XML into a set of objects. In this post I'm going to quickly look at some of the transformation capabilities offered by LINQ to XML. To help us get started I'm going to use the following XML which is the XML representation of a contact in Highrise.

<?xml version="1.0" encoding="UTF-8"?>
<person>
  <author-id type="integer">1436</author-id>
  <background/>
  <company-id type="integer">1226900</company-id>
  <created-at type="datetime">2007-06-09T03:13:15Z</created-at>
  <first-name>Steve</first-name>
  <group-id type="integer"/>
  <id type="integer">1226899</id>
  <last-name>Eichert</last-name>
  <owner-id type="integer"/>
  <title/>
  <updated-at type="datetime">2007-06-09T03:15:16Z</updated-at>
  <visible-to>Everyone</visible-to>
  <contact-data>
    <email-addresses type="array">
      <email-address>
        <address>steve.eichert at google mail dot com</address>
        <id type="integer">559722</id>
        <location>Work</location>
      </email-address>
    </email-addresses>
    <web-addresses type="array">
      <web-address>
        <id type="integer">942962</id>
        <location>Work</location>
        <url>http://iqueryable.com/</url>
      </web-address>
    </web-addresses>
  </contact-data>
</person>

Rather than be stuck with our contact in XML, let's see what we can do to transform the above XML into the hCard microformat. We're going to ignore a bunch of data, such as all the ids, since it doesn't have any meaning outside of Highrise. When we're done we'll end up with the much simplified XML shown below:

<div class="vcard">
  <div class="fn">Steve Eichert</div>
  <div>Email: <span class="email">steve.eichert at google mail dot com</span></div>
  <a class="url" href="http://iqueryable.com/">http://iqueryable.com/</a>
</div>

The first step for transforming our Highrise XML into the hCard microformat is to load the Highrise XML into an XElement.

XElement highriseRoot = XElement.Load("highrise-contact.xml");

We use the static Load method of XElement to load the XML contained within the "highrise-contact.xml" file that we've saved locally. I don't believe the Highrise API is officially supported at the moment so I'm not going to load the contact details directly from the highrisehq.com site. Perhaps, in a future post we can explore that as an option.

Anywho, once our XML is loaded into an XElement, we can transform our Highrise XML into the hCard microformat by building a new XElement. We'll use the Element query axis method to retrieve the first and last name of the contact, and we'll embed query expressions and make use of the Descendants query axis method for selecting all the email and web addresses for the contact within the source XML. When we put it all together we end up with the C# code below:

XElement highriseRoot = XElement.Load("highrise-contact.xml");

XElement hCard =
    new XElement("div",
        new XAttribute("class", "vcard"),
        new XElement("div",
            new XAttribute("class", "fn"),
            highriseRoot.Element("first-name") + " " + highriseRoot.Element("last-name")
        ),
        from emailElement in highriseRoot.Descendants("email-address")
        select new XElement("div",
            "Email:",
            new XElement("span",
                new XAttribute("class", "email"),
                (string) emailElement.Element("address")
            )
        ),
        from webElement in highriseRoot.Descendants("web-address")
        select
        new XElement("a",
            new XAttribute("class", "url"),
            new XAttribute("href", (string) webElement.Element("url")),
            (string) webElement.Element("url")
        )
    );

Console.WriteLine(hCard);

At first glance, the above code might be overwhelming. However, once you come to understand the power of functional construction you'll quickly realize how wonderful LINQ to XML can be for transforming XML to alternate XML formats. In addition to making it easy to transform XML into alternate XML formats, LINQ to XML also makes it very easy to transform XML into objects. If we have a Contact class defined as:

public class Contact {
    public string Name { get; set; }
    public IEnumerable<string> EmailAddresses { get; set; }
    public IEnumerable<string> Urls { get; set; }
}

We can transform the contact details in our XML into a Contact instance with the following code:

Contact contact = new Contact {
    Name = (string) highriseRoot.Element("first-name") + " " + (string) highriseRoot.Element("last-name"),
    EmailAddresses = highriseRoot.Descendants("email-address").Select(e => (string)e.Element("address")),
    Urls = highriseRoot.Descendants("web-address").Select(e => (string)e.Element("url"))
};

After looking back at the sample here I wish I had chosen an XML fragment with a little more hierarchy, however it's much too late for that now. Hopefully, the code included in this post gives you a small taste of the types of XML transformations possible with LINQ to XML. As you begin to work with LINQ to XML, you'll find that functional construction, combined with query axis methods, and query expressions provide a tremendous amount of flexibility for transforming XML. Additionally, the new object initializer syntax and LINQ to XML's ability to easily construct objects from XML makes it very easy to create objects from XML. I've attached a zip file with the code above to this post. (VS2008 Beta 2 Required) LINQtoXMLTransformSample.zip (23.69 KB)

Friday, August 03, 2007 3:20:02 AM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Saturday, July 28, 2007
James Avery poses an interesting question in his "How long before ALT.NET becomes NOT.NET?" post.  I'm not really sure what it takes to get into the ALT.NET club, but from what I know I'm guessing I'd fit into the general "demographic".  Like James, I've also been wondering if and when more of the ALT.NET'ters will turn to Ruby on Rails (or alternates like Django).  I've thought about this a bit more lately since I've been spending a lot more time in Ruby and Rails.  In addition to wondering about other ALT.NET peeps, I've also thought a bit about where I want to go with my development efforts and whether I want to continue to focus on .NET as my primary means of making a living. At this point I don't see myself doing anything drastic.  Considering I only have 2 Rails projects under my belt and a heck of a lot more to learn about Ruby as well as Rails I think that's a pretty wise course to take.  I am going to continue on my path to learning Ruby as best I can, afterall it is my language for 2007.  I'm also going to continue to do projects with Rails, try and write a lot more Ruby and Rails related code from scratch (plugins make life way too easy), and evaluate if there is anything I've learned from Ruby and Rails that I can bring over into my .NET related work.  I'm also going to be keeping a close eye on IronRuby, and anxiously awaiting the day when they announce they can run Rails on top of it! 

At the end of the day, I believe learning Ruby, Rails, as well as many of the other things I'm looking into, will make me a better developer.  Whether or not I end up building the software I work on in .NET, Ruby, or Erlang doesn't matter much.  I think we all owe it to ourselves, as well as our customers, to question whether what we're using today is the best tool for the job.  We also owe it to ourselves to question whether we'd find more enjoyment in working with other languages and tools.  After all those questions are raised and answered we still need to make a decision based on where we are in life, what we have control over, and where we want to go in the future.

Perhaps before the migration to Rails starts, Microsoft will change its ways and learn a thing or two about what it takes to make ALT.NET developers happy.  Perhaps they'll realize that designers, wizards, and other magic isn't what where it's at.  Perhaps they'll realize that baking best practices into the platform is a good thing.  Perhaps they'll have a look at TextMate and realize it doesn't have any designers, yet Rails developers love it?!?!?  Perhaps they'll learn a thing or two from the success of Rails and stop the floodgates from opening.  What do you think?


 |  |  | 
Sunday, July 29, 2007 2:45:36 AM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [4]  |  Trackback
Scott Reynolds talks about how in order to make "real progress" we need to introduce some "shocks" into our "system" to get you out of our comfort zone and into a state of self improvement and growth.  I'm not about to get up on stage and do a Beastie Boys rap, however, I do think I could use a shock or two.

Sunday, July 29, 2007 1:46:42 AM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Monday, July 16, 2007
Over the weekend I listened to the latest .NET Rocks episode with John Lam.  I'm very keen on seeing and hearing about where the IronRuby project is going, so I found the interview very informational.  Although I enjoyed the entire show, one particular exchange between Carl and John stood out.  About half way through, Carl asked John whether he thought developers who don't do test driven development (TDD) and unit testing should be working in dynamic languages.  John made the wonderful assertion that he doesn't believe programmers that are not writing "unit tests" should be writing code in any language, regardless of whether the language is dynamic or statically typed.   Following that statement, John went on to mention that whether or not the code is test driven isn't nearly as important as whether the code has unit tests since the "test driven" approach is "extreme" and "dogmatic".  While I agree that the key is unit tests, I don't agree that a test driven approach is extreme or dogmatic.  In my opinion its the most pragmatic approach to writing code that is well designed and well tested.  The fact is, writing unit tests after the fact sucks!  Especially if "after the fact" is days or weeks after the real code is written.

When I first got started with TDD I didn't really understand what it was all about.  Rather than figure out what this magical red-green-refactor thing was all about I decided I'd just write some unit tests once I had my code written.  After a couple projects using this approach I started to realize that I really hated writing unit tests after the fact.  It was because of this hatred that I got started with test driven development.

Rather than testing being a pain in the ass task that I had to do when I finished writing my "real" code, testing became an instrumental step within the process of writing the "real" code.  Since I was using tests to figure out what code needed to be written, it became a vehicle by which I could design the code I was writing, rather than an afterthought.  I'm sure there are people out there that write great tests after the fact, however, I'm not one of them.  For me writing tests first isn't something extreme or dogmatic, it simple the only way I can write high quality code with solid test coverage without going nuts.  For me, writing unit tests after the fact sucks.  For me, driving my code with tests is a joy. 

I wonder how writing tests first could be "extreme" and "dogmatic" for others, but for me its pragmatic?

   
 |  | 
Tuesday, July 17, 2007 3:58:39 AM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [18]  |  Trackback
 Wednesday, July 11, 2007
As I've stated before, my programming language for the year is Ruby.  I actually planned on learning Python or Ruby last year, but things didn't pan out.  Over the last 6-8 months I've been doing a pretty good job of getting myself on the way to learning Ruby.  As with any language the best way to learn it is to write something using it.  As we all know Rails has done a tremendous job of bringing people to Ruby.  I'm no different.  Over the last 6 months I've worked on two Rails projects and in the last week put one of them into production (well almost).  Since I'm half way through the year I wanted to put some thoughts down here, mostly for myself, but also for others who might be interested in a .NET dudes impressions of Ruby and Rails.

Before writing a book myself, I bought a good number of books on technical topics that I found interesting.  After experiencing what goes into writing a book, I find that I'm much quicker to pull the trigger on books that I think I might find interesting.  The amount of work required to get a book out the door is mind boggling to me.  As such I've purchased, and read, the following books to help me learn Ruby.
As you can see not all the books are strictly Ruby related.  Several are focused on Rails, one is focused on working with Google Maps with Rails, and one is to help me learn to work in my new favorite editor, Textmate.

In addition to reading the above, I've been checking out the source code for a couple of the more popular open source Rails applications as well as some of the more popular plugins.  While all of that has been very valuable, nothing is ever as good as actually writing code.  As such I've done several projects that I would have traditionally done in .NET in Rails instead.

The first application that I got started with (and which I'm still working on) is an application that helps geographically visualize key individuals within a social network.  The data for the individuals in the social network, as well as the data for the connections between individuals, is stored in flat files so I got my first chance to play around with the CSV parsing capabilities of Ruby.  I found the FasterCSV library very useful, and got off to a pretty good start with my first attempt at parsing the CSV files and getting them into my MySql database using my ActiveRecord model objects.  After the file parsing was done, I got a chance to build several administrative pages for the site using Rails, as well as the chance to experiment with some very useful plugins such as:
My second application involved setting up a site with paid membership.  The site has several administrative functions for the owner of the site, as well as a handful of features for those who sign up to be members such as exclusive downloads, advertising opportunities, and a members only forum.  In addition to be able to gain a lot more experience with the inner workings of Rails this project also led me to gain experience with:
So given all of the above, if your still reading, I'm guessing your wondering what I think.  In short, I'm becoming a pretty big fan of Ruby as well as Rails.  While Rails isn't perfect it does a lot of things very well.  Rails Migrations are the best solution that I've come across for migrating the schema of a database.  I can see why large teams run into some trouble with them, but for the projects I've been working on migrations have worked wonderfully.  While I'm a big fan of DDD, I also really like ActiveRecord in the right situations.  Being able to create a migration, run rake db:migrate, and have the column automatically available in my model without having to do anything makes developing with Rails and ActiveRecord very enjoyable.  Rather than dealing with the mundane tasks of writing scripts for adding columns, and then updating the associated data access and model classes, I can focus on the stuff that matters.  In addition to migrations and ActiveRecord I'm also fond of ActionMailer and the way that it allows you to create and send email, its far better than what's available in .NET land.  Next up, is the MVC structure that Rails uses for building the pages that make up the application/site.  I'm a huge fan of MVC/MVP for building UI's so it should be no surprise that I'm also a big fan of Rails implementation of MVC.  I really like having a single controller per model object, and having a nice organization to the views used by the controller.  I also really like the validation story for Rails.

As I learn new technologies I often times hack my way around until I get a good feel for what I'm doing and how things are supposed to work and be put together.  This led to me not writing as many unit tests for certain parts of the applications I was working on.  I did test drive most (if not all) of the logic I put into my model objects, but I slacked off a bit when it came to testing the controllers.  This is partly due to the fact that I was using scaffolding, and partly due to the fact that I was pushing almost everything into my model objects rather than allowing my controllers to get "fat".  As part of the test driving of my model objects I used the built in testing infrastructure, although I still want to checkout rspec.  On my latest project I also began experimenting with mocha which really helps with the testing of objects that have dependencies. 

So given all my recent exposure to Ruby and Rails one has to wonder how I rate it against my native "tongue", .NET.  I have to say I've had a lot of fun working with Ruby and Rails.  This is in part because its something unfamiliar and I really enjoy learning, but its also because both Ruby and Rails have a way of making developing with them very enjoyable.   I haven't enjoyed some of the deployments and such that I've had to deal with, but since I was learning a bit about how to deploy Rails applications on Linux it wasn't as bad as I expected.  I'm nowhere near hanging up my .NET toolbelt, but I am going to continue to do a lot of the work that I would have previously done in .NET in Ruby and/or Rails.

 |  | 
Thursday, July 12, 2007 3:11:07 AM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [3]  |  Trackback