Tuesday, October 09, 2007

ALT.NET Goodness

Wow.  What an awesome event.

I’ll skip the play-by-play, because that has been covered to death.  Instead I’ll focus on my notes.  There are definitely some “meaty” posts in my mind that are still storming, so expect good things to come.  There are some good points here, but it’s a long post so I’ll be surprised if I get any comments .

Being a Catalyst for Change

I first attended a session on “Fostering Passion” and “Being a catalyst for change” which were grouped together.  A lot of people showed up and J.P. Boodhoo led us off.  He talked about the importance of a good, healthy work attitude, and if you aren’t getting what you need from your current employer then you should really seek out something better. 

  • You need to show pain before you can start evangelizing new stuff.  Ask people the question “How is that working for you?”  or “What would you want to improve first…. why?”  This gives you the context and the opening for suggesting new ideas.
  • Talk about problems in context with the 4 variables, this helps lead to whether something is “working” or not
    • Time
    • Scope
    • Quality
    • Budget
  • Hosting brown-bag sessions is a great way to get people excited.  Scott Hanselman pointed out that he found it valuable to create a “shadow government” of peers who you can individually get excited about different topics.  Ask them to give a lunch & learn and spread the word that way.  Somebody called them “Hanselminions”  —  epic.
  • JP Boodhoo stressed that we build relationships before we offer to “fix up their processes.”  If you come in wanting to change everything you’ll just alienate your team and ruin your credibility.
  • Another thing that we discussed is that newcomer’s to our community are going to be very overwhelmed…  currently there isn’t much direction.  We don’t want to be prescriptive, but a general “go in that direction” will definitely be helpful.

Advanced NHibernate

The next session I attended was Advanced NHibernate Techniques, facilitated by Jeffrey Palermo.  I found this to be awesome, because usually when I get to talk (or listen) to NHibernate at a user group or code camp, it’s focused on the beginner side of it.  Everyone in the room had been using it for a while, and had some really good suggestions and valid problems with it.

  • ActiveRecord vs. Persistant Ignorant?
    • I suggested that for dead-simple models, or a team that doesn’t know DDD, that AR was a much easier path with less friction, however you do quickly hit a limit here when you want to start using more Domain Driven Design such as the Aggregate root/aggregate relationship, repository pattern…  or if you need these to be remote… they can’t be used on the client side.  Somebody pointed out that it is very difficult to switch from one to the other, and this makes the initial decision very hard.
    • Howard Dierking pointed out that “No Simple CRUD app stays that way”
  • Database, Mapping, Code -> which first?
    • This was basically a poll question.  Almost everybody here started with code, then database, then mapping.  Very few people used hbm2ddl (like I do) to generate the database.  We all agreed that generating the database needs to be abandoned once you start doing tuning and specific tweaks.  The Eleutian guys (who have names, by the way… Aaron and Jacob) have a pretty hefty process that all starts with a modeling tool.  It kind of scares me, but they seem to have it working so that they don’t have to re-work anything.  To be truly DRY you definitely need another abstraction, however I’m not convinced that UML is it.   What if we had a Boo DSL that represented the mapping, and we could specify advanced DDD concepts there, and have it generate the code, hbm, and Database…?
  • Issues?
    • Aaron and Jacob have been stressing about Adaptive Queries and Read-only queries, and I need to make an effort to understand their problem.  Originally I dismissed this as a non-issue, but that’s a cop-out.  I want to understand what they are wanting that they aren’t getting with NHibernate.
    • We all seemed to agree that it’s painful that if you have a single error in your mapping file, the session factory throws an exception and just about every test in your application will fail.  This SUCKS for pinpointing the error.  I heard Howard mention something about jitting the mapping assemblies (I guess while writing?) — I definitely need to continue this discussion with him.
    • Partials mappings would be pretty cool, so you could generate the mappings based on default conventions, then you could override when necessary.

ASP.NET MVC Framework presented by Scott Guthrie

  • This flippin’ rocks.  A detailed post to follow.

Domain Driven Design – Facilitated by Dave Laribee and Scott Bellware (with a cameo from yours truly!)

  • This was pretty much review for me, but it’s always good to get refreshed.
  • Opening your mouth is a good way to get people to ask you another question (provided you didn’t say something completely stupid) — I kept getting asked to explain more topics here, which was flattering.
  • At one point I said “If you haven’t read Evans yet, go TODAY and buy his book.  Then read it 8 times.”  — This led people to believe that I had read it a few times.  Nope!  I still have 7 more to go .
  • A lot of discussion went around the different between responsibilities of the entities, and the responsibilities of domain services (not to be confused with application services or <gasp> SOA).

