Since I moved to Redmond I've been looking for a regular coding dojo in this area but I've not been able to find one. So I first planned a number of team dojos in my team but I felt that was not enough. I think an important part of each dojo session is to meet other people and learn their TDD tricks. So since I couldn't find any dojo in the area I planned one myself and invited people on one of the internal mailing lists (also set up a separate internal mailing list for the dojo). I thought Microsoft would have more than enough people to be interested in attending coding dojos.
So yesterday was the first dojo session I arranged open to all Microsoft employees. We did the kata I'm most familiar with: MineSweeper. For the first time we tried to build parts rather than stick to the end-to-end type of tests. It was an interesting experience and we got further toward a complete solution than I've ever seen myself. Not sure it was just because we approached the problem slightly different or the fact that the group was fairly small. The important part is that I got to learn a few small tricks and I'm pretty sure others learned some tricks too.
So now I just have to plan the next session...
Thought it was time to combine my old favorite subject (SQL) with a new interest (TDD). So how do you test drive your SQL? I think the first answer is you don't. The database is typically something you want to fake anyway since setting up and accessing the database is to slow when you want rapid feedback. Nowadays when things like NHibernate are popular I think most people don't write much SQL anyway so there is no need to test drive the creation of SQL queries or stored procedures. But there was a time when many applications kept a lot of logic in the stored procedures and in those systems it might make some sense. Also we have the fact that the database needs to be created some way. Why not test drive the database schema?
So even though this might not be the hottest topic on the block, what alternatives do we have? First of all we have SQLUnit. This project does not seem to have been updated for several years. Guess that is because we don't put all application logic in stored procedures any more. But it is at least an attempt to create a unit test framework for SQL. But why use the same language for the tests as the implementation? Some people think this is OK but I think there is also a danger in doing so. Switching languages typically makes you do small stupid mistakes you don't do if you stick to one language. But sometimes it might still be worth it. For example I'd much rather use any .Net based unit test framework over SQLUnit and an example of how that looks can be found here.
Then there is of course the option of not using any framework at all. Creating your own framework may be the most efficient way of doing things and an example of database creation in a test driven manner without any fancy frameworks can be found here.
You've probably heard a thousand times that a good variable name describes what it is. Some people also thinks that the shorter the scope of the variable, the shorter should the name be. That was maybe true if you write the name out by hand but I think the best (and only) rule of thumb is that the name should be easy to read and describe what it represents. But sometimes it is hard coming up with a good name so what do you do? In the past a did my best to come up with something good but if it is hard to come up with the name, whatever name you come up with will not be that good. But from now on I'll do another thing I read about here. It is embarrassing how obvious the solution is. In TDD you make minimal changes until you have enough code to see the obvious refactorings needed. And the same thing applies to variable names. If it's not obvious at the moment what a variable should be called, just call it something and move on. A few TDD cycles later you'll probably know what a good name for that variable is and you refactor it then. So don't waste time trying to come up with good variable names. Move on and refactor later when it is obvious!
The good thing about this strategy is that it applies not only to variable names. It works great on all types of names in your code; methods, classes, constants and so on. And yes, I'm assuming you have a refactoring tool that let's you change these names securely and you don't have to do a search and replace that might be a little more dangerous if all your I-don't-know-the-name-yet variables are called "x"...
If you liked the more or less humorus Scrum Bestiary then you might like the Consultant Bestiary. Personally I've been a duck most of the time I worked as a consultant but sometimes a was seal.
There is a very funny introduction to F# available here. So if you want an introduction to F# and/or a few laughs you should watch it.
I recently needed to move all my private domains to a new hosting solution and the new solution did not allow any other access than FTP. I considered setting up a mirror on my ubuntu host at home but that didn't feel like the best solution. So I thought there must be a way to mount a file system using FTP. And there is several I think. The one I tested and that looks good so far is curlftpfs. The only tweak not mentioned on the curlftpfs site (in an obvious place) is that you need to put the following in your /etc/fstab to make sure all users (and not just root) have access to the mounted file system:
curlftpfs#ftp-user:ftp-password@ftp-host /mount/point fuse rw,uid=500,user,allow_other,noauto 0 0
"allow_other" is the magic enabling all users access. Since it uses FTP under the hood you will notice the file system is quite slow at times. Especially when editing large files. But compared with having a local mirror and updating all changed files when needed I think this a pretty convenient way to access the files on the FTP server.
If you're negotiating with a customer over a contract for something and you want to be agile I think one of your hardest problems probably is to convince the customer of the value of an agile development process. Because you don't really want to be negotiating, right? And most customers want a fixed price so they know how much money they'll spend at most. I think this compilation of contract variants is great since it helps you (and your customer) to compare different types of contracts/collaboration. The most interesting is of cause the "Money for nothing - changes for free" contract (more on it here). What it essentially means is that the supplier estimates the initial work just as if it was a fixed price contract. That price is the target price. Rules for what happens if the target is exceeded may vary but that is not really something new. The interesting part is that if the project is canceled prematurely the supplier gets some percentage of the remaining sum without doing anything. And the customer may change everything and nothing at will (change for free) during the project. The idea is that if enough customer value is delivered early then the project ends early. This is good for the supplier since there is money for nothing. And the customer gets maximum value in shortest time probably also cheaper since the project can be canceled whenever the customer is happy enough. Because we all know that a fixed price or cost ceiling in reality means the same thing. So even if the customer pays "money for nothing" it is still better than paying for things you don't really want...
One thing that struck me as kind of odd when I first started to look at PowerShell and how to include other script files in order to gain access to functions in that other script is that all examples I found use an absolute path to include scripts (ex: ". C:\Some\Path\Script.ps1"). At least for me, using absolute paths is never good so I tried a relative path like this: ".\Script.ps1"
The result is no errors running the script but no functions from the script are defined outside the script. ". Script.ps1" is even worse since it does not even execute the script. What you have to do is this: ". .\Script.ps1"
Remember to use "double dots" with space between them! And I cannot understand why all tutorials I found use the absolute path approach since relative inclusion is much more likely to work.