My Pex has not flexed recently. Peli has dropped a new version of Pex with a few breaking changes and I’m two revs behind him on implementing. One thing that I’ve come to realize is that I can’t manage the churn taking place for the code under test. The last few sprints have introduce large amounts of change in our persistence model and that, well, just screws the pooch when you’re trying to keep things updated. I’m trying to figure out the best way to manage the churn in my testing libraries – and hopefully Peli implemented some of my hidden feature requests he noticed a while back.
In addition to this a framework for Silverlight UI testing dropped (twice) during my last sprint and this was an interesting and valuable distraction from Pex. However, in Pex’ defense, it is very easy to rebuild anything you’ve constructed so far but my advice would be to version your custom code. I built up many stubs and factories for Pex to use when it needed to build up certain types. Most of that code I can keep since the interface changes were limited in some areas. Other areas it was not, and that code will just get dropped.
My strategy will probably revolve around the UI and service implementations and balance when they are getting close to “done-done”. Most of the Pex setup work can be done on the “not-so-done” elements and then will get fleshed out when they arrive at “mostly-done-done” stage. We have a mocking library as well which has a lot of code that will change as well, but for the most part isn’t adding much value while Pex is duplicating some of this effort. The library we are using works with Pex, so I may have the libraries join forces and/or just build my own PUTs for the “mostly-done-done”, this would be on the service implementations.
That still leaves the Silverlight unit testing work, it’s very automated as well and can using the A-A-A model for building tests like Pex suggests. Oh, and the bread crumbs I need to leave behind for the sustainment folks as well have to be straightforward otherwise I’ll be building tests that won’t be used in the future for regression. Pex helps with this, but folks will need to (want to) understand how that happens. All of this to aid in getting us closer to CI – more rapid feedback for all to see and use.
More later.
Last night I finished my first SketchFlow project last night. I was using the (free) first chapter of an upcoming book “Dynamic Prototyping with SketchFlow in Expression Blend”. This copy doesn’t look like first draft stuff, it’s stuff that you can use right now. The free chapter gets you grounded with how you can put SketchFlow to work for you.
The first thing I did was set aside what little I knew about prototyping. I’ve used many napkins to layout an app and that makes total sense. The examples do as much but have added color to their napkins (sketches). While building this first project I wanted to make things click and move, add behaviors, “oh, I can make this spin or flip!”, you get it. Resist that urge and wait to satisfy those “demons” when your layout is finished.
Taken from the “Who Should Read This Book" section
If you’re a software architect or developer that often finds yourself thrust into playing the role of a designer in your projects and day to day activities you’ll find that the techniques put forth here will enhance your ability to do better work. This book shouldn’t however be regarded as a replacement for having the capability and skill of a professional designer on your project team.
Bingo. I won’t feel too guilty about wearing a designer hat for my own projects, but my designs shouldn’t go much further than something that has a Balsamiq look (which it can do OTB), nothing polished but still conveying intent. That’s what we’re after right? Not even being a devigner (or Deselepor as they said on C9 yesterday) myself, it was hard not to stay out of the behavior folder. But I did. If you’re the hard core designer, you probably have more business in that behavior folder than I but get the layout right and flowing first. Let me rephrase that, get your sketches laid out and flowing, first. Adding navigation is a snap and once I wired the navigation for each object in the SketchFlow Map surface (the pane on the bottom with the colored shapes) it worked. After I started exercising the the flow navigation when I ran the app a few things happened: more/better ideas for the flow and layout started appearing; I dropped a shape and added two; made a few navigation connection swaps on a few shapes which made more sense after walking through the app; I came up with a better name for some shapes. Two words: rapid feedback. Two more words: love it.
I followed along in the first chapter until the author begin importing assets. Then I scanned my own sketches I had done a few nights before during a trip to the library with my kids. Within an hour I had things snapped together and the SketchFlow Navigator was moving me around the layout. The export to Word worked as advertised. I’m going to take this back to see if I can enlist some folks using Blend for the first time to help build up the application. This will mainly be an exercise to help move myself and someone else forward using this technology. I’ve already added the few initial user stories to my AgileZen backlog so I ready to go.
Lessons Learned
- Scan as grayscale if using #2 pencil and regular 8x11 paper
- Ink pens or Sharpies work better but don’t have erasers
- Can add some color for emphasis using Sharpies
- Multiple sketches on one page can be imported as Sketch01, Sketch02, …
- Multiple sketches on one page, then use Paint(.net) to crop into individual sketches
- Import cropped sketches, images, etc. into appropriately named folders with descriptive names
- Cropped sketches with real names that match SketchFlow shapes helps with Assets display later on.
- If possible use generic names for sketch components so they can be composed on multiple shapes
- Try to keep Sharpie tips off of the library table tops