Monday, February 25, 2008

VB come backs to scripting

Paul Vick, the Principal Architect for VB, gave an interesting talk at the Lang.NET Symposium about the future direction of VB with regards to scripting. He also discussed this on his blog:
“The main theme of the presentation is the same one I've been talking about on and off over the past year or two: moving Visual Basic back towards it's scripting roots. The main thrust of this presentation was the technical side of the story--namely, what we would need to do to the existing Visual Basic compiler to be able to effectively use it as a scripting engine. The presentation talks some about the way the compiler is structured, how it might change and some of the things were thinking about enabling.
“all the services that the compiler provides...are available to be used by any program that needs them.”
In particular, what we'd like to see is not just that Visual Basic can be embedded anywhere, but that all the services that the compiler provides--parsing, semantic analysis, code generation--are available to be used by any program that needs them. The DLR is a key part of this, but there's a lot of work on top of that.”
He also pointed out that language changes (like the XML native stuff in VB9) are necessary too:
“One thing this presentation didn't cover (and which Ted Neward brought up in the Q&A afterward) is what we might do to the language itself to make it more scripting-friendly. That's an area where things are less well-defined and even more speculative than what I talked about, so I left it out for now.”
Making the IDE services available to other programs allows a suite of competitors to Visual Studio to open up - so I'm not sure whether that will really fly (unless it's protected by licensing). But it does offer intriguing possibilities for scripting tools for administrators to use (provided they are familiar with VB) and perhaps even the ability to give end-users some access to create code in a Domain Specific Language (DSL) that makes sense to them. It could let you create an online query tool for large XML files. Whether modern systems administrators will welcome this sort functionality is another thing of course - and the security implications could be pretty scary.

Monday, February 18, 2008

Feeling secure or not ...

ZDNet.com.au have posted an interesting short interview with Bruce Schneier, security guru and author of Applied Cryptography and Beyond Fear.

They point out that he highlights that there is usually a difference, sometimes a great one, between how secure we feel, and how secure we really are. I've added to the quote below a bit missing in the ZDNet article (highlighted):
“When something rare happens it's talked about endlessly. It's repeated again and again so our brains are fooled in to thinking it's or common because it's what psychologists call "available" -- the memories are more available. And one of our mental short cuts is to think of things that are more available as more common. So we might not phrase it that way, but we react as though terrorism or child kidnapping is more common than it really is, because the media endlessly repeats the rare thing.
I was discussing with some other parents this very issue the other day. We are all hyper-aware as parents of the potential for our children being snatched from us at the park or shops, and so we find ourselves placing boundaries for our children that we never had ourselves.

For example I remember as a 5 year old I was allowed to run around the local neighbourhood (we lived in a cul-de-sac) and playing in the banks of snow that snowploughs had pushed up on either side of the road (I lived in Toronto, Canada at the time). There is NO WAY I would allow my kids to do this now - for one thing a minor car accident could have resulted in a car plunging into our snow bank, and clobbering us in the process - I'm too aware of similar improbable events occurring. For example a local pre-school was recently hit by an out of control driver and several children were badly hurt.

However my parents weren't being bombarded with stories about that sort of thing, so they thought it reasonably safe letting me play on my own outside (although there was the time I got busted throwing overripe oranges at passing cars ... and one driver had his window open).

In reality the chances of my being wiped out by an out of control car were probably no greater in that snow bank than they were while crossing the road, or being driven to school in the family car (possibly greater as my Mum grew up in sunny Australia, and never much liked driving on icy roads).

The problem is that we make decisions based on emotions rather than pure logic, and that is no matter how coldly logical we try to be. 'Fear' is an emotional warning sign that lets us know when something bad could happen, but as Schneier points out it is biased towards events that we 'know' about, thus giving media stories an unwarranted weight in our decision making.

