Casey Charlton - Insane World

September 2008 - Posts

• Where Did filterContext.ActionMethod Go?

  Awww cmon Microsoft, play nice with us. I want to do something that should be pretty simple, I just need to know what action is being wrapped by my custom filter in ASP.NET MVC After a surreal amount of Googling I finally found a blog post that showed where this little bit of information hides, in filterContext.ActionMethod. But I could have sworn I went over that 100x with Intellisense and never saw anything like that. Oh yes, indeed I did, Preview 5 removed this convenient method. So after a bit of swearing, and a small (140 chars or less) rant on Twitter ... Sidar came up with the answer buried in the ASP.NET forums. So what is the new location ... would you believe it is now an entry in the dictionary in RouteData??? No, nor would I have believed it. What kind of crazy world is this, when a strongly typed method is replaced by a magic string key to the RouteData dictionary :S So for now, this fixes it, but I hope MS can make this all nice and strongly typed again, it is a fairly minor thing, but I like my Intellisense, and I hate magic strings: public override void OnActionExecuting( ActionExecutingContext filterContext) { var methodName = (string)filterContext.RouteData.Values["action"]; p.s. Hmmm this Twitter thing may be the future ...   Posted Sep 30 2008, 05:57 PM by Casey Charlton with 3 comment(s) Filed under: Rants, Sample Code, ASP.NET MVC

• 8am and The Managed Extensibility Framework

  Brad Abrams can always be relied upon for a great post - and the latest whizzy thing to come from Microsoft is the Managed Extensibility Framework. I know this is a good thing, because Ayende and Sidar blogged and told me it was. In his simple step by step run through, Brad shows some of the benefits of MEF to those kind of applciations you have to plug together ... but for the life of me I cannot understand a word of it ... I'm pretty sure it isn't Brad, and I'm pretty sure it is me ... 8am really isn't a good time to approach this stuff. It isn't helped by MS calling it the "Managed Extensibility Framework", but Brad referring to it as the "Managed Extensions Framework" On a similarly related note, I decided to sign up to Twitter last night to see if anything interesting happens there (I left my mouse in work, and couldn't be bothered to use my laptop glide pad, so I was playing on my iPhone, and Twitter came up in a search, and ... well you know how this goes). Anyway ... the main reason this is related is that one of my first comments to Twitter was "6am sucks" ... well 8am hasn't got any better ... and I strongly suspect the day is going downhill from a bad start. Ever have a feeling it was going to be "one of those days" ?   Posted Sep 30 2008, 07:56 AM by Casey Charlton with 2 comment(s) Filed under: Rants, MEF, Twitter

• Development is Hard

  Oren, as he often does, hits the nail bang on with his latest post Cuddling is consider harmful. Development is hard, and getting harder all the time. For every new framework that comes out to simplifying the complexity of the code we write, another two technologies hit the market. For every practice and principle we get to grips with, two other will evolve. The better we make software, the more users expect. Not only is development itself hard, but you have to be constantly learning and adapting to stay in the game - it is an endless race. As Oren says: Development requires a lot of skill, it requires quite a lot of knowledge and at least some measure of affinity. It takes time and effort to be a good developer. You won't be a good developer if you seek the "X in 24 Hours" or "Y in 21 days". Those things only barely scratch the surface, and that is not going to help at all for real problems. The rewards can be high, but the tradeoff is that you must work for your money, both in terms of producing real results, in keeping yourself educated, and in being aware of what is happening in the wider field, and that requires time and effort. And yes, a lot of the people who call themselves developers should put down their keyboards and go home. I cannot help but agree. If you aren't willing to put in the time and effort, then you probably should be in an easier profession. This isn't an elitist rant on my part, nor I am sure on Oren's - it is merely an observation that things don't come for free, and hard work and dedication can pay off. We all have to start somewhere, and for those people I would offer every encouragement and helping hand, but in return you must put the effort in, and strive to be better.   Posted Sep 23 2008, 09:30 PM by Casey Charlton with 8 comment(s) Filed under: Practices and Principles, Rants

