May 2004 - Posts
I noticed a few bloggers including Brad picked up Norman Alex Rupp recent TechEd blog postings. "These people don't write code--they have forms and wizards for developing just about anything you can think of. When they do write code, they have development tools that actually force them to write unit and performance tests" is an interesting statement from Norman. Over the last x months we have been churning through a lot of .NET candidates, a large majority of them really don't seem to care what code wizards generate, how .NET works under the covers, or why certain things work the way they do. A majority of the .NET candidates we've seen also don't seem to care or understand about performance issues. That's why the FxCop/Unit testing/etc integration that Microsoft is adding to Visual Studio 2005 is the best thing to happen to VS for a long time. At least now, developers who stay in the IDE world, can run everything in their world, and not have to think about running tools like FxCop externally - and hence not bothering to do so. I for one think that FxCop should be enabled by default in all VS projects - when I check VS 2005 May CTP last night, it appeared to be disabled by default.
Well if this is
true then
Barclays will be ahead of the curve, and its a win for Microsoft over
Linux in the UK. I'd be interested to know if this also applies to
Barclays Capital - the investment banking division of Barclays which has always used a lot of Microsoft technologies.
I wonder how well
this market/sales concept works. Nice to see a consultancy
blogging on their home page.
The VS.NET Reflector Add-In is very nice. Almost a must install.
Johan had some interesting comments on the Lomboz Eclipse plug-in. I downloaded Lomboz a while ago, but only recently got round to playing with it. This tutorial gives isn't bad for a quick introduction into what Lomboz can do for you. Checkstyle is another worthwhile plug-in to have installed, and then there's JadClipse - kind of equivalent to .NET Reflector.
Assuming this article (and here) is correct (big assumption), then maybe we can expect MPI on the CLR in the next few year. Most banks have some type of cluster/grid computing environment - either home grown (we wrote a distributed computing framework in using Microsoft COM (later ported to Java) in the mid 90's for internal usage), or using software from Platform or DataSynapse.
As both the articles above state, Microsoft has a bit of a hill to climb in the supercomputer arena. The current Top 5 supercomputer sites can be found here - the Earth Simulator being No 1, and running Super-UX (UNIX based OS).
Microsoft already has the Computational Clustering Technical Preview Toolkit, but this release doesn't have anything to do with the managed world.
It appears that the company I work for has a new client (hedge fund) and a new .NET project. The client already uses a lot of Microsoft technology, so it's not surprising that they are going to use .NET for the new development. WinForm as normal will be used for the rich client interface, with .NET remoting used to communicate to a number of .NET services (pricing, risk management, portfolio management, market risk - mark to market), SQL Server will also be used. There is also the possibility of some distributed .NET work being done further down the line, possibly using
Alchemi .NET.
CruiseControl.NET and CVS will be part of the development environment. A
colleague will be leading the project. From the look of his blog, there appears to be some message bus work on the project as well.
Sometimes in a WinForm, you need to associate a bit of data with a UI control.
Control.Tag then becomes useful, or a more preferable option,
IExtenderProvider.
I finally managed to remove some horrible if statements in the framework I am working on - I'd forgotten how useful
Double Dispatch was in removing
if/
is code (or in Java,
if/instanceof).
Its interesting to see Eric glancing at a Java book. A colleague recently purchased the same book, and we ended up having a similar discussion in the office centred around Chapter 2, "The Final Story". Overall I think the general feeling was that the book wasn't actually that hard core, but did highlight a number of good practices that should be followed.
With regards the sealed keyword in C#, microsoft.public.dotnet.language.csharp has an interesting thread. Which begs the question, why when calling the same method in different ways, does the JIT generate a different IL calling instruction (see IL below - call/callvirt)
using System;
namespace SealedTEst
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
Sealed s = new Sealed();
s.Hello();
new Sealed().Hello();
}
}
sealed class Sealed
{
public void Hello()
{
Console.WriteLine("Hello");
}
}
}
IL generate for Main:
.maxstack 1
.locals init (class SealedTEst.Sealed V_0)
IL_0000: newobj instance void SealedTEst.Sealed::.ctor()
IL_0005: stloc.0
IL_0006: ldloc.0
IL_0007: callvirt instance void SealedTEst.Sealed::Hello() // callvirt
IL_000c: newobj instance void SealedTEst.Sealed::.ctor()
IL_0011: call instance void SealedTEst.Sealed::Hello() // call
IL_0016: ret
Seth has an interesting viewpoint
More Posts
Next page »