please visit http://chandramohan.tools4software.com/stores/chandramohan/266145pgabout.html
Contains asp.net,c#,silverlight and other asp.net technologies related articles,coding examples.
You can use Google’s Realtime search feature to track trending topics on social media networks like Twitter. To find it, just do a search as usual, then click on the More icon on the left to open up the Realtime option (or just go to http://google.com/realtime).
The default view will show you the most recent items for the given term(s). You’ll also see a timeline showing the frequency with which the term(s) have appeared over a given time period.
If you’re hosting an event (like the Stir Trek developer conference in Columbus, Ohio) and have set up a hashtag for the event, this can be very useful to see how things are going on the day of the event:
Now, what I haven’t found is a way to put some kind of scale on the Timeline, or how to do a search query that tells you how many results there were on a given day (please post a comment if you know how to do so). That would be useful information to plug into your own metrics when assessing your online marketing and social media strategy. But still, seeing the pretty graph and being able to go back in time and see what people were talking about is pretty darned cool.
The var keyword was introduced in C# 3.0, and has since gained quite a bit of popularity. There is also a fair bit of contention over how it should be used, with posts like this one (with which I happen to agree) being not uncommon. Over the last week I posted a couple of polls on twitter that asked about specific scenarios in which one might use var, trying to address the two scenarios outlined by the author of that post.
Scenario One
This was meant to depict the case where the type would appear twice on one line, and so using var makes the code more succinct while no less clear.
http://twtpoll.com/r/a3w7j7
75% of respondents agree that this is a scenario in which you should use the var keyword. I’ve heard from more than one person (including the article linked in the first paragraph) that even better would be if you could instantiate a variable more easily, as in String s = new(); or alternately to not require the type at all on the left:
Of course, neither of those options are going to fly with C# (without some significant changes to the compiler), so getting back to “things we can actually do today with C#” we come to the second scenario.
Scenario Two
In this scenario I’m going for the case where there is some method that is returning a type, and the type isn’t obvious.
So the question comes down to, should you use var to declare variables that are initialized from a method call such that the type being returned is not obvious? 64% of respondents still favor using var in this case. Personally, I prefer the somewhat more clear red option, since it’s apparent immediately what the type of result is, but obviously I’m in the minority (for this poll) in this case.
Scenario Three
The third question was in response to some comments and questions I had about the first scenario. Some folks contended that in the case of var s = new String(); it wasn’t really worth it to use var, but that they would use var if it was a very long, complex, or convoluted type. So that’s what this question was meant to reflect.
In this case 78% (3% more than scenario one) agree that one should use var here. A number of people suggested that a custom type would be better than the ugly Dictionary of Dictionaries that I used in my example, resulting in some of the 3% Other votes (and I agree, but I was just going for a long and complex type, so work with me here). Less than 20% of respondents felt that it was worthwhile to type out the complex type twice on this particular line of code.
A scenario that I’m obviously leaving out is where anonymous types are required. These can only be represented by var, and are the main reason for its introduction into the C# language in the first place. Thus, I didn’t see much value in polling people about its usage in this case.
Summary
Although initially there was a fair bit of skepticism about its usage, it appears from these unscientific polls that the var keyword has gained widespread acceptance among C# developers. In fact, its usage has become the rule, rather than the exception, even in scenarios where the actual type of the variable in question is not immediately obvious upon examining its declaration (as in scenario two, above). I personally think that the rise in popularity of dynamic languages like Ruby and JavaScript has a lot to do with this trend, perhaps combined with the widespread acceptance of using a powerful IDE like Visual Studio (as opposed to a plain text editor) that is easily able to provide type information via mouseover or Intellisense. What do you think? How do you prefer to use var, and how does your organization try to enforce var usage among its developers (if at all)?
Last week I ran a poll (that maxed out at 400 responses on twtpoll) asking how developers recommend using regions in C# (or not). You can see the results here:
About 15% of the respondents chose Other and/or chose to leave a comment. The comments are useful because they often highlight answer categories that I overlooked when I set up the poll. In this case, there were a lot of comments, I think because there are a lot of different opinions about regions in general, some of them rather heated.
Clearly the largest number of respondents simply never use Regions. A number of comments went on to say things like “Regions aren’t evil I just don’t know a situation where they’re useful.” The most popular use of regions from the ones I provided was for wrapping interface implementations, which isn’t too surprising since these regions are often automatically added when an interface is implemented automatically. Similarly, a large number of comments referenced “generated code” as a use case for regions, which I probably should have included in the original listing.
I added a couple of the options above, F and G, as items that I would consider obvious wrong answers on a standardized test. Surprisingly, both got a reasonable number of votes, with 13% of respondents recommending the use of regions with long functions. Now, some of these votes probably belong to commenters like this one: “Hiding long methods as I refactor it”. If you’re temporarily collapsing sections of a long function during your refactoring exercise, that seems quite reasonable to me. But if you’re putting regions into your function as a recommended, long-term approach, then I probably don’t want to work on that codebase with you. I would much rather functions be small enough that (without regions) they fit on one screen, and if they get too big for that, fix the problem by extracting out well-named and well-composed methods, as opposed to hiding the problem behind regions. And regions with regions. Wow.
My personal opinion is that regions had some great and common use cases in the early versions of .NET and C#. For instance, the first version of ASP.NET used regions appropriately to hide auto-generated wire-up code in the codebehind. A large number of comments continue to suggest that regions be used for generated code. Today, two things make this less of an issue. The first is partial classes. Generated code today is almost always in its own class, or could be, and as such rather than wrapping it with a region, I find it is better to simply use a partial class to keep the generated code in a separate file from the custom code. The second feature is more of an IDE feature. A lot of users find regions helpful as a code navigation tool, or as a way to limit what they are looking at on the screen. VS2010 provides great support for expanding and collapsing methods and other areas of code that you don’t wish to see, and tools like ReSharper make it trivial to navigate to a type or member anywhere in your solution (ctrl-T, then type a substring of the type, then enter and you’re there. For a member, the default keymap is the not-quite-as-easy-to-type ctrl-F12). A number of comments also suggested using regions for using statements. These don’t tend to bother me because I can quickly scroll down and not have to see them on my screen, and my using statements are usually quite small since ReSharper will clean up the ones I don’t need and will auto-add any that I do need, and my classes are small so they aren’t generally using more than a handful of other namespaces. And of course, VS2010 supports collapsing using statements as well, like so:
Why Consider Them Harmful, Smelly, or even “Evil”?
Evil is obviously a strong word, and of course since regions have no effect on compiled code, they can’t directly have any impact on the software you’re creating. However, I do think it is at least fair to say that regions often represent “code smells.” That is, areas of your code that may be worth investigating to see if there is rotten code that needs to be cleaned up. Why do some, including me, tend to feel this way? Because regions are often a symptom of underlying problems with the code itself. Regions do two things:
Provide a single-line commentWrap some number of lines of code and allow it to be hidden on demandWhen might you need these features?
The intent of the code is unclearThe code is too long to quickly understand at a glanceBoth of the aboveYou prefer an “outline view” of classes so you can drill into each category of member when you dig into a classIn the case of items 1 through 3, regions are covering up problems.
If the intent of a block of code is unclear, fix the code. Extract a method. Rename the variables. Refactor. Simplify. Don’t add a comment or a region (glorified comment) to try and cover up the problem. If you spill something in the kitchen, should you clean up the floor, or just throw a rug over it or put out an orange cone to warn people about the spill? Which option is going to keep the kitchen optimally usable? The same goes for your code. Keep it clean.
If the code is simply too long, fix it. Eliminate duplication. Refactor. Abstract details into larger-grained operations. If you’re spending 10 lines of plumbing code talking to a database or service, move that into its own method or class that is only responsible for that work. If you’re spending lots of lines of code copying values from one object to another, use a tool like Automapper to map the values with one line of code. Keep your code concise and at the appropriate level of abstraction for the method you’re in, and don’t mix plumbing code with application code if you can help it.
In the case of 4, regions are being used to do something that your IDE should be able to easily do for you. I won’t say regions are being mis-used in this context, but I do think that if a large number of people use them for this purpose, then Visual Studio or one of the add-in providers should provide this kind of view such that you don’t have to implement yourself in the source code with region statements. I definitely think it’s valid that some developers prefer this view of their classes, I just don’t think they should have to clutter up everybody’s codebase in order to do so. Let the IDE do that work. And of course, if the classes and methods are small, the need for a high-level view is significantly lessened. If you prefer to have all of your public properties in one section, public methods in another, private members in another, etc. then wouldn’t you prefer to have an IDE that would simply let you specify the organization you prefer, and automatically have it in every file you open?
Summary
Almost half of the developers polled would never recommend using regions. Yet nearly 15% of those polled would recommend using them to organize long methods. A great many use them to organize code into categories (public, private, methods, properties), though this could probably be better done automatically by a tool. When .NET was young, regions provided a useful way to hide generated code within classes or to provide expand/collapse capabilities within the IDE. Today, partial classes and improvements to the IDE and various plug-ins make these uses unnecessary for many developers. Clearly, there are still some opportunities for IDE/plug-in vendors to build in code organization support that will further erode the legitimate use cases for regions. If you’re not using them for such organizational purposes today, think about the underlying reason you’re using a region the next time you add one, and consider if you wouldn’t be better off correcting the underlying code deficiency rather than hiding it under the region rug.
Last week I hosted a quick poll on Twitter about how useful a particular XML comment was for a particular class. The code looked like this:
///The poll actually got 355 votes, which is pretty impressive. In hindsight I should have added an option relating to generating documentation, or updated the “necessary evil” option to include documentation as a valid reason for having these, since a large number of comments pointed to documentation as a motivation for this. Or intellisense. Personally I don’t see how the above would provide me with anything useful either as documentation or via intellisense, and I know it frustrates me to no end when I go to MSDN or a help file and I find this level of documentation on a public framework or API. However, the vast majority of developers aren’t developing public frameworks or APIs, so I think the need for generating docs is certainly a minority case.
Here’s the results from the poll:
Two people actually thought the comment was “essential” to understand the code. I’m not surprised that this is a small number. I would be inclined to ask the two who answered this, “Really?” I just don’t get it. Sorry.
4% of respondents found the comment useful. I’m assuming they’re also some of the ones who noted things like “The comment is practical for Intellisense.” I’m not sure how it’s terribly useful for increasing one’s understanding of the code (except those 2 respondents above).
About a quarter of respondents felt the comment block was a “necessary evil” because they favored requiring such comments to ensure that comments were written for classes that actually merited them. Again I’m guessing that many of these respondents also felt it was a necessary evil because of the documentation generation and/or Intellisense factor. 7% voted “Other” and I’m guessing many of these feel the same way, so I would unscientifically say that about 30% of respondents feel that the comment block, while probably not ideal in terms of what it’s saying, is useful in general because of the benefits it yields in some fashion outside of the scope of reading this code (e.g. documentation or intellisense).
64% of respondents felt the comment was a complete waste. A few disagreed that it obscured the ability to read the code, and I can understand that. My reason for including that in the response was that I’ve often had to deal with code bases that include so many required comments on every little field that it’s almost impossible to see the actual code among the clutter. In that kind of scenario, I see such comments as being obscuring, rather than clarifying, the intent of the code (and in case it’s not obvious, I voted for this option myself). I’ve written about when you should comment your code before, as well as one way that you can reduce the friction from these kinds of comments by putting them on your interfaces, not your implementations.
Can Our IDE Fix This, Please?
I do agree that Intellisense if a wonderful tool, and that generated documentation that lives near the code is a good thing. However, I don’t think comments are necessarily the best way to achieve this. Considering that we’re talking about C# code, it’s almost a given that we’re talking about Visual Studio for our IDE. Thus, it would be pretty easy to build something that leveraged the tool to specify the comments and/or other documentation, without having to force the user to deal directly with verbose XML or bloat their code with many lines of non-running code. Imagine if the experience for dealing with code documentation and Intellisense mirrored Intellisense itself. That is, if you were to mouse over a class, method, or property (or select it and use a keyboard shortcut), the current help would appear in a tooltip. In addition to showing the documentation, it would, if you were hovering over the declaration of the item in question, allow you to edit the current documentation. You would make your edits in a small dialog using a rich editor, not direct XML markup, and save them with with a click or keyboard shortcut. This documentation would be stored somewhere – I’m not too picky about where. Probably the most sensible location would be in a side-by-side file with the class in question, e.g. Foo.cs.xml or Foo.cs.docfile, which Visual Studio would normally keep hidden.
I would love to see richer, more intelligent support for documentation within our tools, and like 2/3 of other developers, I’d like to see an end to useless clutter in my source code in the form of check-the-block XML summary comments.
Sometimes when you’re about to do some major surgery on your database, you want the comfort of knowing that you can always rollback if there’s a problem. And it’s not always the case that you’ll immediately know there was a problem. Sometimes, you just want a copy of the original data so that you can go back to it, or use it to analyze where you went wrong. Of course, you can backup the whole database, but restoring the full system is often overkill if you’re only working on a handful of tables, not to mention the fact that backups are rather cumbersome and slow compared to standard SQL statements. What if you just need a complete copy of the data from one table in another table? You can easily achieve this using this approach:
-- EverythingSELECT * INTO [Products_backup] FROM [Products] -- Only Some ColumnsSELECT ID, Name INTO [Products_backup] FROM [Products] -- Only Some RowsSELECT * INTO [Products_backup] FROM [Products] WHERE ID > 1000Of course, you can also combine “only some columns” version with a where clause, too. Once you’re done with your scary operation and are certain that you won’t need to roll it back, you can drop the _backup table.
Fiddler is a great tool for examining and working with HTTP requests. If you’re a web developer, it’s one of those tools that you should definitely be at least aware of. The most recent version has some nice new features, like being able to very easily isolate which window or process it’s recording, so you don’t end up with a lot of noise from messengers and other background HTTP requests. The feature I want to describe for this post has actually been around for a while, so even if you’re using an older version of Fiddler, you can probably take advantage of it. That is, you can easily export a Fiddler session as a Visual Studio Web Test (or Web Performance Test).
In Visual Studio 2005 and 2008, these tests are called Web Tests. In Visual Studio 2010, the name was changed to Web Performance Test. The extension in either case is .webtest, and the file formats are compatible.
Since Fiddler is a free and very small tool, it’s something you could easily provide to remote testers or technical end users who could then record sessions with it showing problems they’d encountered or scenarios that were particularly important from a performance perspective. They wouldn’t need to install or learn Visual Studio or its testing tools, but they could provide these scripts and you would be able to run them and incorporate them into your Visual Studio testing projects, ensuring that you were testing these important scenarios.
To get started, simply begin capturing traffic with Fiddler (F12 or File – Capture Traffic). Open up the site you want to record and make a few requests. If you’re using IE9 you should be able to go against localhost if necessary, but with earlier versions of IE and with some other browsers, you may need to do some additional configuration to get localhost to work. Hitting any other name, including your own machinename, should work, though. Once you have some requests, stop capturing traffic. The result should look something like this:
Next, go to File – Export Sessions – All Sessions.
Select the Visual Studio WebTest export format:
Save the file – hit OK on the Select Plugins window.
Now, from a Visual Studio Test Project, choose Add Existing Item and add the file you just saved. You should be able to immediately run the test, like so:
And there you have it. Now you or your users can record web tests using Fiddler, without the need for Visual Studio, and you can import these easily into your web projects. Enjoy!