Wednesday, August 31, 2011
Tuesday, August 30, 2011
You wanted a banana but you got a gorilla holding the banana
The common problem in object-oriented design and implementation
http://www.johndcook.com/blog/2011/07/19/you-wanted-banana/
http://www.johndcook.com/blog/2011/07/19/you-wanted-banana/
Monday, August 29, 2011
How to implement SQL Distinct keyword in LINQ?
There is a Distinct keyword in LINQ, but not as same as in SQL.
Following is the same implementation for SQL distinct in LINQ
var distinctItems = items
Following is the same implementation for SQL distinct in LINQ
var distinctItems = items
.GroupBy(x => x.PropertyToCompare)
.Select(x => x.First());
http://blog.jordanterrell.com/post/LINQ-Distinct()-does-not-work-as-expected.aspx
HOW TO GET DISTINCT VALUES FROM THE LIST<T> WITH LINQ
HOW TO GET DISTINCT VALUES FROM THE LIST<T> WITH LINQ
Sunday, August 28, 2011
Saturday, August 27, 2011
Friday, August 26, 2011
How to solve "A potentially dangerous Request.Form value was detected from the client" in ASP.NET MVC 3
#1: Add AllowHtml Attribute into property in the model
#2: Turn off validation on the Action:
[HttpPost]
[ValidateInput(false)]
public ActionResult Index(string htmlsource)
{
var x = htmlsource;
return View();
}
http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.98).aspx
Following link is about to solve same problem in ASP.NET webform
http://rayaspnet.blogspot.ca/2011/02/how-to-properly-deal-with-exception.html
#2: Turn off validation on the Action:
[HttpPost]
[ValidateInput(false)]
public ActionResult Index(string htmlsource)
{
var x = htmlsource;
return View();
}
http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.98).aspx
Following link is about to solve same problem in ASP.NET webform
http://rayaspnet.blogspot.ca/2011/02/how-to-properly-deal-with-exception.html
How to click a button by Javascript in Webforms?
Two ways:
1. By jQuery:
$("#ClientID").trigger("click");
2. By __doPostBack function
__doPostBack('server side id name', 'Click');
1. By jQuery:
$("#ClientID").trigger("click");
2. By __doPostBack function
__doPostBack('server side id name', 'Click');
Thursday, August 25, 2011
Wednesday, August 24, 2011
Tuesday, August 23, 2011
How to make a postback withoud validation for a button in ASP.NET webform?
Set
CauseValidation to false.
<asp:Button runat="server" ID="button1" Text="Go" OnClick="Button1_Click" CausesValidation="false"/>
Monday, August 22, 2011
Paging in LINQ
public static IEnumerable<TSource>
Page<TSource>(this IEnumerable<TSource>
source, int page, int
pageSize)
{
return source.Skip((page - 1)*pageSize).Take(pageSize);
}
return source.Skip((page - 1)*pageSize).Take(pageSize);
}
What is SVG?
SVG stands for Scalable Vector Graphics and it is a language for describing 2D-graphics and graphical applications in XML and the XML is then rendered by an SVG viewer.
HTML5 allows embeding SVG directly using <svg>...</svg> tag.
<!DOCTYPE html>
<head>
<title>SVG</title>
<meta charset="utf-8" />
</head>
<body>
<h2>HTML5 SVG Circle</h2>
<svg id="svgelem" height="200" xmlns="http://www.w3.org/2000/svg">
<circle id="redcircle" cx="50" cy="50" r="50" fill="red" />
</svg>
</body>
</html>
http://www.tutorialspoint.com/html5/html5_svg.htm
Sunday, August 21, 2011
Saturday, August 20, 2011
Friday, August 19, 2011
Thursday, August 18, 2011
Wednesday, August 17, 2011
HTML 5 Updates for .NET 4
After we shipped .NET 4 we began working on the next version of the framework and one of the things that we have worked on for the next version of the framework is more support for HTML 5. We think that HTML 5 is so important that we have taken many of updates from the next framework and provided some of the most important ones as part of updates to .NET 4. This enables our customers to more easily develop HTML 5 applications now instead of waiting for the next framework. I’m going to highlight a couple of the updates and the major fixes they provide
http://blogs.msdn.com/b/scothu/archive/2011/08/10/html-5-updates-for-net-4.aspx
http://blogs.msdn.com/b/scothu/archive/2011/08/10/html-5-updates-for-net-4.aspx
Tuesday, August 16, 2011
Monday, August 15, 2011
Multiple Submit Buttons in ASP.NET MVC
In Razor view
@using (Html.BeginForm())
{
<p>
<input type="submit" name="AddButton" value="Add" />
<input type="submit" name = "RemoveButton" value="Remove" />
</p>
}
[HttpPost]
public ActionResult TwoButtonss(string AddButton, string RemoveButton)
{
var AddButtonClick = AddButton ?? RemoveButton;
return View();
}
Reference:
http://www.dotnetcurry.com/ShowArticle.aspx?ID=705
@using (Html.BeginForm())
{
<p>
<input type="submit" name="AddButton" value="Add" />
<input type="submit" name = "RemoveButton" value="Remove" />
</p>
}
In Controller:
public ActionResult TwoButtonss(string AddButton, string RemoveButton)
{
var AddButtonClick = AddButton ?? RemoveButton;
return View();
}
Reference:
http://www.dotnetcurry.com/ShowArticle.aspx?ID=705
Sunday, August 14, 2011
Saturday, August 13, 2011
Friday, August 12, 2011
Thursday, August 11, 2011
ViewBag, ViewData, or TempData in ASP.NET MVC
- ViewData is a dictionary object that you put data into, which then becomes available to the view. ViewData is a derivative of the ViewDataDictionary class, so you can access by the familiar "key/value" syntax.
- The ViewBag object is a wrapper around the ViewData object that allows you to create dynamic properties for the ViewBag.
TempData
TempData is meant to be a very short-lived instance, and you should only use it during the current and the subsequent requests only! Since TempData works this way, you need to know for sure what the next request will be, and redirecting to another view is the only time you can guarantee this. Therefore, the only scenario where using TempData will reliably work is when you are redirectinghttp://rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications
Wednesday, August 10, 2011
Clean Code Versus Great Code
http://davybrion.com/blog/2011/07/clean-code-versus-great-code/
I've had some interesting discussions with other developers about writing code recently. I often have the impression that some developers put too much emphasis on clean code. Don't get me wrong, i strive for clean code as well, and have written about its importance quite a lot in the past couple of years. But when i'm coding, clean code is my secondary goal and it could never take the place of my primary goal: making it work. And preferably, i want to make it work great.
A lot of people love to talk the talk when it comes to writing clean code. They'll stress their dedication to it, in some cases even wearing Uncle Bob's green band while coding so they'll never lose sight of what's incredibly important to them: writing clean code. Unfortunately, i've noticed on numerous occasions that many of these people don't always put as much emphasis on what the code is doing compared to how it looks. Sometimes they don't really bother to learn what their ORM is doing behind the scenes. Or they'll prefer to use something like Automapper to map entities to DTO's even though it is woefully inefficient compared to simply retrieving projected data. They don't always think about the cost of multiple remote calls or sending way too much data over the wire. And when they're not perfecting the art of writing bowling games over and over again, they just might hit the database in loop.
Clean code is not necessarily great code, nor is great code necessarily clean code. To me, great code is code that works great, performs great, is easy to understand and easy to change. In that order. I know all too well how important it is to easily understand code when you first read it, and to be able to easily and safely make changes to it. But no matter how easy it is to read or change, if it's not doing what it should be doing (including covering all the corner cases) or if it's taking more than its fair share of time to do it, it's not good code. Sure, it might be clean, but it's not great, is it?
That doesn't mean that you should indulge in premature optimization. Unless you have Neo-like skills in this coding Matrix, you're unlikely to be right in even a quarter of all scenarios that you want to optimize prematurely. There are however a few guidelines which will help you avoid most common performance problems. Most other situations are better left ignored until proven by a profiler to be a bottleneck. But you should at least think about what the code is actually doing and whether or not any downsides to that are worth the cleanliness. Don't hesitate to go with the slightly less clean looking code if that code makes more sense from a correctness and performance point of view.
By all means, strive to write clean code. But think twice before you sacrifice its ability to be great.
I've had some interesting discussions with other developers about writing code recently. I often have the impression that some developers put too much emphasis on clean code. Don't get me wrong, i strive for clean code as well, and have written about its importance quite a lot in the past couple of years. But when i'm coding, clean code is my secondary goal and it could never take the place of my primary goal: making it work. And preferably, i want to make it work great.
A lot of people love to talk the talk when it comes to writing clean code. They'll stress their dedication to it, in some cases even wearing Uncle Bob's green band while coding so they'll never lose sight of what's incredibly important to them: writing clean code. Unfortunately, i've noticed on numerous occasions that many of these people don't always put as much emphasis on what the code is doing compared to how it looks. Sometimes they don't really bother to learn what their ORM is doing behind the scenes. Or they'll prefer to use something like Automapper to map entities to DTO's even though it is woefully inefficient compared to simply retrieving projected data. They don't always think about the cost of multiple remote calls or sending way too much data over the wire. And when they're not perfecting the art of writing bowling games over and over again, they just might hit the database in loop.
Clean code is not necessarily great code, nor is great code necessarily clean code. To me, great code is code that works great, performs great, is easy to understand and easy to change. In that order. I know all too well how important it is to easily understand code when you first read it, and to be able to easily and safely make changes to it. But no matter how easy it is to read or change, if it's not doing what it should be doing (including covering all the corner cases) or if it's taking more than its fair share of time to do it, it's not good code. Sure, it might be clean, but it's not great, is it?
That doesn't mean that you should indulge in premature optimization. Unless you have Neo-like skills in this coding Matrix, you're unlikely to be right in even a quarter of all scenarios that you want to optimize prematurely. There are however a few guidelines which will help you avoid most common performance problems. Most other situations are better left ignored until proven by a profiler to be a bottleneck. But you should at least think about what the code is actually doing and whether or not any downsides to that are worth the cleanliness. Don't hesitate to go with the slightly less clean looking code if that code makes more sense from a correctness and performance point of view.
By all means, strive to write clean code. But think twice before you sacrifice its ability to be great.
nopCommerce v2.00 released, A Open source shopping cart (ASP.NET MVC)
Highlight features:
• Architecture improvements
• Moved to ASP.NET MVC 3.0 (Razor syntax)
• Really pluggable architecture (just drop a plugin to the /plugins folder in your nopCommerce directory)
• SQL Server Compact support
• Code-First Development with Entity Framework 4 (data access)
http://www.nopcommerce.com/boards/t/10906/nopcommerce-v200-released.aspx
http://nopcommerce.codeplex.com/
• Architecture improvements
• Moved to ASP.NET MVC 3.0 (Razor syntax)
• Really pluggable architecture (just drop a plugin to the /plugins folder in your nopCommerce directory)
• SQL Server Compact support
• Code-First Development with Entity Framework 4 (data access)
http://www.nopcommerce.com/boards/t/10906/nopcommerce-v200-released.aspx
http://nopcommerce.codeplex.com/
Tuesday, August 9, 2011
Monday, August 8, 2011
Sunday, August 7, 2011
Saturday, August 6, 2011
Friday, August 5, 2011
How to check a string is in valid number format in C#?
public static bool IsNumber(string
str)
{
double Number;
if (double.TryParse(str,
out Number)) return
true;
return false;
}
Righting The Wrongs: Van Halen and M&Ms
http://jimcofer.com/personal/?p=621
The 1980s were heady and decadent times for rock stars. Stories of bad behavior by some of rock’s finest – from trashing hotel rooms to over-the-top prima donna demands – were splashed all over the headlines. And few of those stories were as famous as the “Van Halen M&Ms” story.
In case you weren’t around during the 80s, the rock supergroup Van Halen had a clause in their concert contracts that stipulated that the band would “be provided with one large bowl of M&M candies, with all brown candies removed”.
Once the “M&Ms” story leaked to the press, social commentators jumped all over it. Some called it an egregious example of the pampered and spoiled behavior of rock artists. Some saw it as yet another sign of the decline of Western Civilization. And to this very day, any time a story about a celebrity acting like a diva surfaces, my mother rolls her eyes, clucks her tongue, and says “well… did she want the brown M&Ms taken out of the bowl, too??”
Here’s the thing, though: the band put the “no brown M&Ms” clause in their contracts for a very good reason.
Van Halen was one of the first rock bands to bring truly massive concerts to mid-size cities like Macon, Georgia. The arena staff in these smallish cities were used to bands coming to town with, at most, three tractor-trailers full of equipment. Van Halen’s equipment took up nine tractor-trailers. It was a lot of stuff, and staff at these venues were frequently overwhelmed. And when people are overwhelmed, they make mistakes. At a rock concert, “making a mistake” during setup has a large number of possible outcomes. Some mistakes don’t have any effect at all. Other mistakes can make the band sound awful, which only hurts the band’s image. But more serious mistakes can kill people… which is exactly what the band was afraid of.
At the heart of any major concert is the contract. Much of the text of these contracts is standard legal boilerplate, but each band may attach specific demands via something called a “rider”. Most contracts involving large venue concerts are jam-packed with riders, most of which involve technical details specific to the band’s stage design. For instance, a rider might say “Article 148: There will be fifteen amperage voltage sockets at twenty-foot spaces, spaced evenly, providing nineteen amperes total, on beams suspended from the ceiling of the venue, which shall be able to support a total gross weight of 5,600 pounds each, and be suspended no less than 30 feet, but no more than 37.5 feet, above the stage surface”. Van Halen’s concert contracts would have several hundred such demands, and their contracts ended up, as lead singer David Lee Roth would say, looking “like a Chinese Yellow Pages”.
The staff at large venues in big cities were used to technically-complex shows like Van Halen’s. The band played in venues like New York’s Madison Square Garden or Atlanta’s The Omni without incident. But the band kept noticing errors, sometimes significant errors, in the stage setup in smaller cities. The band needed a way to know that their contract had been read fully. And this is where the “no brown M&Ms” came in. The band put a clause smack dab in the middle of the technical jargon of other riders: “Article 126: There will be no brown M&M’s in the backstage area, upon pain of forfeiture of the show, with full compensation”. That way, the band could simply enter the arena and look for a bowl of M&Ms in the backstage area. No brown M&Ms? Someone read the contract fully, so there were probably no major mistakes with the equipment. A bowl of M&Ms with the brown candies? No bowl of M&Ms at all? Stop everyone and check every single thing, because someone didn’t bother to read the contract. Roth himself said:
The 1980s were heady and decadent times for rock stars. Stories of bad behavior by some of rock’s finest – from trashing hotel rooms to over-the-top prima donna demands – were splashed all over the headlines. And few of those stories were as famous as the “Van Halen M&Ms” story.
In case you weren’t around during the 80s, the rock supergroup Van Halen had a clause in their concert contracts that stipulated that the band would “be provided with one large bowl of M&M candies, with all brown candies removed”.
Once the “M&Ms” story leaked to the press, social commentators jumped all over it. Some called it an egregious example of the pampered and spoiled behavior of rock artists. Some saw it as yet another sign of the decline of Western Civilization. And to this very day, any time a story about a celebrity acting like a diva surfaces, my mother rolls her eyes, clucks her tongue, and says “well… did she want the brown M&Ms taken out of the bowl, too??”
Here’s the thing, though: the band put the “no brown M&Ms” clause in their contracts for a very good reason.
Van Halen was one of the first rock bands to bring truly massive concerts to mid-size cities like Macon, Georgia. The arena staff in these smallish cities were used to bands coming to town with, at most, three tractor-trailers full of equipment. Van Halen’s equipment took up nine tractor-trailers. It was a lot of stuff, and staff at these venues were frequently overwhelmed. And when people are overwhelmed, they make mistakes. At a rock concert, “making a mistake” during setup has a large number of possible outcomes. Some mistakes don’t have any effect at all. Other mistakes can make the band sound awful, which only hurts the band’s image. But more serious mistakes can kill people… which is exactly what the band was afraid of.
At the heart of any major concert is the contract. Much of the text of these contracts is standard legal boilerplate, but each band may attach specific demands via something called a “rider”. Most contracts involving large venue concerts are jam-packed with riders, most of which involve technical details specific to the band’s stage design. For instance, a rider might say “Article 148: There will be fifteen amperage voltage sockets at twenty-foot spaces, spaced evenly, providing nineteen amperes total, on beams suspended from the ceiling of the venue, which shall be able to support a total gross weight of 5,600 pounds each, and be suspended no less than 30 feet, but no more than 37.5 feet, above the stage surface”. Van Halen’s concert contracts would have several hundred such demands, and their contracts ended up, as lead singer David Lee Roth would say, looking “like a Chinese Yellow Pages”.
The staff at large venues in big cities were used to technically-complex shows like Van Halen’s. The band played in venues like New York’s Madison Square Garden or Atlanta’s The Omni without incident. But the band kept noticing errors, sometimes significant errors, in the stage setup in smaller cities. The band needed a way to know that their contract had been read fully. And this is where the “no brown M&Ms” came in. The band put a clause smack dab in the middle of the technical jargon of other riders: “Article 126: There will be no brown M&M’s in the backstage area, upon pain of forfeiture of the show, with full compensation”. That way, the band could simply enter the arena and look for a bowl of M&Ms in the backstage area. No brown M&Ms? Someone read the contract fully, so there were probably no major mistakes with the equipment. A bowl of M&Ms with the brown candies? No bowl of M&Ms at all? Stop everyone and check every single thing, because someone didn’t bother to read the contract. Roth himself said:
“So, when I would walk backstage, if I saw a brown M&M in that bowl . . . well, line-check the entire production. Guaranteed you’re going to arrive at a technical error. They didn’t read the contract. Guaranteed you’d run into a problem. Sometimes it would threaten to just destroy the whole show. Something like, literally, life-threatening.”The “no brown M&Ms” clause became a national news story after an “incident” at Colorado State University. The national press told a story of unacceptable behavior from the band, and how they caused $85,000 worth of damage to the arena. David Lee Roth remembers it a bit differently:
The folks in Pueblo, Colorado, at the university, took the contract rather kinda casual. They had one of these new rubberized bouncy basketball floorings in their arena. They hadn’t read the contract, and weren’t sure, really, about the weight of this production; this thing weighed like the business end of a 747.
I came backstage. I found some brown M&M’s, I went into full Shakespearean “What is this before me?” . . . you know, with the skull in one hand . . . and promptly trashed the dressing room. Dumped the buffet, kicked a hole in the door, twelve thousand dollars’ worth of fun.
The staging sank through their floor. They didn’t bother to look at the weight requirements or anything, and this sank through their new flooring and did eighty thousand dollars’ worth of damage to the arena floor. The whole thing had to be replaced. It came out in the press that I discovered brown M&M’s and did eighty-five thousand dollars’ worth of damage to the backstage area.
Well, who am I to get in the way of a good rumor?
Thursday, August 4, 2011
Wednesday, August 3, 2011
Tuesday, August 2, 2011
Monday, August 1, 2011
Subscribe to:
Posts (Atom)