mardi 15 janvier 2008

Google vs Wikiasari: The Results

The results are in for last week's edition of the Internet Evolution in-site poll: Google vs 'Wikiasari'.
Despite
harrowing first reviews of Wikiasari, or Wikia Search, Wikipedia's brand new search engine, the majority of Internet Evolution readers seem to harbor a soft spot for Wikipedia, which on the whole took precedence in their heart of hearts over their love of Google (Nasdaq: GOOG), Ask.com, and even (dun dun dun) their mothers.
In response to our question: "If [Wikiasari] launches successfully, would you choose it over Google?" our reader poll shows:
  • 56 percent responded "Yes."
  • 40 percent responded "No."
  • 4 percent responded "N/A" claiming to use a different search engine.

Citing Wikia Search's appeal as a trusted search engine based on user feedback, researcher Viboons notes that the search engine will have to really battle it out for a seat among the better-known search engines: "And Google, in particular, is the one company that is not easy to battle against as it integrates its search engine with its other Web apps, recognizes the dynamic nature of Web pages, and has the strong capability and resources to continuously improve and advance its search engine technology."
Regardless of Wikipedia's initial launch struggle and any windy, grindy roads to come, a look at our results shows at least one thing: We are not as head-over-heels in lovely love with Google as Google leads us to believe we are.
Moreover, for the end user, it seems a modest business model may be preferred to a lucrative business model hidden behind an almost laughable "we're on your side" facade. While we may have our gripes with many of Google's cyberspacious adventures, the fact remains that it performs search very well (hat, hand). Thus, the idea that 56 percent of our readers would abandon an already great, established search engine in favor of Wikipedia perhaps demonstrates distrust (disgust?) with Google as a company.
That's why this week Internet Evolution is giving you (yes, YOU!) a chance to unveil your true feelings for your Internet companies. In a brand new poll born today (awww), "Best & Worst Online Companies" we ask, "Of all the big-name companies in the online space, which do you love and which do you loathe?"
Here's your chance to really stick it to the companies that have made your virtual life hellish and, in turn, give an old teary-eyed thumbs up to the ones that have been like a reliable pal.
So take our poll before it's too late (which is never -- but sometimes you need good threat). And, if not too cowardly, go ahead and back up your choices on the boards.

Source : Internetevolution.com

lundi 12 novembre 2007

Releasing the Source Code for the .NET Framework Libraries


One of the things my team has been working to enable has been the ability for .NET developers to download and browse the source code of the .NET Framework libraries, and to easily enable debugging support in them.
Today I'm excited to announce that we'll be providing this with the .NET 3.5 and VS 2008 release later this year.
We'll begin by offering the source code (with source file comments included) for the .NET Base Class Libraries (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text, etc), ASP.NET (System.Web), Windows Forms (System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), and WPF (System.Windows). We'll then be adding more libraries in the months ahead (including WCF, Workflow, and LINQ). The source code will be released under the
Microsoft Reference License (MS-RL).
You'll be able to download the .NET Framework source libraries via a standalone install (allowing you to use any text editor to browse it locally). We will also provide integrated debugging support of it within VS 2008.
Integrated Visual Studio 2008 Debugging Support
The final release of VS 2008 will support the ability to configure the debugger to dynamically download the .NET Framework debugger symbols (and corresponding source code) from a web server hosted by Microsoft. You'll be able to configure the .NET Framework symbols to be downloaded all in one shot, or manually retrieved on demand.

dimanche 11 novembre 2007

Extensions for Microsoft AJAX Framework

