• Get the Bing Maps Silverlight Control
• Get a Bing Maps API Key
• Play with the Bing Maps interactive SDK Application
• Read the Bing Maps blog
• Check out the Bing Maps forum

You can also get the source code to my presentation here:  Download the source.

Note: You will need to download the Bing Maps Silverlight control and re-reference the DLLs before the source will compile.  Also, you have to have a Bing Maps API key in order to use any of the geocoding service examples.

I also have a blog post that steps you through the sample code here.

Like always, if you have any questions feel free to ask.

Recap:

The Silverlight and WPF platforms are very similar, but they do not have binary compatibility; this means that an assembly compiled for one platform cannot execute on the other platform (Although, the story is a little different in Silverlight 4). You may want to target some or all of your application on WPF and Silverlight for a number of reasons.

Due to the fact that Silverlight and WPF are so closely related, the bulk of your application code can be shared between the two platforms. This encourages heavy use of pattern based development to isolate the logic from the presentation and maximize the separation between UI code and non-UI code.

Elements you can share:

• Presenters
• Controllers
• Models
• Services
• Unit tests
• Simple views, if the XAML used is supported by both Silverlight and WPF.

Elements that are harder to share:

• Complex views (XAML)
• Controls
• Styling
• Animation

Like always, if anyone has any questions feel free ask.

Recap:

The Silverlight and WPF platforms are very similar, but they do not have binary compatibility; this means that an assembly compiled for one platform cannot execute on the other platform (Although, the story is a little different in Silverlight 4). You may want to target some or all of your application on WPF and Silverlight for a number of reasons.

Due to the fact that Silverlight and WPF are so closely related, the bulk of your application code can be shared between the two platforms. This encourages heavy use of pattern based development to isolate the logic from the presentation and maximize the separation between UI code and non-UI code.

Elements you can share:

• Presenters
• Controllers
• Models
• Services
• Unit tests
• Simple views, if the XAML used is supported by both Silverlight and WPF.

Elements that are harder to share:

• Complex views (XAML)
• Controls
• Styling
• Animation

Like always, if anyone has any questions feel free ask.

Jeremy’s other contributions to the community include StructureMap and an obtuse fascination with separation patterns for user interfaces.

Story Teller is an alternative for Fitnesse, implemented in .NET and chases the holy grail of executable requirements. If you are interested in how to achieve the promise of shared and executable requirements, this just might be your tool.

• Story Teller
• Jeremy’s StoryTeller post on a preview release

Get the show here

Things That Went Well

