Tuesday, October 30, 2007

Buy 1, Donate 1 Laptop for $399 - The One Laptop Per Child Project

A while back, I saw a 60 Minutes interview with Nicholas Negroponti about the One Laptop Per Child Project, and it was very interesting.  These things really are useful in an African village.  Kids, as kids do, were taking to them like ducks on a pond.  It's a cool box, too.

Now we have a chance to both satisfy our lust for curiosity about the technology and help a child.  Come November 12th, there is a two week program where you can buy one of these babies and have one donated.  Sign up here to be notified when it officially starts.

Rob Walling has blogged about it.

Wednesday, October 24, 2007

WCF Performance Comparisons

Ken Brubaker points to a summary by Clemens Vasters of a white paper comparing various existing distributed communication technologies with WCF.  The bottom line - WCF is

  • %25 - %50 faster than ASMX
  • %25 faster than .NET Remoting
  • %100 faster - %25 slower than .NET Enterprise Services (DCOM)

Also in his summary, Clemens remarks (italics his):

For WSE 2.0/3.0 implementations, migrating them to WCF will obviously provide the most significant performance gains of almost 4x.

The performance differences alone make WCF a technology worth exploring.

Team Foundation Server Version Control

Jeff Levinson provides a brief overview of how you could set up and do change management for development using TFS.  The approach is a bit different than I've seen in the past.

Thursday, October 18, 2007

Integrating TortiseSVN with Visual Studio.NET

Here's a nice CodeProject article on both using TortiseSVN (the primo Subversion client) and integrating it with Visual Studio.  It discusses Ankh, VisualSVN, and an add-in developed by Garry Bodsworth (described here).  There are some useful tips on Subversion in general, and some of the comments have interesting questions and answers as well.

Wednesday, October 17, 2007

Beginning the WCF Journey

I'm going to dip my foot into WCF.  That's more than a toe but less than a headlong dive.  Of the four books listed in our library, I have found two.  Here are some quotes from the intros:

...you might instinctively treat WCF as just another API.  Resist this temptation... WCF is not just a wrapper around existing functionality or just another whiz-bang API.  WCF is the evidence that a tectonic shift has occurred in distributed software development.

Justin Smith, Inside Windows Communication Foundation

Tectonic shift!?  Wow!  Equally as eye-opening is this one:

To me, WCF is simply the next development platform, which to a large extent subsumes raw .NET programming. 

Juval Lowy, Programming WCF Services

This could be fun...

F# About to go Mainstream

I've been noodling around with F# for a while, partly to get used to the upcoming Functional Programming F# Major Chordfeatures of C# 3.0, partly to expand the way I approach programming problems.  Now, Somasegar has announced that Microsoft will be making F# a first class language, along with C#, VB.NET, etc.  This is very  good news, not only for devotees of ML-type languages, but also for FP in general.  When something is readily available in Visual Studio, there's more of a likelihood that someone will give it a try*. 

And while it's true that other ML implementations for .NET have been around for a while, such as Nemerle, SML, CAML, OCaml and Haskell, the polish that Microsoft will put on F# will make it much easier to use. 

Also, unlike some of the above examples, F# is under active development by Microsoft Research in the UK.  Don Syme is the leader of the team.  F# can be either compiled or scripted like Python, but it has ML's type inference and is type-safe.  It generally performs as well as (or better than!) compiled C# code.  For an intro and overview of features, check out the project's main page.

 

 

 

 

 

 

* Except for J#.  Don't ever try J#.

Monday, October 15, 2007

REMs don't sleep

Let's say you have a .BAT file with a command like

c:\bin\dcc32.exe   [parms to compile a Delphi program]

It will return an %errorlevel% of greater than zero if the program does not compile, zero if it does.

Since I was testing this by double-clicking, I put a PAUSE statement right after it to see the output of the compile step. 

c:\bin\dcc32.exe   [parms to compile a Delphi program]
pause

Once the whole build project started working, I left the PAUSE in but REM'ed it out so I could remember what I had done in case I needed to go back and debug later.

c:\bin\dcc32.exe   [parms to compile a Delphi program]
rem pause

It turns out that REM is an "active" statement in a .BAT file and sets %errorlevel% to zero!  When the compile line really did fail, the error was being masked by the REM right after it, so the MSBuild project kept going as if nothing was wrong.  Once the REM line was removed, the MSBuild project failed as it should.

Wednesday, October 10, 2007

A gift idea for that special someone

Got somebody who's hard to buy for?  Here's something that's appropriate for either a nerd or a geek.

Database Humor

From xkcd.

Thursday, October 04, 2007

Software Branching and Parallel Universes

There's a nice description of version control branching and merging on Jeff Atwood's blog.  He points out some patterns and anti-patterns taken from a Microsoft article.  We are facing some complex issues with branches and customer-specific features right now at work.  I don't know the best answer (yet), but these two articles give a good framework for discussing the technical as well as organizational ramifications.

Wednesday, October 03, 2007

Whodunnit?

If your code is running in a Sql Server context (sproc, trigger, CLR assembly, etc.) and you wish to know who initiated the execution, you can try the T-SQL command SELECT SYSTEM_USER.  This will give you one of three answers:

  1. The Sql Server userid, if Sql Server Authentication was used to log in
  2. The Windows user in the form Domain\UserLoginName, if Windows Authentication was used to log in
  3. The name of the currently executing context

Number three is interesting, because it masks the "real" user identifier behind a persona.  To change your context, issue the command

EXECUTE AS USER = 'Gsl\SierraServer'

Then no matter who you are or how you logged in to the server, SELECT SYSTEM_USER will return "Gsl\SierraServer".  The BOL even calls it the "impersonated" context.

Not that customers would ever fiddle with sprocs or table schema or permissions that you carefully craft and install...

Monday, October 01, 2007

Helper DLL for MSBuild

In creating a new build, I found I needed a way to set an environment variable within the MSBuild script for subsequent use by a .BAT file.  On CodePlex, I found a project called SDC Tasks Library that filled the bill and then some.  From the site:

This is the latest version of the SDC Tasks for .NET 2.0. The SDC Tasks are a collection of MSBuild tasks designed to make your life easier. You can use these tasks in your own MSBuild projects. You can use them stand alone and, if all else fails, you can use them as sample code.


There are over 300 tasks included in this library including tasks for: creating websites, creating application pools, creating ActiveDirectory users, running FxCop, configuring virtual servers, creating zip files, configuring COM+, creating folder shares, installing into the GAC, configuring SQL Server, configuring BizTalk 2004 and BizTalk 2006 etc.

This used to be on GotDotNet (RIP) but is alive and well now on CodePlex.  To use this in your MSBuild script, put something like this at the top of the script:

<UsingTask AssemblyFile="Microsoft.Sdc.Tasks.dll" TaskName = "Microsoft.Sdc.Tasks.SetEnvironmentVariable" />

When you need to use it...

<SetEnvironmentVariable Variable="MyEnvVar" Value = "$(BuildPathVar)\Bin" Target="Process"/>

The help file that comes with the .DLL is only a reference and seems to have no examples, but for some tasks, the usage is pretty clear.  As always Google is your friend for real-life examples.