The Code Bucket

Speaking at Iowa Code Camp Tomorrow

Lee Brandt — Sat, 07 Nov 2009 00:37:44 GMT

OK, I’ve been remiss in my duties as a blogger I know. Can you forgive me? Both of you? C’mon! It was only a couple of weeks. I promise to be more diligent in my posts in the future. So… we cool? Ok.

I am really posting to let you both know that I will be speaking at Iowa Code Camp tomorrow. I have two talks. One on BDD, of course, and one on The Opinionated Web Solution. This is a new talk that is about arranging web projects in a solutions.

If you happen to be in the Des Moines area, drop by.

~Lee

More To Come…

Lee Brandt — Sun, 11 Oct 2009 23:44:27 GMT

I’ve been a little scarce lately as I prepare for HDC (I’m doing a lightening round), finishing up a project for a client (rollout in a week), and help out some with Sharepoint Saturday, Kansas City (December 12th).

Be sure that I will continue my series on building a dev shop and things should get more back to normal after next weekend.

Stay tuned…

The Backyard Mechanic

Lee Brandt — Sat, 26 Sep 2009 15:58:27 GMT

Recently, I read some posts about Duct Tape programming from Joel Spolsky, Michael C. Neel, Jak Charlton, “Uncle” Bob Martin and Jeffrey Palermo. I have followed these posts closely. While the intent is good, I think the delivery suffers.

The whole thing started with Spolsky (as it often does) creating a post that (I think) was meant to say, “Hey stop pontificating on sweet new techniques and start shipping software!” Excellent point. Do that. Don’t worry anymore what other developers might think about the code you’ve written, or you developer “Image” and start delivering business value. Spolsky’s Duct Tape Programmer uses Duct Tape and WD-40 to get the job done, and it reminded me of another archetype I’d been exposed to earlier in my life.

The Backyard Mechanic

The Backyard Mechanic, if you’re not familiar with the term, is a term used to describe those guys who have been around cars all their lives. They rebuilt their first Chevy short-block 350 at age ten, and have always smelled like axle grease. I like these guys. With the exception of the rebuild, I am one of these guys (it was my Dad’s Ford 302 and I was 13). If I am ever broke down on the side of the 395 between Barstow and Tahoe, I want this guy riding shotgun. He will get me to the next town. He will make sure I get there. But I would NEVER pay these guys to work on my car, not even myself. Why? Because the “Git-R-Done” tips and tricks they use are simply patches. They know how to compress a brake caliper with a crowbar and a piece of wood, but a brake tool work much better and won’t run the risk of breaking (no pun intended) your knuckles if your hand slips. If I am overheating because of a leak in a radiator hose, I can put duct tape on the hose and piss in the radiator to get me to the next town. But I certainly don’t want to run my car on piss & Duct Tape on a daily basis. I guess my point is, when people PAY you for a job, they expect quality. They also expect you to get their car fixed as soon as possible, and I guess that’s Spolsky’s point.

Ship The F___ing Thing!

In Jak Charlton’s post, he talks about the alignment of business and IT and, to me, that is a more important point. In the “Project Triangle”, (Time, Quality and Functionality) you can only focus on two sides at once. The point is, it is not up to IT to make those decisions; it is up to the business. Developers need to align their development goals with the business goals of their customer. It sounds obvious, but it doesn’t seem to happen as often as it should. If the business decides to focus on functionality and time, the programmers should focus on functionality and time as well. But the business should be making an informed decision when they decide to let quality slip. They should know what it means to let quality slip and THEY SHOULD DECIDE that quality is less important than functionality and schedule. They should be made aware that the second version of this product might require a complete rewrite (let’s hope not), but they should be aware of that and walk into that decision informed and with their eyes wide open.

Quality Saves Time (And Not Just In The Long Run)

