n-1

Given the nth item, grab the n-1 item in a list.

Simple, right? You essentially create a stack of size 1 to hold the previous element.

public T GetPrevious<T>(IOrderedEnumerable<T> list, T target)
{
    var previous = null;

    foreach (var item in list)
    {
        if (item == target)
        {
            break;
        }

        previous = item;
    }

    return previous;
}

As usual, LINQ provides a more condensed and elegant solution:

public T GetPrevious<T>(IEnumerable<T> list, T target)
{
    return list
        .OrderByDescending(i => i.Updated)
        .SkipWhile(i => i != target)
        .Skip(1)
        .FirstOrDefault();
}

The n-ith element should be the same logic.  This is the actually first time I’ve used SkipWhile! You can use TakeWhile to do something similar, coming from the other end of the list.

2014/09/17 – 4:27 pm Categories: Code | Post a comment

Tagged , |

IndexOf

The IList<T> interface has an IndexOf method (and a corresponding Item property). The IEnumerable<T> interface does not have an equivalent IndexOf method (though it does have an extension method ElementAt<T> that mirrors the Item property).

Naturally, you can add your own extension method:

public static int IndexOf<TSource>(this IEnumerable<TSource> source, TSource t)
{
    var index = source.TakeWhile(s => s != t).Count();
    return index == source.Count() ? -1 : index;
}
2014/06/29 – 12:02 am Categories: Code | Post a comment

Tagged , |

Deferred Execution

Or, not putting things back where they belong.

I am a big fan of using LINQ, but it’s not without its gotchas.  I recently wrote some code that was behaving unexpectedly, and it took me a bit to figure out what was actually going on, even though it was actually pretty simple.  (Sometimes it’s the simple things that we forget.)

So, let’s bake a cake.  Here’s a snippet.

. . .

var unusedDry = ingredients.Where(i => i.IsDry() && !i.Used);

foreach (var ingredient in unusedDry)
{
    this.Measure(ingredient);
    this.Combine(ingredient);

    ingredient.Used = true;

    this.ReturnToCupboard(ingredient);
}

this.Mix();

. . .

But let’s be honest.  No matter how well your parents taught you, no one actually puts things away immediately after using them.  Usually we do this all in one go at the end.  That’s a simple enough change:

var unusedDry = ingredients.Where(i => i.IsDry() && !i.Used);

foreach (var ingredient in unusedDry)
{
    this.Measure(ingredient);
    this.Combine(ingredient);

    ingredient.Used = true;
}

this.Mix();

. . .

