The Number One Visual Studio 2009 Weblog on the Web
Hebrew BlogSyntax:
VLOOKUP(A2, D$11:E:22, 2, False)
Means:
If the value of cell A2 matches a value in the supplied range (Cells D11 to E22), the function’s result is the value of the second column from the range, from the row containing the matching value.
This function and the matching HLookup function can be very handy.
2 comments » | Uncategorized
Frans Bouma thinks that looking at the source code makes you liable to legal action:
Take for example the new ReaderWriterLockSlim class introduced in .NET 3.5. It’s in the System.Threading namespace which will be released in the pack of sourcecode-you-can-look-at. This class is a replacement for the flawed ReaderWriterLock in the current versions of .NET. This new lock is based on a patent, which (I’m told) is developed by Jeffrey Richter and sold to MS. This new class has its weaknesses as well (nothing is perfect). If you want to bend this class to meet your particular locking needs by writing a new one based on the ideas in that class’ sourcecode, you’re liable for a lawsuit as your code is a derivative work based on a patented class which is available in sourcecode form.
Phil Haack partly disagrees, and sees no problem as long as you exercise caution.
I think both of them may be missing another side of this mess:
Suppose you read the source code, and some time later, after you forgot all about it, you write your own ReaderWriterLock which violates Microsoft’s patent.
Now, the hotshot lawyer working for Microsoft has no way of proving you read the source code prior to writing your implementation - but he doesn’t need to. He only needs to claim that since your code works in a similar way to the MS code, and since MS code is already out there, it’s highly probable you read it.
In other words, this move gives Microsoft an extra advantage in future patent lawsuits, even if no one reads the thing.
The conclusion: read the source code, even for the single purpose of being sure your code doesn’t violate any patent.
I previously wrote a post on password security based on Jeff Atwood’s post explaining “Rainbow tables”.
As it turns out, Jeff received a feedback from cryptographer Thomas Ptacek pointing out some corrections to the strategy offered in the original post.
The most important idea was using a cryptographically secure hash, meaning hash which expansive in processor time, unlike the common MD5.
One alternative is the Bcrypt algorithm, which has a C# implementation from Derek Slager.
(thanks to Kansir for the photo)
