It looks like you can hold a reference to the method you are entering and exiting by using the MethodExecutionTag.
You can assign what you want to it as it is just an object and is bound to the eventArgs of the enter and exit events.
Sweet.
This means you could also make every single method a transaction if you wanted to (if you were Juval Lowy/mad man), or mark entry and exit of a specific instance call of a method using a GUID as colleague had mentioned would be nice for logging.
As this is weaved in to the IL its should have not have any more a negative performance impact on calling the method, over over putting the code in to the method to do exactly the same. You do however have a whole load more flexibility to pull out and put in what you want and where (ie certain assemblies, classes or methods).
I am loving PostSharp :)
Tuesday, December 25, 2007
Monday, December 24, 2007
DBC within the C# language - Spec#
Spec# or SpecSharp
I have been hoping for something like this for quite awhile. I am hoping this will be something that will aid in compile time assistance for Design By Contract programming.
I have been looking into third party apps and even building my own libraries, however what i really wanted was compile time errors as opposed to run time errors, which although Test would usually find, don't really help other developers as they leverage of my code.
Currently i have comments and run time checks however this still does not force consumers of my method to adhere to the contract, it only throw run time exceptions when they break the contract. the benefit here is they fail fats and they get a more meaningful exception message as to WHY the parameters are not valid. But it often also means that i have code the looks like:
public class Foo: IFoo
{
public void Bar(object param1)
{
Check.IsNotnull(param1, "Foo.Bar: param1 can not be null");
if(param1 != null) //***this line is effectively redundant
{
//do something with param1...
}
}
}
The null check is still in place to prevent FXCop errors arising by not checking for the objects state before using it.
I really hope the Spec# C# additions will aid in this.
I have been hoping for something like this for quite awhile. I am hoping this will be something that will aid in compile time assistance for Design By Contract programming.
I have been looking into third party apps and even building my own libraries, however what i really wanted was compile time errors as opposed to run time errors, which although Test would usually find, don't really help other developers as they leverage of my code.
Currently i have comments and run time checks however this still does not force consumers of my method to adhere to the contract, it only throw run time exceptions when they break the contract. the benefit here is they fail fats and they get a more meaningful exception message as to WHY the parameters are not valid. But it often also means that i have code the looks like:
public class Foo: IFoo
{
public void Bar(object param1)
{
Check.IsNotnull(param1, "Foo.Bar: param1 can not be null");
if(param1 != null) //***this line is effectively redundant
{
//do something with param1...
}
}
}
The null check is still in place to prevent FXCop errors arising by not checking for the objects state before using it.
I really hope the Spec# C# additions will aid in this.
Tuesday, December 18, 2007
When is a bug not a bug?
I am sure the Tester at the place I currently work at secretly hates me. He is far too nice and far too professional to ever say... but i am sure of it.
He is in a position where he knows what the application we are building should do and how it should do it. Unfortunately this is only ever communicated to me after I have built the module. He doesnt write the use case so dosen't get a chance to prewarn me.
These changes are raised as bugs (as we only have the concept of bug, no concept of a change request) and so it looks like my code sucks as i have a couple of dozen bugs logged against my name (which is standard across the team). I dont like the idea of my code sucking. While looking through the buglist today, after reading the first 12 and realising that they were either A) Not bugs, but changes or B) not my bugs to fix; I got a little stroppy.
*begin blowing trumpet*
Now, when I get a use case I assume that this is what is required... I know, what an idiot... so I write my unit tests and do the whole Red, Green, Refactor like a good TDD agile boy,
*end blowing trumpet*
however I forget that we only call ourselves agile we are in fact... dreamers.
Huge numbers of tests fail and are left unattended, iteration after iteration... our scope is non existent.. our use case are guesses at what we kinda, maybe want and are completely ok to change at any time with the expectation to deliver on time still intact.
So I have tried to push back.
-A bug is raised
> If in use case ==> FIX NOW!
>Else ==>can be done in next iteration and is logged as "Not in spec/Functional change".
I thought this may rustle some feathers and hopefully means the uses case would be a little more robust. It also means the actual bugs got higher priority, as I think they should.
No...
Now we just do non-functional iterations where we do "bug fixes" on all the functionality that was never originally asked for.
As there are a few developers (6-12) all on UK rates (not exactly cheap) and one BA (still only UK rates, but only 1), I would think it would make sense to focus the effort on the up front work, hell maybe even hire another "BA" so the development team don’t have to handle code 2,3,4 + times.
It also means the teste (again on UK rates) has to test and then retest every time the change is made... how do you spell D.R.Y???
To say this annoys me is somewhat of an understatement. It is pretty hard to be focused and passionate about what you are doing, knowing full well in only a few hours/days/weeks it will all get thrown out because someone threw together a Use case, with out putting more than 5 minutes thought into it.
More time scoping => less time "bug fixing"*
*i.e. retrofitting missing functionality
Now I know Agile encompasses the ability to "handle change", but never getting the original scope correct... ever, through laziness, is not Agile, it's just software cowboy bollocks.
Unfortunately nothing is going to change. This could be a really good project, even a flag ship project for the company as it is using new exciting tools for the comapny (.Net 3.0, Nhibernate etc) and it would honestly only require the smallest extra bit of effort. But it wont and that’s a shame.
end of yet another rant...
He is in a position where he knows what the application we are building should do and how it should do it. Unfortunately this is only ever communicated to me after I have built the module. He doesnt write the use case so dosen't get a chance to prewarn me.
These changes are raised as bugs (as we only have the concept of bug, no concept of a change request) and so it looks like my code sucks as i have a couple of dozen bugs logged against my name (which is standard across the team). I dont like the idea of my code sucking. While looking through the buglist today, after reading the first 12 and realising that they were either A) Not bugs, but changes or B) not my bugs to fix; I got a little stroppy.
*begin blowing trumpet*
Now, when I get a use case I assume that this is what is required... I know, what an idiot... so I write my unit tests and do the whole Red, Green, Refactor like a good TDD agile boy,
*end blowing trumpet*
however I forget that we only call ourselves agile we are in fact... dreamers.
Huge numbers of tests fail and are left unattended, iteration after iteration... our scope is non existent.. our use case are guesses at what we kinda, maybe want and are completely ok to change at any time with the expectation to deliver on time still intact.
So I have tried to push back.
-A bug is raised
> If in use case ==> FIX NOW!
>Else ==>can be done in next iteration and is logged as "Not in spec/Functional change".
I thought this may rustle some feathers and hopefully means the uses case would be a little more robust. It also means the actual bugs got higher priority, as I think they should.
No...
Now we just do non-functional iterations where we do "bug fixes" on all the functionality that was never originally asked for.
As there are a few developers (6-12) all on UK rates (not exactly cheap) and one BA (still only UK rates, but only 1), I would think it would make sense to focus the effort on the up front work, hell maybe even hire another "BA" so the development team don’t have to handle code 2,3,4 + times.
It also means the teste (again on UK rates) has to test and then retest every time the change is made... how do you spell D.R.Y???
To say this annoys me is somewhat of an understatement. It is pretty hard to be focused and passionate about what you are doing, knowing full well in only a few hours/days/weeks it will all get thrown out because someone threw together a Use case, with out putting more than 5 minutes thought into it.
More time scoping => less time "bug fixing"*
*i.e. retrofitting missing functionality
Now I know Agile encompasses the ability to "handle change", but never getting the original scope correct... ever, through laziness, is not Agile, it's just software cowboy bollocks.
Unfortunately nothing is going to change. This could be a really good project, even a flag ship project for the company as it is using new exciting tools for the comapny (.Net 3.0, Nhibernate etc) and it would honestly only require the smallest extra bit of effort. But it wont and that’s a shame.
end of yet another rant...
M$ and OSS playing nice!
http://codebetter.com/blogs/jeffrey.palermo/archive/2007/12/11/mvccontrib-now-has-ioc-container-support-for-quot-the-big-3-quot.aspx
Windsor, Spring.Net and StrutureMap can now bolt in directly in to the new MVC framework... hopefully this is a begining... :)
Windsor, Spring.Net and StrutureMap can now bolt in directly in to the new MVC framework... hopefully this is a begining... :)
Wednesday, December 12, 2007
Apache.org = 404
It really pisses me off that anytime i try to get something from Apache there are 404 error all over the show. I normally use Nlog, however at work we are using Log4Net. I went to the log4net site and most of the links i click on a dead... 404 bloody everywhere.
PITA!
As such i continue to use pretty much no Apache api's in my dev.
<UPDATE>
...and the downloads are 1.1 that dont run... NLog has just cemented its place in my toolbox.
</UPDATE>
PITA!
As such i continue to use pretty much no Apache api's in my dev.
...and the downloads are 1.1 that dont run... NLog has just cemented its place in my toolbox.
Sunday, December 9, 2007
XBox
Yeah I had to get one.
At the apartment we have a huge HD screen. Gears of War and Assassin's Creed are awesome on it.
This thing blows my mind, the graphics are unbelievable... clearly I have not been up to speed on gaming or HD tv's....
I am addicted to the creed... stealth kills.. I feel like a bad man ;)
At the apartment we have a huge HD screen. Gears of War and Assassin's Creed are awesome on it.
This thing blows my mind, the graphics are unbelievable... clearly I have not been up to speed on gaming or HD tv's....
I am addicted to the creed... stealth kills.. I feel like a bad man ;)
DSL's and tearing up tiers
Boo:
I read a lot of Ayende's post, well actually I read everything he puts out, so as he references his work with Binsor and Brail (which are Boo off shoots/DSL), I figured I had better see what its all about. Well I am still getting my head around things, I haven't learnt a new language in so long (shame on me). However I can now see why Bindsor would be so handy. I am not a huge fan of strings and XML to me, is one massive string. If i can get compile time checking AND get the flexibility of easy config. Sweet. Another thing on my massive to do list DSL up my configs.
Volta from MSDN labs is out... another thing I need to play with. Could be great for small teams teams if it works... after reading the blurb i am wondering if this is stepping on CSLA.Nets toes?
I read a lot of Ayende's post, well actually I read everything he puts out, so as he references his work with Binsor and Brail (which are Boo off shoots/DSL), I figured I had better see what its all about. Well I am still getting my head around things, I haven't learnt a new language in so long (shame on me). However I can now see why Bindsor would be so handy. I am not a huge fan of strings and XML to me, is one massive string. If i can get compile time checking AND get the flexibility of easy config. Sweet. Another thing on my massive to do list DSL up my configs.
Volta from MSDN labs is out... another thing I need to play with. Could be great for small teams teams if it works... after reading the blurb i am wondering if this is stepping on CSLA.Nets toes?
Subscribe to:
Posts (Atom)