This doesn’t mean scrap the idea of quality programming all together. What it means is that, given the choice between time, functionality and quality, time and functionality win and we understand quality may suffer. From what I’ve seen, quality software actually saves developers time. Now, writing fifteen layers of abstraction and creating a new development framework for your project does not constitute quality. That’s architectural masturbation. Following the SOLID OO programming principles at the very least can certainly save you time, and not just in the long run. The fact that quality code is easier to change and enhance, means that as you build feature 2, 3 and 4, it will be easier and easier to do without having to re-factor chunks of existing code to do it. Techniques like Test-Driven or Behavior-Driven Development were developed out of a need to deliver software quickly without letting sacrificing quality. When done correctly, not only does TDD speed things up, it gives you a low-level regression suite that helps you ensure you didn’t break anything WITHOUT having to go manually test everything again (a MAJOR time expenditure). ORMs save a tremendous amount of SQL writing, not because it’s hard to do, but because it’s time consuming, and if you’re looking to ship fast without sacrificing quality, a battle-tested ORM (like NHibernate or SubSonic) can be a great fit. Finally, quality saves time just be cutting re-work. Doing it right the first time, means you shouldn’t have to go back and redo it a second time, which should save you time as well. All this is real time savings in the first version, not some hopeful future-vision of time savings down the road.

Quality Is A Requirement

Ultimately, quality should be a customer requirement. I don’t mean as in it’s required, I mean as in the customer should specify the expectation of quality. When gathering requirements, it might not be a bad idea to ask, “..and how high should the quality be?”

It sounds like a dumb question, and it will need some qualifying when you ask it, but it can help. Telling the customer about the project triangle, if they don’t know about it, and explaining how each side influences the outcome of the project can be invaluable. The way I tend to breach the subject is, “If I am building software for an EKG machine, I probably need to ENSURE the highest quality, even if it takes a while, but when building a corporate website, if the outgoing email from the contact us form says ‘Thanks for your fedback’, no one is going to die.”

If you don’t make the customer specify which side of the triangle is the least important to them and help them understand what letting each one slip means, you’re telling them you’re going to deliver 100% on all three sides, and your project is doomed. For the most part, businesses understand what letting the timeline or the functionality slip means, but as developers we need to make them understand what letting quality slip means to them. Otherwise, they will not understand why it takes you twice as long to make changes to the codebase after version one, if you don’t.

Finally

I guess my biggest point is don’t start by sacrificing quality. Duct Tape and WD-40 are awesome tools and every developer (and mechanic) should keep some in his toolbox. But that shouldn’t be the first tool you grab. When time and functionality are the most important things, I would start by looking to tried-and-tested tools (like an ORM or a scaffolding framework) to help get thing delivered quickly without sacrificing quality. Then once you have exhausted all of those avenues, reach for the Duct Tape to limp the thing home (until you can fix it properly).

That’s all of my rant for now. It is my opinion, I am entitled to it, and dog-gone-it people like me.

Let’s Build A Dev Shop (Part 5 In An Ngoing Saga)

Lee Brandt — Tue, 15 Sep 2009 03:00:58 GMT

Well, here we are again. Last time, we talked about project structure and came up with the one we’ll use for this series. Next we’ll talk tools. We’ll talk tools like Tim Taylor talks tools: with lots of grunts for my favorites and only a little explanation about what the tools do.) This is mostly because there is LOTS of material on the interwebs about all of these tools. I tend to favor the tools that are the most widely used for two main reasons: they have been battle tested by the largest crowd and two, they usually have the largest volume of content written about how to use them; some more useful than others. Having said that, let me also say that my choice of a specific tool doesn’t mean that the others in that space don’t have value. Most of the tools I will mention are all well respected by the well respected and each has its own strengths and weaknesses. If you are in charge of picking a developer stack, do your homework, but you could start with the stack I use and change fairly easily, if the particular tool doesn’t fit your needs. I will also easily swap one tool for another, if it will make the development process easier. ALT.NET… respect.

Getting on with it, there are several practices that I engage in on almost ALL projects that have tools that make them easier to do. The most important thing about a tool is that it should stay out of your way. Once you’ve set the tool in your stack it should grease the wheels of development. If it doesn’t, it’s either not the right tool, or you’re not using it correctly.

ORM or OR/M or O/RM (not sure where the slash goes)

