-
-
I've started listening to podcasts from the PBS series NerdTv and today I was listening to a conversation with Max Levchin, one of the co-founders of Paypal. who had just been through his third all-nighter - that week. He said it was not unusual for him to do this, and some people like all-nighters and some don't. (An all-nighter is when you work through the night on some problem, or coding thing - in Microserfs it was referred to as a "Trip To Australia".)
I have only done a handful of all-nighters, but there is something about the level of productivity you can achieve - though for me its spotty, there is a time where I am very hyper-focussed and productive, then at some point you hit the wall and push on through, and I'm not sure of the quality of code after that point.
He also mentioned working weekends in the same way.
I think one of the biggest reasons that working all-nighters (and to a lesser extend, weekenders) can be productive is that a lot less people or things interrupt you. Its easier to stay "in the zone" with no phone, email, messaging, TV, co-workers, bosses, yadda yadda (the last all-nighter I did was with Joel, and I told him to go to sleep about 3:30 am).
In some ways, I'd like to have two summer vacations a year - one with my family, and one where I send them somewhere without me, and I hole up somewhere and code on my pet project for two weeks (it's been too long since I've had a pet coding project).
In a recent DotNetRocks show, Carl Franklin was talking to David Smith, writer of btSharp (a BitTorrent client written in C# 2.0), and David told of a time when he was coerced into an all-nighter by having a benefactor deliver four pizzas and six large bottles of Mountain Dew to his dorm room late one evening. (The benefactor was Carl Franklin.)
-
-
I was just looking at the Composite UI App Block (for .NET 2.0 recently released) and they ship with their framework both Nunit and Team System tests.
The really cool thing is this: the test source files are common between the two of them. Here is the header:
#If (Not NUNIT) Then
Imports Microsoft.VisualStudio.TestTools.UnitTesting
#Else
Imports NUnit.Framework
Imports TestClass = NUnit.Framework.TestFixtureAttribute
Imports TestMethod = NUnit.Framework.TestAttribute
Imports TestInitialize = NUnit.Framework.SetUpAttribute
Imports TestCleanup = NUnit.Framework.TearDownAttribute
#End If
This maps the attribute names from TeamSystem into Nunits attributes, and it looks like the Assert methods are the same (or they have used the same methods).
-
-
I love Authorization Manager (AzMan), especially the idea of using role-based authorization, but with the roles being outside of the application altogether. So, from an developer point of view, you tell AzMan that you have a certain named application, and it performs a set of operations, let's say "OrderWidget", "UpdateInventory", and "CreateNewProduct". Then an administrator can create roles, organize operations into tasks, and assign permission to roles for tasks or operations. Finally, administrators can map Active Directory users or groups (and with a little help, other types of non-AD identities) into those roles.
In the code, the developer simply asks AzMan if the user has permission to perform an operation. AzMan figures out what AD-groups the user belongs to, what AzMan roles they belong to, and what tasks and ultimately operations are assigned to those roles, and then answers back Yes or No. So, instead of role-based authorization in the code, such as the developer testing if the user is a member of the Managers role, the developer simply asks, is the user authorized to perform the operation "OrderWidget"?
This means that what it means to be a member of Managers can change over time, in terms of what operations that role can perform, without recompiling the application. If the need arises for a "Supervisors" role in the future, that has a subset of permissions of the "Managers" role, it can be accomplished administratively through the AzMan MMC snapin.
Now, with web services happening all over the place, security for them is a concern. Here's an article in MSDN Magazine (Nov 2005) that shows how to hook up AzMan with a WSE3 web service, so that the web service's policy configuration can be used to map web services and methods to AzMan operations automagically.
-
-
At the company Christmas Party a couple of weeks ago, the employees received an iPod (30GB) as a present. A great feature of these particular set of iPods was that our names were engraved on the back, otherwise I would have had a fight on my hands with my wife and my oldest daughter (who is turning into a big-time geek) over this new toy.
Anyway, I have been downloading PodCasts and listening to them on my commute, which is about 30-40 minutes each way. What a great way to spend that time.
The programs I have been listening to are DotNetRocks! and SqlDownUnder. I also found today an ASP.NET podcast, which I might catch up on. Maybe Joel and I will think of enough things to start a podcast of our own.
These programs are entertaining (especially DNR!) and very informative - I especially enjoyed the SqlDownUnder episode with Itzak Ben-Gan. What a brain that guy has, and his puzzle solutions are often so elegant. Great food for the brain.
-
-
I'm getting into writing tests for a .NET 2.0 project, and I must say that one of the great things about writing unit tests in the Team Test environment is how easy it is to run those tests in the debugger in Visual Studio.
I've also been mentoring a class of .NET newbies, using VS.NET 2003, and I've been forcing them to write NUnit tests to test the code they are writing. They're buying into the process, and running them with the NUnit-gui tool, getting green lights before moving on. However, when their code generates an exception or they want to step through their code to see what it is doing, attaching to the debugger is really hard to help a beginner to do. I tried using TestRunner but it's unreliable at picking up the tests in the projects. And of course, throw in a .config file and the class feels like they are learning more "voodoo science".
Moving from VS.NET 2003 to VS 2005 and Team Test, it was so easy (though I haven't tried using a .config file yet).
I found out this week that my next six-month consulting engagement as some kind of developer team leader, begining Monday, will be using VS 2005, and if I have any influence, I hope we will adopt Team System to some degree during the project. I'm really happy about that, and I really hope that I will be able to guide the team through some best practices, and influence the project managers to adopting some new methods.
-
-
There's a new post from bHarry telling how they scaled Team Foundation Server to a team of over 2000 developers, using a dual processor 2.8 Ghz, 4GB application server and a quad-processor 2.7 Ghz, 16 GB database server.
They used a test set of 750,000 work items and 1,350,000 files.
That's pretty impressive I'd say. Team System should be usable by small shops (less than 5 developers) right up to the big enterprises.