With the original 0.86 beta 1 release, there was a small problem with folks who only had VS 2008 installed because there was a dependency on a registry key that was installed with the .Net 2.0 SDK (or VS 2005).
I have to say that over the past 2.5 years, I have been very pleased with NAnt. It is a great open-source build tool, and it integrates with every other command-line tool I could want. I normally <exec/> out to msbuild.exe for the compile. I have a NAnt build template available in my public source code repository here.
It is very important to keep the VS2005 solution the main solution and the solution used in the continuous build because VS2008 supports everything there, but if you add a project using VS2008, VS2005 might not recognize some things. An example of this is with the path to the Microsoft.CSharp.targets file.
If you create a new project using VS2008, you’ll see the following in the newly created project:
Note the $(MSBuildToolsPath) property. This was added in .Net 3.5, and Visual Studio 2005 and MSBuild for .Net 2.0 doesn’t understand this property. Changing the project file to the following makes both versions of Visual Studio happy. (change it to $(MSBuildBinPath)
I’ll be attending the AltNetConf. Convenient for me that it’s in Austin, TX. It’s an open space conference, and I consider it the founding conference of a conversation that is “Alt.Net”. I’ll be proposing the topic: What are the Alt.Net principles?.
The definition of Alt.Net isn’t defined yet. It’s not even at a point where I can explain what it is and actually have other agree with me.
Since I know the guy who originally coined the term, I have some insight into what David meant, but I’m going to propose some principles that, together, should be the definition of Alt.Net.
First, Alt.Net inherits Agile, and IS Agile. Therefore:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Excellence and quality In a world of wizard-generated, disposable software (disposed 2 years later by necessity, not choice), Alt.Net focuses us on excellence in the software we create. While the world may pay for and accept software that lives for 2 years before becoming utterly unmaintainable, we don’t accept shoddy work. We know that we can deliver high quality software faster than others can deliver low quality software, so we accept no less than the highest in quality. We strive for excellence through solid engineering practices and a high level of software education. Coincidentally, Extreme Programming helps in this area, but Alt.Net does not specifically _mean_ XP.
Alternative Vendors A common theme in many .Net shops is they are “Microsoft” shops. In other words, if it doesn’t come from Microsoft, they won’t use it. This makes no sense. Microsoft is not a large enough company to be the vendor to the whole world. .Net is a great platform, and we as a community have chosen the platform and choose to participate in this segment of the industry. We strongly believe that 3rd party vendors complement the .Net platform in a way that can contribute to excellent working software. In fact, some 3rd party offerings are superior to Microsoft’s offering. For instance, in a strive for excellence in an e-commerce website, a team may choose a mature O/R Mapper like NHibernate to accelerate team speed and produce a flexible data layer; however, Alt.Net does not _mean_ ORM. Open source software is a source of excellent 3rd party alternatives built on the .Net platform, and it should be used over Microsoft alternatives when they contribute to excellence; however, Alt.Net does not _mean_ open source.
Joy in our work We know that we will produce better software if a team is motivated and morale is high; therefore, we use libraries, tools, and practices that add joy to the working environment. We abandon or correct libraries, tools, and practices that make it a drag to work on the software. For instance, many find that Visual Studio is a bit slow to work with and that adding Resharper to the IDE adds a high level of joy while working with .Net code; however, Alt.Net does not _mean_ Resharper.
Knowledge We know that we will never know everything there is to know. We strive for a greater understanding of software through studying successes and failures of the past as well as the present. We educate ourselves through many sources in order to bring the most value to our clients. We keep up with other platforms, such as Java and Ruby, so that we can apply their good ideas to .Net development and increase the quality of our .Net software. The technology is always changing, but the knowledge accumulates. We know that the knowledge applies no matter how the technology changes. With knowledge comes humility because without humility, knowledge would pass us by.
The above are principles, so they are intentionally abstract. Below, I’ll list some items that are concrete. These items apply the principles but are more directly applicable:
Read more than just MSDN magazine and MS Press. Authors like Feathers, Fowler, Martin, Evans, etc have a lot to give (Knowledge)
Use Resharper. It makes working with Visual Studio a (Joy). But if another vendor comes along that does even better than JetBrains, consider switching
Use NUnit over MSTest, Subversion over TFS SCC, Infragistics/Telerik over in-the-box controls, RedGate over in-the-box SQL tools. Each of these is a better alternative to that which Microsoft provides (Alternative Vendors). Use NHibernate over hand-rolled stored procedures and especially over DataAdapter/DataSet, but if EntityFramework proves to actually be superior to NHibernate in a meaningful way, consider using it.
Use a responsible application architecture. Don’t put everything in Page_Load like you see demonstrated at MSDN Events. Use knowledge to create an application that can stand the test of time and not be rewritten every 2 years. Deliver (high quality and excellence).
Automate every repetitive task; builds, tests, deployments, etc – excellence and joy
The concrete examples could go on and on, and I hope AltNetConf produces a long list. I’ll be interested in having my proposed principles accepted by the community there or revised into something better. Either way, I’d like to get to a point where there is an accepted definition of Alt.Net.
What makes a good general-purpose development platform?
Easy to install
Easy to configure
Integrates well with simple tools
Easily extended to make simple tools
Easy to debug
Easy to create test automation
All configuration stores easily in source control
Others I’m forgetting
I’ve heard many times that Sharepoint can be used as a development platform. Technically, that statement is correct, but there is so much friction involved with it, many get frustrated in the process. Consider the dependencies:
Must run on a server OS, Not XP/Vista, Full Stop
After that one, I don’t see a need to go on. In a team environment, every developer needs to have a dedicated development environment. What does that mean? Everything necessary to build and run the system fits on the developer workstation. Why not run a server OS on the developer workstation? Perhaps. I’ve done it before, but there is other friction associated with that. Why not use a server OS VM to run Sharepoint on the box? Perhaps, but again, more friction.
A development environment should be a pleasure to work with, and that require minimizing friction. The harder it is to make a batch file that completely builds, tests, and deploys the system, the harder it is to develop for that platform.
My purpose for this post isn’t to say that “Sharepoint sucks”, notice the worst I say is that it’s not a good development platform. For content-management and list-based stores, it’s great, but as a development platform, there is plenty to be desired.
In the comments below, astute reader clarify that Sharepoint excels as a content management system but not as a general development platform. I would yield that point. In fact it makes more sense to me for Microsoft to market the product for that niche and have users singing its praises than for Microsoft to present it as a higher level ASP.Net platform and have users (see comments below) lamenting the pain involved.
There it is. A pile of ripped up note cards denoting all the engineering tasks completed by my pair. This was an unusual day because it started at 7:30am with some white board modeling and brain-crunching a very, very tough problem. We wrote out some tasks to get us started, and we played the TDD game. It was such a tough problem that neither my pair partner nor I could imagine the complete solution, but we could imagine a few things that would be included. We wrote down the items to do on note cards and ordered them. The navigator manned the note card deck. In the course of completing some of the engineering tasks (all part of the same story), we uncovered new tasks that needed to be done. We wrote those down and added them to the bottom of the pile. We also ran into a brick wall and had to stop to do another task before we could continue. We wrote that down and added it to the TOP of the stack. We used these note cards as a true STACK. FILO. It helped us stay on track. We finally got through the stack, and when we did, the story was implemented. We didn't have the complete plan at the beginning, but we adapted and changed the plan along the way.
This pile of ripped up note cards is all that's left of that nasty story. It did take us all day, though, and at 6PM, we both were wiped out! It was the last day of the iteration, and we had committed to the story. We ate a quick lunch at our desks and worked straight through. It was great that we were able to meet our iteration through micro-adaptive planning.
I hope I don't have to do that again for a long time because that was the most difficult pair-programming I have ever done. We were talking through the problems _all day_. My brain was hurting on the way home.
My pair partner commented that it would have taken him 3 days if he had had to work through this nasty story by himself. Pairing on the entire solution cut the delivery by 2/3.
I'm going to present you with a very exciting new feature of StructureMap that is available in the 2.0 release. You can download StructureMap from SourceForge.
There are plenty of articles about StructureMap's service location capabilities, and the documentation is quite good, but I'll throw out the bread-and-butter usage scenario for service location. Here is is.
I have an ICustomerRepository, and an "impl" class that implements the interface, CustomerRepository. As the names suggest, this interface will return an array of Customer(s) given a whole or partial phone number. Here is the full code.
Now that you get the gist of it, I'm going to use StructureMap to enable the Model-View-Presenter pattern in a cleaner way with ASP.NET UserControls. First consider the following usage:
I have a page that has a complicated piece which has been delegated to a usercontrol-presenter pair. The page, of course, will embed this usercontrol in the appropriate place. Immediately you can spot the problem: The "Foo" view is responsible for creating the "Widget" view. Then the Widget view creates its presenter and uses it. This is too much responsibility for both views.
Now consider an alternative:
Now notice that the FooPresenter is responsible for creating and using WidgetPresenter. WidgetPresenter, in return, uses StructureMap to service-locate its view, which implements IWidgetView. Because Widget.ascx.cs implements IWidgetView, this wiring works easily. The StructureMap change that made this possible is the following usage of the configuration. Here is the code:
Now that we can service-locate asp.net usercontrols, we can inject them as well. The next step is having the WidgetPresenter receive IWidgetView in the constructor. StructureMap will chain-create the usercontrol in order to create WidgetPresenter. Now, our presenter is in control, and the views can concentrate on presenting information to the user and not worry about control flow.
I am a big fan of shortcut keys. I find that if I can keep my hands on the
keyboard and not reach for the mouse, my productivity stays high.
want to say thanks to Steve Donie
for this change in my mindset. Steve has a key for everything, and if there
is not a key for it, he has a batch script with a shortcut key mapped. Below,
I'll illustrate some shortcut keys I love. Note, I use many, many shortcut
keys that hook into Resharper,
but these shortcut keys work in Visual Studio 2005.
ctrl+enter: Insert a line above the current line and jump to the
ctrl+shift+enter: Add a line below the current line and jump to
the new line
I find it very frustrating that there is no obvious way to have the .resx
generator mark members as public instead of internal. In my team's solution, we
have a need for these to be public. Here's how I solved it:
Add a nant target that can do a
find/replace in a file (I don't know of a shell command that will do that)
There's a lot of talk about IE7 vs. FF2. It's all pretty boring for me.
Browsers are boring. They are glorified terminals. Dave Thomas (of Pragmatic
Programmers fame) puts it in an interesting way: (paraphrasing) -We have the same
client-server terminal we had years ago, but now the terminal can show porn.-
That drew quite a few laughs at the NoFluffJustStuff conference in Austin this
In short, displaying web pages isn't all
that exciting. What all the browsers have turned to for added value is
add-ins. Add-ins for ad-blocking, popup blocking, anti-phishing, etc. While
some browsers develop all add-ins in-house, I believe the main factor behind
Firefox's success is the large number of add-ins available for free that have
been contributed by the developer community. The other browsers don't have
this. If it weren't for all the FF add-ins, FF wouldn't have much of a leg to
Back to my main reason for this post: I
have installed Firefox 2, and I love the spell checking. Anywhere I write text
in a web-page, I get in-line spell checking. Write emails with Gmail, Forum
posts, anything – instant spell-checking. Brilliant!
These first two guidelines are very important. The first drives efficiency, and the second drives effectiveness. Even doing these first two well can leave a team spinning its wheels, however. If parts 1 and 2 are fully implemented, we are now certain that the team is focusing on the small portion of work that delivers great value. We are also sure that the team's time isn't being wasted with nonessential or repetitive tasks. What's next?
Part 3: Use Powerful Tools
A skilled craftsman needs good tools. First, the craftsman needs the correct tools. Second, the craftsman needs those tools to be powerful. A craftsman plowing along with inadequate tools is exerting more effort than necessary. Why use a hammer and nail when a nail-gun is available? Why use a screwdriver and wood screws instead of a power drill?
This is the most obvious, but sometimes neglected, tool for a software developer. Does it make sense to have a highly-paid professional on staff using a mediocre workstation? The programmer will spend time waiting on a machine. The answer, of course, is no. The newest member of my team came on board with a 3.4Ghz Pentium D (dual core) workstation. 1Ghz FSB, 10,000 RPM SATA drive, 2GB RAM. He had never seen Visual Studio 2005 install in 10 minutes. Compared to what I'm paying him, his workstation cost pennies. He spends less time waiting on compiles. The local build runs very fast as well. In my mind, it is well worth the cost.
IDE & related tools
Many programmers with whom I talk use Visual Studio. Just Visual Studio. Some haven't been exposed to other tools for software development. First and foremost, Visual Studio is a pretty good solution/project linking and compiling package. It's pretty poor at helping the coding process, though. There are a few neat extras you can unlock through SHIFT+ALT+F10 in 2005, but they are sparse. Install Resharper into the IDE, and it comes alive. It does use more RAM, but RAM is cheap, and the boost it provides is more than worth it. Without Resharper, Visual Studio is just a glorified text editor that compiles. With Resharper, you know about compile errors on the fly, and unused code is grayed out, so you know it's safe for deletion.
It's one thing to give an individual programmer the best tools money can buy. It's another to focus on the team tools. There are some tools that all members of the team depend on. Besides the network connection and the printer, I'm talking about a revision control system and a build server. It's important to have a quality revision control system. The team needs to be able to rely on the branching and merging capabilities as well as the commit transactions. My team uses Subversion. It has proven itself time and time again.
The build server is another shared asset. It must be fast as well since every member of the team will have to wait on it at some point. The build server can either have the build script run on it manually, or a CI server can run the build when new code is checked in. Either way, the build needs to run fast, be configurable, and be reliable. My team uses CruiseControl.Net with NAnt and MSBuild.
Other general, programming and debugging tools
There are many tools that help with a single part of development. The IDE is the tool that stays open all day long, but other tools are just as critical for specialized tasks. There is no way I can list them all, but I'll give a run-down of the tools I use:
Resharper – productivity add-in for Visual Studio (refactoring, code generation, etc).
Visual XPath – quickly create the correct xpath to get a node from an xml doc.
Regulator – Hash out regular expressions quickly with this tool by Roy Osherove.
The list is never ending
Always be on the lookout for tools that will save time or speed you up. Tools are always improving. It's important to talk with other professionals from different companies to see what tools are helping them. Chances are that those tools can help you as well.