• I was impressed by everyone's enthusiasm. I was a little worried that we were under-prepared going in, but the enthusiasm and depth of knowledge that the presenters shared was impressive.
• People really liked the Outside-in Testing (Jeff Olson) and TDD sessions (Robin Clowers). These had the most code shown during their presentations, which, I think, says something.
• The facilities were just about right. We were a tiny bit over capacity (technically we were under, but it didn't feel that way to me.)
• We had the right refreshments and stuff to keep people from getting hungry and distracted. At one point, someone I know asked if we had anything besides pizza, as he has dietary reasons for avoiding it. I felt bad and told him no, making a mental note that we should have some other food available next time, until I realized Anne had prepared Salad and lunch meats. Yay!

To Work on for Next Time

• We tried to cover way to much ground for one day. I think we all knew this going in, but were just in denial or something. Next time: I think we're going to cover just one topic.
• We hardly got to show any code. I had code that I wanted to show for both the refactoring and patterns talks that I didn't even get to. I got to show a tiny bit of code in the refactoring talk, but I had a whole series of small refactorings I wanted to do but didn't. I think we went over in a few of the earlier sessions, it felt right then, but then it compressed the sessions for the rest of the day. The one person that just showed code the whole time, Robin, received props for that. Next time: no slides for me.
• We asked people to bring laptops, then never worked on any code. This was mostly a side effect of the above, I think. Next time: give them the code ahead of time and use the pauses while people catch up with coding tasks to answer off-the-rails questions.
• Some people weren't into the whole "be interactive" thing. At the start of the workshop we asked everyone to shout out questions as soon as they had them, but some felt this led to derailment. Next time: I think we'll save space at the end or at pre-determined spots for questions, although I personally feel this leads to people forgetting their questions.
• We (the hosts) didn't communicate enough before the event and I think it showed. Next time: I think we need to get together on a Saturday a few weeks before the event and make sure we're all on the same page. I think this is one area where I personally did a pretty poor job, kind of assuming everyone was "directionally correct" and just kind of knew what to do. For the most part this was true, but I think this will be something we improve upon.
• Using git and markdown was great for the geekier amongst us, but proved a burden for some of the presenters and the attendees. Next time: git for us to share the code, zip files (skydrive?) for everything else and for code for the attendees to download.

In summary, I think the loudest message was: more code. I am in total agreement and I usually don't like to use any slides at all if I can help it, but somehow got the wrong headed idea that I needed to have something to look at while I did the talking, intro-part of my sessions.

I also tried rehearsing more than usual for this and it turned out to be a complete waste of time. The actual session went wayyyy slower than then I rehearsed. I must be doing it wrong. // TODO: Imagine Arun
asking questions while I am rehearsing.

It sounded like the majority of the attendees would like to come back for another session like this, more focused on one topic. The organizers are going to hold a skype retrospective sometime in the next few days and figure out what we want to do next.

I’d like to give mass props to the people that made this happen: Justin Bozonier, Robin Clowers, Bobby Johnson, Jeff Olson, Trevor Rotzien, and Anne Wax. Together we are helping ALT.NET grow from a small fringe group into something that’s doing real work and making things better than when we got here.

UPDATE: We actually held the retrospective last night. We're planning another event soon, possibly in more locations, something more focused. Keep your eyes peeled.

Download the Presentation Source.  This contains the all sample code that I discussed during the presentation.

Useful links:

• The Composite WPF and Silverlight (Prism) website is where you want to start.
• Elegant Code Cast of Prism v2 – David Starr, Scott Nichols, and myself sat down with the Patterns and Practices team to discuss Prism.
• Channel9 has some good videos available to help you understand and get started using Prism.
• WPF Recipes in C# 2008: A Problem-Solution Approach – This is not a Prism book but it is a great book for solving common problems in WPF.

You're at work and you catch yourself writing another 100 line method that you can't test and really can't even understand. You scour the internet for ideas but there are so many ideas. Some say don't test, others says don't test anything, still others say test every keystroke! You just let your head drop to your desk with a solid thud. You think to yourself, "Is this really the best I can do?" The Olympia Software Craftsmanship Workshop is one day workshop, developed with the intention of increasing the level of awareness of practices and skills that can improve our software. Any developer interested in improving and learning new skills is welcome. If you can bring a laptop, please do. We will provide the software you need. If you can't bring a laptop, don't worry, you can pair up with someone who has one. ************************************************************************* What: Olympia Software Craftsmanship Workshop Where: Olympia Center, 222 Columbia St NW, Olympia, WA 98501 When: Saturday June 6, 2009.  10 am to 4 pm How much does it cost? .00 to cover the cost of the facility and lunch. How do I sign up? Go to www.olympiasoftwarecraftsmanship.org The workshop is hosted by members of the South Sound.NET users group and Alt.Net Seattle who want to help others build better software. For more information: http://github.com/altnetseattle/olympia_software_craftsmanship_workshop/tree/master Or contact Bobby Johnson at bobby.johnson@gmail.com

Things That Went Well

• I was impressed by everyone's enthusiasm. I was a little worried that we were under-prepared going in, but the enthusiasm and depth of knowledge that the presenters shared was impressive.
• People really liked the Outside-in Testing (Jeff Olson) and TDD sessions (Robin Clowers). These had the most code shown during their presentations, which, I think, says something.
• The facilities were just about right. We were a tiny bit over capacity (technically we were under, but it didn't feel that way to me.)
• We had the right refreshments and stuff to keep people from getting hungry and distracted. At one point, someone I know asked if we had anything besides pizza, as he has dietary reasons for avoiding it. I felt bad and told him no, making a mental note that we should have some other food available next time, until I realized Anne had prepared Salad and lunch meats. Yay!

To Work on for Next Time

• We tried to cover way to much ground for one day. I think we all knew this going in, but were just in denial or something. Next time: I think we're going to cover just one topic.
• We hardly got to show any code. I had code that I wanted to show for both the refactoring and patterns talks that I didn't even get to. I got to show a tiny bit of code in the refactoring talk, but I had a whole series of small refactorings I wanted to do but didn't. I think we went over in a few of the earlier sessions, it felt right then, but then it compressed the sessions for the rest of the day. The one person that just showed code the whole time, Robin, received props for that. Next time: no slides for me.
• We asked people to bring laptops, then never worked on any code. This was mostly a side effect of the above, I think. Next time: give them the code ahead of time and use the pauses while people catch up with coding tasks to answer off-the-rails questions.
• Some people weren't into the whole "be interactive" thing. At the start of the workshop we asked everyone to shout out questions as soon as they had them, but some felt this led to derailment. Next time: I think we'll save space at the end or at pre-determined spots for questions, although I personally feel this leads to people forgetting their questions.
• We (the hosts) didn't communicate enough before the event and I think it showed. Next time: I think we need to get together on a Saturday a few weeks before the event and make sure we're all on the same page. I think this is one area where I personally did a pretty poor job, kind of assuming everyone was "directionally correct" and just kind of knew what to do. For the most part this was true, but I think this will be something we improve upon.
• Using git and markdown was great for the geekier amongst us, but proved a burden for some of the presenters and the attendees. Next time: git for us to share the code, zip files (skydrive?) for everything else and for code for the attendees to download.

In summary, I think the loudest message was: more code. I am in total agreement and I usually don't like to use any slides at all if I can help it, but somehow got the wrong headed idea that I needed to have something to look at while I did the talking, intro-part of my sessions.

I also tried rehearsing more than usual for this and it turned out to be a complete waste of time. The actual session went wayyyy slower than then I rehearsed. I must be doing it wrong. // TODO: Imagine Arun
asking questions while I am rehearsing.

It sounded like the majority of the attendees would like to come back for another session like this, more focused on one topic. The organizers are going to hold a skype retrospective sometime in the next few days and figure out what we want to do next.

I’d like to give mass props to the people that made this happen: Justin Bozonier, Robin Clowers, Bobby Johnson, Jeff Olson, Trevor Rotzien, and Anne Wax. Together we are helping ALT.NET grow from a small fringe group into something that’s doing real work and making things better than when we got here.

UPDATE: We actually held the retrospective last night. We're planning another event soon, possibly in more locations, something more focused. Keep your eyes peeled.