Herding Code 58: Presentation Patterns with Jeremy Miller, Ward Bell, Rob Eisenberg and Glenn Block (Part 2)

How about that?  You stuck around!  It was the Waylon Jennings, Good Ol’ Boys, Dukes of Hazzard, freeze frame cliffhanger at the end of Part 1 which hooked you, wasn’t it?  Undoubtedly you have been on the edge of your seat for days, just waiting to see how the show turns out.  Well, wait no further.  Here’s the commercial free, dramatic conclusion to the longest Presentation Patterns discussion ever.

When we last left our heroes, Jeremy Miller, Ward Bell, Rob Eisenberg and Glenn Block were in the thick of their discussion.  Jeremy had just finished explaining the role of the Screen Conductor and Ward was ready to start flushing out implementation strategies.  That is, implementation strategies which might work across most solutions. 

But thankfully, Glenn starts by stepping back a bit and asking how the presentation patterns discussion fits in the context of mainstream development.

Will the guys provide a single answer to the age-old question, “Which came first the View or the ViewModel?”  Is there a one size implementation which fits all solutions?  Will this conversation ever end?  Find out this week on Herding Code.

Show Links:

Download / Listen:

Herding Code 58: Presentation Patterns with Jeremy Miller, Ward Bell, Rob Eisenberg and Glenn Block (Part 2)

