Archive for the ‘altdotnet’ tag
The first thing to say is thanks to James and Richard for getting this setup so quickly – it was less than a month ago that Richard suggested the idea of creating a group on the Alt.NET mailing list.
The meeting was split into three parts with a retrospective on proceedings at the end:
Richard opened the meeting by talking about some of the latest news in the .NET community in the last month or so.
I thought this worked very well and helped to get some discussion going very early on. One of my comments from the London Alt.NET Conference was that very few people seemed to get involved – that certainly wasn’t the case last night and there was a very collaborative feel about the whole event.
The first news was that the much talked about jQuery is going to ship with ASP.NET MVC and Visual Studio and that Microsoft intend to provide Product Support Services for it and contribute any changes they make to it back into the community. It was suggested that this is a bit strange as jQuery is effectively a competitor to Silverlight – Microsoft’s plugin for developing rich applications for the web. Apparently Nokia are also intending to get involved.
Another thing which I hadn’t heard about was the DevSta coding competition which was mentioned at Tech Ed earlier in the year. I haven’t read exactly what the competition is all about but you get 200 hours and 8 minutes to prove your skills with Visual Studio 2008. The challenge is here for those that are interested.
Richard also pointed out some open source projects which I hadn’t come across, notably CloneDetectiveVS – a duplicate code finder plugin for Visual Studio – and SnippetDesigner – another plugin to create code snippets. Not sure how different this would be to Resharper’s code templates but it’s another option.
A new language which runs on the CLR called Cobra was mentioned. It has support for contracts and testing so it could be a contender – probably needs someone high profile to run with it for that to happen I would imagine.
gocosmos was also discussed – an operating system project implemented completely in CIL compliant languages.
Ruby and Rails From a .NET Perspective
James opened the second half of the evening with a talk about using Ruby in the world of .NET.
He opened with a brief history of the Ruby language going through some of the ideas that Ruby brings to the table – principle of least surprise being the most intriguing one to me – before covering some of the Ruby compilers currently available – MRI, YARV JRuby and IronRuby. The last one was the focus for the talk – being a .NET implementation of the Ruby language.
James went through some demos using the Interactive IronRuby Console to start with but later showing how to create a simple application using Rails.
There was an interesting discussion around testing – James pointed out that the Ruby/Rails world is much more test focused than the .NET one and unit testing is available right out the box.
I haven’t worked with Ruby enough to know if everyone in the Ruby world unit tests but as a general feeling I would say this is probably accurate.
RSpec was covered briefly as an alternative to the Test::Unit framework that comes baked in with Rails. I haven’t played around with it before but as I’m working a bit in the world of Ruby at the moment it is something that I hope to use in the near future.
Finally build and deployment tools from the Ruby world such as Capistrano and Rake were mentioned. I can see the latter having some influence but as the former is meant for Unix I can’t see it being heavily used in the .NET world.
Richard closed the evening with a presentation on Rhino Mocks.
I went into this presentation with the belief that Moq was the way to go when it comes to .NET mocking frameworks.
The Arrange Act Assert or Mockito approach to mocking is one which makes it much easier to do and leads to far less clutter in tests.
Richard gave a demonstration on several of the ways that you can use Rhino Mocks in your testing efforts – covering simple interaction testing, event testing and several other clever techniques that Rhino Mocks allows.
An interesting statement was made that ‘Mocking = Genuine Unit Testing’, a statement that I tend to agree with. Several people mentioned that they now realised their unit tests were actually functional tests – this is a problem which mocking can help to reduce.
Overall it was again interesting to meet up with the .NET crowd and hear the different ways that people are doing – I was impressed with the turn out given the short notice – there were over 30 people in attendance.
The next meeting is on 28th October 2008, ThoughtWorks Sydney Office, 51 Pitt Street again.
I spent most of yesterday at the 2nd Alt.NET UK conference at Conway Hall in London.
It was again run using the open spaces format and we started with an interesting discussion on what Alt.NET actually is. There’s been quite a bit of discussion in the blogosphere and everyone seemed to have a slightly different opinion – for me it’s a group of people who are interested in improving how they work in .NET. Ian Cooper pointed out the Foundations of Programming e-book as something concrete which has been released regarding what Alt.NET actually is.
The day was again split into four streams – I stuck to the more general software development oriented discussions.
Ian Cooper raised an interesting idea around the discussion of estimates – he suggested getting the person with the highest and lowest estimates to explain why they had given that estimate to help bring out the different assumptions that people were making regarding the story.
He also spoke about his use of Alistair Cockburn’s Crystal methodology which advocates a 3 phase approach to development whereby you start with the skeleton of the system early on and gradually fill it out in future iterations. I have read a little bit of the book but never used it myself so it was interesting to hear a practical experience.
The idea of only releasing software when it is actually needed rather than at frequent 2 week intervals regardless was also raised but from what I’ve seen on my projects when there are releases it is because the software is needed by the users. I think this is more a case of pragmatically using the methodology rather than sticking to precise rules.
A lot of the focus in this session was around how we can improve the communication between BAs, QAs and Developers when it comes to writing acceptance criteria.
Gojko Adzic suggested the idea of having an Acceptance Testing 3-Some before a story is played so that these tests can be written with all opinions taken into account. The idea here was that the tests written would be more accurate and hopefully reduce the problem of having to go back and change them later on.
While this idea seems good I am more of the opinion that we should just go with the acceptance tests that the QA writes, implement those, then check with the business whether everything is covered. The feedback loop in this approach is much shorter and as the key to software development for me is getting frequent feedback I prefer this approach. This is certainly the way we have done things on the ThoughtWorks projects I’ve been a part of. Requirements by Collaboration was pointed out as being a good book to read with regards to getting everyone involved in the process.
The idea of having a ubiquitous language that everyone in the team used to describe acceptance tests was another good idea that came out of discussions – although I think if a team is developing software using a Domain Driven approach then this is likely to happen anyway.
A large part of the session focused on UI tests and the problems people experienced with regards to brittleness and long running time. One way to get around this is clearly not to have so many tests at this level – one idea was to only have automated UI level tests for critical scenarios e.g. logging into the system and then manual test other scenarios.
One way we have got around this on the projects I’ve worked on is by having a level of tests one level down which test component interaction separate from the UI – typically called functional tests. These could be used to test things such as NHibernate logic rather than doing this through the UI. We would also look to keep minimal logic in the presentation layer as this is the most difficult part of systems to get automated tests around.
TextTest was mentioned as being an acceptance testing tool which tested the system by going through the log files. This has the added benefit of forcing you to write more useful logging code. Green Pepper was also mentioned as a useful way of using acceptance tests which link together Jira and Confluence.
Domain Driven Design
The discussion (perhaps not surprisingly) focused on the concepts described in Eric Evans’ book.
The value of having rich domain objects with the business logic inside was questioned with Ian Cooper pointing out that business logic need not necessarily be business rules but could also describe the way that we traverse the object graph. In particular the Law of Demeter was discussed as a way of avoiding an anaemic domain model.
The problem of designing from the database upwards resulting in these anaemic objects was raised – one potential solution being driving the design from acceptance tests i.e. top down.
Ian Cooper pointed out that coding in a Domain Driven way with lots of plain C# objects made testing much easier. I think in general keeping the behaviour and data together in an object makes it easy to test. Doing this using a Domain Driven approach just makes it even easier to use the code as a communication mechanism.
There was also discussion around the use of Data Transfer Objects, with the general consensus being that using DTOs was good around the UI to save you having to deal with incomplete domain objects around these areas.
The idea of the UI being outside the bounded context that our domain model is used in was also suggested which strikes me as a good idea – would be good to see it done in practice though.
It was suggested that DDD is only useful in complex domains. I think this is true to an extent but some some of the ideas of DDD are just good software development principles such as having a common/ubiquitous language in the team. Ideas such as bounded context are clearly only necessary when there is a greater level of complexity.
I would certainly recommend picking up a copy of the book – 90% of what was discussed is in there.
This was the most interactive session I attended and the majority of the people in the room were able to offer their opinions which I thought was much more aligned with the spirit of the open spaces format.
The discussion focused on how the environment that you’re working in influences your enthusiasm for learning new technologies and new ways of doing things. I am lucky in that working for ThoughtWorks I have colleagues who are very enthusiastic about technology and encouraging other people to learn.
The Ruby community was pointed out as one where there appears to be much more enthusiasm than there is in the .NET world. I’m not sure how exactly we can measure this but blogging wise the Ruby guys definitely have the edge. I think some of this can be explained that people who ran with Ruby early on are massive technology enthusiasts and you’re unlikely to start working with Ruby because you have to – it normally starts out for the love of the language from my experience.
A suggestion was made that holding Brown Bag sessions at lunch time where people could share their learnings with colleagues was a good way of helping to share knowledge. This is certainly an idea that we use frequently at ThoughtWorks and there is actually even more value in the conversations which come afterwards.
The Google idea of 20 % time to dedicate to your own learning was raised as being ideal, although it was pointed out that this was a hard thing to implement as getting things done always takes precedence.
It was an interesting day and it’s always good to hear the experiences of other people outside of ThoughtWorks.
I think we need to try and find a way that more people can get involved because most of the sessions I attended were very dominated by a few people who had great knowledge on the subject. While it is no doubt very useful to hear their opinions I think it would be even better if more people could get to speak.
I’ve had the opportunity to have worked with many different people pair programming wise over the last year or so, and having seen it done in several different ways thought it would be interesting to work through some of my thoughts about this Extreme Programming (XP) originated practice.
First of all it seems to me that pair programming is a technique that is used with a lot more frequency at ThoughtWorks than at any other IT organisation.
Obviously I do not know every IT organisation in the world, but based on discussions at the ALT.NET UK conference I went to last weekend; it certainly came across to me like that. The difficulty in getting clients and/or management to see the value in having two people on one machine was the main factor mentioned as proving problematic.
I have been working for ThoughtWorks for 18 months now and have been pairing for all but 3 of those months. Perhaps contrary to popular opinion, not every project is a 100% pairing one.
I’ve paired with people for 20-30 days at a time, paired with people for 1 day at a time, paired with people who have been pairing for years, paired with people who are pairing for the first time, and all in all it’s been fun.
I now find writing code far more enjoyable when working with someone else, motivated by the opportunity to bounce ideas around and come up with better solutions.
The biggest benefit for me of pairing is that you have to vocalise your ideas to your pair. This massively reduces the chance of going down a dead alley as a ‘wrong’ idea would have to somehow make sense to two people, which is much less likely to happen.
Equally, when done well, you end up thinking a lot more about why you are doing things e.g. why should that method go on this class, should we introduce a new service, why are we testing it in this way, should we be testing it another way etc.
On the flip side there are times when you just want to look up something which interests you but isn’t totally relevant to the current task and that has to be placed on the backburner for the time being. Pairing can also prove very tedious when doing fairly trivial tasks such as changing configuration files; although of course it does help if every knows how to do this so pairing on these tasks does provide some benefit.
I will cover some of my other thoughts in future posts.