February 2008 - Posts

Before I even get started, a quick side note.  I initially assumed I should write LINQ [all caps] since it is an acronym (from what I recall), but I decided to go with the .NET Framework namespace capitalization instead.  I should have learned my lesson with AJAX or Ajax, or however you want to write it. ;)

Ok, back to the point.  I've seen a couple of posts in the Infragistics forums lately asking about checkbox columns.  You see, even though we put some snazzy selection feature into our grids, many end users have had the checkbox selection paradigm pounded into their heads for years.  They're used to it, they like it, and they demand it from you the developer.  The question becomes - is there an easy way to associate checkbox state with row selection?

Rather than have the checkbox toggle the grid's built-in selection mechanism, I think it makes more sense to treat the checked rows as you would have treated selected rows.  The only complexity is getting a collection of checked rows.  Now I use the term complexity loosely here, because getting the checked rows is really just a single for loop away.  But something just feels clumsy about using a for loop to search through all the rows.  What seems like a natural fit for me is Linq. You can use a Linq query to get a collection of rows from the grid based on their checked state.  Here's an example of a method which does just that.

protected RowsCollection GetSelectedRows(UltraWebGrid grid)
{
    var rows =
        from UltraGridRow row in grid.Rows
        where row.Cells.FromKey("check").Value!=null && ((bool)row.Cells.FromKey("check").Value)==true
        select row;
    return rows;
}

 

On the outside this is a simple method that returns a RowsCollection.  However, notice that on the inside there are some different ingredients.  First of all, there's no semi-colons!  Linq expressions can be broken up in to multiple lines, and do not require semi-colons.  Aside from the return parameter (var rows) the expression has 3 parts just like a SQL query.  In the first piece, we're defining the IEnumerable that we'll be iterating over, and assigning 'row' as the loop variable.  Then we set up the 'where', which will act to filter out our results (just like in a SQL query), and we finally define the select statement which will decide what gets returned.  In the example above we're simply returning the rows collection that is being created.  But we could just as easily return a collection of objects, or even us anonymous types here to construct an object with specific properties we want.  As an example:

    var rows =
        from UltraGridRow row in grid.Rows
        where row.Cells.FromKey("check").Value!=null && ((bool)row.Cells.FromKey("check").Value)==true
        select new {ID=(int)row.Cell[0].Value, Value=row.Cell[1].Text};
    return rows;

In the above example, rather than returning a rows collection, we're returning a collection of objects, where the object has 2 properties - ID and Value.  Pretty powerful, and the syntax is short and sweet.

 

I used the checkbox selection problem as an example of where you can use Linq, but that certainly isn't the only place.  I encourage you to try it out yourself.  There are some great resources out there, including blog posts from Scott Gu, and plenty of documentation on MSDN.  If you haven't been introduced to Linq yet, it's time you take the plunge.  You'll be pleasantly surprised. 

When I first heard the title Technical Evangelist I thought it was a joke.  Then I found out it was a real position, but I still didn't understand what it was about.  It took about a year for me to truly get it, and in the end.. it was simply a description of what I was already doing. 

I spent most of last year trying to decipher the right career path for me, and decide where I wanted to go.  I had enjoyed Product Management, but oddly enough I tended to enjoy the parts of Product Management which often fell outside the scope of the actual job.  

Jason (Chief Technical Evangelist at the time) had approached me and told me that he thought I was perfect for Evangelism.  If you've ever met Jason, you know that he has a special way of making you see the brighter side of life.  I was worried that Jason's optimism was getting the best of him, so I took his advice cautiously.  Finally, I had a conversation with my boss at the time (Jonathan), and he sat me down and forced me to tell him about myself.  I described what I enjoyed doing, what I didn't enjoy doing, and went through the whole process of building a pro/con list.  I thought it was a waste of time because I already knew (or so I thought) that I didn't want to do evangelism.  Well, it turned out that my interests couldn't have been more aligned with that of a technical evangelist.  I tried to deny it, but Jonathan forced me to acknowledge that I indeed was 'right for the job'.  I agreed, but was still hesitant to admit that this was right for me.  Well, time has passed now and I can say - Jonathan you were right (and so were you Jason).  Thank you.

Why was I so hesitant to take the role?  Because I didn't really understand the job.  Looking at the essential duties of an Evangelist it covers things like doing product demos, building samples, aiding the sales team.  These aren't very glamorous tasks on the surface.  Take a product demo for example.  We've all sat in a room before and had someone demo a product to us.  It's usually part of a sales pitch, and it's generally boring.  Was this really what I wanted to spend my time doing?  No!  Of course not!  I don't think anybody aspires to be a boring presenter. 

But when I finally examined the "why" of it all, I found that it was something I was very passionate about.  I realized that the purpose of the 'demo' (from an Evangelism perspective) was not to sell - selling was almost like a side effect.  I present demos to teach about the product, and why I think it's great.  I'm showing you how to accomplish a task using the product.  When I build a sample, I'm not just building another test project.  I'm demonstrating the capabilities of a product that have the potential to change your job, or at least make it easier.  And it doesn't end with NetAdvantage - if you've ever seen me at a Code Camp or User Group, you know that I am passionate about ASP.NET and Silverlight.  Actually I think of all the talks I've given outside of Infragistics, only one was about NetAdvantage (at the User Groups request).

So why am I talking about this now?  Because I just found a post from Thomas Lewis on 7 Tips to Become a Microsoft Technical Evangelist that I wish had been available last year.  Thomas does an excellent job of describing what a Technical Evangelist does, and what skills he needs to have.  Even though the title is Microsoft Technical Evangelist, the tips are true of any technical evangelist role.  So if you've ever wondered what a Technical Evangelist really is - go ahead and read Thomas's post, it's worth it.  And it may open up your eyes to a job you always wanted but never knew existed.

More Posts