An object-relational mapper is a tool that allow you to map your object model to your relational database (thanks again, Captain Obvious). Basically you tell your ORM that your Person object is stored in your People table and that it’s FirstName property maps to the FirstName field in that table and so on. Linq To SQL is an ORM. There are tons of them out there now. From free stuff (Subsonic, NHibernate and Castle ActiveRecord) to paid ones (LLBLGenPro and Telerik OpenAccess ORM come to mind). One of the things that will help in a transition to an ORM is adopting the idea that the relational database is merely a way to persist your object data. I have used only two and a half in the past: Nhibernate, netTiers and SubSonic. I say two and a half because I have not used SubSonic extensively or on a production project.. yet. It looks very promising. I choose NHibernate because of its many ways to map objects and it’s humongous user base. If I am hiring developers I can actually ask for NHibernate experience and probably see some.

IoC Container

IoC is inversion on control (so the C doesn’t stand for container and make for doubled-up words like GCO Carpet Outlet – Georgia Carpet Outlet Carpet Outlet). An IoC container helps to inject dependencies and works a bit like a factory method on steroids. If I have a dependency on a type, I can inject that dependency by inverting the control over that dependency to someone outside myself. If that made no sense, that’s ok, here’s how it works.

I need a laptop to make my presentation at the conference, but instead of lugging around my laptop (cause she’s a big girl), I can ask the conference to provide me with that laptop and bring only my presentation on a thumb drive. I am inverting the control of that dependency to the conference coordinators, and telling them it must have PowerPoint and Visual Studio 2008 on it. I “depend” on that contract. When I get there, I just ask for my lappy and plug my thumb drive in and away I go. This loosens the coupling to my machine. I don’t HAVE to have MY MACHNE to do the presentation. When I need a laptop for a talk, I just find one with PowerPoint and VS2008 and I get that dependency handed (injected) to me.

There are many free IoC Containers out there as well (StructureMap, NInject, Unity and Castle Windsor just to name a few). I chose StructureMap because of the large number of resources I found when doing research on Inversion of Control and Dependency Injection. (Also, Jeremy Miller is from Missouri, even if he lives in Texas now). I also feel very comfortable with the way you register you dependencies in StructureMap, although that could just be because that’s the tool I used to learn about Dependency Injection with.

BDD and the Infinite Melancholy

When driving a project, I try to drive it from the requirements (again, shaddap Captain Obvious). What I mean is, I try to codify those requirements so that they are executable. This makes them verifiable at every step of the project. Instead of “winging it” and hoping the change I just made doesn’t break something I developed yesterday or last week, I write the “specifications” in executable format, so I can use that as my checklist of what the system can do. I can also all the specs at any time to make sure everything still works as required by the customer.

For BDD, I choose Machine.Specification or MSpec. The syntax is very strange for C# developers at first, but I find the English-y way the code reads to be very compelling, and the report that it generates is a top-notch artifact to pass on to stakeholders. There are also other BDD frameworks out there (NBehave, NSpecify and you can even use RSpec (Ruby) to spec out your .Net code if you are so inclined.) Also, there are a few extensions to traditional unit-testing frameworks out there that allow you to work in a Behavio(u)r-Driven way (SpecUnit.NET, DevelopWithPassion.BDD and recently Gary Shutler has done a series on building your own BDD framework.)

Mock Me? Mock YOU, PAL!

If you’re going to do TDD/BDD, you’re going to need to mock. It’s that simple. If I tried to drive my design with BDD without using mocking or IoC, I would stab myself in the neck with a spork. Mocking is simply a technique of using “fakes” or “stand-ins” to isolate sections of your application in order to drive out their design. Remember, using BDD requires writing your spec first, THEN writing code to make it complete. By that very definition, you’ll be dependent on code that you haven’t developed yet and that you’re NOT going to develop yet. Mocking is the only way to get this done.

Again, there are free mocking solutions out there (Moq, NMock and RhinoMocks) and paid solutions (TypeMock). I’ve never used TypeMock, but I have heard that it can mock just about anything and if you’re trying to do TDD in SharePoint (I’ve heard) it’s the only way. I choose RhinoMocks, again because of the active user base and Oren Eini’s inability to stop coding/blogging/teaching for one second.

Architectural Pattern (MVSomething)

