According to www.dictionary.com:
Option: the power or right of choosing.
According to Visual Studio 2010 installer:
One of the projects I’m working on is a product catalog update service. Basically, it provides a couple of web services that updates the database following some rules. One of the services receives a review and upgrades the metadata according an analysis of the text. When I came to the project, all was implemented but it was slow, so my work was to help optimizing the code. I love when projects follows the “desing first, optimize later” idea.
The model have a Searcher class that looks for a series of terms in the text and returns the ones contained in it. The performance problem begun when we started using a real database containing 50000 terms. Let’s assume that the search algorythm is really fast.
Since the text we received has something like 1000 words, the first approach we thought was to create a text with the 50000 terms and to look the 1000 words in it. It didn’t work, because we have to look for terms, not words, and terms could have spaces, so it’s impossible to know where to cut the text.
Well, analyizing the stored terms we realized that several terms were similar or, what is more interesting, started with the same word. So we indexed the terms by first word and look for those words first. Once we know which words exist in the text, we could look for the terms starting with those words only and reduce the amount of terms to find.
Well, the amount of “first words” was ~3500, and it was solved really fast. Finally, the new code performed 25 times faster that the old one :). I was really impressed.
Few days ago we were doing a new algorithm for a existing (and slow) feature. Basically, the algorithm returns a list of strings, and the way we choose to test it is to trust the first one and run both algorithms looking for the same result in both. The first line of the assertion is natural:
But the second one seems to be coded by Yoda
Ok, it’s not actually a Yoda style sentence, but I found it quite funny.
I don’t understand what’s happening. Besides the aberrant idea of havig such a monster without a way to mock it by design (I know, TypeMock supports Sharepoint isolation, but it’s not by design and it’s not free), they just disabled the possibility of doing unit tests over it.
Basically, it seems like Sharepoint runs in .NET framework 3.5 and you can’t change the target of a Visual Studio Test Project to 3.5, it has to be 4.0. So, you are not able to test it.
One more time, I’m moving to NUnit.
In Microsoft’s site, it says:
Windows PowerShell 2.0 is a pre-requisite for installing SharePoint 2010 Products. It will be installed, if necessary, when you run the Microsoft SharePoint Products Preparation Tool. By default, Windows PowerShell is located at the following path: \System32\WindowsPowerShell\v1.0\PowerShell.exe.
Could anyone explain me why 2.0 version is in 1.0 folder?
I’m working on a project that has some performance issues. One them is one single page that takes more than a minute to show. I analyzed what was going on and the truth was that the page’s size was about 3.5 mb. So, what was making the markup so large? comboboxes. Seventeen comboboxes with about 600 options average (but there was some with 2000 options!).
My first reaction was “Why in the hell they need a combobox with 2000 options? this is a functional failure”. But you know, “it’s what the client wants, it’s too late for chaning it now”.
The first solution we came with was to render only the selected value in the markup and to populate the entire list using ajax when the user clicks/focuses on the combo. The great about it is that the ajax responses could be cached by the server side for reducing the server processing and by the browser, so there’s no need to go find the same items again. Just lovely.
And it worked, and worked fine. Except for Internet Explorer. For some reason, if you change the options collection, the select will close, so the user have to click it again.
Our second approach was to call the populate method when the page loading is complete (aka document.ready). The idea was to have the user filling the form while the combos where loading. And, of course, we could make use of the sweet cache I told before. Well, loading about 9000 options will crash your browser. In this way, it takes more time than the 3.5 mb page! So we moved from adding options using the DOM to use innerHTML, so we can change all the options in one shot. It works perfect in firefox, but for internet explorer… well… This code:
var combo = document.getElementById("combo"); combo.innerHTML = "<option value='1'>Test1</option><option value='2'>Test 2</option>" alert(combo.innerHTML);
Gives me this:
And, of course, it doen’t work. Then, I tried this approach:
var combo = document.getElementById("combo"); var option = new Option(); combo.add(option); option.outerHTML = "<option value='1'>Test1</option><option value='2'>Test 2</option>" alert(combo.innerHTML);
And it gives me the same result!! It just doesn’t make sense at all! At least, Microsoft is aware of it… are you kidding me? it was found in the IE 5.5 era and continues broken?
Changing the combobox outerHTML works, but we miss the reference to the previous combo in the DOM and the ASP.NET Validators stop working.
After days of Internet Explorer induced stress we decide that the problem was actually functional, and called the client. He confirmed that there shouldn’t be so many options and that there should be a configuration problem, so we limited the amount of options to 200 and start working on the configuration issues instead.