User Stories (facilitated by Scott Bellware & Raymond Lewallen)

  • The more I dig into this stuff the more I like it
  • Epics– 30,000 ft view (almost impossible to estimate) (if you have to, also provide a low confidence value)
  • Theme – closer, but not enough to estimate.  Gives more detail.  Many themes per epic
  • Story – small enough to provide estimate & acceptance criteria.
  • Ray said “I can give you a gantt chart & have it say whatever you want on it.”  — this is funny, but SO true
  • Estimation accuracy and Trust are increased as time goes on… providing you aren’t making empty promises early on
  • Don’t estimate a user story until you have acceptance criteria
  • Acceptance Criteria (AC) can be technical
  • AC helps define “done”
  • Early stories will add a LOT of new concepts
    • new models
      • tables, entities, whatever
    • some UI req’s
  • Estimating epics helps w/ product planning  (“How much can we put in by next year?”)
  • Release planning should NOT include epics.  Break them down.
  • AC transitions, which leads is implemented in TDD/BDD style
  • Test names should describe the behavior, not impl.  I’ve got to follow this rule more often.  A lot of tests I write are explicit in that I know what happened if it failed, but the actual story that I’m working on is missing.  The failing test has no context, and thus no value associated with it.
  • BDD classes are named after the state or original behavior.  The setups for this class put the object in that state.
  • Method names are named like the AC
    • public class When_a_case_is_opened
      • public void Its_status_is_changed_to_open

Are Executable Requirements Possible?

  • Jeremy Miller started off by stating the value of Fit vs. FitNesse and a lot of people showed pain with FitNesse. 
  • Fit/FitNesse works great when dealing with state-based testing
  • Behavior based testing is where it breaks down and becomes really cumbersome
  • He invited Joe Ocampo (from Los Techies) to talk about NBehave
  • NBehave solves their problem of providing change tracking and traceability into their organization because they have a strict environment that requires it.
  • They have a fluent language that looks like theUserStory.AsA(“Premier Member”).IWantTo(“get a discount on future purchases”).SoThat(“I can save money”)
  • I joked that they could also have another fluent interface that looked like SystemShall.(“Have a textbox”).ThatShallContain(“the user’s name”) 
  • This helps solve the issue where refactoring is difficult.  Since the strings above are keys for delegate hashes, you’ll get an exception if someone changes the text of a story.  This will spark a much needed conversation with the developers.

I’m still trying to bask in the awesomeness that came from this event.  All you naysayers out there are just upset that you missed out .

Tuesday, October 09, 2007 3:28:43 PM (Central Standard Time, UTC-06:00)
Thanks to all in the DDD session who didn't denigrate my "noobness" questions.

Ordered the Evans book today.

FYI: The Laribee link above is broken:
http://www.flux88.com/codebetter.com/blogs/david_laribee
Brad Mead
Tuesday, October 09, 2007 6:42:15 PM (Central Standard Time, UTC-06:00)
Hey Ben,
It was good to meet you in Austin. With regards to adaptive queries, it's not that we really have a problem per se, there's just a lot of room for improvement. Jason Grundy said it well when we were talking in the hallways... regular object queries are good enough 80% of the time or so before you need to go to hand tweaking. Adaptive Queries would just get you up to 90-95% for "free".
Tuesday, October 09, 2007 7:14:23 PM (Central Standard Time, UTC-06:00)
Aaron, what about in session-per-webrequest pattern, where the session is so short lived? Would you recommend persisting these strategies outside of the session context? How would the system unlearn strategies that were previously used heavily?
Thursday, October 11, 2007 2:13:09 AM (Central Standard Time, UTC-06:00)
Ben,

The strategies *must* be persisted outside of the session. That is the whole point. They are session and user agnostic. They basically "learn" what is the maximum set of data all users need from the database for each context (service method, controller method, whatever you decide your context is) & query combination. The only time they really need to be unlearned is if the code is changed.

To give a simple example, say you have a "select * from User" but you only need firstname and lastname. Well, you can either do that in your query "select firstname, lastname from User", or you can just use an adaptive query "select *? from User" and it would figure out and persist the "firstname, lastname" piece.
Thursday, October 11, 2007 11:02:12 AM (Central Standard Time, UTC-06:00)
Interesting that you said "session and user agnostic" which might actually mean totally different things. I guess your "scope" would need to accommodate the scenarios where the query needs to adapt on a per-user basis.

You know what's funny? This whole adaptive queries problem is so much better explained by your hql. Select *? is actually a really great syntax.

I'm still on the fence, but this is interesting stuff.
Comments are closed.
Remortgages - Loans - Credit Card Consolidation - Credit Counseling