jaredpar's WebLog : Misc

Presentation Follow up

Jared Parsons — Wed, 29 Oct 2008 15:00:19 GMT

Thanks to everyone who showed up at the presentation on monday. For those interested, I've uploaded the contents of the presentation here.

I was unable to upload the large DB file used during the demo due to size limitations (sky drive will only let me upload a 50 MB file). But better than wasting both mine and your bandwidth, I included the script used to generate the db file.

The file is a powershell script named GenerateDb.ps1. If you pass the -argLarge switch, it will generate the 120MB demo file.

PS>.\GenerateDb.ps1 -argLarge

Presenting at Net Developers Association Meeting Oct 27

Jared Parsons — Fri, 24 Oct 2008 04:22:41 GMT

I will be presenting at the Net Developers Associating meeting this upcoming Monday. If you're interested in hearing me ramble on in person please drop by.

Event Details:

When: Oct 27 7:00PM
Where: Microsoft Building 40: The Steptoe Room (Map)
Who: Me
Why: Blogging's fun but it's great to go out and talk to people in person

My talk will center around how to get the most out of a LINQ query. I'll be covering a lot of the misunderstood aspects of LINQ such as deferred execution. Most bit of the talk will focus on the MSDN article I wrote a few months back.

Community Interview

Jared Parsons — Fri, 17 Oct 2008 15:00:00 GMT

Recently I did a community interview with Microsoft MVP Alessandro Del Sole.

The Italian version can be read here. And no, I don’t speak Italian. The original transcript is below.

1. Nice to meet you Jared Parsons! Let’s begin by asking a simple question: where are you from?

Born in Kentucky, raised in Tennessee, lived in Alabama for awhile, then back to Tennessee and went to college in Georgia. Usually I simplify it by saying I grew up all over the southeast.

2. We all know that you’re a Visual Basic Team member, but could we know something more about your role inside the Team?

I’m a developer in the VB team. I started out on the VB Compiler several years ago. Towards the end of Visual Studio 2008 I switched to the VB expression evaluator (aka debugger, watch, immediate window). This role expanded to other parts of the VB IDE experience including a lot of features users will be (hopefully) really excited about for the next release of Visual Studio.

3. What’s your favorite Visual Basic feature regarding the language and/or the IDE?

My favorite VB feature is usually whatever I’m implementing at the moment I’m asked this questionJ. Luckily I’m in between features at the moment so I can give an unbiased answer. XML Literals are my favorite VB feature. It really allows me to seamlessly integrate my data and queries into my application. I feel like I find a new way to use it every day.

4. How long have you been working for Microsoft and what was your occupation before joining the VB Team?

I’ve been working at Microsoft for 4 ½ years now. I joined Microsoft immediately after college in the in the Visual Studio Team System division. More specifically I was a developer on Team Developer and Team Architect. After shipping Visual Studio 2005 I was eager for new challenges. I spent a good deal of my time in college working on low level systems and being a teaching assistant for an introduction to compiler courses. I was interested in getting back to these roots. A job opened up on the VB compiler team and it was the perfect fit.

5. Why do you think VB is such a great language?

We have a tie here: flexibility and IDE. VB is an amazingly flexible language. It lends itself to whatever task I’m trying to do. On one end of the spectrum I have XML literals to work with my data and at the other end generics and lambda expressions to really geek out on a problem. The IDE support is also very good (I promise I’m not biased here). It’s really difficult to express everything the IDE offers to the programmer. The best way to understand though is to get out notepad and try and code up a VB application. That will really give you a handle on what the IDE is doing for you.

6. Have you ever been to Italy?

No but it’s definitely on the list of places to visit.

7. Would you like to tell us something about your life outside the office (how do you like to spend your free time, what do you like to do when/if you go out in the evening or when you’re at home and so on)?

Outside of work I still lead a largely geek lifestyle; lots of programming, blogging and book reading. I do manage to leave my geek role by playing a variety of sports. Right now I’m playing soccer (indoor and outdoor), softball and football. I’m not very picky when it comes to sports. As long as it’s athletic and preferably outdoors I’m there. It’s a great way to get release after a day of programming.

Of course there is the occasional Rock Band party as well.

8. Who is your favorite musician?

Much to my parent’s disappointment, I don’t have an ear for music (read that as 100% tone deaf). As a consequence my taste for music is … bad according to my friends. I prefer to think of it as blissful ignorance. On that note (pun intentional) I love a good punk album or some techno while coding.

9. What’s your favorite food?

The hands down winner here is French Fries.

stackoverflow: a new addiction

Jared Parsons — Fri, 10 Oct 2008 15:00:00 GMT

If you haven't visited stackoverflow.com yet I encourage you to take a trip. It's a great tag based newsgroup system. Check it out.

PInvoke Interop Assistant on Channel 9

Jared Parsons — Thu, 11 Sep 2008 15:00:56 GMT

