The Sherpa Project

CodeMash has started! To see what’s going on, check out technorati and flickr.
I just attended the keynote session by Neal Ford. I have to say that it was one of the best keynotes that I’ve seen in a long time. The session was “Domain Specific Languages and Their Role in the Evolution of the Programming Paradigm.”

I’ve heard that the slides will all be posted. I’ll update this post with a link to the deck when it is published.

Why is it that a general best-practice is to have strong passwords when most applications don't support them? I tend to use (very) strong passwords, but it seems like I'm discouraged more often than I can utilize them.

Is it really too much to ask?

James Shore has written a very straight-forward introduction to dependency injection. I agree with James, the concept is simple, powerful, and usually appears to be complicated because of the way it is explained. You can find the article here.

About a week ago I purchased the Getting Real book from 37signals. I’ve been eagerly waiting for this book to come out for a while now and I can say that it was well worth the wait. The book (available only as a pdf) is entertaining and very thought provoking. I can say that I agree with almost every one of the statements and sections in the book.

The biggest value for me in the reading of the book was the ability to be exposed to ideas for design as well as development. My primary activities mostly center around development on a day-to-day basis, but the insight into the design ideas in the book were a big eye-opener for me. I’ve preached most of the development-centric practices that are outlined in the book and it was nice to view the logic behind each of the sections in the book. The book also contains many good quotes that are provided from a diverse set of individuals.
I would recommend this book to anyone and promise that it will be well worth your $19.

I’ve been playing more and more with Ruby On Rails lately and it has been a very mind-opening experience with regards to many of my ideas around application architecture. There are many wonderful things about Rails, but the idea (and implemenations) of “convention over configuration” is demonstrated beautifully within Rails.

My development experience has been primarily centered around .Net since the early betas of .Net 1.0. I’ve completed dozens of production systems with .Net and there are many ideas and thought processes that repeat themselves over and over throughout each project. In some of my earlier projects, I played with the idea of convention and decided that there was too much “magic” in many of the convention-based implementations that I participated in. After a few different attempts, I finally gave up on convention and fell back to the typical .Net configuration as the norm for my projects.

I have to say that Ruby On Rails has completely changed my views on the power of convention. From my (limited) experience with Rails, I would have to say that the conventions that are built into Rails provide provide a ton of acceleration in producing working web applications. I love the idea that almost everything is based on convention.

The way Rails encourages convention provides for rapid development, prototyping, and results in cheaper applications. Convention is encouraged throughout Rails by assuming that you are following convention (plural table names, primary keys named id, urls indicating actions, etc.) while still allowing the flexibility to deviate from the conventions when necessary.

I’m still not sure that one-off conventions are extremely valuable in .Net because they would not be standard conventions and would likely widely differ between projects and across companies. I think that the potential is there, but some type of framework would need to be established to (at least partially) encourge common conventions across projects. As an idea, convention is a very powerful concept, especially when it’s built into a framework (or an acceleration platform). I’m hoping that something is on the horizon that will provide this concept to .Net and that it gains traction soon. I would love to be able to write .Net applications at the speed that I can implement Rails applications.

I was working with Drew today and preparing for our .Net Users Group presentation on leveraging open source development tools with .Net. For this presentation, we have consistently met at Panera because of the free wifi access. When we arrived this evening we were unable to connect to the wifi. At first, this seemed like a pretty big problem, but it ended up being a perfect scenario for how mock objects can provide a significant advantage..

My pieces of the presentations are centered around NUnit and NMock. In the example code that we put together for the presentation, the data layer is comprised of an external (XMethods) web service. Without wifi, we were obviously unable to connect to the web service. The wonderful part about all of this was … it didn’t matter.

Since the tests in the business layer utilized the functionality of NMock, the tests all ran as expected. The only exception to this was the suite of integration tests, which confirmed that the service wasn’t available and that the integration tests were doing their job correctly.

So, even without the core service that we needed to talk to, Drew was able to setup NAnt scripts and get Cruise working with full unit test integration. We would have been able to do a portion of this work anyway, but we wouldn’t have been able to do any refactoring of the tests or code modifications with full confidence that the code was still functioning as we expected (the test would have all failed instead of passing).

There are a variety of scenarios where mock objects can be a wonderful addition to your toolset and development process. This scenario was a prime example. We didn’t control the internet connection at Panera, but it wasn’t able to stop us from moving forward and preparing the presentation or performing the integration of the code and various toolsets.

A couple of other places where mocks (implemented correctly) can save the day include:

• When your unit tests take a long time to run (the faster the feedback the better)
• When systems are out of your control (that big mainframe app that goes down all the time)
• When systems are not always available (when that big mainframe has to be rebooted every night and takes a couple of hours to get back up successfully)
• When systems return dynamic results (such as stock prices, current temperature, the current election results, etc.)
• When a system doesn’t exist yet (parallel development, etc.)

If you are interested in learning more about how to implement mock objects in .Net, take a look at this MSDN article. The article provides all you need to know to get started with NMock up and running.

The MSDN Software Factories page is up and running (and worth keeping an eye on).

The Software Factories web site defines a software factory as: A Software Factory is a software product line that configures extensible development tools like Visual Studio Team System with packaged content like DSLs, patterns, frameworks and guidance, based on recipes for building specific kinds of applications.

I’ve had the opportunity to participate in the creation of this type of system for an order management product (a couple of years ago) and to say the least, it was a very interesting experiment. As a result of the creation of the system, the business was able to realize substantial value when new customers were enlisted for the product suite. The software factory approach worked very well because the company was an application service provider based around B2B procurement solutions. Although this is a big space, the majority of companies are using similar workflows and have (roughly) similar objectives and pain points in their current solutions. We were able to take the time to implement an end-to-end solution (previously done in a one-off manner) from approximately 6-7 months to 2-3 months (for full life cycle). The development time was drastically reduced.

We were able to automate the majority of the construction of an implmentation for a new customer and get them up-an-running very quickly. The presentation, business logic, and workflow layers each were split into their own domain-specific languages and the data layer could be reused across all of the customer implementations. The data layer was able to stay common because we mapped all of the customer-specific document formats (think edi, flat-files, etc.) to an internal standard. The presentation, business, and workflow layers were usually able to be at least partially generated and then hand-modified for customization. All of our domain-specific languages were written in xml (similar to NAnt) and although we didn’t have any graphical tools, we were able to use XSD and XML Spy to provide autocomplete functionality and syntax highlighting.

Overall, I really liked the software factory approach. It was a good fit in this case because of the repetitive work that was done by the ASP to implement solutions for their customers. It’s nice to see some movement in this space, and I think we’ll likely see a lot more moving forward.