VncSharp Rocks for Programmatic and Interactive Remote Access from .NET

VncSharp is a C# implementation of the VNC protocol together with a handy visual Remote Desktop .Net widget.

At first, the open-source VNC remote-access solution might seem like a surprising item to need in a Microsoft-based solution.

But once he gets you in the little room, VNC starts telling you that, in exchange for lower performance (than Microsoft’s own RDP), he can get you more flexibility, more features, no licensing issues, and access to remote Macs or *nix hosts. After these arguments (or is it the heat?) VNC looks a lot more persuasive.

Throw in the fact that you can run your VncSharp-enabled apps on Mono, and … well, it would be cool if that bought you a lot. But actually if you aren’t already focused on a Linux solution then the Mono angle is just another bullet.

VncSharp itself, though, works extremely well straight out of the gate.

When you see the documentation page – where the author essentially invites you to read the source to figure out how to drive it – you may be concerned. Or even start to form silent curse words with your lips.

Do not let that stop you. There are demo/sample apps that will show you what you need for basic use cases (e.g., popping open a “remote help” window will only require a line or two). And the source, if you need it, is elegant and straightforward to navigate.

A programmable VNC client is, perhaps, a niche product. VNC on Windows maybe more so. So it’s gratifying to see such a mature and streamlined OSS effort.

Maybe a Reason to Learn some Scheme, not a Reason to Avoid Anonymous Functions

A team member with one of my consulting projects sent an email yesterday, describing his counterintuitive run-in with the this keyword in an ActionScript 3 anonymous function. He found a fellow traveler looking at the same issue here... and concluded this might by 'yet another reason to avoid anonymous functions.'

I have a different view, which I thought might be worth reproducing here:

I'm not sure this is a reason to avoid anonymous functions. Looking at the issue and the blog post, the following points may be helpful for the newbies to ActionScript. AS3, and the Flex/Eclipse (FlexBuilder) environment especially, make ActionScript seem like a strange flavor of Java (or C#). But it's not.
ActionScript 3 is an implementation of EcmaScript 4. It has much more to do with JavaScript than with Java, although Adobe intentionally created an environment that would be familiar and comfy for Java devs.

EcmaScript (aka JavaScript) is a Lisp/Scheme family language not a C/C++/Java family language.

Unfortunately, for historical reasons, it shares some syntax constructs with the C-derivative languages, and ES4/AS3/JS2 adds more of those -- but many of them have different meanings, as the aforementioned blogger discovers the hard way.

If you're interested in how this came about, and how to think about it, I can't say enough to praise Douglas Crockford's lectures on "The JavaScript Programming Language", which you can watch from YUI theater. Brendan Eich takes issue with some of the "politics" stories in Crockford's account. But confirms that engineers were recruited to Netscape with the promise of implementing [some flavor of] Scheme in the browser.

If you expect to spend any amount of time in the future doing JS or AS, a couple hours watching Doug Crockford speak are unbelievably worth it. JavaScript (and AS) are extremely powerful languages and can work really well ... only they definitely don't work like they appear they should, if you see the syntax and come from a C/Java background...

Once we realize that we're basically running Scheme in the browser (Brendan says Self), lambda -- anonymous functions and their closures -- become first-class objects as fundamental to us as stack vars in a C language.

As a bonus, if you're new to this and have some time, MIT has published one of the classic textbooks, "Structure and Interpretation of Computer Programs" online for free under a Creative Commons License, along with instructors' manual, exercises, etc.

Actually, I'm gonna go out on a limb here and say if your company or team has a C/stack/register kind of background (Assembly/C/C++/C#/Java/Pascal/Delphi/VB.net/etc) and you're looking at getting involved in JavaScript/ActionScript/Ruby projects, make a team workshop out of doing as much of the Abelson/Sussman book as you can get away with. As a practical side effect, it'll also make your SQL code easier (core SQL is more like Scheme than C) and give you another way to look at problems.

Great Article on the True Nature of LINQ in C#

In the early days of C# 3.0, Microsoft distributed a whitepaper which walked through the rationale behind the additions to language, how the language changes related to the syntax options, and what it could be used for.

Among the key applications ... perhaps a co-evolved objective ... for the new constructs was LINQ ... of the to-SQL, to-XML, and over-Objects varieties.

As Visual Studio 2008 and C# 3.0 has moved out into wide use, though, that background has faded away and instead one sees a ton of quick examples and how-tos about LINQ and database operations that give the impression it's all some kind of fancy SQL trick.

Which is why I really liked this article on 7 Tricks to Simplify Your Programs with LINQ.

The only thing I didn't love was the name, because it's not really LINQ that Igor is talking about, it's the awesome functional programming features under the hood ... which happen to enable LINQ.

Igor shows how the underlying extension method and lamba constructs let you do the cool Lisp (ok, Ruby) tricks with C#, and he does it without getting into explaining what all the machinery is or even what it's called. Those explanations are important to be sure, but having these quick (2-3 lines!), powerful examples communicates a lot at first glance to readers who may not want to read about all the CS issues right away.

Furthermore, Igor avoids examples featuring the slightly misleading SQLesque syntactic sugar that can cloud what's really happening... until his last example.

Which is very useful, because the busy developer-on-the-run seeing a LINQ example doesn't realize that the select/from/where stuff are not magic language keywords. They're just an alternate way of saying Foo.Where or Foo.Select. They're just extension methods that happen to be fairly fundamental to working with lists and sets.

Maybe Igor even gets some folks who thought C# had somehow sucked in SQL to realize that, instead, all the time they've been writing complex SQL queries, they've actually been doing that functional programming stuff they've been hearing so much about. And now they can "think the same way" in C#.