ALT.NET Montreal Meeting @ O'Regans Irish Pub – 5:30pm

Tonight we will be holding a little ALT.NET meeting with a beer. I’ll be at the pub at around 5:30pm-5:45pm.

See you all tonight!

If you are looking for the Pub, it’s right there:

View Larger Map

Which bug reporting method should I choose?

Alright, my previous post was lot of ranting… I have to make it up. I hate ranting because it never bring any solutions, only problems. When someone is building a software, bugs will happen as true as the sun rise everyday. Sometimes it will be simple change request but there will be bug that are going to be logged in.

It’s important that the user of the software has an easy way of reporting the bug. Depending on the kind of software you are building, there will be different kind of way to actually report a bug. There is 4 main kind of software that programmer works on. Open-source software, product, internal software and public web sites. They all require different kind of bug reporting due to their reach and needs.

Open-source software

Open-source software are normally better with 2 kind of bug reporting. The first is an actual bug reporting tool that is linked to a source control software like Google Code or Codeplex. The other kind is a discussion list/forum. The first one is to actually report bug and the second one refer more to actual support by the community. It might sound confusing but they both highlight bugs as the consumer have a way to contact the project leader or contributors to the project.

Examples includes: Firefox, Moq, BlogEngine.NET

Product

Product are either websites or actual executables that are sold to consumers. Since they don’t display the source and especially not their bug lists, they need a way for the consumer to actually report their bugs. Since products are normally backed by a company with staffing, bug reporting can go from the simplest form to a complicated bug submission tools. Sometimes, the integration of the bug report are even more advanced. Some software even catch crash in the software and send them when the software can successfully restart. Whatever the way the bugs are caught, company should always offer a free way of sending bug report even if it’s through a support@example.com kind of email.

Examples include: FogBugz, Copilot, StackOverflow, Apple Mac OSX

Internal Software

Those are whole different kind of game. Those are software that you are hired to build for another company or that you build for your own company. Those kind of software mostly stay internal and are never going to be released into the wild. Those includes, CMS, ERP, wiki, etc. Those are normally what most developer will face. Direct contact with the user about the bugs, Team System for the bug reporting (or any other kind of bug reporting software used internally). The bug list is internal and new bugs are often reported by a direct email. phone call or a conversation with the program manager/architect/team lead/developer.

Websites

Websites normally don’t have specific bug reporting system. Most websites works or the user leaves. The main bug reporting system in those system is heavy logging for any errors that happens and IIS logs for anything that doesn’t go through the .NET runtime. However, some websites that offer service might offer some way to report bugs but they are  the exception… not the rule.

Examples include: StackOverflow

Conclusion

Bug reporting is not what you want your user to use (unless you are selling bug reporting software). However, when a user is seeking to you to report a bug, you must offer them a painless process to report bugs. Without this, you will only be able to find out bugs from other forums where people are complaining(if you have a large user base) but mostly, you will never get any notice that the software doesn’t work as planned.

So please… if I want to report a bug… make my life easy and make it a process that don’t take more than a few clicks.

Thanks

Report a Bug – The feature all products should have

I was writing acceptance test for project today and I needed to include a file inside my Excel 2007 sheet. After fiddling around a little, I found “Insert Object”. This allowed me to insert a file and have it available to anyone opening the Excel 2007 document. When I dragged and dropped the file to my desktop, the file was truncated! I couldn’t believe it! I found a bug in Excel 2007! Being a developer, I wanted to properly report that bug.

So I started with a small Google search for “report Microsoft bug” which lead me to this, this and that.

Let me bring you the title of the last article : “Mission: Impossible. Submitting a Bug Report to Microsoft”.

This had me afraid. The article is dated 2002 and the other ones are 2006. We are in 2009 at the time of writing this article. So I searched more and more. I literally found nothing.

How can an application ship without having an easy way to report a bug? Apple does it. Ubuntu does it. OpenOffice does it. Firefox does it. Google Chrome does it. Why can’t I report a bug for Internet Explorer, Office or Vista (soon Windows 7)?

It goes without mention that if you are building a product, there should be an easy way to report a bug. Be it by a small contact form, an official bug reporting software, etc. But please don’t charge your user 35$ to fill out bug report.

Microsoft has recently (in the last few years) opened up and launched Connect to help user report bug inside the .NET Framework. They should extend it to all their product line. It seems that developer working on the .NET framework are reachable and have blogs everywhere and that the Excel team is just higher up in the sky and untouchable by customer feedback.

So? Does your application have a way to easily report bug? Because if the process to report a bug is long and tedious, you will have a “bug-less” product with marginal amount of users that tolerates the bug or that are hard-core enough to take the time to report it.