[audio://herdingcode.com/wp-content/uploads/HerdingCode-0058-Presentation-Patterns-with-Jeremy-Miller-Ward-Bell-Rob-Eisenberg-and-Glenn-Block-Part-2.mp3]

Show notes compiled by Ben Griswold. Thanks!

Herding Code 57: Presentation Patterns with Jeremy Miller, Ward Bell, Rob Eisenberg and Glenn Block (Part 1)

Have you seen the circus gag where clown after clown emerges from the smallest car one could possibly image?  Well, this week on Herding Code, the guys attempt that very same trick!  Listen in as Jeremy Miller, Ward Bell, Rob Eisenberg and Glenn Block (that’s right, four guests!) join the cast and talk Presentation Patterns.  This conversation started earlier this week on Twitter and it is shows no sign of slowing down.  Join us this week and next for an enlightening and exhaustive discussion about Views and Models and ViewModels and everything in between. 

  • Kevin asks the four guests to introduce themselves and then turns the podcast up to 11.
  • Jeremy kicks off the conversation with the “View First vs ViewModel First” discussion.  Jeremy talks about Views, ViewModels, Presenters, Behaviors, Implementation Detail, Separated Presentation, Passive View, iView Interface, Screen Activation, and User Controls… In summary, he’s pro-ViewModel or Presenter first.
  • Ward asks if anyone wishes to defend the View First position.
  • Rob shares that he tends to create his View and Presenter at the same time (although he’s mostly a Model kind of guy.)  Rob also calls out that he does a lot of prototyping in his workflow.
  • Ward talks about where his development always starts – sketching out the UI with his clients.  The ViewModel is ultimately developed to support the interaction discovered in sketching. 
  • Rob agrees. Talks more about prototyping first, gathering requirements, user feedback, workflow, architecture and conventions.
  • Jeremy considers application navigation, behavioral aspects of screens and the contract for view.
  • Glenn calls out the difference between Balsamiq mockups and screens which are maintained by a designer in Blend.  Which approach best supports the tooling experience, maintainability, and testability?  Glenn references Jonas Follesoe and how his designer girlfriend couldn’t function unless he defined the View first.  Glenn initiates conversations about Service Locators.
  • Jeremy questions whether one needs that level of detail.  Do you need to fake in a service locator for your designer experience or are there alternatives?
  • Glenn stresses that we must think about the designer (albeit there aren’t many right now), consider tradeoffs with varying approaches, talks about Prism and Patterns and Practices experiences, and tooling – particularly Blend.
  • Rob talks about providing simple conventions which are taught to designers in lieu of using an inversion of control containers like Windsor.
  • Glenn asks what the designer would see inside of Blend in this case and Rob isn’t aware of  any limitations with this approach.  Is this an issue of designer not having sample data to work with?
  • Jon shares his experience at Vertigo – applications favor design and tooling, applications don’t have complex business rules, applications are Blendable.
  • Jeremy appreciates that appearance may be the most challenging aspect of some applications.  In this case, maybe View First is the most appropriate approach but having Blend driving workflow is a case of the tail wagging the dog.  We need to consider the line of business applications and in that case ViewModel or Presenter must come first.
  • Glenn notes that the View being created first as part of instantiation does not correlate to whether the ViewModel drives behavior from that point on. View First is at the point of activation.  Whether the view is injected into ViewModel or the ViewModel get set into the View, the ViewModel is the guy which is in control.
  • Jeremy explains the Screen Activation pattern and some fairly complex scenarios where logic is executed before the view is activated. 
  • Ward states that he is not a fan of the view determining the ViewModel or the ViewModel selecting the View and prompts Jeremy by asking if a factory could pull the right pieces together and sequence them.
  • Jeremy takes Ward’s queue and talks about the Screen Activator acting as the gatekeeper which puts screens together.  Jeremy reference the Caliburn approach.
  • Rob clarifies the Caliburn ViewModels hierarchy and the use of screen activators and the composite pattern.
  • Glenn talks a bit about complexity, CAB, debugging hierarchies, event aggregators and messaging.
  • Jeremy calls out the benefit of using a composite pattern on a dashboard type application where a part of the screen may act as an application itself but an event aggregator would be best of cross-piece communication.
  • Rob notes that communication in Caliburn is local – it is parent to child or child to parent and this approach can really simplify development.
  • Jon and Rob discuss the approach of simply navigating between two tabs.  Would you use event aggregation, publishing event, commanding or what?
  • Jeremy gives detail to the Screen Conductor role and pattern and Rob stresses the value of methods such as Initialize, Activate, Deactivate, Shutdown and CanShutdown. Jeremy and Glenn walk through an example.
  • Glenn, Rob and Jeremy consider roles and patterns and if they vary from application to application.  Is there an established best practice?  Jeremy believes roles seem to be consistent but implementation changes from project to project. 
  • Ward wraps up Part 1 stating that he agrees with the idea of like roles but not ready to lock into any implementation.  He suggests we call out the actors and see how it plays… 
  • This conversation just won’t end.  Be sure to tune in next week for Part 2.

Show Links:

Download / Listen:

Herding Code 57: Presentation Patterns with Jeremy Miller, Ward Bell, Rob Eisenberg and Glenn Block (Part 1)

[audio://herdingcode.com/wp-content/uploads/HerdingCode-0057-Presentation-Patterns-with-Jeremy-Miller-Ward-Bell-Rob-Eisenberg-and-Glenn-Block-Part-1.mp3]

Show notes compiled by Ben Griswold. Thanks!

Herding Code 56: Markus Völter on Model-Driven Development, DSLs and Product Line Engineering

You know Markus Völter as the founder and voice of Software Engineering Radio. Well, this week on Herding Code, Markus finds himself on the other side of the microphone – fielding, rather than asking, questions. Listen in as Markus explains model-driven software development and product line engineering. Learn about modeling, domain-specific languages, code generation, Eclipse, development outside of the Microsoft/.NET world and much, much more, this week on Herding Code.

  • K Scott leads the discussion asking about developing with Eclipse. Jon asks how Eclipse’s plugin model compares to that of Visual Studio.
  • K Scott introduce the topic of model-driven development and DSLs. Markus steps back and takes some time to talk about terminology.
  • Markus shares why UML can’t be used to appropriately describe one’s domain and jokes that Microsoft has been ignoring UML for years but that are now gravitating toward it just as everyone else is moving away.
  • Markus discusses the difference between modeling and programming.
  • Kevin asks Markus his opinion of Oslo and M, the Oslo Modeling Language. Markus says it is difficult to compare Oslo to Textual Modeling Framework (TMF) found in Eclipse, talks about code generation being incorporated (or not) into Oslo and shares his thoughts about competition between groups at Microsoft. K Scott and Markus discuss their concern with Oslo becoming an extension of SQL and the mixed messages Microsoft is sending.
  • Markus talks about the blurring lines between External vs Internal DSLs.
  • K Scott and Markus discuss productivity gains when incorporating modeling into one’s development.
  • Markus shares the things which changed and influenced his career – design patterns and modeling. Markus stresses that building languages and generators is more applicable to software development than learning the API-of-the-day. K Scott and Markus talk about learning, focusing on the important stuff and separating technical and domain concerns.
  • Jon asks about Microsoft Axum. Markus explains Axum as “Erlang for .NET” and expands upon the benefits of concurrent and functional programming.
  • The show finishes with Markus providing a very nice overview of Product Line Engineering.

Show Links:

Download / Listen:

Herding Code 56: Markus Völter on Model-Driven Development, DSLs and Product Line Engineering

[audio://herdingcode.com/wp-content/uploads/HerdingCode-0056-Markus-Volter-on-Model-Driven-Development-DSLs-and-Product-Line-Engineering.mp3]

Show notes compiled by Ben Griswold. Thanks!