| Ian Cooper 的个人资料Staccato Signals日志列表 |  工具  帮助 |
|
3月30日 XMLSerializer and dependencies not foundThe XMLSerializer needs permissions to the Windows\Temp directory to work as it compiles an assembly on the fly. Without permissions you may get file i/o exceptions raised during serialization.
Usually the error looks something like:
This is common in an ASP.NET application where you are running without permissions to Windows\Temp but can occur on any application that has this characterstic. You can find more on this on Scott Hanselman's blog, .NET 24/7, or the knowledge base. 3月29日 DDD5, call for speakers!We are now calling for speakers for DDD5. DDD is organized by the UK community for the UK community so, as before, there will be no Microsoft speakers on the day, just advice from people at the sharp end. Microsoft will however be hosting us as usual. As usual we are open to sessions of interest to UK developers. Once we have the list of proposed sessions we will open up the agenda to public vote. That allows attendees to help shape the day as we will use your votes to decide which sessions to include.
This year we are asking for proposals for grok talks as well as full-hour sessions after the success of the lunchtime events last year. If you have ever felt like speaking, but do not feel up to a full session this is an ideal opportunity for you. Grok talks are a great way to start being active in the UK community rather than just passive. So give it a go.
Sadly, because we have had a lot of logistical problems in the past with speakers from abroad, we are unlikely to accept applications from speakers who are non-resident in the UK at the time of DDD.
3月28日 London .NET user group tonight: 28 MarchWe have had quite a few signups for my LINQ presentation tonight, so I just wanted to re-iterate the usual warning that it is first come first served until we hit the fire limit (50 people). We don't usually overflow, because we budget on around 50%, but it has happened before.
See you there.
CI Factory, Simian and discovering toolsZi pointed me in the direction of CI factory. We already have a good set of Nant build scripts here that a few guys have toiled away on that do build and deployment for us, so it is not that useful to us now, but if you were greenfield it could be valuable. Even if you just have a look at what they put out and then modify it to what you need, it could give a lot of people who are put off from doing Continuous Integration by lack of experience with putting build scripts together a leg up.
There are a couple of interesting links from that page too. I had completely missed the existence of Simian. What's interesting is that now I know about it I can find people talking about it in the blogsphere. Now I think I am pretty good at monitoring the OSS tools space and Agile development practices, but the fact that this one passed me by suggests I'm missing some sources that would have highlighted this one.
I'm curious as to whether anyone has a good list of tools for .NET teams pursuing agile development. I know about Scott's tool list and Simian is in there so shame on me, but Scott does not cover OSS projects like the Castle project tools, NHibernate, NVelocity ,Subsonic, StructureMap, Selenium, Watir, dbDeploy, etc. Is anyone aware of such a site? If not should the .NET community build one?
3月23日 Technical DebtJeremy Miller adds to my comments on the ratio of test code to production code to point out that you should not let the put you off. It is a great amplification because my post was not intended to frighten anyone thinking of approaching TDD, or be used as a reason not to.
I would add that when you use TDD the usual ratio time figured at 1/3 design; 1/3 code; 1/3 test begins to come apart, so if you are using ratios to figure project costs from developer estimates you need to re-figure these. The reason is that TDD reduces the design ratino is that the the act of designing is subsumed into your tests. That is the essence of what TDD is and why some folks prefer Test-Driven Design as a name. You reduce the testing phase because the quality of code produced by TDD will be much higher and the testing phase can focus not on finding programmer bugs but on ensuring that the user's expectations have been adequately captured by the design.
Finally work in terms of total cost of ownership, not cost to live. Project Managers often get pressured to hit certain dates - the cost to live - because it is seem as reducing cost. This can lead to quality shortcuts to 'get-it-live'. However, software spends 80% of its life in maintenance so these shortcuts will increase your total cost of ownership over the long-term by making your software less amenable to change. This is the notion of technical debt, making shortcuts now that you have to pay for later. I'm sure we have all been on projects that decayed from too much 'deficit buget spending' to the point that the development team expended all their effort servicing the debt instead of adding new value. Sadly the managers that spend the future are often no longer around when the team has to start making loan payments. Once you get too much debt you end up bankrupt and have to re-write the software from scratch. TDD helps you make sure that you 'balance the books'.
BTW, you should also consider estimating and planning and design activities btw, essentially focus on design-all-the-time over design-up-front. For my estimating and planning, usually the act of breaking the required stories into tasks, implicity suggest a design. Try to get as much of the team involved as you can as this spreads the knowledge and encourages buy-in from the team members. 3月22日 eBay does not use stored proceduresIt was interesting at the MSDN Roadshow yesterday to see one DB developers reaction to LINQ. His attitude was a common one from the DB community toward ORM products that use dynamic sql that 'real applications use stored procedures'. Usually the concerns people have center around peformance and security.
There is a huge amount of myth around performance of dynamic sql and a number of people have tried to debunk the myths here over time such as Frans Bourma, Paul Wilson, and recently Andres Aguiar. In that light it was interesting to note the following snippet from QCon then via Ferren Rodenas:
they don’t use stored procedures, triggers and, amazing, nor transactions (Martin Fowler is talking about this in his post Transactionless). This means that all business logic is executed by the application (sorts, joins, referential integrity, …). They use intensively prepared statements an bind variables (cached by datasources). They also scales using a rewritten connection pool and an internally developed ORM solution called DAL (Data Access Layer). All CRUD operations are executed through this infrastructure.
There is a full PDF here.
It it too particular an example to form a general pattern. Nevertheless, I would hope that the fact that eBay have chosen to use an ORM, don't use stored procs or transactions, and keep all their logic in the domain layer will make a few more people at least question the sacred cows they have around these techniques. Particularly the broad assumption that domain focused applications don't scale or are unpeformant would seem to be very questionable, because Ebay appears to be using them for the very reason that the provide better scalability. On security, I have said before that I believe the main reason why people demand stored procedures is because they want a boundary. When you cross the boundary from the application domain into the DB domain it is easy to become involved in border disputes. In an enterprise the databases are often owned outside the development team, which reinforces the notion of boundaries and uncontrolled access as tresspass. I suspect that DB teams like stored procedures because they are good fences to stop the developers roaming over their territory. They give them the feeling of control over what happens on thier 'turf'. Application developers often hate them because they find the restrictions on their freedom make it much more difficult to get thier work done. The corollary is that when a development team owns its own DB, these disputes are far less common. What we end up with though resembles a range war with free-ranging developers fighting a DB team determined to fence them in.
The sad thing here is that what the DB team are controlling is often low-value, low-risk CRUD statements. This is all that a lot of the dev teams using ORM tools are replacing. Those CRUD statements are not an area where DB devs add real value. Most are simple and mechanical. Sometimes the DB team even generate them using CodeSmith templates themselves. In that case they can't believe they really need hand optimization, so why not let the application developers 'generate' them. There are other ways to control security of your data, such as using the identity the application impersonates.
I would say to the DB devs that if you are fighting for stored procedures to fence in the application devs it namy now be time to let them roam freely across the transactional store. Move your fences to the OLAP database, That's where a smart DB Dev can use BI tools to add genuine value to the business.
3月20日 Gavin Joyce open sourcing DotNetKicksGavin Joyce has decided to open source DotNetKicks becuase of the time pressure of other commitments. He is looking for contributors to the project here. It could prove to be a really valuable community resource.
Gavin appears to be suggesting Subsonic for his ORM. I need to find some time to take a look at what the Subsonic project is up to.
New Bristol .NET user groupGood news if you live in Bristol. Guy Smith-Ferrier is setting up a new .NET User Group over there called the .NET Developer Network. Like the London .NET User Group the .NET Developer Network is free to attend. The first session is Mike Taulty talking about LINQ. Best of luck to Guy and if you live in the area, get involved.
We have a LINQ session too on the 28th so no need to pack your bags and head off to Bristol if you live in the Smoke. I can tell you now that the major difference will be that I will be taller (and fatter) and Mike will type faster. Much faster. Ratio of test code to production codeOne question that arises is how much test code should you expect to write if you are aiming to 'test everything that could possibly break'. Our experience is looking like 1 to 1.5 times the amount of production code that you have. A lot of people balk when they see this figure, but our experience is that if you hit it, the number of bugs found in any exploratory phase drops dramatically and is focused in areas where existing TDD tooling is weakest (complex event driven UIs and multi-threaded code seem to be two areas of concern). Simply put we find it difficult to exercise tests in those areas, so we expect a bug count during exploratory testing.
Personally I would focus less on using this ratio as a metric than ensuring that you keep your code coverage high and that your tests adequately prove the operations on your domain objects. Just do not be suprised if you end up writing as much test code as production code or more.
I would be interested in hearing from other TDD projects on the ratio of test code to production code they have, and how that reflects on the code coverage they have. Feel free to leave a comment. NUnit 2.4 releasedNUnit 2.4 has been released. There is a lot in this one so if you use NUnit and have not upgraded to a point release for a while, you may want to look at this one. The item that leaps out at me is the change to the Assert syntax to use the idea of constraints, similar to NMock2.
I would always recommend using your xUnit tool in conjunction with a code coverage tool. Some folks view code coverage as just another piece of output on the cruise control box to ignore (shame on you!), but I would suggest being pro-active with code-coverage tools and actively running them with your xUnit tool and at very least before commiting your changes. Reviewing your code coverage it keeps you honest, because it will pick up code that is speculative and has no tests (or code where your test cases are not doing what you expect). If you are using NUnit, NCoverExplorer is a great tool, and is baked into TestDriven.NET. MSTest also includes integrated code coverage in VS 2005.
We aim for 100% code coverage. We do not hit it because of de-testable layers (for example in web applications anything that uses the ASP.NET runtime like HTTPRequest or HTTPContext) or because they violate Michael Feather's rules on what it a unit test. The DB is a common one here, so we usually put code that talks to the DB (via an ORM or ADO.NET) behind a Repository so we can replace it with something in-memory for unit tests. We use a test double in those instances as to be able to unit test the remaining code. Some of those de-testable areas we can then pick up with integration tests, particularly around the DB, others you have to grab with tools like FIT, UI test tools (take a look at Selenium or Watir for free ones).
Interestingly my current team has few UIs and we have rolled our own test harnesses in WinForms for driving our application tests. Some of these work in a similar way to FIT - calling our application classes to do the end-to-end test - and we just found that the table driven idiom of FIT did not work well for us in that instance. In other cases it was easier to build a harness ourselves because we wanted to do something very different to what FIT offered. For example on our recent work server project one of the devs on the team built a test application that automatically submitted jobs to our store, over a specified time period. It allowed you to configure what records from a pre-populated db of test records to fill the store with. From there our work service would pick them up and the test harness also displayed the results of the work service loading those jobs. A big win of this homebrew test tool was that it enabled us to drive long-running tests of our work service.
Of course the irony is that the harness was not put together with TDD, a fact was often cursed when we needed to change it. So even those who preach can slip up in practice.
Geek Dinner at the MSDN Roadshow on 21stFor those of you attending the MSDN roadshow tomorrow we will be holding a Geek Dinner afterwards. Zi has the details on a wiki, so add your self to the list.
For those of you who will be there tomorrow, see you then. It should be good. 3月18日 Misuse of the term refactoringThis one keeps annoying me. Having done linguistics in my first degree I should know all about the futility of trying to fix the meaning of words, however I hear a lot of developers using the term refactoring without really understanding what it means. Refactoring is changing the implementation of a class without changing its behavior. You cannot refactor without testing because you need to check that when you change the implementation the behavior remains consistent. Automated tests, particularly those provided by test-driven development are the key to refactoring being a low-risk operation, because they continue to confirm the behavior of your classes as you refactor them. Refactoring consists of small steps, which are individually safe in the presence of tests, that lead to a bigger whole. Refactoring is documented by Fowler in his book of the same name. Tool support tends to focus on automating some of these small changes. When you set off to change the behavior of parts of your application, or work without the support of automated tests, or work in large chunks you are not refactoring you are re-writing. Your risk is proportionally high not low. So when you tell your team lead or project manager that you want to do some refactoring in that context, you are being misleading. Automated testing is vital and it is a key benefit of test-driven design that you will have tests to support refactorings 'as you go' thus making your application amenable to low-risk improvement thus preventing software rot. Anyone who has worked on a legacy project (where legacy == no automated tests) knows the pain of never being certain what the impact of even small implementation changes is, such as bug fixes, and how the effect of that is to make applications brittle.
Technorati tags: Refactoring, Test-Driven Development 3月15日 Meeting the CodeBetter crewOne of the best aspects of the MVP Summit for me was the chance to meet with people who are outside of my normal circle. Meeting the CodeBetter gang was great. If you don't subscribe to the CodeBetter feed you really should. The bloggers there are commited to improving the practice of .NET developers and are passionate about communicating those ideas. If ideas like agile, test driven development, and domain driven design mean anything to you, you should look to what those guys are saying, if those terms don't you need to go there even more. I spent a lot of time getting validation about the way I feel about development in conversation with Jeremy Miller and Raymond Lewallen, and got the chance to meet Sam Gentile, Scott Bellware and Jeffrey Palermo among others. Being on opposite sides of the pond it is re-assuring to know that we are working in similar ways and using similar toolsets. Having fought a few struggles over ORM tools in my time it was interesting to see many of the guys were using NHibernate and Wilson O/R mapper for their persistance technologies too, and were commited to a POCO persistance ignorance approach. I picked up on couple of tools that had not crossed my radar from these guys, in particular Jeremy's Structure Mapper and a new Castle project called Igloo. Besides being able to read about the dialog between MVPs and the LINQ teams over our preferred approach also check out Jeremy's post which is a manifesto for continuous learning from other communities. The pragmatic programmers make a similar point in their book. The pragmatic guys suggest planning on spending 4-5 hours a week on improving your skills and learning another language a year to broaden your horizons. [BTW looks like the pragmatic guys are talking about Erlang at the moment, which tries to answer issues around concurrent programming, and seeing as those guys also predicted the wave of interest in Ruby it could well be worth looking at the ideas there]. Think of this as going to the gym for software developers. If you don't keep working out, you are going to get fat and slow, instead of staying lean and mean. I'll be posting some ideas about how to use LINQ for SQL from the POCO persistance ignorance perspective in the coming weeks, as I try to formulate my ideas on best practice in that arena. 3月12日 Party with PalermoLast night was Party with Palermo here at the MVP Summit and was a great chance to catch up with a lot of the other MVPs here such as Craig Murphy, Simon Sabin, Dave McMahon, and Richard Costall. We shot some pool, drank some beer, and got into the summit spirit. While I was meeting a colleague here it appears that the NextGenUG boys took the Duck tour here in Seattle yesterday. You can watch their adventures here. If you are a fan of the ReadyBoost song I suggest you check it out. 3月7日 March 28th: London .NET user group: An evening with LINQAn evening with LINQ
-------------------------- In these two presentations we will show you how the forthcoming LINQ technology stack in C# 3.0 will change the way you program. LINQ will change how you write queries for ever
--------------------------------------------------------- In this presentation we show you how you can use LINQ to query data in a type safe and elegant manner. We will look both at in-memory query expressions and LINQ for SQL and LINQ for XML. We will not be covering the new language features of C# 3.0 in depth, but will have brief explanation where they help explain what we are doing. The focus instead is on writing query expressions. Next generation data access
---------------------------------- It seems that MS like to change how we access our data on a regular basis. This presentation will look at the forthecoming changes in LINQ for SQL and LINQ to entities and how the new data access approach build on but are radically different from the old world of SqlCommand. We will also look at how you should be using these new technologies and how they fit with practices like domain driven design and test-driven development. About the speaker:
Ian Cooper has over 15 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group. http://www.dnug.org.uk 3月1日 The March CTP of Orcas is outThe March CTP of Orcas is out, both as a Virtual PC Image and as self-extracting download. For those of you wanting to get the heads up on technologies like LINQ I'm told that this should be the one that you will want to use over the May CTP of LINQ and the August CTP of ADO.NET vNext. This version includes the 'Cider' IDE enhancements for WPF, improved WCF and WF support, so while the C# 3.0 LINQ and ADO.NET changes are grabbing my attention there is a lot for other folks in there too who are less 'graphically challenged' than myself.
Let's hammer those servers people.
|
|
|
