An upsert is an operation where rows in the database are updated if they exists and inserted if they don't. This has been available as a replace statement in MySQL for quite some time. At first glance the merge seems much more cumbersome to use than the replace, but don't be fooled by this. One problem I've had with the replace command is knowing exactly what rows will be updated and which will be added. Especially when updating things that are part of a multi-column primary key. The merge however is really more clear in what it actually does and you have full control of what you update and what you insert.
Version 1.0 of xUnit.net has been released. So do we need another unit test framework? And I think the answer is yes. There are a number of things that I've found a little bit weird in NUnit and with xUnit.net they have been removed. I definitely think that you should take a closer look at why xUnit.net was written and the comparison with other unit test frameworks. xUnit.net definitely feels like a new fresh wind in the TDD/BDD toolbox.
Fun to see more and more people say this. In a typical development project there are three variables to play with; you can deliver at a certain date, with a certain level of quality or a with a certain number of features. You can guarantee two of these but never all three. Pricing comes into the picture since pricing generally limits the number of hours that can be put into the project. So adding money may shorten the calendar time it takes to complete the project or it increases quality and/or the number of features that can be implemented. Fixed price often goes hand in hand with fixed date but it does not have to be that way. And trading off quality is a big no-no I think since it will backfire.
So the only thing the customer really has to play with is price or features. Either you pay for all you want or you cut the number of features. Think of it as choosing restaurant for lunch. If you really want a steak you have to pay for a steak, but if you only want to spend one dollar you're suck with a taco I guess...
Here's another article on the subject.
As many before me I was recently looking at different mocking frameworks in order to find one that suited my needs, and was written in C++. And there are not many alternatives out there if you're using C++. I've found one open source and two internal (Microsoft staff can access what can be described as an internal codeplex) ones. Pretty soon it turned out that none of these frameworks did what I wanted. Actually they suggested using no framework at all for the situations I was looking to "solve" with a framework.
At this point I rediscovered an old article by Martin Fowler and it became crystal clear that the reason I didn't find what I wanted in the mocking frameworks was because I really wanted a stub framework (or rather a stub helper). Because what I wanted was a simple way to reuse the algorithm "return 17 the first 7 times called and then throw an exception after that, unless called with argument 4711 in which case you should always return 42". A pretty simple method to write in your stub if you just subclass and override the object you want to mock/stub but a little bit cumbersome in the long run if you do this a lot.
During a discussion on a company internal mailing list for TDD it became clear that people generally use the term mock object for almost every kind of non-production object used during testing. And when another large group do make the distinction between mocks, stubs, fakes and dummies you quickly run into trouble since you are no longer discussing the same thing. So here is yet another recap on what the different kinds of objects are so I can contribute to the cause, making world a better place to be. At least when talking about mocks & friends.
An alternative title could have been "why unsponsored open source never work" but since sponsored open source sometimes don't work very well either, I didn't want to exclude sponsored open source from this post.
Over the years I've had to work with a number of open source projects. Both sponsored and unsponsored. With sponsored I mean a project where there is a company driving the development and making sure the project progresses and produce good results. An unsponsored project is when a number of volunteers drive the development of the project. I guess most open source projects are unsponsored as in there is no company making business decisions on what features to support.
And that is usually where everything goes wrong in my humble opinion. Because there are is no business involved the most advanced features and the most complex bugs almost never get fixed because if you're developing in your spare time you will concentrate on the fun stuff, not the boring obscure bugs someone has filed. And this is the experience I have from several projects (where wxWidgets and geeklog are is just two examples). A well documented and used-by-many open source projects usually covers about 99% of my needs. And I've often chosen the open source because it really adds value and is easy to use. But always, always there is this last percent it does not cover.
And this is when I run into trouble because the last percent of functionality I need, and that isn't in there, I discover quite late and there is no way I can defend the decision to change the decision so I'm stuck with what I got. And now I have to start working around the missing functionality or I have to rethink my solution so that I do not need that last percent of functionality. Neither option is very appealing to me since both include a lot of work and the reason for using the open source in the first place is to save me some time.
OK so now we all hopefully agree that almost all open source projects have missing functionality (or bugs) that you need fixed in order to continue working. So why don't I just fix the things I need in the open source and contribute it back to the open source community? Well first of all I have contributed fixes to various open source communities. I'm glad to do that whenever possible but most of the time I'm unable to do that. The reason I'm unable to contribute back is that it would take me more time to understand how the open source project works internally than it takes me to work around the problem. Remember that I typically use open source in order to reduce how much I have to work. So when I have to work around some missing functionality, I want to do it as quickly as possible. And most open source projects I've been in contact with have been pretty hard to get familiar with when I start looking at internal stuff of the project. A nice clean, well documented interface sometimes covers something that takes lots of time to understand.
Preemptive comment: So how much open source does Microsoft use internally? Well I don't know. Each use of open source in each project have to be cleared by lawyers and since that takes time I guess developers at Microsoft tend to not use open source very much.
In the last year or so, Scrum has become very popular and people are trying to apply it left and right. I don't know if it is Scrum but the number of projects that are trying to use agile methodology have exploded in the last one or two years. And there is a problem with this. Many projects that "start being agile" are not agile at all.
For example: imagine you're working on a project where you used to develop for 4 months and then test for 2 months and then prepare a release for one month. Your boss have heard that agile increases productivity and you start having 3 week iterations; 2 weeks of development, one week of test and prepare a release for one week. Instantly you see productivity drop 50%. And the reason is that you have just chopped up your regular work in smaller chunks and the productivity feels like it drops because you now do 3 weeks of work in 5 weeks.
The problem with agile is that you need to understand it fully before you can implement it correctly. And this applies to the large picture (Scrum, XP) and the small picture (TDD, Daily stand-ups) - if you do not understand the purpose, you will probably do it wrong. Agile methods like Scrum will act as an catalyst helping you understand what all the building blocks are but you will still need to understand the purpose in order to be successful.
Then we have another problem; Agile methods, especially when applied as a bundled concept like Scrum may not fit every organization. For example I heard that one company I've previously helped start using Scrum (and I think I was successful since more and more of their development teams are using Scrum even without my help) are now trying to apply Scrum to the marketing team. I'm sure their marketing team will have benefit from some of the parts suggested in Scrum but if they try to force all their work into a Scrum-like cycle I think they will need a really, really good coach to get it right.
Yet another problem with applying agile is that it will probably be a big change in how you work and I know many developers who don't like change. These developers will try to resist and see all the problems with the new methodology and you will be working upstream in order to get them aboard. And I think there is an easier way to do it.
So where do I start?
There are several books you can read in order to prepare your self and try to not fall into the same pits as everyone else before you. Think that will be a future post... I have come to the conclusion that applying agile in small steps are probably the easiest way to do it. If you're going to apply agile in tiny steps I think this is the way to do it:
Thats it... If you do those two things correctly you will successfully implement agile into your team. If you think my list is to short you can always look at this Scrum checklist. But what about iterations? I mentioned that you should have retrospects after each iteration but that is not on the list... Well iterations are not needed to have retrospects. Just have your retrospects at a regular interval and I suggest no more than four weeks apart in the beginning. The longer the period between the retrospects the more problems will the team see and the slower change will be because after each retrospect the process used by the team will improve. If you want really quick changes in the process you should have a retrospect each week. Also iterations gives you the power of closure which should not be forgotten but if I have to choose between iterations and daily stand-ups or retrospects - iterations come in last. Also there is no point in making the list any longer because the last item, respect retrospects will over time have you implement all other good things than are considered agile.
Finally I think there is one more thing you should do in order to quickly become successful with applying agile. Get a coach! Maybe that should be the only item on my list because everything else will come over time with help of a good coach. I did not put it on my two item list because I know many teams will not have the opportunity to hire a coach. But if your retrospective shows the team wants a coach - you should get one. If your organization does not allow you to hire an agile coach there are two other things you can do; Ask around on agile forums or get someone from outside the team come and listen to your daily stand-ups and retrospects. This person will look at the process from the outside and may in many cases come up with a few new ideas on how to improve that you have not yet thought about. This person from the outside may also say things that the team is afraid to say. This will also bring problems to the surface.
Preemptive comment: How does Microsoft do Agile? Well Microsoft Research have one report you can read. And I will also come back to this subject in later posts on this blog.
When I wrote my master's thesis was the first time I came in to contact with VC++ and MFC. I worked with MFC and VC++ quite a lot for a number of years but the last four or five years have not had much MFC work in it. When the .Net framework came along with the possibility to write managed C++ applications I thought MFC was dead and didn't give it much more thought.
Then I read about the new VC++2008 feature pack here and watched the channel 9 video referenced. I noticed how the reporter also questions the MFC developer about the presumed death of MFC. Apparently MFC is not dead as many, including me, thought. The reason I thought so was that I just assumed that with managed C++ no one would bother writing them unmanaged in MFC any more. But when I think a little more about it I guess there are lots of people still out there who are familiar with the MFC framework and who do not have the time and/or interest to learn the new managed equivalents.
Some might say that you want to write MFC applications in stead of managed ones because the users do not have the .Net framework installed. A fair point but frankly I do not think that the user that will benefit from this MFC update (which for example includes office ribbon support for office 2007) also already have the .Net framework installed.
Update: I noticed that this post was referenced by this one: http://blog.stevienova.com/2008/04/12/why-is-mfc-not-dead/. I realized I was not 100% clear in my post. I must say that I agree with the author of that post - MFC will be used for many years for the reasons mentioned: People want to make applications that work across many different versions of Windows without installing the .Net framework. There was never a doubt in my mind that was the case. However I was surprised there was so much new development put into new versions of MFC since I guess all the new stuff will not work very well anyway. And much of the new stuff in MFC is there to mimic stuff seen in the managed framework and/or in latest versions of office/windows. And if you run Vista or Server 2008 I guess you will have the .net framework already installed and hence do not need to use MFC.
I almost forgot that before the BDD/DDD presentation, there was a presentation about Selenium. I didn't forget it because it was a bad presentation but because the following presentation was so good...
I've never had any good experiences with tools for automatic testing but I must confess that Selenium looks nice. At least if you want to add regression tests to an existing GUI. And it is a web based GUI. So if those two fact apply to you, you should take a look at Selenium I think.
Selenium is good at recording actions and create test code. And it creates test code for unit tests frameworks such as NUnit and a whole bunch of other languages such as Python, Java, Ruby, PHP and more. However there seems to be some stability problems at the moment. According to the presenter (I have not found a link to verify this); Google have more than 51000 selenium tests in their projects. 96% of the tests run with no problem, 2% have problems due to confirmed bugs in Selenium and the last 2% are tests failing where the reason is unclear (Selenium vs the code tested).
This is a common problem I see when I work with open source. Open source applications are typically quite useful and easy to use 99% of the time. But I always tend to end up needing the last percent which is never implemented or have bugs. And the reason for this is usually that no one have bothered to implement the last tricky advanced feature I end up needing. You probably wanna know why I do not sit down and implement that feature and contribute it back to the open source community. Well that is a whole other topic and I will write about that it the near future.
I've previously written about BDD (in Swedish) and maybe I should translate some of those articles since I've now decided to start writing in English. Anyhow, last night I had the chance to listen to Dan North on the topic: How does DDD and BDD relate? This was the first time I've listened to Dan live and I must say I was surprised - in a good way.
First of all he have that special British humor we tend to like in Sweden. Secondly he was very pragmatic in his thoughts about different theories and how (and why) they should be implemented. Another thing I like since agile evangelists (not saying Dan is an evangelist but...) tend to be less pragmatic than what is healthy for them and their theories.
First part was about describing DDD. I must confess that I've had some troubles understanding what all the fuzz has been all about when it comes to DDD since domain driven design always have been quite obvious to me. That was until this evening. Dan pointed out that there are a lot more domains to consider than even the traditional DDD-evangelists talk about and I think this was an important point. As was the point that some of the domains might be technology related. One interesting trick of the trade I learned where: If some domain is not interesting to one person - it is a domain interesting to someone else. Example: End users don't care about implementation platform - hence it is a domain important to someone else.
Then started a short presentation of BDD. And now it got interesting since I've had a few discussions with other people and I'm a firm believer that BDD is TDD done right. I still agree that TDD is a bad name for Example Driven Development or whatever you want to call it and I have always felt a little uncomfortable with how BDD is often presented, i.e. as something new. I'd rather like to see BDD as a coaching aid in order to explain TDD. But since TDD is such a bad name I'm happy to use BDD since it better describes how I think TDD should be practiced. The good thing is that I don't feel Dan said anything contradicting my beliefs. If anything the opposite, I feel my view on BDD is the same as Dan's which at least makes me feel good when I talk to people about BDD.
So what was the conclusion of the presentation? Well, DDD is about design and DDD helps you design the vocabulary you should use. BDD helps you develop the correct behavior. Together they are a better tool than each of them alone.