• ASP.NET MVC, JQuery and Cross-View Javascript Events

  I wrote a nice little charting component for our site recently, and needed to call a Javascript function in one View (the one that was the main page for charting), from another View (one that went off to the server using Ajax to load up a list of feeds that could be charted). This would have been traditionally done by putting a function on one View and calling it from another, but this is just a little bit "messy" and prone to breaking. Luckily I decided fairly early on to use JQuery on this site (mostly as I hate writing Javascript and JQuery makes it a doddle). With JQuery I can define a Javascript event across the two views, thereby providing me with a loosely coupled way of achieving my objective. On my main index page I have: $('#graphFeeds').bind("add", function(e, feedId, description){         for(i=0;i<graphedFeeds.length;i++){             if(feedId==graphedFeeds[i].feedId) return null; }         var theFeed = new feed(feedId, description, "Green", "Line", 0, 1);         $('#graphFeeds #table tbody').append(createFeedTableRow(theFeed));         graphedFeeds.push(theFeed);    }); And on the view that contains the list of feeds I have: function addFeed(feedId, description) {    $('#graphFeeds').trigger('add', [feedId, description]);} Now by calling the addFeed() function on my list of feeds (I have a little "add to chart" link to the right of each feed), the Javascript event will be fired for the #graphFeeds div ... and the listening handler defined on the index view will go off on it's merry way and add the selected feed into the chart. Much as I hate Javascript, I love JQuery    Posted Sep 17 2008, 01:50 PM by Casey Charlton with 2 comment(s) Filed under: ASP.NET MVC, Javascript, JQuery

• Don't Tell Me "How", Tell me "What"

  During a discussion with our project manager earlier today, I used the phrase "Don't tell me how you want it to work, tell me what you want it to do" We were discussing user stories, and I was trying to get across what I wanted to see on a story card, and what I didn't want to see. He had put a story card on the wall that read: On the login screen: Should be a username box Should be a password box Should be a change password link Should be a remember me link Should be a register link As user stories go, this pretty much sucks as badly as it could. He was trying to tell me how to write a login page, as he saw it, but he wasn't describing what functionality he wanted the accounts system to have. Don't Tell Me "How", Tell me "What" My user stories for a similar scenario would be more like: As a registered user I want to be able to use my existing account details to sign in to the site to allow me to access restricted content As a registered user I want the site to offer to remember me when I sign in so I don't have to enter my details every visit As a registered user I want to be able to get a password reminder so that I can login even when I have forgotten my password As a registered user I want to be able to change my password so that my account is more secure As a new user I want to be able to register on the site and receive a username and password None of these say how the user achieves the objectives, but they do encapsulate what functionality is actually required. The first card would have had a developer acting as a parrot and likely producing something that missed the goals widely. The second version allows the developer to see how all these functions will interact, and to make a page that best reflects the requirements ... it also happens that the second set of cards neatly becomes a directly applicable UAT script. Now we can easily adapt the functionality to new requirements, for example these stories encourage a separation of the view from the actual functionality, so it is more likely we can put a login box on every page, or provide a register by email option instead of filling out a form. What Format Should Stories Be In? Traditionally I have tended to go for a simple format: As a [insert role or type of user here] I want to [insert required fucntionality here] So that [insert business benefit, or desired outcome here] There is a pretty good write up of this on Dan North's site, so to save me repeating it, check his page out, he also steps into BDD style stories too, and how they reflect various scenarios.     Posted Sep 17 2008, 12:55 PM by Casey Charlton with 14 comment(s) Filed under: Practices and Principles, Agile