Schneier wants us all to talk different about real and felt (security) risks as he feels that the ambiguity of English (and many other languages) means that we help the process along:
“In effect we have two very different concepts mapped on the same word. And this makes a lot of conversations about the feeling and reality of security hard to have because our language fails us.”
In IT terms the problem is not so much the software as the hardware - we could remove the obfuscation by ensuring we always qualify our statements with a disclaimer as to whether we are talking about 'feeling' secure or 'being' secure. Our brains are built to respond to emotional triggers, when someone tells us something is true we use emotional cues (theirs and ours) to help us evaluate if that is really true.

[UPDATE: Fixed minor typo.]

Monday, February 11, 2008

Rewarding failure

In a recent interview CNET's Dan Farber asked Lloyd Taylor, VP of Technical Operations at LinkedIn “how do you create that culture of innovation in these different places that you go, how do you inspire people to kind of break all the rules?”
“The culture needs to reward failure. That is the answer.”
Lloyd Taylor
VP of Technical Operations at LinkedIn

Friday, February 08, 2008

My coding themes

Scott Hanselman posted some samples of various developer's coding themes and asked people to link to their own, so here is mine.

This is how C# code looks, I couldn't find any snappy looking VB code to post that wasn't live code I couldn't share, so I took a snapshot of our internal code generator's code:


ASPX files look slightly different, and as I spend a lot of time coding them it's important to get those looking good too:


I spend a fair chunk of time going into SQL Management Studio, so I figured I needed to theme that in a similar fashion:


In Visual Studio 2008 I'm using the Consolas font, set to 11pt in size. My aim with these themes was to get something where I had nothing too high contrast, but I could clearly tell the difference at a glance between a string and a comment, or an XML comment.

Thursday, February 07, 2008

Heroes happen at Elcom

Elcom's updated our website and posted this nifty flash animation highlighting the work we've done to get onto the 2008 Microsoft stack:

UPDATED: Added link as the flash link doesn't seem to want to work on my blog ...

Wednesday, February 06, 2008

US Election: Who's playing the race card?

Jon Stewart makes a very good point about US election coverage:

Tuesday, February 05, 2008

Interesting Links 2008-02-05

Madhav Rao has a great post summarising the unit testing tools currently available for .NET developers.

Chad Myers also has a great post explaining his development methodology, called I don't trust me.

I've been reading C.S. Lewis' The Abolition of Man, and have found a good version of it online thanks to Columbia University.

Finally, DevTopics has 101 great computer programming quotes (via Chad Myers, via DotNetKicks). Here are some of my favourites:
“The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry.”
(Henry Petroski)

“Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test, it introduces security challenges, and it causes end-user and administrator frustration.”
(Ray Ozzie)

“There are only two industries that refer to their customers as 'users'.”
(Edward Tufte)

“The trouble with programmers is that you can never tell what a programmer is doing until it's too late.”
(Seymour Cray)

“That's the thing about people who think they hate computers. What they really hate is lousy programmers.”
(Larry Niven)

“A hacker on a roll may be able to produce–in a period of a few months–something that a small development group (say, 7-8 people) would have a hard time getting together over a year. IBM used to report that certain programmers might be as much as 100 times as productive as other workers, or more.”
(Peter Seebach)

“The best programmers are not marginally better than merely good ones. They are an order-of-magnitude better, measured by whatever standard: conceptual creativity, speed, ingenuity of design, or problem-solving ability.”
(Randall E. Stross)

“Optimism is an occupational hazard of programming; feedback is the treatment.”
(Kent Beck)

“In software, we rarely have meaningful requirements. Even if we do, the only measure of success that matters is whether our solution solves the customer's shifting idea of what their problem is.”
(Jeff Atwood)

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are–by definition–not smart enough to debug it.”
(Brian Kernighan)

“As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.”
(Maurice Wilkes discovers debugging, 1949)

“I don't care if it works on your machine! We are not shipping your machine!”
(Vidiu Platon)

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
(Martin Golding)