After lots new coding, refactoring and upgrading to .NET 3.5, dotNetTips.Utility 3.5 is finally released! This assembly is much of the common code I have been writing for the past 8+ years all wrapped up in a nice package and easy to use.

read more: dotNetTips.Utility 3.5 Released

What’s great about this is that you will get some serious tools and the VB.Net source to see how they work.  Dave is a proponent of Standards and you can see in this library how he implements some of the techniques he talks about.

From AvailablePhysicalMemory to UsStateCollection the helpers get you from nowhere to somewhere fast.

Highly Recommended!

Codeplex Project: http://dotnettips.codeplex.com/

Today, one of the biggest payment gateways, Authorize.Net, went down because of a big power outage caused by a fire. Everyone is twittering like crazy, ranting and asking customers to order by phone.

Authorize.Net is also our payment gateway at work, but this wasn't a major issue for us. We just had to swap the payment processing implementation from Authorize.Net with the one that uses a Verisign Payflow Pro account, and that's it. We even didn't have to shut down the site because we have this set up via dynamic.web.config.

Really, you gotta love dependency injection in times like these!

In the end, you get a chance to win a conference pass to the Microsoft SharePoint Conference 2009 (October 19-22) in Las Vegas. This pass is worth $1,119 USD if purchased with real money. A winner will be drawn randomly after the closing of the survey July 17th then notified by email and/or phone. Note the contest is *only* for the conference pass. You still need to provide a way to get there and pay for your hotel, mini-bar, and pub crawl expenses (and trust me, when you hang with SharePoint dudes, the bar bill can get pretty hefty). Still, it’s a short slice out of your life for a chance to make it big in the city that never sleep.

You can fill out the survey here. Enjoy and good luck!

Tonight, you’ll be the judge in this first contest of charm, grace, and readability.

Contestant #1 hails from the System.Web.Mvc namespace. It likes pina coladas and string literals, but is turned off by tattoos that look like programming symbols. Let me introduce the SelectList class:

var products = GetProducts();
var selectItems = new SelectList(products, "ID", "Name");

Contestant #2 lives in the System.Linq namespace. It likes whips and method chains. Functional programmers call it “map”, but in .NET we call it "Select":

var selectItems = from product in GetProducts()
                  select new SelectListItem 
                  {
                      Text = product.Name,
                      Value = product.ID.ToString()
                  };

var selectList = GetProducts().Select(product =>
                    new SelectListItem
                    {
                        Value = product.ID.ToString(),
                        Text = product.Name 
                    });

Contestant #3 lives in the MvcContrib project. It’s turned on by pointy things and practices yoga for extensibility. Introducing the ToSelectList method:

var selectItems = GetProducts().ToSelectList(product => product.ID,
                                             product => product.Name);

Personally, I like #2. While the name of #3 makes its purpose obvious, it sometimes takes a moment to be 100% clear about what property becomes Text, and what property becomes Value. In #2 the Text and Value assignments are obvious, even though the code is a little longer. Setting the Selected properties with either approach is trivial.

What do you think?

http://forums.iis.net/p/1158781/1909100.aspx

Great stuff!

Steve

I want to thank to all the people in Microsoft Uruguay and Latinoamerica that kept inviting me to talk in their events.

Here is my almost-empty MVP Profile. I'll complete it during the following days.

Thanks!

Before you get too excited; it’s quite obvious that when you use this sample on a production server with lots of users, the SharePoint Search component can be hammered with lots of requests (which can be bad for the performance). So use it wisely! To minimize the impact on the performance of the server, the code will only execute a search query when (by default) three characters are entered, and while the user is still typing no queries are executed at all (there’s a configurable delay).

