September 2008



Early one morning, a programmer asked the great master:

“I am ready to write some unit tests. What code coverage should I aim for?”

The great master replied:

“Don’t worry about coverage, just write some good tests.”

The programmer smiled, bowed, and left.

Later that day, a second programmer asked the same question.

The great master pointed at a pot of boiling water and said:

“How many grains of rice should put in that pot?”

The programmer, looking puzzled, replied:

“How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”

“Exactly,” said the great master.

The second programmer smiled, bowed, and left.

Toward the end of the day, a third programmer came and asked the same question about code coverage.

“Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table.

The third programmer smiled, bowed, and left.

After this last reply, a young apprentice approached the great master:

“Great master, today I overheard you answer the same question about code coverage with three different answers. Why?”

The great master stood up from his chair:

“Come get some fresh tea with me and let’s talk about it.”

After they filled their cups with smoking hot green tea, the great master began to answer:

“The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.”

“The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”

“I see,” said the young apprentice, “but if there is no single simple answer, then why did you answer the third programmer ‘Eighty percent and no less’?”

The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down.

“The third programmer wants only simple answers – even when there are no simple answers … and then does not follow them anyway.”

The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.

They are similiar but very different technologies. Astoria or what is now called at Microsoft ADO.NET Data Services is a programming library that will allow data to be passed through RESTful web services. You develop these web services to be run against data you have access to. ADO.NET Data Services is now included in the .NET 3.5 SP1 updates.

SQL Server Data Services is a new service provided by Microsoft. The following is a decription:

“SQL Server Data Services (SSDS) are highly scalable, on-demand data storage and query processing utility services. Built on robust SQL Server database and Windows Server technologies, these services provide high availability, security and support standards-based web interfaces for easy programming and quick provisioning.”

SQL Server Data Services is very similair to Amazon S3 service.

Here is accepted answer on my provocation on “Stack Overflow”.

 

Create documentation that speeds up communication and helps you move faster. Let the principle of “Mutual Benefit” guide you.

  • Adoption documents: “NewPerson handbook”. Getting started with any “framework” or niche tools you are using.
  • Also document team conventions if any.
  • Instructions for Setting up a development machine is another good one. Source Control server settings, Installation paths for tools used.
  • Product Maps: You would need product design roadmaps – block diagrams of various top-level components and the like. Tests can serve as the always updated specs – ground zero documentation.. but you need a simple word doc … bulleted list of high level product needs / features.
  • “Here the dragons lie” – any known minefields with products (esp. legacy), ‘Don’t tread here’ areas that you need to be careful while changing.. e.g. If you change something here, make sure you have it reviewed by Y and Z before checking in.

Core Metric: If you find no one on the team complaining “WTH? Why didnt anyone document this? I’m stuck.. How am I supposed to proceed on this?” – you’re good.

  • If the team finds that they have been drawing a class diagram or sequence diagram over and over, that’s proof that it is a useful artifact. Soon someone will make a sticky copy and save it somewhere to save time. Over time , the more useful artifacts would build up.
  • Don’t pester the team to churn out documents no one else will read…(No “This is mandated by the process”)
  • Don’t create documents that are 40-50 pages long. No one will read them.. “Take more time and write a shorter letter” 5-6 pages max.

Finally as for TFS, once again let the team tell you. If it seems to be working well.. continue if not find alternatives & switch.

 

by Gishu

If you are including scripts in your ASP.NET pages, don’t forget that you CANNOT put script tag like this

<script type=”text/javascript” src=”somescript.js” />

because browser will not recognise this as correct markup and probably all your stuff after this tag will not be correctly put to the DOM model.

You need to use this instead:

<script type=”text/javascript” src=”somescript.js”></script>

Is someone told me that they’re fully XHTML compatible? :)

This is part of my latest experience on working at the client side with some sensible network security restrictions (most port are closed even in local area network, default proxy is set up for all machines etc.)

There is one problem here when you trying to connect SQL Server 2005 from another machine in network and in doesn’t connect without any good error raised. The problem is Windows Firewall restricts access to the SQL Server by default. As soon as you can’t switch firewall off you need to add exception for SQL Server process to allow remote connections to your SQL Server instance:

So your Firewall Exceptions list should contain sqlserver record after all: