Taking random elements out of a collection using LINQ

2. maart 2013 10:05 by martijn in

An elegant solution is so simple that something seems to be missing. I had that feeling when I found this solution of taking a random subset of a set of items:

 

 
 public static IEnumerable<T> TakeRandom<T>(this IEnumerable<T> list, int count) 
{
var shuffledList = list.OrderBy(l => Guid.NewGuid());
return shuffledList.Take(count);
}



Programming is not plumbing

27. februari 2013 12:26 by martijn in
As a C# developer I have a natural preference of C# over plSQL. Nevertheless i think there are many reasons why not to put business logic into the DB.
 
  1. plSQL does not contain the same high level building blocks (interfaces,classes,assemblies) as 3G languages. There might be equavalents sometimes for example packages but overall plSQL is a lot less expressive.
  2. Stored procedures quickly turn into large functions which are not nicely divided into small blocks. It might be possible with temp_tables etc but in practice these constructs are not used very often
  3. Introducing a SP layer usually introduces more people into the development process. Apart from changing the schema you also need people with plSQL knowledge.
  4. Adding a SP layer makes your code less DRY. Adding an extra field requires updating of all create and update SPs. This is boring, simple, repetetive and therefore very error prone. Moreover the repetitive nature of plSQL prevents changing your model and leads to suboptimal code.
I am not saying you should use EF directly in your business or view code but I do think that a DAL layer using EF instead of stored procedures strongly reduces the development time,maintenance and errors. Putting you data access code in a separate layer does allows you to switch to other techniques (for example from EF to SP) if needed.

Compiling aspx forms

27. september 2012 13:02 by martijn in

Build succeeded run...fail. It annoys me that I use a TYPE SAFE language like C#, use ASP.NET with ItemType (strongly typed stuff) and still get runtime errors. So I have to click through every page when I refactor? 

 
Luckily compiling the views can be done by adding a afterbuild or using a postbuild event. Here what you paste in your afterbuild event to get the aspx compiling :
 
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_compiler.exe -v /-p "$(SolutionDir)$(ProjectName)"