So how is all of this implemented? Well the idea is to display an HTML textbox in a Content Editor Web Part. Using the jQuery library, an eventhandler is added to that textbox for every keypress. When there are more than three characters (value is configurable) entered in the textbox, jQuery will make an asynchronous call to the Search web services (/_layouts/search.asmx). The resulting found items are displayed in an HTML div element which is positioned right below the textbox, on top of all other HTML elements. The user can select a result using the arrow keys, or by hovering the mouse over a result. When a result is selected by pressing the enter key or by clicking on it, the user is redirected to the corresponding page or document. You can see the code working in a web part in the following animated screenshot.

If you want to try this out yourself, just follow these steps. Once again, there is absolutely nothing you need to tweak and/or deploy on your server. You can do all of this through the web user interface of SharePoint.

1. Download the code file here.
   
2. Add a new Content Editor Web Part, which is available in SharePoint out-of-the-box, to a page.
3. Modify the newly added web part, use the Source Editor button in the properties task pane to add the downloaded code.
4. Optionally you can give the web part a meaningful Title in the Appearance group (e.g. Quick Search).
   

When you check out the code, notice that the first line is a reference to the jQuery library, hosted on Google’s servers. If you plan to use this in production, I’d recommend you to host the jQuery library in your own environment so you have to update the reference with your own URL.

Yesterday I’ve been informed that I’ve gained the Most Valuable Professional award again for next year, in ASP.NET category. This is the third time I have received this award, which is pretty exciting.

Here is my MVP profile: https://mvp.support.microsoft.com/profile/Ashraful

Special thanks to few Microsoft employees including Technical Fellow Brain Harry, Sr. Program Manager Joe Stagner, Lead Product Manager Dan Fernandez and South Asia MVP Lead Abhishek Kant who encouraged and supported me in several ways last year.

Thanks Microsoft for this recognition, which will encourage me to keep my passion on MS products continued with more optimization and greater efforts.

The book was previously already announced in beta 1, now it's the Beta 2 release.

Find all the info at the Codeplex site : http://codeplex.com/TestingGuidance

Application localization is not a trivial task for any type of application scenario. The process is based on a few core principles that apply to WPF as they do to any other type of client application with a user interface.
It is important for developers to understand the basic concepts of regional data display, locale-specific user interface customization and how to serve localized resources in both static and dynamic fashion. These concepts are very similar for most client applications but the actual process of localizing the static user interface components tends to vary between environments and WPF introduces yet another approach to resource localization for XAML resources.

Rick Strahl & Michele Leroux Bustamante have published a Localization Guidance whitepaper (June 2009). It starts with a quick review of general localization considerations for completeness, discusses how the .NET Framework handles resources for all applications, and then focuses specifically on localization scenarios for WPF explaining some of the trade-offs within each approach.
This whitepaper is complete and may be updated according to YOUR feedbacks.
Download it (and some source code) here: WPF Localization Guidance Whitepaper.

You may also be interested in Microsoft's WPF Globalization and Localization Overview, which has a lot in common with RIck and Michele's guidance.
And how would you implement the the translation of application resources into localized versions for the specific cultures that the application supports?
When you localize in WPF, you use the APIs in the System.Windows.Markup.Localizer namespace. These APIs power the LocBaml Tool Sample command-line tool, which was developed by Microsoft to present a sample that uses some of the localization APIs and illustrates how you might write a localization tool.

There is also the CodePlex WPF Localizationan Extention project which is a (FREE) stable extension project to localize any type of DependencyProperties on DependencyObjects.

As you can see, there are many (and good) ways to implement localization in WPF project. If you know any other great localization tools, please share it with us.
Thanks,
J.

"... Sehr geehrter Herr Tomicic, herzlichen Glückwunsch! Wir freuen uns, Ihnen den Microsoft® MVP Award 2009 verleihen zu können! ..."

Da freue ich mich aber auch. Vielen herzlichen Dank!

Die MVPs sind eine begeisternde Truppe von Technologie-Enthusiasten. Ich genieße die Treffen mit den MVPs und die Diskussionen, wie zuletzt beim Software Strategy Summit in Köln [2].