Here I present the JavaScript library that extends Microsoft AJAX Framework with new classes. Undoubtedly Microsoft AJAX Framework is great. However, it doesn't provide or emulate all classes and functionality that .NET Framework does. That's why I decide to extend Microsoft AJAX Framework with some classes and methods that .NET BCL provides, and which can be useful in JavaScript environment.Currently library includes three files: Sys.Core.js, Sys.Text.js, and Sys.Crypto.js.
Similar to .NET 3.5 that provides additional classes through new System.Core.dll, Sys.Core.js provides additional methods for JavaScript native objects and some new classes like Sys.Convert.
Sys.Text.js contains classes representing ASCII, Unicode, UTF-7, UTF-8, and UTF-32 character encoding. These classes are helpful for data encoding or decoding and in cryptography services.
Sys.Crypto.js provides cryptographic services including secure encoding and decoding of data, as well as hashing and random number generation like System.Security.Cryptography namespace in .NET Framework.
In this article I describe how to use cryptographic services the library provides.Let's compare the most current and popular implementation of MD5 -
the Paul Johnston's implementation in JavaScript with the one we have in this library. First, Johnston's implementation requires string as an input. What does this mean? This means you cannot use any encoding you want. For example, if you hash some non-ASCII string with Johnston's implementation and compare it with the hash computed with the .NET's widely-known FormsAuthentication.HashPasswordForStoringInConfigFile method, you'll see they do not match. Why? Because HashPasswordForStoringInConfigFile method uses UTF-8 that Johnston's implementation is unable to provide. Cryptographic algorithm should not care about strings and encodings. It should work only with bytes like .NET works. Next is the performance. Sys.Crypto.MD5CryptoServiceProvider class works about 6 - 8 times faster than Johnston's one (much here depends on browser).Let's see how to use the class mentioned above.
Using the code
Using MD5 algorithm var buff = Sys.Text.Encoding.UTF8.getBytes("abc");
var md5 = Sys.Crypto.MD5.create();
var hash = md5.computeHash(buff);
window.alert(Sys.Convert.toBase64String(hash));
Compared with C# code: byte[] buff = System.Text.Encoding.UTF8.GetBytes("abc");
MD5 md5 = System.Security.Cryptography.MD5.Create();
byte[] hash = md5.ComputeHash(buff);
Console.WriteLine(System.Convert.ToBase64String(hash));
Sys.Crypto namespace provides classes for following algorithms: MD5, SHA1, HMAC, Rijndael (AES). Let's see how to use them. SHA1 algorithm: var buff = Sys.Text.Encoding.UTF7.getBytes("abc");
var sha1= Sys.Crypto.SHA1.create();
var hash = sha1.computeHash(buff);
window.alert(Sys.Convert.toBase64String(hash));
HMAC algorithm: var hmac = new Sys.Crypto.HMAC("SHA1"); // currently supported SHA1 and MD5
var key = Sys.Text.Encoding.BigEndianUnicode.getBytes("Key to mix");
hmac.set_key(key); // if key is not provided, a random genereted key will be used
var buffer = Sys.Text.Encoding.BigEndianUnicode.getBytes("Hello World!");
var hash = hmac.computeHash(buffer);
window.alert(Sys.Convert.toBase64String(hash));
AES algorithm: var aes = new Sys.Crypto.Aes.create();
// encrypting
var aesEnc = aes.createEncryptor();
var buffer = Sys.Text.Encoding.ASCII.getBytes("Hello World!");
var encrypted = aesEnc.transform(buffer);
window.alert(Sys.Convert.toBase64String(encrypted));
// decrypting
var aesDec = aes.createDecryptor();
var decrypted = aesDec.transform(encrypted);
window.alert(Sys.Text.Encoding.ASCII.getString(decrypted));
Sys.Text namespace classes now are fixed according to
Microsoft KB940521 (security bulletin MS07-040) except UTF7Encoding class which will be fixed soon.
Here I introduce Sys.Crypto namespace in a nutshell. For complete documentation of this namespace and its base and abstract classes (not mentioned here) see the attached files. Actually, currently there is no any documentation for classes in Sys.Core.js. It'll be ready soon. In the near future I plan to release XML and Drawing classes.Any feedback, suggestions, perfomance improvement, or critics will be welcome and appreciated.
Now available at
CodePlex.