Here at InterKnowlogy we have this great program called RECESS where we get to take a few hours each week to try our hand at new technologies. One of our leads, Dan Hanan, posted a great little read on what RECESS actually is so I won’t go into any more detail about it.
Background
One of the best ways, we’ve found, to learn a new technology is to utilize it in an application in order to find its strengths, weaknesses, etc. Being a bunch of Software Engineers we have a tendency to be obsessive and compulsive in almost everything we do, and when that is paired with pickiness over certain types of food, deciding upon where to go to lunch as a group becomes very time consuming (almost longer than actually eating the food). So back in the spring of this year a couple of other devs and myself decided we wanted to learn more about ASP.Net MVC, Silverlight 4 (with RIA), and Entity Framework 4, and decided on creating a lunch decision service using these technologies (kill 2 birds with 1 stone and have fun doing it). We also decided that we needed a good name for this application before we could start, and since InterKnowlogy’s slogan had recently changed to Delivering the Art of Software, we decided to play with it and call our application the DAL (Delivering the Art of Lunch).
Scenario
The most important thing we’ve learned from other RECESS projects is to keep the finished project as simple as possible otherwise it won’t ever be finished. So we decided to create a service that would send out an email to all the registered users, at a specified time in the morning, to see if they will be joining the group for lunch. In the email is a link to an MVC page where they say yes or no. A little later on everyone who says that they are in for lunch then receive another email with a link to another MVC page where they can choose their top 3 restaurant choices(the restaurants are an intersection of all the preferred restaurants of the users joining in for lunch), and a little later an email stating the restaurant choice is sent out to everyone participating in lunch. It is then up to the people involved on whether they are going to abide by the choice or not.
We decided to use the Silverlight client to be where we register users, create/update/delete restaurants, and choose which restaurants the user is ok with going to for lunch, and the ASP.Net MVC site is where the users specify if they are available for lunch and their top 3 restaurant choices. It also shows who has said they are joining in and what the final restaurant choice is.
After a few weeks of work we had an Alpha version that we wanted to try out with our coworkers. So we deployed it to a server, and sent out an email letting everyone know about it. With it being Alpha we expected to run into a few issues, but within the 1st day we hit one issue that brought the whole thing down. Our owner, Tim Huckaby, loves to hear about new things we’re working on and try them out. So he joined in, added 5 top restaurants in the world (that none of us can afford let alone get to over lunch time), and made only those 5 his preferred restaurants. The next day when the process started and he said he was in for lunch (even though he doesn’t eat lunch with us), the resulting intersection of preferred restaurants was empty, and we weren’t able to use the application when it never provided restaurants to choose from.
Fixing the bug
While we have given Tim some much deserved crap over the restaurants he chose, he did find a very damaging bug that needed to be fixed. Our end result was if the restaurant intersection didn’t return any results then choose up to 5 of the most popular preferred restaurants, and if there still weren’t any the service randomly chooses 5 restaurants for everyone to vote on.
After a long hiatus, I finally got the bug fix along with a number of other refactorings up again and we’ll see how long it can stand. 🙂
Finally
The overall learning experience was pretty positive. Entity Framework makes development against a simple database extremely easy, and in the Silverlight world, pairing that with RIA services gives you the same functionality on the client side. One issue with RIA that I ran into is the fact that any extra methods you create to extend the DomainService is very limited to the parameter types that can be used. It is extremely powerful for basic CRUD functionality, but it takes work to get more complex things functioning. ASP.Net MVC is really powerful and something that I will need to delve into more in the future.
More RECESS rambles to come.