5 reasons why you should use ASP.NET MVC

I’ll be fair with you readers. I’ve only toyed with the ASP.NET MVC framework. It looks great as of now but it’s the first full blown MVC framework that we have that is backed by Microsoft. However, there is a lot of opposition nowadays that tend to be formulated like this:

Why should I use ASP.NET MVC? WebForms works well.

Other problems come from the lack of server controls. When a developer look at that and he then wonder why he should have to write HTML and Javascript when before he could have retrieved all that beautiful information with a simple postback.

So without ranting any further, here is 5 reasons why you should use ASP.NET MVC.

1. Testability

When the MVC model is properly applied, it allow for a better separation of your business logic and your presentation code. If the view is not included inside your model, you can easily test without requiring a web server. By default, when starting a new MVC project, Visual Studio offer to create a new Unit Test project based on Microsoft’s Unit Test framework. Other Unit tests framework can also be configured to be used by default instead of Microsoft’s solution.

The way the code is also made, the controller is the one handling the calls from the route. They can be instantiated outside of a web request which makes them easy to test too.

2. Perfect control of the URLs

ASP.NET MVC use URL Routing to better control the request and forward them to your controllers. Instead of 1 to 1 mapping, they allow pattern matching. The default being “{controller}/{action}/{id}” with the default being “Home/Index”. This technically allow you to set the URLs exactly how you want. You don’t have to create folder for every level deep it goes. The URL routing allows you to make clean URL that will be easy to remember.

Would you rather try to remember http://localhost/Sales/DisplayProduct.aspx?ProductID=23213 or http://localhost/Product/Detail/23213 ? Even better, if you are an e-Commerce site and want some fast link…. you can directly bind those URL to http://localhost/23213 to make it more easy to remember. Doing that in WebForm while keeping all this unit testable would just be too time consuming now is it?

3. Better Mobility Support

In WebForm, you would have to detect on each page that the browser is a mobile and adapt your rendering for the mobile on each and every form. You could also redirect the user to different page when it’s a mobile. What is excellent with MVC is that it’s not the view that is receiving the request. It’s the controller. The controller can then dynamically decide which view to render while keeping the same URL. So to see a product view, you don’t even need to send different URL to different provider. You just detect which device you are handling and redirect it to the proper view. As you support more and more mobile device, you can keep on adding view that are more specific to each device. Want to support this new HTC? Create a view, detect the browser and ensure the right view is displayed. Want to support some iPhone goodness with some device specific HTML? Create the necessary view, reuse the browser detection and display the view.

You can keep on doing that ad infinitum and as much as you want depending on your audience. Having Mobile support now is more convenient than it has ever been.

4. View Engines

Now if you only built ASP.NET WebForms, this term might be weird for you. Let’s just say that you have been using the same view engine all this time without wondering if you could choose. The WebForm view engine is… well… what you have been using all this time. This includes server tags (<% %>), binding tags (<%# %>) as well as control tag (<asp:TextBox … />).

The Spark Engine is a good example. MvcContrib also offer 4 different view engine (Brail, NHaml, NVelocity, XSLT). Each of those engine are created to fix some specific problems. Different view engines can be used on different view. One page could be handled with WebForm view engine, one with Spark Engine, one with XSLT, etc. Different view, different problem different solution.

You might not have to use those, but the simple fact that they are available will make your life easier if they are needed.

5. Built-in and shipped jQuery support

Let’s keep the best for the end. jQuery is shipped with any new project instance of ASP.NET MVC. Since Microsoft announced support for jQuery, it’s been the big buzz in the javascript world. Since ASP.NET MVC don’t rely on Postback, a strong javascript framework is needed to provide for all the UI the previous server control were offering. jQuery easily offer you AJAX, DOM manipulation, event binding and  this across browser.

Of course, jQuery is not an advance to MVC itself. But it is a serious offering from ASP.NET MVC. No more download or “I’ll write my own” stuff. I don’t know for all of you but if I have to do javascript, I normally do a document.getElementById. This will work in most browsers but as soon as you start going funky, some browser will misbehave. jQuery simply allow you to write $(“#myControlId”) or many more shortcuts to simply do what you need across browsers. Just by having jQuery available stops me from writing incompatible code.

Conclusions

Lots of point goes toward MVC. Way more could be added. You certainly don’t want to miss Kazi Manzur Rashid’s blog about ASP.NET MVC Best Practices (part 1, part 2). Scott Hanselman, Phil Haack also have great posts about ASP.NET MVC.

Don’t be fooled. Web Forms are not necessarly evil. They just aren’t leading you to a pit of success.