I started using a model-view-presenter pattern a couple of years ago, after I read an article from Jean-Paul Boodhoo in the MSDN Magazine in August of 2006 and a blog post from David Hayden about the Unity IoC container where he used Unity to wire together his Views and their presenters. It was an easy transition for me, because it felt a lot like web forms. At the time, ASP.NET MVC was in early preview releases and we had a significant investment in Telerik controls which (at the time) relied on ViewState to do some of their magic, and ASP.NET MVC doesn’t have ViewState available. I used MVP happily on several projects and still use it when a project requires ViewState or must be written in earlier version of ASP.NET.

ASP.NET MVC is the new kid on the block, but is making a huge impression. On me, as well. I have just begun to really dig into ASP.NET MVC, but the Sharp Architecture project can give some good guidance on how to set up, arrange and even test an MVC app. This is ultimately the one I have chosen for the project in this series, because it is very powerful and something I really want to get more familiar with.

Them Model-View-ViewModel pattern is the newest kid on the block and permeates the WPF stack (WPF Windows and Silverlight Apps). It is especially effective where two-way binding for your View to your View-Model is possible.

Quite a lot has already been written about all of these patterns, and rather than rehash them, I will just give links in the references area.

A-budee—A-budee—A-That’s all folks

I knew this was going to be a long post. We covered a lot of topics very lightly, but I felt it was important to give a short background on why and what we’ll use in this exemplary series. I’ll leave it at this for now, with some links below for more exploration. Then, next time, we’ll actually create the base project and set up it’s continuous build on our TeamCity CI Server!

Link-age

MVP – MVC – MVVM

http://msdn.microsoft.com/en-us/magazine/cc188690.aspx

http://davidhayden.com/blog/dave/archive/2008/02/19/ASPNETModelViewPresenterUnityIoCMicrosoftPatternsPractices.aspx

http://weblogs.asp.net/scottgu/archive/tags/MVC/default.aspx

http://haacked.com/Tags/aspnetmvc/default.aspx

http://code.google.com/p/sharp-architecture/

Mocking

http://martinfowler.com/articles/mocksArentStubs.html

http://weblogs.asp.net/rosherove/archive/2007/04/26/choosing-a-mock-object-framework.aspx

http://ayende.com/projects/rhino-mocks.aspx

http://devlicio.us/blogs/tim_barcz/archive/2009/03/19/choosing-a-mocking-framework.aspx

BDD

http://code.google.com/p/nbehave/

http://nspecify.sourceforge.net/

http://github.com/machine/machine.specifications

http://blog.robustsoftware.co.uk/search/label/BDD%20from%20scratch

http://www.lostechies.com/blogs/derickbailey/archive/tags/Behavior+Driven+Development/default.aspx

http://blog.scottbellware.com/

Inversion of Control / Dependency Injection

http://structuremap.sourceforge.net/Default.htm

http://ninject.org/

http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx

ORM

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

http://nhforge.org/Default.aspx

http://subsonicproject.com/

Technical Arguments Are Good

Lee Brandt — Tue, 15 Sep 2009 00:38:07 GMT

I might have made a decent lawyer. If I’d been born without any self respect and complete absence of morality, I might’ve become a lawyer. I love to argue. I love it. I like pitting my ideas against another’s. I like that at any moment I might have an epiphany and change my perspective or opinions about something. That’s learning. Basically, in technical arguing, I’ve seen basically three scenarios.

The Salesman

First is the useless scenario. Someone has a bone to pick or an agenda to push. This is the most frustrating scenario. In that case, I am not arguing your perspective against mine, and there is no way you will ever concede defeat, because you have a prize that you are after.

The Amicable Divorce

The Second scenario is that we agree to disagree. To me this isn’t much more useful than the first. I still may learn something and later when researching your points, I may find golden nuggets of information that I can learn from, but generally, this means that one of us couldn’t convince the other, but were just not comfortable conceding the point. If I do this, I generally assume that I am wrong and quickly start researching your points so I can figure out where I am wrong if I am right, I will be better equipped to convince you (or someone) next time.

Teach You, Teach Me

The last scenario is: We argue, one of us concedes the point and we end up learning something. That’s my favorite. I love to learn and I love to teach. Even more than I love to argue. (And I argue with myself in the shower just to keep in practice).

