As of now, I’m happy to announce that the next installment of the Autumn of Agile Screencast series is available for download and viewing from the main site.
WARNING: Length is still an issue!
Despite my best efforts to contain the length of these things, this one has now set a brand new (personal) record for length: 3 hours and 17 minutes! 
I know that in comments rec’d to this prior post, viewers indicated that longer wasn’t necessarily an issue (so long as there was good content for the entire length of the screencast), but even if viewers combine judicious use of the STOP button with Windows-Media-Player’s ability to play in 2X speed, I’m still concerned that the length is going to be a barrier to consumption.
Determined NOT to fade-in and fade-out
Never the less, I am determined not to fall back to the fade-in/out method and start skipping any actual recording of work on the project. I feel strongly that for this effort to be truly valuable to a viewer, its important to show the entire process, warts and all, so that what is presented here is a realistic version of an actual Agile project (or at least as real as it can be when there is only one member of the team and there isn’t really a client/end-user in-play).
That said, I’d be very interested in viewer feedback about what really starts to constitute too long an installment. What’s too big to download in today’s era of (generally) available higher-bandwidth Internet connections (this one is over 380MB)?
What’s Covered
The upside to a 3+ hour screencast, is that we get to cover A LOT of material 
. Here are some high-points in this installment…
- Thinking about the design of our URLs as first-class citizens in our application
- Creating our first ASP.NET MVC controller
- Creating unit tests for the controller
- Wiring up our IoC container to inject our repository into our controller
- Extracting an interface for our repository so that we can mock it in our unit tests
- Understanding how to (properly) mock our Rhino UnitOfWork abstraction for the sake of our unit tests
- Creating our first ASP.NET MVC view
- Wiring up HTML CheckBox inputs to our SkillTypes list
- Creating our first HTML form elements in ASP.NET MVC
- Understanding HTTP Verb Action Filters in ASP.NET MVC
- Introducing a UserService to get the Employee object for the current user
- Writing unit tests for our action methods
- Understanding how to pass complex objects from Controllers to Views (introducing the ViewModel concept)
- Uncovering a bug in ASP.NET MVC BETA form data modelbinding (and working around it)
- Exposing an oversight in our AddSkill(…) business logic (and saving it for next time!)
As always, comments, feedback, etc. are welcome from all.
Happy viewing~!
Yeah, keep it going! Size/length doesn’t matter.
I enjoy following your screencast every single time. Its detailed, profound and therefore easy to follow. Unlike many tutorials the code I reproduce watching your screencast just works.
I’m really excited and i will be downloading soon and I’m set for this week 😉
size/length does not matter
great job!
Hi Steve,
Same opinion on the length. And i was thinking whether you could post the code in google code or something as it would be easier for us to just update the code base instead of downloading the whole thing for every episode.. Not that it is of any trouble 🙂
And thanks for the effort of doing this for the community….
Hi, congrats for the new screen cast. In my oppinion all screen casts are too short 😉
Regards
OK, I’m going to say two things:
1) I’m going stop worrying about the length of these screencasts given the repeated feedback from viewers that it doesn’t matter; I will still *attempt* to keep them somewhat shorter, but am not going to sweat much over their being too long
2) I’d like to propose a moratorium on the phrase “Size/Length doesn’t matter” because its too possible to misinterpret that taken out of context 😀
Thanks again, all.
I know this would add a zillion pounds of complexity, but wouldn’t running feet be cool in a long screen cast? Like at the bottom in the form of an overlay it could say what topic is being explored “Wiring up the IoC container” or something, so that those who are looking for a specific section afterwards could easily jump to the right spot?
Or when the series is done and complete maybe it could be re-cut in smaller sections…just thinking out loud.
But I gotta add my 2 cents that the length of the screencast is not a problem for me.
Ryan
@Ryan:
Hmmmm…actually that’s not a bad idea in general although the implementation you are suggesting is perhaps a bit more complex than I want to undertake.
HOWEVER, I actually DO record these in short (relatively) snippets and then use CAMTASIA to stich them together so it might acually not be that much effort for me to publish show notes or something that lists each topic and when its being covered like “12:34 – Wiring Up the IoC Container” or something and then you could just ffwd to the part you wanted to see.
Would that make sense…?
[…] Vote Autumn of Agile Iteration 01 – Part C Screencast is now Available […]
I’m with everyone else in saying that I’d rather see everything without the jump cuts between coding. I think these casts are excellent, in that no one really puts all the best practices together in one place in other examples online simply because they don’t have the space (or time!). I’m finding this series extremely valuable. Keep up the great work!!
The long length is not important, but I really like your screencast.
I totally agree on the part of being able to jump to a particular part in the screen cast.
Last weekend I was ffwd-ing a screen cast to watch how you set the CI server up.
My 2 cents.
Besides that I don’t have any problem with the lengths.
@steve
Yeah I think that could be really helpful, even if it’s just in the blog post. It’s not much of a problem now…but I can see in like 5 videos from now trying to recall in which cast at what time you did what could become problematic.
@Steve
What do you think about the SEO for this project? I know that this website will be used only by the mikrodesk’s employees but imagine you have to make good SEO. I read that the MVC has some problems with the routing model like the last “/” in the URL (just type “mvc seo” and hit the first 2 results). I know that SEO was not in the list of contents but I think that SEO is important for the headline AutumnOfAgile. SEO is not only URLs but also content, page structure, validation etc. Can you spend 15 minutes of the next 3h screen cast and share your experience about this?
Regards
@mynkow:
>>Can you spend 15 minutes of the next 3h screen cast and share your experience about this?
BRILLIANT!!!! Turning the length of these things against me! I love it~! 😀
Sure, I’d be glad to do this. Will see what I can do in the next installment.
@Steve
I am happy that you like the idea. Now about the microdesk.dll which you use in these screen casts for GUID and other purposes. I didn’t download the code but I am sure it will be in the *.zip. But is it possible to have this dll from the microdesk official/unofficial website? So when you make changes or expand the lib we can have them too for example 1-2 years after the end of AoA(AutumnOfAgile) or new NHib version. The other solution is all we to “spam” Rhino to include similar functions into the known library (with your help).
Best regards, mynkow
In addition to what mynkow wrote, it would be nice to also have a release build of the microdesk.domain.foundation.dll.
@mynkow/tbrooks:
I will press my employer to make a decision about this issue by the close of 2008 either way. Thus far, no decision either way.
If I cannot release the source code (google code, etc.) then I will definitely provide a release build of the Microdesk.Domain.Foundation assembly that is properly versioned, etc. (you will note that the present DEBUG assy is just 1.0.*.*).
@steve
Thank you.
Steve, thanks again for the great content. Let me echo everyone else here in saying that the length of the screencasts is not a problem…its like a bonus 😉
I have a couple questions about how you are using the Unit of Work in your controllers. (EmployeeController line 88)
– Looking at the code for UnitOfWorkApplication, it seems like a UoW is started at the beginning of each request, and disposed at the end of the request. Given this, would you still recommend always explicitly calling UnitOfWork.Start() and Flush() within the controller methods? I can see that these explicit calls communicate intent, but for simple things they also seem to add a bit of ‘noise’ to the code.
– I noticed that Rhino provides a couple other ways to do things within a Unit of Work – the With.Transaction((() => //do stuff); syntax and also a facility for using [Transaction] in castle. Would you recommend using either of these as alternatives to explicit calls to UnitOfWork?
Thanks again,
Ben
@bydlo:
You are indeed correct that there are several implementation patterns for the (Rhino)UnitOfWork and I have shown but one. Rest assured that before the application is complete, we will have bumped into the need for several (if not all) of the others that you mentioned (including the With.Transaction(…)
In general, I prefer to be explicit about when I intend to flush my UoW within my controller methods rather than just letting the ‘ambient’ UoW handle it per-request. This may put me at odds with most Rhino users, but I’m ok with that 😀
I usually find that while at first glance it may seem that this is ‘noise’ in the body of the controller method as you suggest, I think that the UoW (at least in re: when its flushed, etc.) is more of a business concern rather than a persistence concern and so I don’t ‘mind’ it appearing in my controller methods. It also makes the code easier to follow for anyone reading through it and provides a simple extension-point in the code should there be a need to change the implementation to start a nested UoW rather than simply hook into the ambient HTTP-request parent UoW (e.g., the originally-intended ‘scope’ of the UoW is already delimited by the using(…) block).
As you say, there are actually many different ways to use the Rhino UoW abstraction (frankly that’s one of its strengths IMHO) and which one you choose is *sometimes* largely a matter of personal taste. For example others might look @ the controller methods and say “I would prefer that even the fact that there IS a UoW is abstracted away from me” and in this case you can simply use the ambient UoW without explicitly invoking it.
Hope this helps clarify a bit,
-Steve B.
@sbohlen
Thanks for the clarification. I agree that it is VERY nice that Rhino allows you to choose how in your face the UoW is.
Thinking further on this, I can see your point about why being as explicit as possible with Flush() is probably a good thing…and certainly there are times when you would want to flush the transaction before the end of the request.
(That said, I’m glad that you are planning on looking at this further as the series progresses. :D)
@Steve
Hi again. I didn’t watch the last screen cast. My notebook is broken ;(. I am not sure if you included the SEO part in the new video lesson. I want to add something and this is the multi-language support. So what do you think about the constructing URLs for different languages? May be a custom routing. I think it is important for SEO the multi-lang support to comes from the URL. Do you have experience about this? Can you talk about Multi-lang and SEO or post some static guide?
Thank you.
Hi Steve
Firstly, thanks for a great series on Agile so far – I’m looking forward to the rest!!
Its not directly related to your example application as I’m primarily focussed on Winforms appls, so I’m not sure if you’re going to be able to help me, but I am hopeful that you can give me a couple of pointers.
My question is around using Rhino.Commons with a Winforms application.
I’m a little confused – mostly because I’ve looked at various posts on this and I can’t find a clear answer.
With WinForms I presume I still need to do the IoC initialization, but I’m not sure where to place this in my code. Do I do this once i.e. in Program.cs or a base class, per form,etc??
I guess some of my problem is following a screencast designed for a different application architecture. I’m also very new to NHibernate and have never used Rhino.Commons before. Not to mention I’m looing at agile for the first time.
Well there you go. Thanks again for the great series and I appreciate any advice you may be able to offer.
@Steve
One of the pieces to this conversation that might be more trivial, but relevant none the less, is the use of Guid’s in the url. You no longer have Controller/Action/4, but Controller/Action/44444444-4444-4444-44444444. The logical URLs in the MVC pattern are one of the positives in my opinion and this complicates it. Would be curious to hear your opinion on this.
Regards
Ryan:
This is an interesting observation, but not one that has crossed my path largely because I consider exposing PK values to users to be a pretty big anti-pattern (e.g., one of the reasons that GUIDs are ‘acceptable’ to me as PK values is that I don’t EVER want my users to see them under really any circumstances). In the synthetic- vs. natural-PK database design debate, I come down pretty strongly on the synthetic side, meaning that PKs never have any semantic business meaning to me.
In a URL, if (as you quite correctly suggest) its often valuable to expose some business meaning-value, I would *still* permit the user to see Controller/Action/4 but in this case ‘4’ would *never* be the PK of the thing I wanted to list but would instead be the ‘customer number’ or some other value with business meaning to my users.
IMO the canonical example of an exposed MVC URL of the form Controller/Action/id is a horrendously poor design decision to expose the PK of your records to the user of the system. PKs are an implementation detail that shouldn’t be exposed to users. I don’t mind seeing Controller/Action/4 at all as it can make the app easier to navigate, to link to, etc. but in this case ‘4’ would never be the PK value.
I seem to recall from memory that in this series of screencasts, I *was* exposing the PK as part of the URL at the early-stage design of the app (largely b/c it made testing it simpler for the time being) but by the end of the development cycle, the URL would certainly be adapted such that the ‘id’ part of the routing definition wouldn’t be the PK of the record in the DB.
Hope this makes sense and helps clarify my (eventual) intent with that approach.
-Steve B.
@Steve
My comment was intended to go under the Guid discussion post, but I must have not had enough coffee when I posted.
Thanks for the reply, it makes perfect sense. The only thing that I wonder is how else you would select something like a conference when the PK value is all that would provide you a sure unique value to select by? For Employees I can see the client having their own HR unique key for each employee that you can use, 1) because the employee is likely to know their employee number and 2) doesn’t expose the PK as you say. But what about entities that are created only in the software? I know you leveraged an Employee service to get the currently logged in user, but what about editing the details of a skill type? Would you not expose the PK to the Edit Action in order to get back the values for the form?