Und ich bin froh und fühle mich wirklich geehrt ein weiteres Jahr dazu zählen zu dürfen. Klasse! :-)

[1] http://mvp.support.microsoft.com
[2] http://blogs.msdn.com/mvpawardprogram/archive/2009/05/18/german-mvp-interviews-steve-ballmer.aspx

This also pointed out to me that I was doing something annoying. I was reading the data out every time for every image request. Not exactly the most efficient use of resources. Static files come down with information in the headers indicating when they were last modified (IIS, and presumably any other Web server does this), so the next time the browser makes the request, it the server compares the time in the request header with that of the file, and returns a 304 "not modified" response, and no file.

That seemed like an obvious thing to do, even if it has no impact on Google indexing. Fortunately, it just required some refactoring of the IHttpHandler I had doing the work.

Sidebar: This is probably the point at which some people will make a big stink about serving images out of a database, and how it's bad for performance or scalability. That's a fine argument to make, but outside of doing obviously stupid things, this is not an issue here. I'd prefer to address performance and scalability problems if I have them, not when I might have them, or never have them. Seriously, this is a site that does somewhere between a half-million and a million page views a month depending on the season. There are no performance issues here.

So anyway, assuming for a moment that "photo" is a business object in this code, and it was determined by a query value to the handler, this is the meaty part of the ProcessRequest() method of the handler:

Yes, it probably needs to be refactored, and yes, it should probably be used in an IHttpAsyncHandler. But let's go through what's happening, starting at the bottom.

The last few lines write out the actual bytes of the image (MIME type was set in previous code), then set the cacheability and the modification time of the image, which in my case is stored with the bits. The goofy part is where we create a new DateTime to make its kind known. If you don't explicitly state that it's a UTC time, the SetLastModified() method apparently adjusts it. I happen to store most times as UTC, so that was one less thing to worry about. This adds a header in the response called Last-Modified, and gives it a value that looks something like "Sun, 22 Jun 2003 16:27:19 GMT" (note that it truncates milliseconds and ticks, as you may expect).

Now, on subsequent requests for the same image, the browser adds an If-Modified-Since header to the request, with the same date and time as the value. Here we're checking to see if the value is present on the request, and if so, let's see if we should do a 304. If it's there, we parse it into a DateTime and compare the time with the one stored in the business object. We're stripping off the milliseconds because the database will fill them in on our DateTime, and the incoming request doesn't have the same high resolution. If we have a match, we send out the 304 and return, not sending any more data or reading the bytes from the database.

You can do this pretty easily in ASP.NET MVC as well.

Let me start by saying that this was something I just prototyped. It's in dire need of refactoring, as much of the logic isn't stuff you'd normally put in a controller action. I think there's a method for returning nothing on the Controller base, but I don't remember off the top of my head. If there is, you'd use that instead of Content() in the 304 case.

I hope this helps someone out!

Attended Cloud Camp PDX today.  Great overall conversation, with a lot of familiar faces & people of the Portland brain trust participating.

The conference started off with a large group gathering in the main cafeteria room.  There was an unpanel put together with a few cloud gurus.  After a round of questions the main sessions where laid out and everyone started out to the break out session.  Open session conference topics ranges from couchdb to cloud security, to the glorious tips and tricks of Amazon.  Overall a great bunch of discussions really breaking down what a cloud is and what a cloud does.

Overall a lot of fun, great food, and good people with great minds.  One has to love to Portland tech scene.  If there was ever a reason for a company to locate in Portland, this room full of talent discussing the bleeding edge of technology is a prime reason.

After that we all broke into second set sessions.  I went to the "Is Cloud Computing a return to the time share, maintenance model, and what does that mean?".  I have to say, I don't think it will ever be an honest return to truly dumb terminals and server focus, it will continue to be mixed.

That was it for me, being the host I had cleanup and such, so hope all had fun.  I had a blast as I tend to at nerd events.  All in all, a good day.

