Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


JohnLudlow JohnLudlow

Niner since 2011

  • Defrag Tools #146 - WinDiff

    I've found the tool in VS 2013 has the tearing problem, so I use KDiff3 (http://kdiff3.sourceforge.net/)

    It also has the capability to do 3-way merging and to copy changes from one side to the other.

  • Welcome/Introduction and Doing Data Science with FsLab

    @erbalrajs: +1

    A demonstration of why F# is impressive loses a lot of its power if the people watching the video can't read the code.

  • Looking Ahead to C# 7 with Mads Torgersen

    @MadsTorgersen:Right! Forgot to raise that (you even mentioned async not supporting out parameters in the video).

    @aarondandy: If we forget backward compatibility for a second, defaulting to non-nullable for ref types is IMHO the right choice (with some sort of modifier like the ? suffix for switching on nullability) when you need it. It'd be nice to get to a point where I don't have to remember to put the ! on everything, because you just know I'll forget. It'd be nice if getting there didn't require a whole new language.

    The way to get there without a whole new language (which has probably been suggested in the discussions) is probably through some type of compile-time option. Mads talked about some sort of warning (which will often be ignored) or Roslyn checker (a la Dustin's C# Essentials). I think a code analysis rule (which can be made to trigger compiler warnings, errors, or just be ignored, on a project-by-project basis) probably gives the right semantics.


  • Looking Ahead to C# 7 with Mads Torgersen

    The reason I like tuples is for stuff that might fail.

    Let's suppose that you have a method which connects to a service of some sort, and can either succeed and bring back data, or fail and bring back an error. How can we represent that in C# today? I can think of 3 ways, all bad:

    1. Throw an exception, which is bad because it goes against the idea that exceptions are for exceptional circumstances.
    2. Return a value which indicates the status of the method (a la DateTime.TryParse(string input, out DateTime result)), and use an out parameters, which is bad because out parameters are ugliest monstrosity ever.
    3. Put a status property on the object which is returned (a la WebClient.GetResponse(....)) which is bad because the status of the request becomes conflated with the state of the object.

    Compare any of these with something like (excuse the psuedo-ish code)


       (Data d, Status s) GetDataFromService(....)
    // called like so
       (Data d, Status s) = GetDataFromService(....)
       if (s.Ok)

  • Defrag Tools #138 - Debugging - 'dx' Command Part 1

    @siodmy: I was thinking the same thing through the episode.

    Having said that, LINQ method-like syntax is pretty cool

  • Intellitest

    @jfattic:Thanks for the answer. That seems like a brittle workaround. Suppose the other tests change such that they don't cover that scenario any more?

    There are two reasons I'm interested in this.

    The first is that I have some coverage already in my application, and I want Intellitest to tell me where the gaps are (and help me fill them). If it's generating tests that I already have, then that's less interesting than only generating the tests I don't have.

    The other reason is my (ahem) "views" on code generation.


    Feature request, then: Perhaps it could integrate with the coverage reports to figure out what cases my tests are already covering.

    Edit: turns out this is on UserVoice : https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/8592451-enable-intellitest-leverage-existing-unit-tests 

    I voted for it

  • Intellitest

    Is it smart enough to not generate tests I have already written manually? So if I am already testing a case where a negative int is passed, will it be smart enough to recognise that it doesn't need to generate one for me?

  • Hello Visual Studio Code (with NodeJS)

    @wfuk:I'll take a look. Thanks.

  • Hello Visual Studio Code (with NodeJS)

    @wfuk:Yeah I got that. I was thinking about for other languages that aren't Javascript. Or is VS Code intended mainly as a Javascript editor?

    Edit: "languages that aren't JavaScript" should probably say "languages that aren't JavaScript and its associates like TypeScript"

  • Hello Visual Studio Code (with NodeJS)

    Nice introduction. It would be nice to see a more advanced tour through the features - maybe an hour long Visual Studio Toolbox video would be nice, though you showed a good amount considering the video is less than 10 minutes long.

    One question - clearly, it has some built-in knowledge of Node.js and Javascript. Is there a way of extending that?

See more comments…