• The Tao of Domain Driven Design

  Tao is often referred to as 'the nameless', because neither it nor its principles can ever be adequately expressed in words. It is conceived, for example, with neither shape nor form, as simultaneously perfectly still and constantly moving, as both larger than the largest thing and smaller than the smallest, because the words that describe shape, movement, size, or other qualities always create dichotomies that are only parts of Tao. (wikipedia) Domain Driven Design is the latest  software fad, and DDD is already becoming a buzzword recruiters are looking for on CVs. Every developer wants to be doing it, and many think they are doing it. But most of these developers see DDD as a series of software patterns and development guidance, and miss what really underpins DDD - The Tao of DDD Domain Driven Design certainly includes software patterns, and certainly includes coding guidance, but what the book is really about is a different way of thinking, a different way of solving problems, a different way of communicating. In DDD the principles of Repositories, Entities, and Anti Corruption Layers merely mask the more important message, that software developers need to become part of their business users domains, developers need to stop thinking in technical terms and constructs, and need to immerse themselves in the world their business users inhabit. DDD is more about how we as developers remove the artifical boundaries that exist between IT and the businesses we are there to support. If you read DDD as a software development "cookbook", or you pick and choose patterns you like from the book, you will miss the whole point: There is technically nothing new or revolutionary in DDD, there is only a guide to a better way of thinking. While the Tao cannot be expressed, Taoism holds that it can be known, and its principles can be followed.   (wikipedia) Posted Sep 10 2008, 09:21 AM by Casey Charlton with 9 comment(s) Filed under: Practices and Principles, Rants, DDD

• ASP.NET MVC Problems with UpdateModel(model, Request.Form.AllKeys);

  We just added a new dropdown list to one of our forms, which has a javascript function to change the background colour of a textarea. And the UpdateModel() on our controller class promptly fell over ... It turns out that UpdateModel() requires your class to have a property it can map for every form control with a Name(presuming you are using the lazy 'Request.Form.AllKeys')... or it throws an exception ... not the most helpful or obviously expected behaviour. Instead, use TryUpdateModel(), or use our quick fix to remove the Name from our dropdown as it wasn't needed. For binding that uses reflection, I would far rather the default behaviour was just to ignore the property ... this would allow views to be changed more easily without having to change the controller.   Posted Sep 04 2008, 10:31 AM by Casey Charlton with 7 comment(s) Filed under: ASP.NET MVC

• ReSharper 4.1 Released

  Everyone else in the universe has blogged this already, but I don't see anyone else on Devlicio.us having done so ... so here it is ... ReSharper 4.1 is released, lots and lots of bug fixes, some cosmetic stuff, support for VS2008 SP1, and even a few new minor features .... get it here Posted Sep 04 2008, 10:28 AM by Casey Charlton with 1 comment(s) Filed under: ReSharper

