I'm pretty sure most developers (web developers anyway) have heard of ORM (Object Relational Mapping) tools like NHibernate that map your database tables and to objects. These ORM tools reduce interaction with the database to just a few method calls, many times just Save(), GetById(), and a few custom query methods. There's a lot written about ORM, but no one really writes about the mapping between HTML forms and the objects that ORM maps.
ASP.NET has a great solution for OFM (I'm calling it OFM because google won't give me a real name for it). If you use a FormView in combination with an ObjectDataSource you can bind the properties of your object to form elements. This is pretty cool because it reduces your code to writing an ORM mapping, creating factory methods to get and save the object, and some ASP markup that maps the object to HTML elements.
I was playing with Ruby on Rails which has a somewhat different approach to OFM. Basically you write regular HTML and give your form elements names like "account[id]", "account[name]", etc. This seems like a little more work than the ASP.NET way except that on the server side it uses this notation to wrap the query string into an object that can be referenced in object notation from ruby code like "account.id", "account.name", etc. I believe PHP does something similar. I like this method because it's very light on HTTP - there's no obstructively bloated view state being passed around like there is in ASP.NET and you can pass several objects through the query string.
Basically, OFM manages some of the page flow by marshalling form parameters into objects that can easily be passed to a factory method. This is awesome because it means I can focus more effort on writing unit tests for business logic that has no dependencies on the web API. It allows me to to keep page flow simple and sets up business logic for creating restful web services (seriously, you could just slap [WebMethod] attributes on the factory methods and voila you have web services). There seems to be a lot of framework that goes into managing OFM, but oddly I don't think many people have addressed it directly as a problem that needs to be overcome (I assume this is because the MVC architecture is supposed to address this; unfortunately vanilla ASP.NET isn't MVC).
I recently pulled most of my hair out over the ObjectDataSource and interfacing with factory methods. In the future I want to write a post about how I got around it (and another one lambasting Microsoft for even attempting to release an API as thoughtless as the ODS, but seriously, more on that later).
Tuesday, October 19, 2010
Tuesday, October 12, 2010
Why we chose Git instead of Subversion
I just got a new job as an ASP.NET developer at a small company that is freshly developing itself into somewhat of a software company. The development team is undergoing a ton of changes over the past 6 months (6 months ago there were two developers, now there is five as well as a new director of technology). As part of our changes we took some time to evaluate the tools we use. We had been using Microsoft's Team Foundation Server for source control and a home-grown system for bug tracking but after our evaluations we settled on Redmine and Git.
The fact that we are using Redmine for ALM and bug tracking isn't particularly surprising to me because it's a feature heavy and mature product that is very natural to use. There are several other feature heavy mature ALM tools that would fit us, but none that are free (I don't consider Trac feature heavy). Git, however, is a bit of a pleasant surprise for me.
For the uninitiated ones, Git is a distributed SCM (source control management) tool. The distributed part means that it works kind of like Subversion except that everyone has a full clone of the repository. When you want to check your code in you commit first to yourself and then push your changes to the rest of the team. More realistically you would be committing to yourself several times and occasionally pushing your changes to the rest of the team when you verify that your code is stable.
The benefit of this is that you can maintain your own personal branches of the code where you experiment on certain features without having to push them out to everyone else. I see this as psychologically breaking down the barrier to committing code. I often find that I don't commit code for a while because, even though it builds, I'm not sure if some of the pages will run without errors. However, committing to myself means that I can commit whenever I want and not slow any of my teammates down with potential errors.
Git also provides very easy and simple branching. They made it extremely easy to drop everything your doing to fix that top priority bug in production (the "stash" operation lets you save uncommitted changes and move to another part of the code). With this extra change management, Git also forces you to account for all your changes. Before you switch branches you have to either stash, commit or revert your current changes. At first this seems annoying, but on second thought it forces to always have some sort of accounting for why you changed stuff.
We did have some hesitation with changing to Git. Our biggest concern was if one of our partner teams from a different company could keep up with a change in SCM. After some evaluation we realized that Git provided so much flexibility with managing our workflow with this partner that it makes Subversion look like an archaic hack.
Another concern we had was stability. Git itself has been around since 2005 and seems to have pretty strong development community backing it. It has a very strong Linux following and a year ago lacked a good Windows interface. However, TortoiseGit has been developing at a very rapid rate (it's single developer has been releasing more than twice a month and is quickly working toward supporting most of Git's features). Because it is developing so fast we agreed that we could disregard shortcomings in the Windows environment in due to the awesome number and power of the features it brings.
Today I worked on importing our TFS repository into a Git clone. I found a PowerShell script hosted on Github that got me pretty close. The code in the script was a little too brittle so I made the code a little more generic and sent it back to him. It's taking about six hours to migrate the 1200 changesets into Git, so the script probably won't finish running for another couple hours, but I think it's working so far.
I will have to follow up in six months or so with an evaluation of how things have gone.
The fact that we are using Redmine for ALM and bug tracking isn't particularly surprising to me because it's a feature heavy and mature product that is very natural to use. There are several other feature heavy mature ALM tools that would fit us, but none that are free (I don't consider Trac feature heavy). Git, however, is a bit of a pleasant surprise for me.
For the uninitiated ones, Git is a distributed SCM (source control management) tool. The distributed part means that it works kind of like Subversion except that everyone has a full clone of the repository. When you want to check your code in you commit first to yourself and then push your changes to the rest of the team. More realistically you would be committing to yourself several times and occasionally pushing your changes to the rest of the team when you verify that your code is stable.
The benefit of this is that you can maintain your own personal branches of the code where you experiment on certain features without having to push them out to everyone else. I see this as psychologically breaking down the barrier to committing code. I often find that I don't commit code for a while because, even though it builds, I'm not sure if some of the pages will run without errors. However, committing to myself means that I can commit whenever I want and not slow any of my teammates down with potential errors.
Git also provides very easy and simple branching. They made it extremely easy to drop everything your doing to fix that top priority bug in production (the "stash" operation lets you save uncommitted changes and move to another part of the code). With this extra change management, Git also forces you to account for all your changes. Before you switch branches you have to either stash, commit or revert your current changes. At first this seems annoying, but on second thought it forces to always have some sort of accounting for why you changed stuff.
We did have some hesitation with changing to Git. Our biggest concern was if one of our partner teams from a different company could keep up with a change in SCM. After some evaluation we realized that Git provided so much flexibility with managing our workflow with this partner that it makes Subversion look like an archaic hack.
Another concern we had was stability. Git itself has been around since 2005 and seems to have pretty strong development community backing it. It has a very strong Linux following and a year ago lacked a good Windows interface. However, TortoiseGit has been developing at a very rapid rate (it's single developer has been releasing more than twice a month and is quickly working toward supporting most of Git's features). Because it is developing so fast we agreed that we could disregard shortcomings in the Windows environment in due to the awesome number and power of the features it brings.
Today I worked on importing our TFS repository into a Git clone. I found a PowerShell script hosted on Github that got me pretty close. The code in the script was a little too brittle so I made the code a little more generic and sent it back to him. It's taking about six hours to migrate the 1200 changesets into Git, so the script probably won't finish running for another couple hours, but I think it's working so far.
I will have to follow up in six months or so with an evaluation of how things have gone.
Subscribe to:
Posts (Atom)