Beth Massi dropped by my office a couple of months ago and we did a channel 9 video on the PInvoke Interop Assistant. Mainly an overview of the product and a bit of a tutorial. Check out the video here.

http://channel9.msdn.com/posts/funkyonex/The-P-Invoke-Interop-Assistant/

5 things Hollywood thinks computers can do

Jared Parsons — Wed, 27 Aug 2008 15:05:22 GMT

Reading another Jtenos' blog, I came across this article about things Hollywood thinks can be done with computers. Humorous read.

http://www.cracked.com/article_15229_5-things-hollywood-thinks-computers-can-do.html

Don't speak geek to your family

Jared Parsons — Wed, 20 Aug 2008 15:00:54 GMT

In planning my recent vacation an email thread was started about who would be picking up the groceries. Most importantly, who would be picking up the drinks. My brother was quick to volunteer. I said in no uncertain terms I didn't want any of drinkA [1]. In the past my brother was known to buy large quantities of drinkA.

Or at least I thought I said it in no uncertain terms. As we arrived I opened the fridge to find a large quantity of drinkA. I stared in disbelief and confronted my brother. He responded with "yeah, I thought it was weird that your email said to buy that but since you clearly wanted it ..." After several other family members said the same, I placed the blame on a busy week at work and a simple typo.

Luckily my wife brought up the email in question as proof of my mistake. The line read

"Jason we want beer. For the purpose of the beach beer != drinkA"

To most people reading this entry the meaning is as clear as it can be. Don't buy drinkA. Unfortunately the rest of my family are not programmers and read this as an emphatic equals sign.

Lesson learned.

[1] The particular drink in question is not important.

First MSDN article

Jared Parsons — Mon, 18 Aug 2008 15:00:10 GMT

The August issue of MSDN magazine will be carrying an article I wrote this spring. In it I toy around with using the deferred execution and lazy evaluation properties of LINQ to create more responsive UI code.

You can view the article here.

As usual I appreciate any feedback you have.

ImmutableStack in F#

Jared Parsons — Fri, 15 Aug 2008 15:00:43 GMT

When learning a new language I find it very instructive to re-code certain structures from my well used libraries into the new language. It gives a great basis for comparison in terms of ease of implementation, expressiveness of the language and sheer ease of implementation. So on that note I set out today to build an ImmutableStack implementation in F#. This is based off of my C# implementation in RantPack.

Below is the initial implementation. This is my first non "hello world" data structure in F#. I found it surprisingly easy to implement and I'm really enjoying the language. The biggest stumbling block was getting the type union correct and dealing with my compulsion to use "null" for end of stack instead of a value.

After playing around with it a bit I'm left with the following questions/hangups. Most of these will just fall into the category of "I'm starting out with a new language so I'm still hung up on the syntax in places."

I consider Node to be an implementation detail and ideally would like to make it a private nested class if possible
The constructor still allows for invalid data combinations (but will throw)

Ex: ImmutableStack None ImmutableStack.Empty()

Can I get ImmutableStack.Empty to be a property instead of a function?
In All(), that can't be the most efficient way to build up a sequence.

#light

type Node = 
    | Empty
    | Value of int * ImmutableStack

and ImmutableStack(?v:int, ?n:ImmutableStack) = 
    let data = match (v,n) with
                | (Some v, Some n ) -> Value (v,n)
                | (Some v, None) -> Value (v,ImmutableStack.Empty())
                | (None, None) -> Empty
                | _ -> failwith "invalid combination"
    static member Empty() = ImmutableStack()
    member x.IsEmpty() = 
        match data with
            | Empty -> true
            | _ -> false
    member x.Push(y) =
        match data with 
            | Empty -> ImmutableStack(y, x)
            | Value _ -> ImmutableStack(y, x)
    member x.Peek() =
        match data with
            | Empty -> failwith "ImmutableStack is empty"
            | Value (v,_) -> v
    member x.Pop() =
        match data with 
            | Empty -> failwith "ImmutableStack is empty"
            | Value (_,n) -> n
    member x.All() =
        match data with 
            | Empty -> Seq.empty
            | Value (v,n) -> Seq.append (Seq.singleton v) (n.All())
            
let rec printStack (s:ImmutableStack) =
    match s.IsEmpty() with
        | true -> printfn "Empty"
        | false -> 
            printfn "%d" (s.Peek())
            printStack (s.Pop())

let s1 = ImmutableStack.Empty()
let s2 = s1.Push(42).Push(56).Push(62)
let s3 = ImmutableStack 42
let s4 = s3.Pop()

printStack s1
printStack s2
printStack s3
printStack s4

Learning a new Language: F#

Jared Parsons — Thu, 14 Aug 2008 15:00:20 GMT

Time again to learn a new language. I enjoy picking up a new language every now and again. It's a great way to branch out your skill set and usually leads to new programming techniques in languages that are a part of professional or hobby life.