Of those developers who think they know what unit testing actually means, I would be willing to bet that only about 10% really do. You see, the problem is that when most developers are asked to define unit testing they will say something like “tests that are run against a project using a unit testing framework”. That is kinda right… well… not really. It isn’t really right at all. In fact, calling frameworks like NUnit, xUnit, MbUnit, MSTest, etc… “unit testing frameworks” is inaccurate. They are instead “automated testing frameworks” which can be used to execute any number of kinds of tests. One of these kinds of tests just happens to be unit tests. There are also integration tests, performance tests, load tests, etc…

Okay, so what exactly is a unit test? It is a test which verifies a “unit”, or the smallest piece of an application which is able to be tested. Ideally, when writing a unit test in C#, you’d want to isolate an individual class and write tests against only its functionality. The developers doesn’t want to pull in external dependencies and doesn’t want to access external processes or services. Unit testing is all about testing small pieces in isolation.

So why would we want to write tests like this? Many reasons…

They are fast. Have you ever worked in a system that mixes unit tests and integration tests? How long did they take to run? I have worked in a handful of systems that weren’t very large and still had suites of tests that took 10+ minutes to run. How often do you think that developers are going to run these? Not very often at all, and being able to run your unit tests quickly and easily is very important to having quick feedback while developing. Forcing developers to sit through minutes of tests will guarantee that your tests will rarely get run. A broken test found after a developer has moved on to another task will take them substantially longer to fix than one they find right away.

They are reliable. If all of your tests only operate in memory and don’t touch the disk, go across the network, query from a database, etc… then we can be assured that these tests will, for the most part, run smoothly. You won’t have to deal with numerous different settings, connection strings, external processes, etc… Tests which don’t run reliably, or can break frequently will merely frustrate developers and keep them from running them. Remember, tests are useless if they aren’t run.

They are accurate. By this I mean that since they only test very small pieces of functionality it is often quite easy to tell what has broken when the test fails. In a test that crosses a wide swatch of the application, it can often be much harder to figure out where the breakage actually occurred. Having pinpoint tests makes sure that you can find your regressions quickly.

They are flexible. Applications are full of unexpected events. But if they are unexpected, then how can we make them happen in a reliable manner? How can we force a database to throw an exception during a query? Well, in many cases we probably can’t. These are the cases where unit tests allow us to fake dependencies in order to raise exceptions or to cause situations that would otherwise not likely come up during normal execution. Sometimes we don’t care about these events, but sometimes we do, and when we do we need to have some way to force them so that we know how our application is going to respond.

Does this mean that if we are writing integrations tests then we don’t need to write integration tests? Of course not! What it does mean is that integration tests need to be separated out from your unit tests so that they can be run in a single environment away from the developer’s desktop. Ideally this would occur on the build server. This way the developer doesn’t have to worry about long running or brittle tests. If all of the unit tests passed, but the integration tests didn’t, then the developers can take the time to figure out why these tests are executing correctly.

This is all great, why isn’t everyone writing unit tests? Well, unfortunately unit tests aren’t a cure-all. Many people complain that writing unit tests is a burden that they just don’t have time for. In fact, I came across a post today that said just that. I think that this is a myth that is generally driven by poorly designed software. Now I know that this is a generalization that is made quite frequently, and one that is even harder to back up, but I really think that this is the truth.

In an ideal system you would be writing unit tests as you are writing your classes, and then you would writing your integration tests as you integrate them in with the rest of the system. In some larger systems, units tests can be unavoidable. Often different pieces of the system are being written before their dependencies have even been created. Or they are created by separate teams that are simply developing against an interface. In these cases the unit tests would be written long before integration tests are even possible.

Another complaint that I often see is people complaining about brittle unit tests because they are using facilities such as MSTest’s accessors which allow developers to directly tests private methods (which I personally think is very bad practice, but that is another rant). Either that or they haven’t factored out methods in classes enough and they are trying to test way too much. Getting used to testing public interfaces of classes and not relying on internal implementations will go a long way toward having less brittle tests.

