March 2006 - Posts
Gregor Hohpe delivered what sounds like an excellent “keynote” to a room full of Java programmers at the Server Side Java Symposium. Within his presentation he talked about how we need to write code with people in mind rather then the computer. We need to make beautiful code.
"Write code that people aren't compelled to mess up," he said. "Make code so the next person sees you put thought into an elegant solution."
"Write code for people not machines," was Hohpe's mantra throughout his keynote. He suggested that if programmers were only writing for machines, they wouldn't need Java, they could revert to working in Assembler.
"Where did all the beautiful code go?" he asked,…"Maybe the janitor comes in during the night and messes up our code?"
Harry Pierson has an interesting post entitled “The Dual Schema Problem” where he talks about the problems that we face in mapping our object model to our relational model. Although todays mappers help reduce the amount of work required to get data out of our relational model and into our object model they don’t help make our lives easier when it comes to managing our schema. We still have to maintain our schema in two places. And we still (for the most part) have to start with our database schema and work our way back to our objects.
In an ideal environment the “schema” of our application would reside in the same place our object model lives. As our object model evolved so to would our schema. We’d work in a single “environment”, we wouldn’t jump between VS.NET and SQL Server, and we’d be more productive.
Andres has an interesting post on DLINQ and ASP.NET Build Providers. As you might be able to tell from my last couple of posts on DLinq I think it’s pretty cool. As some readers pointed out much (if not all) of what I was showing in my posts can be done in today’s mappers. What I like so much about DLinq how nicely integrated it is in the language which is in large part due to the new C# 3.0 language features (by the way when can we have them 
)
Anyway back to the point of this post. As DLinq gets closer to release I suspect we’re going to see a lot more people get interested in the idea of O/R Mapping and start to use DLinq. Making the process of building applications using DLinq smooth will be key to it’s success in the .NET world (we can argue if this is a good or bad thing at another time). Having “things” like custom ASP.NET Build providers will certainly help.
Rather then posting a short novel on DLinq I decided to cut my previous post “short” and include some more highlights in this follow up post:
- Take(5) – SELECT TOP 5
- Skip(10) — Skips the first 10 records
- Supports “including” related data to prevent additional roundtrips to the database via .Including(c => c.Orders) syntax
- Supports string functions
- StartsWith => ColumnName LIKE ‘foo%’
- EndsWith => ColumnName LIKE ‘%foo’
- Contains => ColumnName LIKE ‘%foo%’
- Length => LEN(ColumnName) > 30
- Substring => SUBSTRING(ColumnName, 0, 5)
- ToUpper => UPPER(ColumnName)
- ToLower => LOWER(ColumnName)
- Concurrency support – OptimisticConcurrencyException is thrown when two users try to modify the same object.
- Supports for direct SQL:
var products = db.ExecuteQuery<Product>(
"SELECT [Product List].ProductID, [Product List].ProductName " +
"FROM Products AS [Product List] " +
"WHERE [Product List].Discontinued = 0 " +
"ORDER BY [Product List].ProductName;"
);
Rather then posting a short novel on DLinq I decided to cut my previous post “short” and include some more highlights in this follow up post:
- Take(5) – SELECT TOP 5
- Skip(10) — Skips the first 10 records
- Supports “including” related data to prevent additional roundtrips to the database via .Including(c => c.Orders) syntax
- Supports string functions
- StartsWith => ColumnName LIKE ‘foo%’
- EndsWith => ColumnName LIKE ‘%foo’
- Contains => ColumnName LIKE ‘%foo%’
- Length => LEN(ColumnName) > 30
- Substring => SUBSTRING(ColumnName, 0, 5)
- ToUpper => UPPER(ColumnName)
- ToLower => LOWER(ColumnName)
- Concurrency support – OptimisticConcurrencyException is thrown when two users try to modify the same object.
- Supports for direct SQL:
var products = db.ExecuteQuery<Product>(
"SELECT [Product List].ProductID, [Product List].ProductName " +
"FROM Products AS [Product List] " +
"WHERE [Product List].Discontinued = 0 " +
"ORDER BY [Product List].ProductName;"
);
One of the things I didn’t mention in my previous CAB Best Practices post is that while out in Redmond I got a chance to have a small peak at some F# and Linq stuff. While I’ve read a decent amount of information on Linq, DLinq, and XLinq, I hadn’t done much of anything from a coding perspective with these technologies. Since that fateful day in building 20 I’ve started to dig into Linq a bit more. The short story is it’s cool. The longer story is that it’s really cool.
I’m sure everyone has seen the basic programming api that Linq provides but as a quick review let’s checkout a simple block of C# code to return a list of customers from the Northwind database.
var customers = from c in db.Customers
where c.City == "London"
select c;
This will return a list of customer objects that have “London” as their city. What’s cool about this is that you have a nice strongly typed query API. In addition to all the nice select like querying provided by Linq it also provides a number of other “functions” such as Sum, Min, Max, Average.
var amount = db.Products.Sum(p => p.UnitPrice);
One of the down-sides of a lot of O/R Mappers is that they don’t make things like the above easy. This often times results in developers witting a bunch of extremely inefficient code. As an example the below is some not so efficient code that one might write using a typical .NET O/R Mapper.
decimal amount = 0;
List<Product> products = new Repository<Product>().FindAll();
products.ForEach(delegate(Product product) { amount += product.UnitPrice; });
The query using DLinq results in one small compact database query that returns a single result.
SELECT SUM([t0].[UnitPrice]) AS [value] FROM [Products] AS [t0]
While the second fictionary O/R Mapper code results in a larger query that returns all the product data and relies on the provided C# code to do the work. The other very nice thing about DLinq is that you can return only the data you want by specifying what data to return in your select.
var customerNames = from c in db.Customers
select c.CompanyName;
// SELECT [t0].[CompanyName] FROM [Customers] AS [t0]
Again DLinq results in much less data coming back from the database then a typical O/R Mapper would provide. The other “super cool” feature that is available within Linq is anonymous types. As an example lets assume we want to get a bunch of “Address” objects extracted from the details within our Customers table. Let’s also assume we don’t have a “Address” object in our system.
var addresses = from c in db.Customers
where c.City == "London"
select new { c.Address, c.City, c.Region, c.PostalCode };
/*
exec sp_executesql N'SELECT [t0].[Address], [t0].[City], [t0].[PostalCode], [t0].[Region] FROM [Customers] AS [t0] WHERE [t0].[City] = @p0', N'@p0 nvarchar(6)', @p0 = N'London'
*/
foreach(var address in addresses) {
Console.WriteLine(address.Address);
Console.WriteLine(address.City + " " + address.Region + " " + address.PostalCode);
}
As you can see we select the Address, City, Region, and PostalCode from our Customers table and turn them into an anonymous type representing our Address. Trying to do something similar using C# 2.0 and a typical O/R Mapper would result in much more code. It’s also nice to be able to have groupby, order by, having, and more as natively supported operations.
var q =
from p in db.Products
group p by p.CategoryID into g
select new {
CategoryID = g.Key,
MaxPrice = g.Group.Max(p => p.UnitPrice)
};
/*
SELECT [t1].[CategoryID], [t1].[value] AS [MaxPrice]
FROM (
SELECT MAX([t0].[UnitPrice]) AS [value], [t0].[CategoryID]
FROM [Products] AS [t0]
GROUP BY [t0].[CategoryID]
) AS [t1]
*/
foreach(var p in q) {
Console.WriteLine(p.CategoryID);
Console.WriteLine(p.MaxPrice);
}
All in all Linq and more specifically DLinq look to be headed down the right path. As a O/R Mapping junkie I’m interested in seeing where things progress from this point forward. It appears that DLinq is making sure that most of the SQL operations and keywords find their way into the core language which will hopefully mean a lot less O/R Mapping abuse in .NET land.
One of the things I didn’t mention in my previous CAB Best Practices post is that while out in Redmond I got a chance to have a small peak at some F# and Linq stuff. While I’ve read a decent amount of information on Linq, DLinq, and XLinq, I hadn’t done much of anything from a coding perspective with these technologies. Since that fateful day in building 20 I’ve started to dig into Linq a bit more. The short story is it’s cool. The longer story is that it’s really cool.
I’m sure everyone has seen the basic programming api that Linq provides but as a quick review let’s checkout a simple block of C# code to return a list of customers from the Northwind database.
var customers = from c in db.Customers
where c.City == "London"
select c;
This will return a list of customer objects that have “London” as their city. What’s cool about this is that you have a nice strongly typed query API. In addition to all the nice select like querying provided by Linq it also provides a number of other “functions” such as Sum, Min, Max, Average.
var amount = db.Products.Sum(p => p.UnitPrice);
One of the down-sides of a lot of O/R Mappers is that they don’t make things like the above easy. This often times results in developers witting a bunch of extremely inefficient code. As an example the below is some not so efficient code that one might write using a typical .NET O/R Mapper.
decimal amount = 0;
List<Product> products = new Repository<Product>().FindAll();
products.ForEach(delegate(Product product) { amount += product.UnitPrice; });
The query using DLinq results in one small compact database query that returns a single result.
SELECT SUM([t0].[UnitPrice]) AS [value] FROM [Products] AS [t0]
While the second fictionary O/R Mapper code results in a larger query that returns all the product data and relies on the provided C# code to do the work. The other very nice thing about DLinq is that you can return only the data you want by specifying what data to return in your select.
var customerNames = from c in db.Customers
select c.CompanyName;
// SELECT [t0].[CompanyName] FROM [Customers] AS [t0]
Again DLinq results in much less data coming back from the database then a typical O/R Mapper would provide. The other “super cool” feature that is available within Linq is anonymous types. As an example lets assume we want to get a bunch of “Address” objects extracted from the details within our Customers table. Let’s also assume we don’t have a “Address” object in our system.
var addresses = from c in db.Customers
where c.City == "London"
select new { c.Address, c.City, c.Region, c.PostalCode };
/*
exec sp_executesql N'SELECT [t0].[Address], [t0].[City], [t0].[PostalCode], [t0].[Region] FROM [Customers] AS [t0] WHERE [t0].[City] = @p0', N'@p0 nvarchar(6)', @p0 = N'London'
*/
foreach(var address in addresses) {
Console.WriteLine(address.Address);
Console.WriteLine(address.City + " " + address.Region + " " + address.PostalCode);
}
As you can see we select the Address, City, Region, and PostalCode from our Customers table and turn them into an anonymous type representing our Address. Trying to do something similar using C# 2.0 and a typical O/R Mapper would result in much more code. It’s also nice to be able to have groupby, order by, having, and more as natively supported operations.
var q =
from p in db.Products
group p by p.CategoryID into g
select new {
CategoryID = g.Key,
MaxPrice = g.Group.Max(p => p.UnitPrice)
};
/*
SELECT [t1].[CategoryID], [t1].[value] AS [MaxPrice]
FROM (
SELECT MAX([t0].[UnitPrice]) AS [value], [t0].[CategoryID]
FROM [Products] AS [t0]
GROUP BY [t0].[CategoryID]
) AS [t1]
*/
foreach(var p in q) {
Console.WriteLine(p.CategoryID);
Console.WriteLine(p.MaxPrice);
}
All in all Linq and more specifically DLinq look to be headed down the right path. As a O/R Mapping junkie I’m interested in seeing where things progress from this point forward. It appears that DLinq is making sure that most of the SQL operations and keywords find their way into the core language which will hopefully mean a lot less O/R Mapping abuse in .NET land.
One of the things that I love about the blogosphere is that it allows everyone to make up new definitions for established practices. As a perfect example have a look at John Wood’s “The Inefficiency of Test Driven Development”.
So what does this have to do with Test Driven Development? Effectively, with only a little hint, I'm determining the requirements based on the reaction to the tests. The tests are driving my efforts to meet her requirements. And this is actually a lot like how TDD works.
With all due respect to John this has absolutely and positively nothing to do with test driven development. If your trying to use TDD to gather your requirements its no wonder your not a fan. Test driven development is not a requirements gathering tool. Believe it or not the people who started the whole agile movement recognized what John is talking about. They recognized that the interactions between people was extremely important. They recognized that the business experts should be a core member of the team and that the interactions between the business experts and programmers was of crucial importance. They even put it at the top of their list of things to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
How is it that we’ve fallen so far from what agile and test driven development are about? Perhaps its the fact that the name doesn’t really suite. Perhaps people take it literally and assume that test driven development means that you shouldn’t talk with anyone, just let your tests drive all aspects of your development. Instead of having business prioritize and develop stories we should just dive right into the test driven development process and have the test drive everything. Forget having a vision, just start coding and let the requirements show themselves.
Anyway since I don’t think the point of John’s post was to redefine TDD as a requirements gathering tool I think I’ll stop there. Before I sign off though let me remind you that TDD is about design. It’s not about gathering requirements, its not about defining a contract of intended behaviour, its about following a process that forces you to think about the design of your software every step of the way. If you don’t value design don’t do TDD. If you think TDD is a requirements tool don’t use TDD.
This past week I attended the Smart Client Baseline Architecture Toolkit (SC-BAT) workshop out in Redmond. Overall it was a very beneficial week. I learned a lot about CAB best practices and also got to meet some members of the core patterns and practices team as well as some other Microsoft employees whom I had “heard” of.
It was also my first trip out to Redmond so it was fun to see what Microsoft was like…it’s HUGE. Anyway I thought I’d get going with some posts on what I learned and how I’ll apply what I learned. This first post is a simple list of the best practices that I came away with. Hopefully future posts will be more beneficial for those who don’t know much about CAB.
- There should be a 1–1 relationship between a view and it’s presenter. Presenters are seen as an implementation detail of a view so nothing outside of the view should know about the presenters existence. [CreateNew] is your friend when it comes to creating a presenter for your view.
- Since views know about their presenter (and vice versa) any work that needs to be done by the view should be directly delegated to it’s presenter. The presenter should handle all work that the view needs done. The view should just display data and be extremely “light”. The event broker should NOT be use to communicate between a view and it’s presenter.
private void button_Click(object sender, EventArgs e) {
_presenter.DoMyButtonClickStuff();
}
- If views need to “communicate” between each other they should use EventPublication/EventSubscription.
- WorkItem’s sole purpose in life is to be a container. Rather then being anything “Use Case” related treat WorkItem as what it is, a container.
- The logic necessary for adding views, services, and etc. to a WorkItem should live inside a Controller class. Since the controller needs to know about it’s WorkItem the ControlledWorkItem class should become one of your good friends.
- Controllers are used to get things wired up and running, and for adding everything necessary to the container (aka WorkItem).
- If possible your views should implement the ISmartPartProvider interface. This allows the view to determine how it is displayed within your workspace(s).
- Views and Presenters should implement IDisposable so they can be cleaned up properly.
- The Guidance Automation Toolkit is your friend. Learn it, live it, love it!
This evening I came across an interesting post by Brian Marick. The following paragraph was of particular interest.
I'm not sure whether people on the Agile projects of today have it better or worse. On the one hand, ideas like the above are no longer so outr, so it's easier to find yourself in situations where you're allowed to indulge them. On the other hand, people's actions are much more visible, and they tend to be much more dedicated to meeting deadlines—deadlines that are always looming. I'm wondering these days whether I'm disenchanted with one-week iterations. I believe that the really experienced team can envision a better structure and move toward it in small, safe steps that add not much time to most every story. I'm not good enough to do that. I need time floundering around. To get things right, I need to be unafraid of taking markedly more time on a story than is needed to get it done with well-tested code that's not all that far from what I wish it were (but makes the effort to get there one story bigger and so one story less likely to be spent). It's tough to be unafraid when you're never more than four days from a deadline.
source: http://www.testing.com/cgi-bin/blog/2006/03/15#two-formative-experiences
I have the beginning of an opinion on this but its not fully formed so I’m going to let it settle before posting. What do you think?
Since I’m getting on the Subversion bandwagon I figured I should learn how to use it. TortoiseSVN actually makes working with Subversion very easy but I like understanding the underpinnings of things I use so I picked up Pragmatic Version Control Using Subversion.
This afternoon after getting home from lunch at the playground with the kids I picked up my nice new Subversion book to get up to speed. Overall the book is a good one to pick up if your going to start using Subversion. With that said I’m not sure it’s really required. As I already stated Subversion along with TortoiseSVN is very easy to use and doesn’t really consist of that much “meat”.
I did enjoy learning more about how the author recommends organizing things in Subversion as well as how best to manage tagging, braching, and merging source. It was also good to get a solid overview of all the Subversion commands that TortoiseSVN hides behind it’s nice UI.
Overall a good read, especially for those completely unfamiliar with version control and/or Subversion.
As a software developer, as well as a member of a software development team, version control is a critical aspect to the work I do. Over the years I’ve used several different version control providers with varying degrees of success.
The majority of my professional life I’ve worked with Visual SourceSafe (VSS). Although the experience hasn’t been stellar, I’ve actually had a surprisingly low number of issues with VSS…until recently. At home I’ve used VSS, Vault, and Subversion. Since at home it’s just me I don’t have many hard core requirements.
Ok, so back to the recent problems with VSS. Every since we’ve been using .NET 2.0 (which started with early betas) we’ve been having a lot of issues. I should note that some of these issues where specific to the VSS integration within VS.NET.
- Get latest takes a long time, and often hangs
- The pending checkins window takes forever and a day to come up and often hangs VS.NET
- While checking in files VSS bombs out which results in the repository becoming corrupted
- Repeated corruption problems
- Merge changes doesn’t exactly merge (sometimes)
Over the course of the last several months we’ve been talking a lot about moving to some alternative source control providers. Since almost everyone on the team had either had very good experiences with Subversion, or heard of people having very good experiences it came up as the best option in most of our conversations.
We’ve been running on Subversion for a couple weeks now and I’ve been very impressed. The top advantages that we’ve seen are:
- Must faster then VSS
- Checkouts over the VPN used to be impossible but are now very doable
- Our build time within CC.NET has gone down considerably (on the order of 3–4 minutes)
- TortoiseSVN is a nicer interface then VSS (integration with the shell is top notch)
- Atomic commits are a very good thing.
- Easy to setup – we were up and running in the matter of a half day
- Setting up the subversion repository took 3–4 hours since we had to figure out how to install it
- Importing our existing source took about 5–10 minutes
- Updating our continuous integration environment took about an hour. Most of that time was spent perusing the CC.NET help and trying to figure out why autogetsource “wan’t working” with subversion. It turns out that you have to do the initial checkout yourself on the build machine in order for this to work.
Funny side note: while spell checking this post BlogJet wanted to change VSS to ASS
Often times while I’m pairing I get strange looks for using new C# language features that aren’t common knowledge yet. I’m cool like that. Or not.
Anyway, one of the new operators in C# 2.0 which I hadn’t really used or come across yet was the ?? operator.
The ?? operator returns the left-hand operand if it is not null, or else it returns the right operand.
While the ?? operator was primarily added for Nullable types it can also be used with reference types. So instead of writing one of those lovely ternary operators like so:
TreeNode rootNode = (myNode.Parent !=
null ? myNode.Parent : myNode);
You can instead write:
TreeNode rootNode = myNode.Parent ?? myNode;
Pretty snazzy eh?
One of the things that a few of my co-workers have been discussing recently is the need for a new modifier in C# to identify things that you want to be testable. Tonight I decided to look into re-writing C# to include a “testable” modifier. Ok, not really.
What I was looking into was the InternalsVisibleTo attribute that is available in .NET 2.0. After taking a quick peak at the MSDN page I was able to setup my test assembly as a “friend assembly” by adding the following lines of code to my business libraries AssemblyInfo.cs:
#if
(DEBUG)
[assembly:
InternalsVisibleToAttribute(
"MyBusinessLibrary.Tests")]
#endif
The friend assemblies feature in .NET allows you to access internal members from your friend assembly. All private types and private members will remain inaccessible as you would expect. I’m not sure how much this will help, or if it will help at all, but at the very least I learned something new tonight. 