Ultimately, I like learning more than anything else, and arguing is a really good way to learn something. The problem is, you have to argue your point fervently, while keeping your mind open to the possibility that you’re wrong and be ready to stop on a dime and say, “Hey, I think you may be right!” The flip side of that is, being ready for the other person to say that you may be right without being a jerk about it.

Danger, Will Robinson, Danger

First, Be ready to answer all questions, and don’t EVER be afraid to say you don’t know something. Faking your way through an answer or an argument is a surefire way to get someone not to trust your arguments, and possibly lose interest in arguing with you altogether.

It is also important to be aware of your arguing style and warn others, however. I have a very animated arguing style, and I am six-foot-five and 350lbs. Seeing me wave my arms and raise my voice may throw people off, but I am truly harmless, and I am NOT using this style as a tactic to win an argument. (At least not a technical argument.)

So feel free to argue with me, and if you prove me wrong, I learned something and I owe you one.

Let’s Build A Dev Shop (Part 4 of n)

Lee Brandt — Mon, 14 Sep 2009 00:20:10 GMT

Alright dear readers (both of you), I told you last time that I would answer that age-old question, “How many projects should I have in my solution?” The answer is: only as many as you need. I know, I know, but it’s not a copout, really it’s not. I’ve really found that is it easier to start with fewer projects and break them out when you need to, than trying to combine projects later on. Does that mean that one project with everything in it is right? Yes. If that is all you need.

I realize it sounds like I am being wishy-washy, but I promise I am not. For the sake of being opinionated (because “as many as you need” is hard-to-follow advice if you are looking for guidance), I will say I normally find that I have three projects. I tend to call them Web.UI, Core and Specifications. For this series we’ll be building a web project, but you could just as easily swap the Web.UI project for a WPF.UI project. Now, if you don’t consider the Specifications project as part of the “According to Hoyle” project, then I only have two projects.

The thing that I will do is namespace everything within the project n a way that makes it easy to break them into their own project if I need to. So I had my data interfaces in a data folder (with that namespace) and inside that a folder for each type of implementation (e.g. an NHibernate folder, a SubSonic folder and an Entity Framework folder). This sill allow me to make a new project called Core.Data.NHibernate and move those files over and hopefully not break anything (I haven’t needed to do that yet).

I have been using this project structure for a while and am pretty happy with it. It came from stealing little ideas from respected developers around the community, and hashing it out with my co-worker, Troy. He is the one who kept reminding me that I didn’t need all those projects in the solution, and eventually we whittled it down to these three.

One thing that I will also do, is have my Specifications project a folder above the location where the Core and Web.UI projects are in the file system. I stole this Idea from Sharp Architecture and it makes for good, solid separation of the Specifications from the rest of the production code.

I hope this gets you ideas flowing for your own solutions and gives you a jumping-off point for deciding just what your solution needs in it. This should also be a good way to get the (civilized) conversation going about your won project structure within your team.

Next time, we’ll talk about tools. We’ll briefly discuss why you would use each tool and what comparable tools are out there. We’ll look at application architectural patterns (MVC vs MVP vs MVVM vs Web Forms), ORM tools, IOC containers, mocking and testing frameworks and some helper libraries that might make it easier to do some things within your own project.

Let’s Build a Dev Shop (Part 3 of n)

Lee Brandt — Wed, 09 Sep 2009 04:26:56 GMT

Last Time… we looked at installing and setting up VisualSVN Server to be our Source Code Management (SCM) system. With our SCM system all set up, now we need to take a look at how to best take advantage of its features. We’ll look at common folder structures for code repositories and what they folder do/mean.

Just about anyone who has used some sort of code repository has probably seen this structure:

This is a very common pattern because it highlights the three main things you want your repository to keep track of for you: your trunk (the main line of development or your current branch), tags (each “marked” version of your code) and branches (each live of development that detours from the main, like prototypes, refactors, etc). Branches help you to to work on the code while keeping the trunk “deployable” (or close to) at all times.

There are many different theories/practices surrounding branching and merging (forking off the main line and developing, and then merging the developed branch back to the main). I tend not to branch unless I am doing a spike story (an experiment or proof of concept) or if I am squashing a major bug that might cause some significant design changes.

You may ask yourself, “How did get here?” (But I digress…) What you may really ask is: Where do these folders go? And, just like any important computing question, the answer is: It depends.

