221 pages of Web Application Performance Testing Guidance. What more could you ask for?
Free download? Got that.
Printed version? That is why you bought a printer.
Free time to read it? I can't help you there. Stop watching so much TV!
Here are a few other links about people talking about it:
J.D Meier's Blog
Rico Mariani's Blog
Next step: get Ayande to write one of these for NHibernate.
August 30, 2007
August 26, 2007
Book Review: Practices of an Agile Developer
Agile development seems to be one of the hotter topics in development today. This is notable because it does not directly involve coding or technology. Agile development is about project management.
But that underscores a lot of interest I am seeing in methodology books in general (but that might just be me). At some point you realize that technology ABC really doesn't matter that much. Ruby, PHP, ASP.NET, Java -- whatever, pick one and lets get the job done. They all do the same basic things, a few of the details are different, but really, that can be learned pretty easily.
What is changes is your approach to development. Do you use source control? Are you test driven? Do you Scrum? While standing up? How important are any of those things? Why are they important?
There in lies the purpose of Practices of an Agile Developer. Why is it important to have a daily scrum -- while standing -- every day -- and why aren't there a bunch of managers there? And more importantly, what does it feel like when you are getting it right?
Have you ever released software where you feel good about it, knowing that it does what it is supposed to, and that the underlying systems all work? If you haven't, this book will help you get there.
The other beauty of this book, it talks about all of this and it is only 180 pages. That is a thing of beauty. It puts in just enough information to give the idea without belaboring the idea. There is something to be said for treating your reader like a thinking adult.
So what is this book? This is the first book that I would recommend to all software developers that contains almost no code. I also don't care if you have no interest in management -- everyone with 5 years of experience should read it (if you have less than five year, there are probably still have a book list three feet tall to plow through -- this one can wait a bit).
Official site
Amazon
Authors blog
Other books worth reading:
Code Complete 2
Framework Design Guidelines
Mythical Man Month
But that underscores a lot of interest I am seeing in methodology books in general (but that might just be me). At some point you realize that technology ABC really doesn't matter that much. Ruby, PHP, ASP.NET, Java -- whatever, pick one and lets get the job done. They all do the same basic things, a few of the details are different, but really, that can be learned pretty easily.
What is changes is your approach to development. Do you use source control? Are you test driven? Do you Scrum? While standing up? How important are any of those things? Why are they important?
There in lies the purpose of Practices of an Agile Developer. Why is it important to have a daily scrum -- while standing -- every day -- and why aren't there a bunch of managers there? And more importantly, what does it feel like when you are getting it right?
Have you ever released software where you feel good about it, knowing that it does what it is supposed to, and that the underlying systems all work? If you haven't, this book will help you get there.
The other beauty of this book, it talks about all of this and it is only 180 pages. That is a thing of beauty. It puts in just enough information to give the idea without belaboring the idea. There is something to be said for treating your reader like a thinking adult.
So what is this book? This is the first book that I would recommend to all software developers that contains almost no code. I also don't care if you have no interest in management -- everyone with 5 years of experience should read it (if you have less than five year, there are probably still have a book list three feet tall to plow through -- this one can wait a bit).
Official site
Amazon
Authors blog
Other books worth reading:
Code Complete 2
Framework Design Guidelines
Mythical Man Month
August 24, 2007
LINQ to SQL: Interfaces on your Domain objects
There has been some gowning about the lack of interfaces built into the domain objects produced by the Linq to SQL code generator.
Note: a domain object, as I am using the term here, is an object that maps column-to-property with a table. For example, if you have a Customer table with an ID and a Name field, you will have a Customer class with an ID and Name property.
I found that it is trivially easy to create. Every object in Linq to SQL is a partial class. So create a partial class that maps to the generated partial (there is no good way to say that, I swear). Then you can use the built in refactoring "Extract Interface" to create an interface that implements the fields in domain object.
The key point that I did not realize is this: you can assign an interface to class in any of the partial class declarations.
So, in Linq to SQL, keeping with our Customer table paradym, your generated partial class will look like this:
public partial class Customer : INotifyPropertyChanging, INotifyPropertyChanged
Now your other partial class (in an entirely different file) will look like this:
public partial class Customer : ICustomer
Both declarations define interfaces. I didn't know you could do that.
Now the cool part is that the interface can be defined anywhere. If you are trying to create a true separation between layers you will probably want to define it an an assembly other than the assembly that the domain classes are defined in.
Anyway, that is my discovery for today. Have a good weekend.
Note: a domain object, as I am using the term here, is an object that maps column-to-property with a table. For example, if you have a Customer table with an ID and a Name field, you will have a Customer class with an ID and Name property.
I found that it is trivially easy to create. Every object in Linq to SQL is a partial class. So create a partial class that maps to the generated partial (there is no good way to say that, I swear). Then you can use the built in refactoring "Extract Interface" to create an interface that implements the fields in domain object.
The key point that I did not realize is this: you can assign an interface to class in any of the partial class declarations.
So, in Linq to SQL, keeping with our Customer table paradym, your generated partial class will look like this:
public partial class Customer : INotifyPropertyChanging, INotifyPropertyChanged
Now your other partial class (in an entirely different file) will look like this:
public partial class Customer : ICustomer
Both declarations define interfaces. I didn't know you could do that.
Now the cool part is that the interface can be defined anywhere. If you are trying to create a true separation between layers you will probably want to define it an an assembly other than the assembly that the domain classes are defined in.
Anyway, that is my discovery for today. Have a good weekend.
August 22, 2007
Lily Rides a bike
A momentous occasion occurred at my house tonight. After dinner, my six year old daughter, Lily, finally figured out how to ride her bike.
The joy of having a large amount of pavement and a slight hill (my house is on the top of a hill, and there used to be a tennis court below the house). I got her to coast down the hill with her feet down, then when the pavement flattened out she just started pedaling.
Best part: no having daddy trying to run behind her on his bad knees.
The joy of having a large amount of pavement and a slight hill (my house is on the top of a hill, and there used to be a tennis court below the house). I got her to coast down the hill with her feet down, then when the pavement flattened out she just started pedaling.
Best part: no having daddy trying to run behind her on his bad knees.
LINQ to SQL: Extension Methods
I've talked about Extension Methods (I probably called them partial methods) before. Now that I actually have Linq to SQL in my hands I thought I would take a look at what extension methods are created when you start with LINQ to SQL.
In my previous example, I showed a sample database that looked like this:
My designer is named "LinqTests.dbml", which is an xml file that is used to generate LinqTests.designer.cs. That is where we find all of the code.
First, we will look at the classes that map to the tables. We have a Customer, Product, and CustomerProduct tables. In each class there is a region named "Extensibility Method Definitions", that is where we are looking right now.
For the Customer class, this is what we see:
Basically, that accounts for two extension methods for every column in a table, plus three more: OnLoaded(), OnValidate(), and OnCreated().
If you can't tell from the name: OnCreated is called right as a new Customer object is created, the OnLoaded() is called after data is loaded into it by Linq to Sql, and OnValidate is called before the code is saved (I think -- since I can't find the code that actually calls it).
The others are for before and after a particular property is set.
Looking into the code further you can see how the code is being called. Here is the constructor:
The line OnCreated(); calls the OnCreated method (duh!), but if you search the code you wont find anywhere that OnCreated does anything. That is for you to do in a partial class.
Now, to add some business logic to my Customer class for when the class is created or loaded, the code will look like this:
Back to basics here. The generated DataContext class also has some Extension Methods
So now you have three extension methods for each table that the Data Context has to manage. One for Insert, Update, and Delete; plus one more for when the Data Context class is created.
Lets take a step back now. Does this really get us anywhere? Before, with generated domain objects (those are the objects that are created to hold data) you could still accomplish all of this using inheritance. The problem with using inheritance is that now you have to use the inherited class and shouldn't user the base class. Worse, there really isn't a good way to tell people not to use the base classes.
Now with extension methods you will have less need to inherit your base domain objects. Now you have the hooks you need to extend your domain objects to fit your business needs. Your developers (or just yourself) now have one set of objects to remember to use. Kind of like one stop shopping.
I've still heard a bit of moaning and groaning about extension methods on the web -- I don't agree with them. I think extension methods are a wonderful addition to C# that will really help fix a need. And what Linq for SQL has done has only helped to illustrate that need for everyone.
In my previous example, I showed a sample database that looked like this:
My designer is named "LinqTests.dbml", which is an xml file that is used to generate LinqTests.designer.cs. That is where we find all of the code.
First, we will look at the classes that map to the tables. We have a Customer, Product, and CustomerProduct tables. In each class there is a region named "Extensibility Method Definitions", that is where we are looking right now.
For the Customer class, this is what we see:
Basically, that accounts for two extension methods for every column in a table, plus three more: OnLoaded(), OnValidate(), and OnCreated().
If you can't tell from the name: OnCreated is called right as a new Customer object is created, the OnLoaded() is called after data is loaded into it by Linq to Sql, and OnValidate is called before the code is saved (I think -- since I can't find the code that actually calls it).
The others are for before and after a particular property is set.
Looking into the code further you can see how the code is being called. Here is the constructor:
public Customer()
{
OnCreated();
this._CustomerProducts = new EntitySet<CustomerProduct>(}
new Action<CustomerProduct>(this.attach_CustomerProducts),
new Action<CustomerProduct>(this.detach_CustomerProducts));
The line OnCreated(); calls the OnCreated method (duh!), but if you search the code you wont find anywhere that OnCreated does anything. That is for you to do in a partial class.
Now, to add some business logic to my Customer class for when the class is created or loaded, the code will look like this:
public partial class Customer
{
partial void OnCreated()
{
this.Name = "Billy-Mac";
}
partial void OnLoaded()
{
if (string.Empty( this.Name ))
this.Name = "Jim-Bob";
}
}
Back to basics here. The generated DataContext class also has some Extension Methods
So now you have three extension methods for each table that the Data Context has to manage. One for Insert, Update, and Delete; plus one more for when the Data Context class is created.
Lets take a step back now. Does this really get us anywhere? Before, with generated domain objects (those are the objects that are created to hold data) you could still accomplish all of this using inheritance. The problem with using inheritance is that now you have to use the inherited class and shouldn't user the base class. Worse, there really isn't a good way to tell people not to use the base classes.
Now with extension methods you will have less need to inherit your base domain objects. Now you have the hooks you need to extend your domain objects to fit your business needs. Your developers (or just yourself) now have one set of objects to remember to use. Kind of like one stop shopping.
I've still heard a bit of moaning and groaning about extension methods on the web -- I don't agree with them. I think extension methods are a wonderful addition to C# that will really help fix a need. And what Linq for SQL has done has only helped to illustrate that need for everyone.
LINQ to SQL: Many-To-Many Tables and Joins
Still having fun with LINQ to SQL over here. One quick note, I've found that the best way to test LINQ queries is to have a unit test class ready to go. Makes things much easier.
So what I've been playing with lately is using LINQ to SQL for querying against Many-To-Many tables. For an illustration, I'll use a table structure like this: (click on it to see a bigger version)
Once imported into your Linq to Sql file type in visual studio, and viewed through a class diagram, you get this:
In my Customer table I have 5 customers, I also have 5 products (Product ID=1 is "Computer"). The CustomerProduct table has about 20 records.
Now we can start having fun with some queries. The question I wanted to answer was: "Which customers have a particular product?". Simple enough.
I found, as with many things, there are multiple ways of getting the same answer. My first query looked like this:
OK, background note. This code is using the LinqTestsDataContext object to query the Customer table and the CustomerProduct table to find all of the customers with a Computer (product id = 1). What is returned is a IQueryiable object. If I want to parse through each Customer object indivitually, can call customersWithProduct.ToList() and get a List object returned.
This lovely piece of Linq generates the following SQL code:
How do I know that is the SQL that is generated? After I run that line I can mouse over the variable (customersWithProduct) and the tooltip displays the generated SQL. I cant change it (that I know of), but at least I can look at it.
Anyway, that is not what I would call the best SQL I have ever seen -- and it is slow.
Next came attempt two at Linq to SQL. I wrote this:
In the previous example, I used that Customer.CustomerProducts object to filter the products. This time I am explicitly joining the Customers and the CustomerProducts tables together in Linq. The only odd part of the query was the "equal" keyword that you have to use in the join.
The SQL generated was much better:
Look: an actual join. Trust me, this works much faster. The first query took 3.24 seconds, the second took 0.06 seconds. I call that significant. Especially considering the amount of data I am querying (not much). You add some real data (thousand and millions of records) and you could be talking about some significant downtime.
Lots more to discover here. All a matter of time.
So what I've been playing with lately is using LINQ to SQL for querying against Many-To-Many tables. For an illustration, I'll use a table structure like this: (click on it to see a bigger version)
Once imported into your Linq to Sql file type in visual studio, and viewed through a class diagram, you get this:
In my Customer table I have 5 customers, I also have 5 products (Product ID=1 is "Computer"). The CustomerProduct table has about 20 records.
Now we can start having fun with some queries. The question I wanted to answer was: "Which customers have a particular product?". Simple enough.
I found, as with many things, there are multiple ways of getting the same answer. My first query looked like this:
int Computer = 1;
LinqTestsDataContext cx = new LinqTestsDataContext();
var customersWithProduct = from c in cx.Customers
from cp in c.CustomerProducts
where cp.ProductID == Computer
select c;
OK, background note. This code is using the LinqTestsDataContext object to query the Customer table and the CustomerProduct table to find all of the customers with a Computer (product id = 1). What is returned is a IQueryiable
This lovely piece of Linq generates the following SQL code:
{SELECT [t0].[ID], [t0].[Name]
FROM [dbo].[Customer] AS [t0], [dbo].[CustomerProduct] AS [t1]
WHERE ([t1].[ProductID] = @p0) AND ([t1].[CustomerID] = [t0].[ID])}
How do I know that is the SQL that is generated? After I run that line I can mouse over the variable (customersWithProduct) and the tooltip displays the generated SQL. I cant change it (that I know of), but at least I can look at it.
Anyway, that is not what I would call the best SQL I have ever seen -- and it is slow.
Next came attempt two at Linq to SQL. I wrote this:
int Computer = 1;
LinqTestsDataContext cx = new LinqTestsDataContext();
var customersWithProduct = from c in cx.Customers
join cp in cx.CustomerProducts on c.ID equals cp.CustomerID
where cp.ProductID == Computer
select c;
In the previous example, I used that Customer.CustomerProducts object to filter the products. This time I am explicitly joining the Customers and the CustomerProducts tables together in Linq. The only odd part of the query was the "equal" keyword that you have to use in the join.
The SQL generated was much better:
{SELECT [t0].[ID], [t0].[Name]
FROM [dbo].[Customer] AS [t0]
INNER JOIN [dbo].[CustomerProduct] AS [t1] ON [t0].[ID] = [t1].[CustomerID]
WHERE [t1].[ProductID] = @p0}
Look: an actual join. Trust me, this works much faster. The first query took 3.24 seconds, the second took 0.06 seconds. I call that significant. Especially considering the amount of data I am querying (not much). You add some real data (thousand and millions of records) and you could be talking about some significant downtime.
Lots more to discover here. All a matter of time.
August 20, 2007
LINQ to SQL: SQL IN clause
Here is a problem I recently had to figure out with LINQ: how do you do an IN with LINQ for SQL?
In standard SQL your query would look like this:
It turns out my savior was Contains.
Every generic List ( List ) with System.Linq available has a Contains< > extension method (this is .Net 3.5 we are talking about here), and that is what you use.
So, when creating a new query via LINQ for SQL in Lambda, you get a IQueryable interface with a Where extension method ...
Oh crap, here is the code, this will take to long to fully explain:
In standard SQL your query would look like this:
SELECT myColumn FROM myTableBut lets put another kink in, shall we. I'm not using LINQ, I'm using Lambda.
WHERE myColumn IN (myVal1, myVal2, myVal3)
It turns out my savior was Contains.
Every generic List ( List
So, when creating a new query via LINQ for SQL in Lambda, you get a IQueryable interface with a Where extension method ...
Oh crap, here is the code, this will take to long to fully explain:
MyDataDataContext cx = new MyDataDataContext(); // from the LINQ to SQL dbmlSo what have we, and what was created. Well, we just used LINQ to SQL to generate a query that will look like this:
IQueryableq = cx.MyTables.AsQueryable(); // creates the query object
ListlistOfData = {1,2,3,4};
q.Where( x => listOfData.Contains(x.MyIntValue));
var result = q2.Select(x => x.MyIntValue);
SELECT [t0].[MyIntValue]There is a @p[number] for every value in the list 'listOfData' above. And to me, the generated SQL is pretty good. That is probably what I would write.
FROM [dbo.MyTable] AS [t0]
WHERE [t0.][MyIntValue] in ( @p1, @p2, @p3, @p4 )
August 03, 2007
LINQ: XElement and Namespaces
I had an opportunity to play with LINQ for XML and Google Maps recently. Quite a bit of fun actually. Anyway, I ran into a problem in that Google Maps encodes all of their XML in Namespaces. I hate Namespaces. I understand that somewhere there is a reason for namespaces to live -- but I still hate them. More than that, I hate having to query for them. XPath with Namespaces is just a pain beyond belief.
So one of the cool new objects you get in .NET 3.5 is XElement for reading xml and being able to use LINQ on it. But...what about querying with namespaces?
Here is how you do it:
Declare a XNamespace object with the namespace. In my case it looked like this:
XNamespace ns = "http://earth.google.com/kml/2.0";
Grab the XML, via a url, into an XElement node:
XElement resultNode = XElement.Load( url );
Now, I just wanted one node buried deap in the structure called "coordinates". This is how I grabbed it:
XElement coordinateNode = resultNode.Descendants( ns + "coordinates" ).First();
So that last line of code. I'm using the Descendants method to return all of the nodes in a flat list. I could have used resultNode.Descendants().Last() and gotten the node I wanted (since the coordinates node is the last node in the document -- but there isn't much of a guarantee that will always be the case.
So I'm asking the Descendants method for the "coordinates" node by name, and I'm prefixing that name with the namespace. Descendants returns an IEnumerable (a list), so I use the First() method to just give me the first instance.
Compared to XPath, this was a dream. But I still hate namespaces.
Here is all the code again in list:
XElement resultNode = XElement.Load( url );
XNamespace ns = "http://earth.google.com/kml/2.0";
XElement coordinateNode = resultNode.Descendants( ns + "coordinates" ).First();
So one of the cool new objects you get in .NET 3.5 is XElement for reading xml and being able to use LINQ on it. But...what about querying with namespaces?
Here is how you do it:
Declare a XNamespace object with the namespace. In my case it looked like this:
XNamespace ns = "http://earth.google.com/kml/2.0";
Grab the XML, via a url, into an XElement node:
XElement resultNode = XElement.Load( url );
Now, I just wanted one node buried deap in the structure called "coordinates". This is how I grabbed it:
XElement coordinateNode = resultNode.Descendants( ns + "coordinates" ).First();
So that last line of code. I'm using the Descendants method to return all of the nodes in a flat list. I could have used resultNode.Descendants().Last() and gotten the node I wanted (since the coordinates node is the last node in the document -- but there isn't much of a guarantee that will always be the case.
So I'm asking the Descendants method for the "coordinates" node by name, and I'm prefixing that name with the namespace. Descendants returns an IEnumerable (a list), so I use the First() method to just give me the first instance.
Compared to XPath, this was a dream. But I still hate namespaces.
Here is all the code again in list:
XElement resultNode = XElement.Load( url );
XNamespace ns = "http://earth.google.com/kml/2.0";
XElement coordinateNode = resultNode.Descendants( ns + "coordinates" ).First();
Subscribe to:
Posts (Atom)