Automated testing is an indispensible tool, and unit testing is just one of the tasks that you should be performing with it. Testing your application from top to bottom is very important, but making sure that the individual pieces of your application work in isolation is often the only way to reliably and quickly exercise a lot of the code in your application.

Next time you are writing an application, give it a shot. Split out your unit tests and integration tests so that they can be easily run separately. You may not notice any advantage at first, but once your suite of tests grows large you’ll find that you are able to write new code much faster because you have almost instant feedback on regressions in your tests.

I think I heard Jerry Seinfeld say that the life of an actor are:

Which really feels these days like:

• What’s “CMM”
• Let’s do “CMM”
• Let’s do an adapted version of “CMM”
• Here’s a better,lighter “CMM”
• What’s “CMM”?
• What’s “Agile”
• Let’s do “Agile”
• Let’s do an adapted version of “Agile”
• Here’s a better, lighter “Agile”
• What’s “Agile”?
• What’s “Scrum”
• Let’s do “Scrum”
• Let’s do an adapted version of “Scrum”
• Here’s a better, lighter “Scrum”
• What’s “Scrum”?
• What’s “Lean”
• Let’s do “Lean”
• Let’s do an adapted version of “Lean”
• Here’s a better, lighter “Lean”
• What’s “Lean”?

It reminded me about another LINQ method I've used from time to time: ToDictionary().  This method will allow you to quickly create a dictionary from any IEnumerable<T>.  Let's start with some sample data that is in a List<T>:

IList<Person> people = new List<Person>

                       {

                        new Person {FirstName = "Bob", LastName = "Smith", SSN = "1"},

                        new Person {FirstName = "Jane", LastName = "Doe", SSN = "2"},

                        new Person {FirstName = "Mike", LastName = "Johnson", SSN = "3"}

                       };

Converting this to a dictionary is pretty trivial without LINQ.  Suppose we want to index these by SSN:

var d = new Dictionary<string, Person>();

foreach(var p in people)

{

    d.Add(p.SSN, p);

}

But why waste our time doing all that when we can simply use LINQ's ToDictionary()?  Just give it a lambda that selects the key and you're all set:

var indexedBySSN = people.ToDictionary(k => k.SSN);

Or perhaps you don't want the entire Person object.  Maybe you just want a collection of last names indexed by Social Security Number (SSN).  No problem --there's an overload that accepts two lambdas: one to select the key and one to select the value.

var lastNamesIndexedBySSN = people.ToDictionary(k => k.SSN, e => e.LastName);

There's also two more overloads that work the same as the two above, but allow you to also provide an IEqualityComparer<T> used to compare your keys.

Everyday I find more and more stuff in LINQ that helps me eliminate the mundane code and make my source more readable.

The timing of this offer is quite nice for me since I have started the blog post series "10 DIY SharePoint Web Parts".

Tags: SharePoint, RSSBus, WebPart

The Chicago Architects Group will be holding its next meeting on May 28th.  Please come and join us and get involved in our architect community.

Register

Presenter: Sean Blanton
Topic: Trends in Continuous Integration and Software Delivery
Location: Microsoft - Downers Grove
3025 Highland Pkwy
Suite 300
Downers Grove, IL 60515-5506
Time: 6:00 - Doors open at 5:30

The offer is MSDN Premium, which gives you access to a whole set of Microsoft software licensed for design, development, testing, and demonstration of your programs. This includes Visual Studio Team Suite, Windows, Office, SQL Server, etc. Given the releases expected this year, this will give you access to such things as Visual Studio 2010 and Windows 7.

If you think that you deserve to get this subscription, just contact me and let me know why I should give YOU this gift. I'll make my choice quickly and I'll reply to you.
Hint: if you can help me update the content of SharpToolbox.com, that can be a plus for you ;-)