It depends on your business and development structure, and how your team organizes its code, but my guideline is: for every solution-level effort (where a Visual Studio solution is being created) I follow this structure. So in my personal code repo on Google code, you’ll find:

These are three of the projects out there. So each undertaking gets it’s own set of the three major folders, and under each is the arrangement for the project itself. Generally, inside of the trunk folder I have several more folders. They are a good way to arrange everything I might need for a solution. Like Below:

The Build folder is used for my build artifacts (we’ll discuss making a build file in the next installment). When the build runs, it will put output files in this folder. The db is where I store my DDL scripts for creating my database (we’ll get into builds creating databases in the next installment or two). The docs folder holds any documentation the project might need (thanks captain obvious). The lib folder holds all of my project references, the dlls my program or it’s helpers need to reference to do their job. For instance, Structure Map, NHibernate, MSpec, etc. The specs folder contains all of my Behaviour-Driven, Executable Specifications. and finally my src folder holds the source code for my program. You’ll also notice that my *.build file and my batch file for running (just to make it one click run) are also here. This is mainly for ease of use, so that the build file has access to all the folders containing the code it is going to build.

Again, there are probably many different folder structures being used all over, but this is the structure I use currently because it serves my needs and makes everything easy to get to. I am never afraid to change it up to accommodate a special requirement or problem. The trick, I think, is to be pragmatic about what you do. Understand that if you start with only a few folders, and it starts to become unruly, you can break things down more, but starting off with a bajillion folders and trying to combine things later can be a bit more tricky.

Well that’s a general breakdown of the source code folder structure for the project we’ll be building our dev shop around. I cannot stress enough that these are my opinions of how I am currently doing things. I may change something if I find it is causing friction. Just recently, in fact, I moved my specs folder up to the same level as the src folder and the lib folder. This is something I saw done in the Sharp Architecture project and I liked it. It keeps my specs back away from my code physically on my hard drive and with projects in a solution, still allows them to look as if they’re side by side (it will become clearer later why this is important).

In the next installment, we’ll create a base project. We’ll talk about project structure, and answer that age old question, “How many projects should you have in your solution?”

Stay tuned for part 4!

Let’s Build a Dev Shop (Part 2 of n)

Lee Brandt — Sat, 05 Sep 2009 04:36:39 GMT

VisualSVN Server

Last time, we talked about Source Code Management (SCM) systems and why you need them. Today we’re going to set up our choice of SCM: Subversion. I used to install Subversion server on a Linux machine and dedicate that box to being a SCM system. The problem I always had was getting it set up and getting it authenticating against Windows credentials. Not long ago, someone turned me on to VisualSVN Server and I haven’t looked back.

Here a quick set-by-step for getting a subversion server set up using VisualSVN Server.

