Consider the following code :

        [Test]

        public void StringFormatEqualsTest()

        {

            string firstString = string.Format(“{0}”, “test”);

            string secondString = string.Format(“{0}”, “test”);

            Assert.AreNotEqual(firstString, secondString); //test passes

        }

        [Test]

        public void StringEqualsTest()

        {

            string firstString = “test”;

            string secondString = “test”;

            Assert.AreNotEqual(firstString, secondString); //test fails

        }

Why does the first test (StringFormatEquals) pass ? In my opinion it shouldn’t. I raised a bug report on the mbunit site.

This behaviour doesn’t exist in nunit.  I’m just putting it out there because you do want your tests to reflect the thruth :).

How exciting.. we’ve been planning this for a while but now we can publically announce that code camp registrations are open.

Our next code camp will be the sunday before TechEd and we will be running it in one of the larger TechEd conference rooms.

Hurry to http://www.codecamp.net.nz for registrations and more details.

I know that we’ve got an impressive list of speakers.

Hope to see you there !!!

Whenever I’m faced with a bunch of legacy code that I would like to write unit tests for I get quickly demotivated because I know the code works but still i’d love to know if the code will still work after I’ve been working on it.

Lately I’ve been faced with a lot of legacy code so I decided to make a little tool that does the same as what VSTS testing does when you select generate unit tests.

I haven’t made an add in yet, it’s just a little winforms app I started it this afternoon and i have something working now. It’s also one of my very first winform apps so things have a lot fo room for improving.

I’m open for suggestions and i decided to open source it so if you have a fix or would like to make it a better tool let me know and I’ll add you to the list of contributors

You can find the tool @ my subversion repo:  https://svn.koolkraft.net/test_generator/trunk

I know that it’s against the rules of TDD to do this stuff but i just want to save some time by generating stubs that don’t actually do anything except setup objects and initial values

Let me know what you think :)

We had another lunch session yesterday. It was a quiet session probably because of the Wellington weather, there were 7 people attending.

The first topic we discussed was mobilizing your application.

The first issue that was raised around this subject what usability issues have you got to tackle around mobile applications.  Like navigation should be vastly different because of the lack of screen real estate. navigation is mostly done with a joystick or keypad there is no mouse which in itself is already a pretty difficult problem to tackle. 

Another person mentioned that dropdownlists are pretty difficult to navigate too.  It would be naive to assume that you can use one codebase and make some style changes to get a great mobile application.  You need to take the fact of mobilizing more serious than that and be prepared to make some drastic changes in how your app flows.

One of the reasons that we haven’t really seen a great mobile app make it big is probably because of the user interface we are facing when operating a mobile device. Technology has changed a lot since mobile phones came to be but the interface hasn’t hardly changed at all. It went from a disc to buttons to buttons with a little display. Until the cell phone was there and we got a menu to operate our phones. The navigation of those menus has evolved somewhat but it’s still the same way of using it. Of course this is when the iPhone came into the conversation, and because I work at Xero i got to play briefly with an iPhone

I have to say that the touch screen navigation was really cool and refreshing and definitely a step in the right direction.

After which our conversation drifted off a little and we dreamt of futuristic interfaces and new ways of interacting with computers.

Simone has got a great post on life in wellington as a european in which he talks about our lunches and other things.

I moved my blog to be on webhost4life.com

I’m also changing blogging engines and announcing that I will stop development on nblogr.

NBlogr was almost ready for a v1 release but it has too big of a memory footprint. The footprint is 70MB which is too much for a blog.

To fix this I would have to change my data access layer to a different approach.  I decided instead to switch to subtext and I’ll see which features I can provide from nblogr for subtext as plugins. I also don’t have the time anymore to occupy myself with nblogr.

The feed should remain working without a change. I upgraded my blog to subtext using Ayende’s instructions

Which means that the permalinks should still work but urls that contain a guid won’t work anymore.

The reason for moving from dasblog to subtext are the same as why i started nblogr in the first place. Dasblog has been nothing but a hassle for me. It is often down, does only trackbacks to my own domain, and many more annoyances.

Rowan Simpson: http://rowansimpson.com/2007/07/04/c-vs-vbnet/

Andrew Peters: http://andrewpeters.net/2007/07/03/73/

Alex James: http://www.base4.net/blog.aspx?ID=515 and http://www.base4.net/blog.aspx?ID=520

Nick Randolph: http://community.softteq.com/blogs/nick/archive/2007/07/03/languages-only-part-of-the-equation.aspx

