UPDATE #1 - If you've been following me on Twitter, you may have noticed that I botched the WordPress migration when I tried to import comments. Not a huge deal but it broke some links to files and images. In the meantime, MikeBosch.net is redirecting here until I can fix all the broken links. Thanks!
I'm leaving the weblogs.asp.net blogging community to my own personal web space. I appreciate all the exposure I've received through the years here and I hope you'll follow me to the blogs new home. I'll be covering the same topics you've seen here and have already migrated the posts over.
Visit the new blog and let me know what you think: http://mikebosch.net
Follow me on Twitter: http://twitter.com/MichaelBosch
I recently read a Gartner research report about the changing space of software development methodologies and the PMO. It compared the PMO to an air traffic controller coordinating flights (ie projects) - scheduling them, coordinating resources for them etc. While this might be a valid comparison, I think the changing face of software development is leaning towards taking road trips as oppose to long flights.
The air traffic controller analogy is good but if the distance is short, sometimes driving a car is faster. I think if our aim as software development managers shifts to focus on delivering small chunks of functionality more often, we don't necessarily need all the planning & scheduling that an international flight requires. Driving to a close destination within 100 miles or so is often faster than the airport parking, luggage check-in, security screening, boarding, possible flight delays, weather conditions etc (not to mention the high upfront cost of a flight). For short distances, driving a car is often the optimal choice.
For farther destinations, say from Miami to Seattle, a flight would definitely win over a drive with no stops. However, if we think of a Seattle as being the final destination, but having several stops along the way, it becomes akin to a road trip. Each stop in a different town adds value to the overall expedition. Everyone is enjoying the progress of the trip because they're getting value out of each stop along the way. The car will need refueling (capital) along the way, but its a smaller cost than filling the plane with 50,000 gallons of jet fuel before takeoff. The analogy here is the benefit of high business value from fast, incremental delivery of application features.
Also, a flight requires coordination from several disparate and highly specialized teams (engineers, pilots, stewards, traffic controllers, etc). In the car analogy, the team is much more close-knit and cross-functional. Anyone can drive, a couple know how to drive as well as change a flat, someone knows how to change the oil as well as fix a flat - they don't need to "borrow" someone from another project to change a flat. Everyone on this cross-functional team is committed to the success of the road trip whereas flight teams work on multiple flights (projects) all the time and need to be coordinated and assigned accordingly.
Without a doubt, coordination and management is necessary with any software development project. However, the scale can change dramatically depending on how far you want to look ahead. It also gives us more options to get around detours along the way.
You may have noticed this blog has been awfully quiet in the past couple of months. That's because I've been working on a neat side project with a couple of other developers. Today, we'd like to submit our project to the ASP.NET community to get some feedback. The site is called WorkGrabber.com. You can check it out here: http://workgrabber.com
What we're trying to create with WorkGrabber is something like the eBay of local service contractors. In an nutshell, when you post a job, you're bringing the entire project directly to contractors in detail. You can upload photos and videos as well as answer questions and interact with contractors while keeping your information private. You can review bids from local contractors and accept the one that you like the most. You can read more about the features of WorkGrabber on the WorkGrabber blog. In this post, I want to focus more on the technology we used to create it.
We started developing WorkGrabber during the earlier releases of ASP.NET MVC although we were pretty sure we weren't going to release it until the first RTM. It gave us more time to beta test the site with friends and family before releasing it into the wild. Here's a breakdown of some of the tools we used.
WorkGrabber is built on top of ASP.NET MVC 1.0. Not a whole lot changed in the past couple releases of MVC so upgrading was fairly simple. The data access code is developed mostly using LINQ to SQL with a SQL 2005 database. jQuery is used throughout the site to create some cool visual effects. For example, we used jQuery Tag Suggestion plugin to create this neat auto-suggest tagging feature for when you're posting a job.
Throughout WorkGrabber, we use the jQuery Facebox plugin to create really cool modal windows. The modal windows themselves are ViewUserControls which are rendered back to the client. Here's an example:
The majority of images are hosted by ImageShack and the galleries use the jQuery lightBox plugin to create a really neat modal effect. So much is built into this jQuery plugins that they really make client side development a blast.
I plan to post more about the internals of WorkGrabber in later posts. I'd love to hear some of your feedback. If you have a project on your "honey-do" list that you keep putting off, try posting it on WorkGrabber to get some free local contractor bids.
Try posting a job and let me know what you think in the comments here.
At first glance, upgrading to the RC1 was quite a debacle. First of all, any link that I created using the much more performant Html.RouteLink (instead of Html.ActionLink) just stopped working. It turns out there was a regression bug in the RC that caused this. The ASP.NET MVC team quickly released a refresh which fixed the problem.
The next problem came when I noticed Stephen Walther's paging helper stopped working. It would throw a null reference exception whenever I used the Html.Pager() helper method. The issue was a breaking change in the RC1 with the location the RequestContext.
To fix the issue, you can download the solution from Stephen's site. Open up the solution and change all the references to the latest ASP.NET MVC assemblies. When you compile the main project, you'll find an error in the PagerBuilder.cs class at line 165. All you have to do is update this line to:
var urlHelper = new UrlHelper(_helper.ViewContext.RequestContext);
Compile the project and replace the assembly in your ASP.NET MVC project. I'm sure Stephen will update the project eventually so you could just download the latest version.
Hope this helps!
First of all, an apology for being so quiet over the past few weeks. I've been putting my blogging aside for a while to chase some pet projects I'm working on. More on that later.
I did, however, run into a particular situation that I thought would be of interest to anyone adopting ASP.NET MVC and looking for some goodies from jQuery. Many of you have no doubt started testing the waters with jQuery since it was announced that Microsoft will be shipping the next version of .NET with it included. If you haven't used jQuery yet, prepare to fall in love!
In this post, I'm going to cover a simple way to build a deep, hierarchical and feature-rich tree structure with only one line of jQuery script. jQuery has a huge library of plugins covering all sorts of functionality. For this, we'll be using a neat plugin from for treeviews. Here's what you need:
jQuery Treeview Plugin
This structure will consist of a category/sub-category relationship that is able to support n-levels of sub-categories with no changes. To demonstrate, let's look at the SQL table that supports the structure.
Notice the rows with ParentCategoryID set to NULL are the parent categories. Each row with a ParentCategoryID is a sub-category and relates to it's parent category. The numbers show the level in outline view.
The jQuery Treeview plug-in requires the resulting HTML to be in a particular unordered list (<ul>) element to parse the tree correctly. Since we don't know how many levels to expect, we are going to call the MVC user control that renders each node recursively. This control accepts a single Category item.
We render the name of that category and then check if it has any categories associated with it. If it does, we recursively render the control again.
In the controller, we are simply passing in the categories where the ParentCategoryID == null.
On the host view (Index.aspx), we create the root unordered list with an ID of "treeview" and pass in an array of the Parent categories (categories where the ParentCategoryID == null) from the controller.
Here's a look at the output WITHOUT the jQuery magic.
Now all we have to do is add the libraries we're going to use and hook up the Treeview plugin.
Note: I always use the jQuery script from the Google API's. By referencing it from Google's server, you get to ride along their CDN, compression, etc. capabilities. As an added bonus, if your user has already visited a site that referenced the same library, the jQuery library would be cached on their browser so they don't take the hit of having to download it again. Sweet!
In our jQuery script, we just get the ul's element ID and call the plugin's treeview() method with no options.
When we refresh the page, we see jQuery has done its magic and now we have collapsable, rich tree view.
There's a ton more options in the Treeview plugin that you can check out for yourself, including async loading with ajax, and tons of customizations. ASP.NET MVC and jQuery - a match made in heaven!
Hope this helps!
I've been feverishly adapting and experimenting with the ASP.NET MVC Framework since the very first CTP. I must admit, it keeps getting better with every release. This past week was the official BETA release and I'm loving it.
It has been a challenge for developers new to the concepts of MVC to find reference samples to help architect MVC web applications. For this, I've suggested to look towards more mature MVC frameworks such as Ruby on Rails for common patterns in MVC applications. RoR is not difficult to read and you'll certainly be able to follow the program logic. I've HIGHLY recommend you take a look at this white paper exploring RESTFul Rails and then see how you can apply it to ASP.NET MVC.
UPDATE: Installation of .NET 3.5 SP 1 on my web hosting completely killed this app! I'm currently going through the process of upgrading it but it will be down for a while.
I am officially announcing the beta release of the GiftListr for Facebook application.
GiftListr is the only truly universal gift registry allowing you to add products from ANY website without limitations. Just browse stores the way you usually do when you shop online. Once you find the item you want, simply copy-and-paste the url into the GiftListr application. GiftListr will then download all the product information and product images available. You can add notes to each item and share you gift list with friends.
The application is built entirely on ASP.NET MVC and makes extensive use of the jQuery library. It also uses the Facebook Developer Toolkit available on CodePlex. I would love to hear some feedback from the ASP.NET community. Let me know what you think. Any features you'd like to see? Would you be willing to contribute to it if I add it to CodePlex as a community project?
I decided to write a second part to my previous post on extending the IQueryable interface to create a really neat and organized data access layer with Linq To Sql. The cool thing about this practice is that it nicely separates individual filters for integration testing and then lets you combine them to form much more complex queries.
I added a new filter, CreatedBefore, which simply filters on the created date of the blog.
I can now use this by itself or daisy-chain it with the other filters I've created. The resulting T-SQL is below. Note the new CreateDate filter's effect on it.
Linq to Sql gets even cooler! Let's say a Blog had associated Posts (a standard one-to-many, parent-child relationship). This would result in a entity model similar to the one below.
Using the same filters I already created for the Blog entity and combining it with the DataLoadOptions property of the data context, I can now get not just the filtered Blog entities, but their associated Posts in just one trip to the database! Nice!
I've blogged about how to use the DataLoadOptions in a previous post. Setting this as usual gives you the immediate result you're looking for.
The generated T-SQL statements start to get a little uglier, but I'll take the Pepsi challenge when it comes to some custom SQL a developer might have written for this same functionality.
Hope this helps!
Inspired by Rob Conery's great work on his MVC Storefront screencasts, I decided to look into his Pipes and Filters implementation and attempt to create my own. Although there was a lot of critical commentary on some of the design decisions, I found myself very intrigued by this fluent interface implementation. I haven't referenced back to the specific code samples so if it differs significantly, please keep in mind that this was certainly inspired by it.
A very nice feature of Linq to Sql is that it delays query execution until you start enumerating over the collection. This lets the developer build complex queries programatically and make only one call to the database. Linq to Sql is smart enough to derive the resulting T-SQL to produce your result set.
For this scenario, let's assume we want to select blogs that are tagged with specific tags and the blog name starts with a certain string. Below we can see a simple entity model that shows the relationships among the Blog, BlogTag and tag tables.
Let's keep the domain-specific language for our extension method names. I'll create two extension methods: "AreTaggedWith" and "BlogNameStartsWith". The former will accept a string array of tags and the latter will accept a string parameter. Both of these methods extend the IQueryable<Blog> interface and return the same.
We can then "daisy-chain" these all together to create are linq query before actually enumerating (and therefore executing) the final query. This will produce a nice looking, fluent interface for our data access layer.
Using SQL Server Profiler, we can take a look at the query that Linq to Sql actually generated and how it is executed with input parameters and all.
Looking at the query above, I'd love to hear your thoughts on whether this is the most tuned query for this scenario. Did Linq to Sql did a good job generating the query?
More Posts Next page »