First, download the server from the VisualSVN website (http://www.visualsvn.com/). Make sure you download the SERVER and not the VisualSVN Visual Studio plug-in. It’s only about 4Mb and it installs with a double-click. The version that downloads by default (as of this writing) is 2.0.6.

Installing VisualSVN

We click on the installer and start with a setup wizard screen that tells you it is going to install Apache and Subversion. Click the “Next” button, and accept the license agreement. The next screen gives us a choice of installing the server and the management console or just the management console. We choose the “VisualSVN Server and Management Console” option and click on the “Next” button. On the next screen you can accept all the defaults except one: the “Use Subversion authentication” we want to change to “User Windows authentication” so we don’t have to manage any user accounts for Subversion, then hit the “Next” button, and click “Install” on the next screen.

When it finishes, make sure the “Start VisualSVN Server Manager” is selected (it is by default) and click the “Finish” button. This will start the VisualSVN Management Console. If you have already unchecked the “Start VisualSVN Server Manager” check box and closed the window, you can go to: Start > All Programs > VisualSVN > VisualSVN Server Manager and start it from there too. You should see a screen like the one below.

You’ll want to right-click on the “Repositories” tree node on the left, and choose “Create New Repository…”. When you do, you will see the “Create New Repository” screen where you can give your repository a name. We’ll name this one “FirstRepo”. You can also choose to have it create the default structure for you (trunk, branches, tags), but in this case we don’t want to (we’ll talk about that in the next post). When you click “Ok”, you be taken back to the Server Manager screen and you’ll notice the “FirstRepo” node has been added to the “Repositories” node on the tree on the left.

Checking Out the Repository

You can get the TortoiseSVN client for SVN from the Tortoise website (http://tortoisesvn.tigris.org/) and install it just as easily. Once you’ve downloaded and install Tortoise, you will probably need to restart your machine (at least I did on the x64 version). Once you’re back, go to your C:\ drive and create an “svn” folder under the root (this isn’t mandatory, it’s just how I do things). Then open that folder, and add a “FirstRepo” folder. Right-click on the “FirstRepo” folder and choose “SVN Checkout” from the context menu. You should see a screen like the one below.

You should enter the URL of your SVN repository shown on you VisualSVN Management screen above. Take the Server URL and append the repository name (for me, that’s https://[servername]/svn/FirstRepo/") everything else should be good by default. Then click “OK”. You might be hit with the screen below.

Since we’re using a self-generated certificate to transfer files over https, this warning will come up. Just “Accept Permanently” and wait for the login screen to come up. Login with your Windows credentials and voila, you have just created and checked out your first repository! You should notice a green circle-check on your “FirstRepo” folder (you may have to refresh the folder to get it to show up). This indicates that the content on your hard drive, matches what’s in the Subversion repository.

Congratulations! Now you can add code files to this folder, and right-click at any level (most often you should do it at the root folder) and choose “SVN commit” and that will check code into the repository.

Next time, we’ll look at common folder structures for SVN repositories and why we use those structures.

‘Til next time…

Additional Resources

The Subversion Book (It’s Free): http://svnbook.red-bean.com/

VisualSVN Documentation: http://www.visualsvn.com/server/doc/server-config/

Another Subversion Book (Not Free): Pragmatic Version Control: Using Subversion

Check Out Some Code

From Google Code: http://code.google.com/

From CodePlex: http://www.codeplex.com/

Let’s Build A Dev Shop (Part 1 of n)

Lee Brandt — Fri, 04 Sep 2009 05:53:28 GMT

I have been thinking about this for a while now. I speak around the Midwest about Behavior-Driven Development and as I poll groups of developers there is one thing I notice: there are a lot of things that I consider “givens” that quite a few people aren’t doing. I’ve been lucky enough in my last two jobs to be asked to basically build a development shop. I did tons of research for both and there are some practices that are going on in the industry that really should be just common practice. So maybe this is a “best practices” list, but I think of it more of a “standard practices” list. As we discuss each tool or practice, we’ll discuss what options are out there as far as tools for achieving the desired results. We’ll discuss a little of the pros and cons of each, and I’ll show you the toll/practice I use most often.

Getting Started

Let’s start at the beginning… thanks captain obvious. There are still some teams that are not even using source control. I know it sounds hardly credible, but I promise you that it is true. There are people who sync their copy with they team-mates’ by copying files to a network share. This is not meant to impugn those developers’ works. They might be mighty fine developers who’ve just never been exposed to a Source Code Management system before. Well, let’s expose you…

Source Code Management System is just a fancy name for source control. You may have used Visual Source Safe (VSS), Subversion (SVN) or Concurrent Versioning System (CVS) before. Each of them have plus and minuses, but let’s look at the standard features of (just about) any CMS.

Check-In & Check-Out

Of course, the most basic thing is the ability to check-in and out source code from your CMS. Making it easy to upload only the changes and have teammates (or even you on another machine) to be able to get those changes is one of the most basic parts of the SCM systems. Most SCM Systems check-in to a central code repository and it uploads only the changed files and keeps track of what’s changed from version to version. Git, however, is a distributed SCM meaning there really ISN’T a central repository (although you can clone, and fetch from an origin repository). Let’s just start simple.

Merging

The next thing, is being able to merge changes when you and another member of your dev team make changes to the same file. If you both change the EXACT same line, you will cause a conflict, and have to resolve it. Most SCMs have some way of setting the “Locking” type. It will be either “Optimistic” or “Pessimistic” locking. Optimistic Locking is just like it sounds, the SCM is being optimistic that any conflicts within a file will be resolvable by you, so it doesn’t lock the files and keep others from working on them. This can be a little hairy, because you WILL have conflicts and you will have to resolve them. Pessimistic Locking, on the other hand, doesn’t trust developers and only lets one person at a time edit each file, by locking the file when someone checks it out.

I prefer optimistic locking. Pessimistic sounds really safe and more desirable, until Jim goes on vacation and forgets to check-in his files so that others can work on them. It’s also problematic when you legitimately need to work on the same file. I need to make a change to file X so I can see how it effects file Z that I am currently working on, and Jim’s working on file X at the moment. The biggest downside to optimistic locking is the conflicts, and to be honest, it is NOT that hard to resolve conflicts. there are tools for the SCMs that make it easy to inspect the differences and accept/reject/merge changes.

Rolling Back

You might find that when writing some code for a feature, you’ve introduced major holes in the rest of your application. (This can be avoided by using TDD/BDD and doing a good “Check-in Dance”, but we’ll get to that.) If you find yourself in the situation where you’ve broken so many things in your code that you wish you could just get back to the way the system was before you did all this, you can. All SCMs support versioning and rolling back. Some make it very easy to do, so ctrl-z is not your only option anymore.

Branching

Branching is another feature of modern SCMs and it allows me to take a snapshot of a codebase and create a fork, so that I can try and fix a bug in without changing the code that is in the “trunk”. Once any bug fixes or enhancements are made in that “branch”, you can merge those changes back into the trunk. As a matter of fact, there are lots of teams that branch for just about everything. I think that’s a little drastic, but if it makes you comfortable to branch every spike, every bug and every new feature, you are certainly welcome to.

There are lots of SCMs out there, both free and paid. I have actually never used one of the paid SCM systems (Perforce, Bitkeeper or SourceGear Vault), there are lots of great free SCMs to get started with and if you find that you need to do something that you can’t get in your free solution, then look at the paid systems. The main free SCMs are Subversion and Git. Microsoft’s Team Foundation Server also has a SCM built into it and it integrates nicely with Visual Studio.

My Choice

I choose Subversion. I use VisualSVN Server to set up the Subversion server on a server machine, and then I use TortoiseSVN as my Windows client. So far, SVN and Tortoise have caused me very little friction. Branching and Merging can be a bit tricky when you first get started, but once you get the hang of it, it becomes easier. Subversion also comes with a free book and has been around for quite a few years now. There is also a huge number of users using SVN for their SCM, so finding help can be very simple.

Summary

So we talked about the basics of an SCM System and some of the choices and we made the choice to go with SVN. Now what? In the interest of not letting this post get any longer; in the next post, we’ll talk about installing VisualSVN and Tortoise and we’ll create a repository to start checking our code into.

On to part 2

St. Louis Day of Dot Net Wrap Up

Lee Brandt — Tue, 01 Sep 2009 05:06:30 GMT

OK, I have wound down enough to get my thoughts together.

First, let me just say how utterly impressed I was with the event. I can’t think of another conference that gives you so much for so little. This conference was on par with Mix09 and it was ~$100 a person!

The content was top-notch as well. Tim Barcz’s talk on mocking, Phil Japikse’s talk on Patterns, Chris Patterson’s talk on Event Driven Architecture and Clint’s talk about starting a company (what little I could see from the hall since there was no way to get in the room). All great content and all great presenters. They were comfortable, relaxed and knew their stuff.

I also got quite a bit out of just hanging in the speaker room. I talked with Brian Button, Brian Blanchard, Chris Hammond, Dan Rigsby, Eric Brown, Muljadi Budiman, Ralph Wheaton, Perry Simeroth and Chris Deweese about everything from BizTalk to C# 4.0. From Twitter to Travel. We had a really good time just making fun of the fact that we were all in the Speaker Room practicing “JIT Presentations”.

The food was excellent and the staff at the Ameristar Casino was Johnny-On-The-Spot with everything the event needed. My only regret is that I didn’t take advantage of the TBD rooms more. I would’ve loved to been in on the REST talk with Dan Rigsby to learn more about REST.

Again, a big congratulations and pat on the back to the organizers of the event and a huge thanks to all the attendees. I hope that I gave enough knowledge to warrant the knowledge I took away.

Looking forward to the next one!