await Task.WaitAll(unusedDry.Select(i => i.ReturnToCupboardAsync());

Sweet!

Or is it?  Turns out that none of the unused dry ingredients got put back where they belong.

When you write LINQ, it’s so natural that sometimes it’s easy to forget that your variable doesn’t actually contain the results of your query, but instead a data structure that contains the query itself, to be executed at some later point in time, when it needs to.  In this case, the Task.WaitAll() method executes the query that’s passed in, namely ingredients.Where(…).Select(…). Since the Used property has been set on each of the unused dry ingredients at this point in time, the results of the query are in fact empty, and Task.WaitAll() is given an empty IEnumerable<Task>.

At times like these, you can use the ToArray() or ToList() methods to force the evaluation of the query and to cache the results.

For more, see Classification of Standard Query Operators.

2013/10/03 – 12:48 am Categories: Code | Post a comment

Tagged , |

Eight

Windows 8 has recently RTM‘ed, and coincidentally I have just hit my 8 year anniversary working full-time at Microsoft.  It has been a wild ride.  I have worked on a handful of products (MSN/Windows Live Messenger, Live Core, Live Mesh, Windows Live Mesh, SkyDrive—I even created a comical presentation detailing the history of the last four) and have first-handedly seen the rise and fall of several products.  The tech industry has changed dramatically over the last 8 years.  I have also seen many friends and co-workers come and go, both within Microsoft and to other companies.

I think I am ready for something new, though I have not decided what that exactly is yet.  Commence navel-gazing.

2012/08/14 – 11:14 am Categories: Uncategorized | Post a comment

From Spaces to WordPress…

Well, I migrated my Spaces blog to WordPress, due to the fact that Spaces is shutting down. I’m not sure I’m a fan of this UI–it’s kind of confusing. Anyhow, WordPress was kind enough to move my posts and comments over as well–all 300+ comments, of which 99% are spam. Nice. Please re-subscribe to RSS feeds.

I haven’t blogged here in over a year and a half. Ouch.

Windows Live Essentials is now released, which includes Windows Live Mesh. Woot! And it’s going to be installed on Dell machines this fall!  It’s been a long journey.

2010/09/30 – 7:13 pm Categories: Live Mesh, Windows Live, Work | Post a comment

Implicit Typing: To var or not to var?

Since the beginning of time, religious wars have been fought over differences in religion and beliefs.  I think this is one such war.  C# 3.0 introduced the concept of implicit typing back in 2007 with the keyword var.  Since then, you are bound to find people vehemently opposed (and disgusted) by the concept, and others that embrace it to the point of no return.  I’m going to try to take an impartial look of implicit typing here (but you may conclude that I have failed).

First off, the facts.  MSDN’s “Implicitly Typed Local Variables” has a very concise explanation, but let’s try to distill it even further.

  • Local variables (and only local variables) can be declared with an inferred “type” of var instead of an explicit type.
  • The var keyword tells the compiler to infer the type of the variable based on the right hand side of the initialization statement.  (ie. You must be in a statement that declares and initializes the local variable to use var; there is no: var x;)
  • In many cases, the use of var is optional and is syntactic convenience.
  • var is not optional when the variable is initialized with an anonymous type.
  • var may be useful with query expressions where the exact constructed type of the query variable is difficult to determine.
  • var can be useful when the specific type of the variable is tedious to type on the keyboard, or is obvious, or does not add to the readability of the code.
  • var does have the potential to make your code more difficult to understand for other developers.

When a member of my team, CS, started using the keyword var, I despised it.  Though the concept is so simple, it’s actually a fairly large paradigm shift.  I thought it made code less readable, and also broke my IDE’s autocompletion feature.  At first he suggested that we only use it for LINQ queries, initializations with constructors, and casting statements.  Trying to keep an open mind, I gave it a shot, and it didn’t take long before I found out that I actually liked it.  Code was looking nicer, cleaner, and simpler.  Talk about heading over to the dark side!

Dictionary<string, List<Item>> dictionary = new Dictionary<string, List<Item>>();

    vs.

var dictionary = new Dictionary<string, List<Item>>();

Which looks better?  (In case it’s not obvious, I think the latter is leaps and bounds better.)  Or:

DateTime dateTime = (DateTime)eventArgs;

    vs.

var dateTime = (DateTime)eventArgs;

At this point though, CS had moved on to using it practically everywhere (except for value types)!  What the heck!?  It is a slippery slope.  I acknowledge that this is probably not as obvious:

foreach (var kvp in this.dictionary) { … }

    vs.

foreach (KeyValuePair<string, List<Item>> kvp in this.dictionary) { … }

… but it’s actually way more readable.  Anyway, you can probably tell that I slid down that slippery slope.  Now I, too, use it when I can (except for value types, though I would not be surprised before I start using it literally everywhere).  There has been backlash though, against this usage.  Why?

By far the largest argument against the usage of var that I’ve seen is that it’s not always clear from looking at the declaration of the variable what the type really is (though this is certainly not true in the previous two examples):

Con: I can’t tell what the type is.
Pro: If you use VS and hover over the variable, it tells you what the type is.
Con: I don’t use VS.
Pro: …
Con: I can’t tell what the type is in Notepad.
Pro: O__o’

Actually I don’t use VS either (I use a combination of SourceInsight and vim, neither of which grok var), yet I like var a lot.  Why?  At the end of the day, I think that argument comes down to the naming of local variables.  When you look at a variable being used in code, you are usually looking at its usage instead of its declaration.  I find that naming the variable with a descriptive name often helps much more than the declaration statement far above, because you don’t need to search for the declaration at all!  For instance:

stringBuilder.Append(“foo”);

    vs.

s.Append(“foo”);

What the heck is “s”?  (Yes, sometimes I will shorten it to “sb” too.)  It has been brought up many times before that the benefit of “better naming for local variables” “really means it compels developers to use longer Hungarian style variable names.” –Carnage4Life.  Personally I think that is a good thing to follow in general; I don’t find it adding to the “noise” in the code.

One other benefit of var that I don’t see purported too often is that when you change a type, property, or return type of a method, you don’t have to go change every usage of that type as well.  Take, for instance:

var fraction = new { Numerator = 9, Divisor = 11 };
var value = fraction.Numerator / fraction.Divisor;

The second variable, value, would be implicitly typed to be an ‘int’ in this scenario.  But if I were to change ‘Numerator’ to 9.0 instead of 9, value would be typed as a float, without me having to change that line.  Obviously this is somewhat of a contrived scenario, but one could easily imagine changing a property in a class (or a return type of a method) and have all the callers of that property to “just work.”

I can’t imagine that the debate to var or not to var will ever end, but I for one, love it.  After having used it dutifully for several months, I cringe at the thought of typing out types—it’s so 20th century!  I’m completely hooked.

Let’s end off with a comment thread from ReSharper:

C:  Variable type declaration is not equal to variable instantiation.

P:  If this were true, the compiler would be unable to infer the type.

C:  I’ve fought far to many battles in classic ASP and vbscript where the type I thought was going into the variable wasn’t the type I ended up with.

P:  Comparing a dynamic language with a strongly-typed one isn’t a great way to develop best practices.  Yet again, I have to ask why people are scrolling to the point of variable declaration to determine the type, rather than just hovering over the variable.

C: That’s supported in Visual Studio only. What if you’re reading code on paper, on a web page, pdf or plain text editor?

P:  If that’s a primary design concern, I worry about your development process.

C:  I guess you’ve never heard of code reviews.

P:  Sure, we do them too, just not on stone tablets.

It’s certainly interesting how something so seemingly trivial could incite such passionate debates among people.

2009/02/28 – 2:54 am Categories: Code | Comments (1)

OEMCP vs. ACP

One of the trepidations I had when starting to work on client software three years ago was dealing with globalization and localization.  I had heard of horror stories of how much busy work localization involved (they have teams that deal with that issue alone), and it was a black box for me.  (Yes, I realize that they’re just strings in resource files.)  Fortunately enough, since I have been working on a client platform, instead of the UX on top of the platform, I never had to deal with localization at all.  In fact, I was pleasantly surprised when I first heard that sync’ing files like 好嗎.txt actually worked.  Effortless!

My naïvité lasted up until a month ago, when I investigated a bug report from a customer.  I sat on the bug for a while, as I was a little perplexed by the whole report.  It was most certainly some sort of localization issue, and it took some head-banging before I figured it out.  The details aren’t particularly important here, so let me just get to the gist of the bug.

At the command prompt: (Yes, the command prompt.  Does that still surprise you?  Seven of my 10 previous “code” posts have to do with the command prompt.)

C:>echo Comment ça va?
Comment ça va?

I took French in high school.  That’s a cedilla under the ‘c’.  Anyway, there’s nothing unexpected here.  Echo does its job as asked.  Now for some redirection:

C:>echo Comment ça va? > salut.txt

C:>type salut.txt
Comment ça va?

Again, nothing unexpected here.  Yawn.

But wait!  (There’s more!)

C:>notepad salut.txt

Notepad will open up.  And what does it show?

Comment ‡a va?

What the heck?!  Blink.  Twice.  Huh?  What’s going on?  I did a bunch of digging and found all sorts of interesting information online about code pages.  From Wikipedia:

Code page is the traditional IBM term used to map a specific set of characters to numerical code point values.  …  [T]he term is most commonly associated with the IBM PC code pages. Microsoft, a maker of PC operating systems, refers to these code pages as OEM code pages, and supplements them with its own "ANSI" code pages.

It turns out that on an EN-US operating system, the OEM code page is CP437, whereas the default ANSI code page (ACP) is CP1252.  Apparently the command prompt uses a different code page than do GUI programs, so this must be an encoding issue.  If you look at the file in a hex editor, you’ll see that the character ‘ç’ is encoded as 0xe7, as expected from the OEMCP: 87 = U+00E7 : LATIN SMALL LETTER C WITH CEDILLA.  But in the ACP, 0xe7 is ‘‡’: 87 = U+2021 : DOUBLE DAGGER!

So does that mean that the issue goes away if you change the code page the command prompt is using to the one UI apps use?

C:>chcp /?
Displays or sets the active code page number.

CHCP [nnn]

  nnn   Specifies a code page number.

Type CHCP without a parameter to display the active code page number.

C:>chcp
Active code page: 437

C:>chcp 1252
Active code page: 1252

C:>echo Comment ça va? > salut.txt

C:>notepad salut.txt

Comment ça va? (in Notepad)

Check that out!  Ah, oui!  Bien sûr!

Raymond Chen has a bit more on the details and the historical reasons behind the schism.  Thanks to Michael Kaplan for a series of excellent posts on the subject.  I still know next to nothing about localization, but it’s pretty cool when you figure things out, even if those things were discussed ad nauseam years before you even came across it.  (And just to wrap this up, the Win32 function GetACP() will allow you to get the current ANSI code page, but that isn’t scriptable unless you wrap it in an exe.)

I’m floating the idea of doing a “Bugs of Live Mesh/Framework” series.  (Bonus points for anyone that can figure out how this bug relates to Live Mesh.  Hint: It’s related to a previous post I made here over a year ago.)  I was thinking of covering some of the more ‘interesting’ bugs: why they exist, what fixes were/will be made, what workarounds there are, or even to solicit feedback.  What say you?

2009/02/21 – 12:00 am Categories: Code | Post a comment

The Two-to-Three Year Itch

Dare’s got an interesting post on “Dealing with the Seven Year Itch …”.  In my experience, and in watching many of the people around me, I think the itch comes along once every two to three years (assuming you scratch the itch when it appears).  My first itch almost three years ago was delivered prematurely.  I can vouch for this:

[…] I’ve had a number of friends go through the sense of needing change or career dissatisfaction which leads to the seven year itch. Both at Microsoft and elsewhere. Some of them have ended up dealing with this poorly and eventual became disgruntled and unhappy with their jobs which turns into a vicious cycle. […] here are the three most successful, proactive steps I’ve seen them make:

(1) Change your perspective. […]
(2) Change your organization.  […]
(3) Change your job. […]

If you haven’t done #1 by the time you get the itch, or aren’t doing #2 already (actually, you shouldn’t get the itch if you’re doing #2), then #3 is really your only option.

I’m at 4.5 years working at MSFT now.  The five year mark is when they give you the five-year service award.  Assuming I don’t get laid off in the next six months, I should have some more reflective thoughts later.  I never would have imagined that I’d still be around here after five years.  When I first started, I scoffed at some that had been around for just two years!  Crazy.

2009/01/21 – 6:56 am Categories: Uncategorized | Post a comment

Crunchie

Live Mesh Awarded Best Technology Innovation Crunchie @ Crunchies 2008

Old news, I know, but I finally got a picture of it.

Those logos are printed out on paper (inkjet?) cut out, and glued on.  lol.

2009/01/18 – 9:22 pm Categories: Uncategorized | Post a comment

He’s Alive!

I can’t believe it’s been 4 months since I last posted here.  Where has the summer gone?  In the past seven months since we unveiled Live Mesh our team’s been working furiously to deliver for the Professional Developers Conference 2008.  I wasn’t lucky enough to go (*grumble*) but if you missed it there’s a wealth of material online for viewing (I still haven’t had a chance to go through all of them).  There are a ton of links off the official blog that are worth looking through.

There are some things I want to write about, but I just haven’t gotten the chance.  Hopefully I’ll be a bit more regular again.  More later.

2008/11/13 – 2:08 am Categories: Uncategorized | Comments (1)