But why bother? The popular languages have a lot of common elements : functions, types, etc ... With all of the common elements what can learning a new language really give you?

It's true that there are a lot of common elements (especially for .Net based languages). But what really interests me are the features which make the individual language extremely productive. Most languages have a feature or two that really makes it worth learning. They greatly increase the productivity of the developer. Often full libraries are designed around these features. For instance

C++ and Templates
- This is somewhat special in that it's extraordinarily powerful for both good and evil
VB and late binding
C# and iterators

What's great about learning these features is I can often import them into my current heavily used languages. For instance, even though C#/VB don't directly support functional style programming, I've spent a bit of time over the last few months building libraries that make it fairly easy to incorporate them into either language. This added a deal of flexibility into my programs and a real functional feel.

Lately I've been focusing on immutable/persistant data structures, lambda expressions and tuples. This makes F# a natural choice for a language to learn. While I tend to program in a somewhat functional style this will be the first functional language I've heavily invested my time in. For awhile I did a bit of Haskell but nothing serious.

I intend to blog about the joys and not so joyful moments of this process.

Vacation

Jared Parsons — Tue, 29 Jul 2008 15:00:56 GMT

I'm embarking upon another cross country road trip this week followed by a much needed vacation. I will be actively blogging during this time (lots of backlogged material to get through) but without a decent internet connection the live blog will be ... quiet.

Live Mesh accepting more users

Jared Parsons — Thu, 17 Jul 2008 15:00:18 GMT

If you haven't tried out live mesh yet I really encourage you to try. It's an amazing well designed product and incredibly useful.

It's still classified as a tech preview but now they are taking on additional users (doubling the current user base in size).

http://blogs.msdn.com/livemesh/archive/2008/07/16/live-mesh-still-in-tech-preview-but-ready-for-more-users.aspx

Book Review: Facts and Fallacies of Software Engineering

Jared Parsons — Wed, 11 Jun 2008 15:00:10 GMT

I finished reading Facts and Fallacies of Software Engineering a few weeks ago. This is an excellent book and I recommend it for anyone who's been in the industry for a few years.

Typically I don't enjoy books of this type because I feel they are too preachy, written by people who aren't on the front lines and don't understand the day to day problems a programmer will face or are just too long winded. Neither appears to be the case here.

Mr Glass takes a very interesting approach to this book. In addition to listing good resources for every fact/fallacy he also offers a small (albeit less detailed) section on why people disbelieve in this particular item.

Top 3 facts which I think have the most value in my job

Fact 36: Programmer-created, built-in debug code is an important supplement to testing tools. The majority of bugs filed against code I own are not because of an invalid behavior. It's much more likely that QA will hit an ASSERT I added to the code base which fire before the behavior difference. What's encouraging is QA will often note: If I ignore the assert everything seems to work alright. Without a dev assert these bugs would have gone unnoticed until a much bigger problem hit.
Fact 43: Maintenance is a solution not a problem. Except for the end of a cycle, I constantly do maintenance work to parts of the code base. If it's broken, doesn't meet standards, uses bad resource management, etc fix it! Don't wait for the bug.
Fact 49: Errors tend to cluster. Good QA members know this and actively exploit it. Unfortunately it affects my job since I'm on the receiving end :)

Top 3 facts which I think more people need to take to heart

Fact 6: New tools and techniques cause an initial loss of productivity/quality. Anyone who reads my blog knows that I am a huge tool guy (see the PowerShell tag). Tools come with a cost though. As productive as PowerShell and my other bag of tools make me they all came with a price tag. One that has been paid over many times but the initial ramp up did cost time.
Fact 19: Modification of re-used code is particularly error prone. In my experience the costs of this are typically underestimated. Mainly because the behavior depended on is not well understood.
Fact 38: Rigorous inspections should not replace testing. I heard an engineer say it best on the history channel "One test is worth one thousand expert opinions." Inspections mean nothing if they are not backed up by tests. Even if the inspectors get it right, without a regression test there is no way to guarantee it will stay that way for the future.

Top 3 facts which most surprised me

Fact 3: Adding people to a late project makes it later. I heard this long before I read the book but I wanted to call it out because I remember just how surprised I was the first time I heard it.
Fact 25: Missing requirements are the hardest requirement errors to fix. Falls into the category of "haven't thought about that one but makes sense."
Fact 30: COBOL is a very bad language, but all the others (for business applications) are so much worse. This stems more than anything else from my complete lack of knowledge about COBOL. It's an often scorned language yet if it was so bad no one used it then no one would complain.

Citation:

Glass, Robert L. Facts and Fallacies of Software Engineering. Pearson, Education Inc, 2003

Inkpot Color Scheme

Jared Parsons — Mon, 02 Jun 2008 15:00:04 GMT

I was reading Charlie's post on VS Color schemes and thought I would add my favorite to the list. InkPot is a color setting for vim which I adapted to VS awhile back. Very easy on the eyes.

You can download it here