Alex Henderson: http://blog.bittercoder.com/PermaLink,guid,05fc0109-3215-410e-8009-447c1e74cacb.aspx

Shouldn’t be a debate at all. I have a personal preference in languages which goes in this order C#, Ruby, Javascript, Boo/brail,  a bunch of languages i don’t know yet, xml + xslt

Why C# is first on the list is because it comes with visual studio which is IMHO the best IDE out there for the moment.

VB.NET isn’t in the list because I don’t see the point in learning another language that is just as powerful as c# but has got a very ugly way for forming syntax. VB doesn’t feel logical to me.

I don’t program in a language because of aesthetics but how they flow from my brain onto the keyboard and the purpose of what I’m writing the script for. I tend to think in larger picture concepts languages that support that better have a distinct advantage in my book.

my 2c.

If you believe this guy then javascript packing is a bad thing.

http://batiste.dosimple.ch/blog/2007-07/

I don’t agree with this post and here’s why (i couldn’t comment on his blog because he doesn’t have comments):

IMHO that’s not entirely correct. 
I’m sure that if you’re not packing stuff but just removing comments and whitespace you’ll get completely different results.

If you’re packing stuff then the reason should be because you want to obfuscate your javascript not because you want to get some speed improvement. It’s just common sense to work out that
1. javascript is slow
2. more javascript execution (i.e. un-obfuscating) is even slower.

Another benefit of packing javascript is that you/your company saves $ on bandwidth. 5k x 5000 pageviews x 30 days = lots of $.

The guy is just looking at 1 aspect or 1 reason which gives a distorted image.
Anyway my experience tells me that removing whitespace and comments in a production environment and then have them sent compressed by the webserver to the client gives me the best results. Regardless of this guys 1x test setup with 1 machine.

I will generally read all the files into one file strip it from extra content after which they get gzipped (deflate is better for xml type structures) and sent to the browser.  Once the javascript has been prepared for the page it should remain cached on the webserver and preferrably on the client.

Another week, another lunch.

This lunch had the biggest attendance yet.  I won’t be putting up all the names because I can’t remember them all :-$. We had about 20 people showing up, most of them were new faces. It was very good to see that Tim Haines could make it as well as Owen Evans. Another new addition was John Rusk and a couple of people from the TradeMe development team.

With lots of people it becomes a lot more difficult to follow all the conversations at once. I’ll do my best to write up the minutes, if I miss something please let me know so I can add it.

            _My start question for today was: How do people do integration testing?_

The question is a bit on the broad side I admit but Owen Evans stepped up and gave us a rundown of how they do it. The first thing I got from his explanation is that there is a right way to write tests and a wrong way to write them. Because unit tests shouldn’t do integration testing etc.
He explained that in the beginning they had a build process that would take about 2 hours to complete and after refactoring their app to use the right way of testing it only takes them a couple of minutes.  Owen uses Fit and Fitnesse for doing the integration testing.  He also explained that integration tests are not tests you would want to run on every build but preferrably during the nightly build so you have something to look forward to when you start your programming day :)  Owen said a lot more but I can’t remember all of it -sorry Owen-
The guys at TradeMe have a manual testing process as do we (Xero).
I think JD was the first to mention watir for automated integration testing, which I second. I think watir or watin are beautiful tools as is Selenium.
For more info on which one fits your project best: http://adamesterline.com/2007/04/23/watin-watir-and-selenium-reviewed/

Somehow we got on the subject of source control and the different source control systems were using. My personal preference is subversion closely followed by Team Foundation Server.  Most people in our group liked subversion the best some of the reasons for it are the fact that it is not bound to a visual studio solution, the cost of subversion is also a major factor and the fact that it is not related to any specific technology and the fact that subversion can be easily integrated with other systems.

JD then asked who did use unit testing and it turns out that about 6 people actually did use unit testing. One of the reasons mentioned for people not using it was that tests take too much maintenance as your code evolves.  The response to that objection was that in that case you’re probably writing your tests wrong.  The benefits in my opinion were that you write code that is a lot more beautifull and you get a nice, warm fuzzy feeling inside called confidence in your code.