• Nasty "Gotcha" with ASP.NET MVC and Views

  We just spent far too long on what turned out to be a stupid problem ... we kept getting an error telling us that the view did not inherit from System.Web.UI.Page ... unfortunately the guy who was working on the particular view and controller could not think of a specific change he had made to cause this error, and looking at the code didn't reveal one either. The problem was actually quite subtle, and quite stupid ... A short while before the developer had decided to change the view from being an ".aspx" to being a ".ascx", so removed the view from the solution, added a new view that was a UserControl, and carried on working.  What he hadn't done was to actually delete the .aspx file, and even if he had done that, the other developers would have got this weird error too unless they pulled a clean copy of the solution, or manually deleted the files from their disk. (clarification: El Guapo pointed out I was being ambiguous here ... if the file is *deleted* from the *solution* then it will go from disk and from SCM, if if is removed from the solution and then deleted it will remain in other developer's directories *if* a VS addin like Ankh is being used, as the Update will operate against the solution and referenced files, not the folder structure) When ASP.NET MVC is told to render a view, by using RenderPartial("MyView") or return ("MyView") for example, it goes off merrily and scans the file system for a file matching "MyView.ascx" or "MyView.aspx" (presuming the default ViewEngine) - however if the view exists on disk in both forms, it is a bit of luck as to which actually gets returned and is rendered. Removing the old file fromn the solution is not enough, it still exists on disk - delete the old one and all is well. Hopefully this is a fairly infrequent problem, but it was a real pain to figure out. So if you get an odd problem in ASP.NET MVC relating to Views ... just make sure you haven't got old files in your directory structure! Posted Sep 04 2008, 09:27 AM by Casey Charlton with 9 comment(s) Filed under: C#, .NET, ASP.NET MVC

• Problems Upgrading ASP.NET MVC to Preview 5

  Expecting it to be painless to move from Preview 4 to Preview 5 was probably hoping a little too much ... but it certainly wasn't the worst thing in the world. A couple of things did catch me that I didn't find in the notes for upgrade, so I thought I best post them in case someone else gets the same problems: BindingHelperExtensions.UpdateFrom has gone Yep, gone ... which was a bit of a pain. I understand many people are using other methods, and probably we should be too, but this was the simplest option and is now being used commonly here.  In it's place it turns out that you can use: UpdateModel.From(model, Request.Form.AllKeys) this.ReadFromRequest has gone Another removal, the replacement is: Request["key"] LinkBuilder and BuildUrlFromExpression gone Actually they haven't, but they have been moved to Microsoft.Web.Mvc ... so you probably need to change your references to the new assembly. Multiple Entries for System.Web.Routing in web.config I did a manual edit to change the assembly version from 0.0.0.0 to 3.5.0.0 and I missed a few - it seems there are 4 entries for this assembly in my web.config - so check you updated all of them ... Update: Html.CheckBox("rememberMe", "Remember me?", "rememberMe", true) has changed! Missed this one till one of the developers here tried to get the login page to work ... it looks like they changed the signature of this, and a few other Html.xxxx extensions ... a bit of a pain, we only have around 50 views at the moment, and unfortunately it isn't a simple find/replace ... oh well ... Further Update: Html.ActionLink is just plain broken Grrrr ... This is annoying ...  They went and changed the signatures on Html.ActionLink This wouldn't be so bad, except that our previous line of: Html.ActionLink("edit", "Edit", ViewData.Model.ControllerName, new { item.Id }) Doesn't work, and results in a link with ?Length=8 on the end of it. This appears to be because it is matching the wrong signature on the ActionLink overloads, and now matches "string controllerName" as object instead. Fixing it is rather "yuk" ... force it to use the right overload with: Html.ActionLink("edit", "Edit", ViewData.Model.ControllerName, new { item.Id }, null)     Posted Sep 02 2008, 01:16 PM by Casey Charlton with 11 comment(s) Filed under: .NET, ASP.NET MVC

• Domain Driven Design Quickly - InfoQ

  A little earlier today I found myself explaining Aggregate Roots and Anemic Domain Models to a couple of developers here, and I wished I had my copy of Domain Driven Design to hand to show them what I was explaining ... then I remembered that InfoQ published an *excellent* online book called "Domain Driven Design Quickly" - free to download, or you can buy the printed version. This book is a perfect introduction to DDD, and as it is free, you cannot really beat if for value for money! From the introduction: The most complicated aspect of large software projects is not the implementation, it is the real world domain that the software serves. Domain Driven Design is a vision and approach for dealing with highly complex domains that is based on making the domain itself the main focus of the project, and maintaining a software model that reflects a deep understanding of the domain. The vision was brought to the world by Eric Evans in his book "Domain Driven Design". Eric's work was based on 20 years of widely accepted best practices in the object community, as well as Eric's own insights.  Domain Driven Design Quickly is a short, quick-readable summary and introduction to the fundamentals of DDD. A special interview with Eric Evans on the state of Domain Driven Design is also included. Posted Sep 01 2008, 12:52 PM by Casey Charlton with 2 comment(s) Filed under: Agile, DDD