Next John Rusk took the floor bringing us back to the original question and he introduced us to a new term: exploratory testing. Which is a way of trying to bring structure to an unstructured process (manual testing). It wasn’t very clear to me where the distinction lies with manual testing except for the fact that the user that does the actual testing does need to have some knowledge of the application domain.

            [JB](http://www.mindscape.co.nz) said that another good way to understand what your application is going to withstand is to take a couple of uneducated users (they don't know anything about the application) and put them in front of a terminal and watch what they are doing. This gives you some very valuable insights for usabilty as well as finding some bugs.





            _My second question was: What differentiates an average developer from a great developer ?_

This question didn’t get the same attention as the first one because the answers to this one were almost unanimously: Passion
The willingness to make mistakes, the drive to look for answers yourself, an inquisitve mind.

I personally don’t think of software development as being a science for me it’s more an art form which might be a good topic for next week.

I’m a bit late in the line of congratulations, but I’d still want to congratulate Alex James with his being awarded an MVP.

He truly is a pilar in the NZ community for .NET

Another week, another lunch. The attendees this week were JD (Mindscape), Andrew Peters (Mindscape), Adam Burmister (Xero), Fletch Brown (Xero), Simone Charietta (Calcium), James Hippolite (Telecom), Martin Harris (Telecom) and me (Xero). 
Our meetings used to be on a thursday but we moved them to Tuesday in the hope that more people would be able to make it (Tim wink wink)

We started out with the OR mapper of mindscape: Lightspeed.  JD and Andrew were pretty quick to point out that Lightspeed is a lot faster than NHibernate for all the operations they currently support.
The analogy was made that NHibernate is like the Oracle of OR mappers and supports every single feature you could every imagine. Where Lightspeed is a bit more limited in features but still does a good job.

From that point on the discussion went on to Katmai (SQL Server 2008) and nobody seemed to know what the new killer features are, apart from the obvious one that it’s a new version.
JB of Mindscape has a the ctp installed but didn’t have time yet to have a proper play with it.  Simone asked what the killer features were for Sql 2005 and offered XPath/XQuery in the Xml columns, I offered CLR integration from then on we struggled a little. It turns out that Andrew and me were the only ones that had actually used the features in a production app.
Luckily JD threw the MAX values for varchar, nvarchar, .. on the table and everybody agreed that that one is overlooked because it should have been there all along :)

The next point of discussion was of course the beta release of Safari for windows. Andrew pointed out that you could go to Pimp my safari to flesh out safari with some much needed plugins.  Nobody really understood why apple didn’t take advantage of cleartype rendering on the windows platform. One of the reasons might be that the apple developers want to maintain one codebase, which is also understandable but then they will have to fix the subpixel rendering because now it isn’t up to scratch. 

James moved the discussion topic over to the fact that Silverlight supports VB.NET better than it will support C# as programming language. Which made me ask why the guys of MS not just kill of the VB language all together ?  Lot’s of C# programmers agreed on this but the poor VB guys didn’t flinch one bit.  Everybody around the table had programmed in some form of Basic in the course of their lives. For me I started with GW-Basic, did some visual basic after that but from then I moved to Turbo Pascal.
The DLR has a dynamic form VB as well so it will still be a while before that one will go away, if it ever does. :) 

Which brought us to the next point of discussion datasets vs OR/mappers. James is a big fan of the dataset and what he can do with it. Where most of the other people around the table liked the OR approach better. After some bickering we agreed that it’s mostly a personal choice. Both methods have their advantages and disadvantages.  Andrew was the one that enlightened us with the big difference between the 2. Domain models have behaviour attached to objects where an RDBMS approach separates the 2 which makes you maintain the code into 2 different places. 

And the last point of discussion would be XML is it a datacontainer/exchanger or is it a programming language.
I personally have a strong dislike for xml, I find it verbose and not friendly to write (number of keystrokes).
JD picked up that discussion by categorically saying that xml is a datacontainer and not a programming language, he then asked me why I asked that question.  The reason for that question is, that whenever I bring up the subject people will tell me it’s a datacontainer and yet we see the new technologies being introduced are all based on xml (WPF, XUL, …). Then people come up with the fact that if there is a good tool support for it it’s not that bad. On this point I personally agree with Ayende, in that you shouldn’t have to use a tool if you want to get on with the technology. To quote Ayende:

Here is a good metric that I like to use. Take an technology, and try to build it without any tool assistance. Is it still a good approach? If not, then there it is complex and hard to use. A lot of UI frameworks fails this test, by the way. WinForms certainly does, when you start to think about complex UI.

Which brought us to the point of DSL’s vs. XML + tools to generate your manifests (manifest => a webpage has an xhtml manifest, with javascript behaviour and CSS for representation)
Somebody around the table didn’t quite know what DSL meant, so Andrew quickly explained that it means Domain Specific Language and it makes it a lot easier for the developer to write out the manifest he needs or to make your code inside your specific domain more readable.

Ok that’s it for today, or at least that’s all I could remember, if I forgot something please let me know and I’ll add it to this post