markhneedham/blog huggingface dataset:
Try it and see what happens
Date: 2008-12-21 17:43:21

Another of the ideas I have picked up from my http://www.markhneedham.com/blog/2008/11/19/the-toyota-way-book-review/[lean] http://www.markhneedham.com/blog/2008/12/20/lean-software-development-book-review/[reading] is that of *trying things out without understanding exactly what is happening*.

Or as The Toyota Way puts it...

____
There are many things one doesn't understand and therefore, we ask them why don't you just go ahead and take action; try to do something?
____

This is an approach which several colleagues I have worked with recently have been encouraging me to follow.

I am generally quite inquisitive and want to understand why something works as well as actually getting it to work, and while I wouldn't want to encourage not reading the manual, taking this approach is sometimes less effective because it slows down our feedback cycle and, particularly when pairing, can be a less effective way of getting to a solution. http://www.brazencareerist.com/2008/12/05/fail-early-fail-often-living-by-the-gamer-s-mantra[Failing early and failing fast] is particularly important when pairing, and that is exactly what this approach encourages.

The 'try it and see' approach is particularly effective when working with some open source software when the best way to find out how it works is to use it rather than to rely on the documentation which may not be completely up to date anyway.

From my experiences so far I think it *works best when we have some sort of direction* over what we want to do and how we want to do it. If we don't have any direction then looking in the manual might be more effective.
Learning cycles
Date: 2008-12-07 11:40:00

I've noticed a recurring trend in the way that I learn new concepts which doesn't seem to fit exactly into any of the models of learning that I have come across so far.

It seems to me to be a learning cycle which goes something like this:

. Don't know what is good and what's bad
. Learn what's good and what's bad but don't know how to fix something that's bad
. Learn how to make something that's bad good

The two areas I have noticed this have both been related to concepts about writing clean code.

When I first started writing code I couldn't tell the difference between testable and untestable code. After my first project I became more aware of patterns that led to untestable code but I wasn't able to make untestable code testable. Finally after working on a couple of projects I had worked with enough people and shown enough tips that I have a reasonable idea of how to get difficult to test code into a state where we can put some kind of tests around it.

I noticed the same trend more recently when discussing how to write truly object oriented code. Initially I wasn't aware that suffixing classes with 'Manager' or 'Helper' was a code smell until I came across http://jupitermoonbeam.blogspot.com/2008/09/agent-nouns-are-code-smells.html[Peter Gillard-Moss' post about this]. Having become aware of this I started noticing this in code bases that I worked on but I still couldn't see how to fix it. I'm not completely in the 3rd part of the learning cycle yet but I am more aware when creating classes to focus on what they are not what they do when it comes to naming, to think about the classes responsibility and so on.

This doesn't seem to fit precisely into learning models that I have come across such as the http://pragmaticstudio.com/dreyfus[Dreyfus Model], http://en.wikipedia.org/wiki/Four_stages_of_competence[Four stages of competence] or http://en.wikipedia.org/wiki/Shuhari[Shu-Ha-Ri].

I think it is closest to the Four stages of competence, closely relating to each of the first 3 stages. I'm not sure how the unconscious competence stage would fit in though.

At the moment I'm using the pattern to raise my awareness of where I currently am for different skills and to help me move from stage 2 to stage 3.
TDD: One test at a time
Date: 2008-12-09 22:07:37

My colleague Sarah Taraporewalla has written a series of posts recently about her http://sarahtaraporewalla.com/thoughts/testing/what-is-a-good-test/[experiences] with http://sarahtaraporewalla.com/thoughts/testing/tdd-does-not-mean-test-first/[TDD] and http://sarahtaraporewalla.com/thoughts/testing/a-conversation-with-a-tdder/[introducing it at her current client].

While I agreed with the majority of the posts, one thing I found interesting was that in the http://sarahtaraporewalla.com/thoughts/testing/a-conversation-with-a-tdder/[conversation with a TDDer] there were two tests being worked on at the same time (at least as far as I understand from the example).

This means that there will be two tests failing if we run our test suite, something which I try to avoid wherever possible.

I like to keep my focus just on the test that I am currently working on, so my approach if I had another test that I knew needed to be written would either be to write it down on a piece of paper or to write the skeleton and then just not put anything inside the test body.

This could be seen as being a touch risky in case I then forget to actually write the test and the build remains green, but I prefer this trade off than the distraction that I feel when having more than one test red.

When driving out the design of classes I am now veering towards the approach of *severe simplicity* such that we literally only do enough to make the test green even if that involves returning a hard coded value for example.

The next test after that would probably be the one that drives out the implementation since it becomes easier to write the code to handle the general case rather than hard coding specific implementations for the individual tests.

I started becoming convinced of this approach after trying the http://codekata.pragprog.com/2007/01/kata_two_karate.html[Karate Chop Code Kata]a couple of months ago where I set up all the tests initially and therefore had 20 tests failing all at once.

It felt quite overwhelming having that many tests failing, and the sense of progress from making a test pass wasn't there for me.

It seems a bit ridiculous but *keeping the steps as small as possible* is certainly the approach I am seeing the most success with at the moment.
Javascript: Creating quick feedback loops
Date: 2008-12-09 21:13:21

I've been working quite a lot with Javascript and in particular http://jquery.com/[jQuery] recently and since I haven't done much in this area before all the tips and tricks are new to me.

One thing which is always useful no matter the programming language is to use it in a way that you can get rapid feedback on what you are doing.

Fortunately there are quite a few tools that allow us to do this with Javascript:

== Firebug

The http://getfirebug.com/[Firefox plugin] is perhaps the quickest way of getting feedback on anything Javascript and indeed CSS related.

The ability to see which HTTP calls have been made on a page is invaluable for checking whether AJAX functionality is working correctly and DOM manipulation can be executed and tested on the fly.

Including jQuery in a page effectively makes Firebug the jQuery Interactive Console, allowing us to try out the different functions and see their effects immediately.

== Unit Testing Frameworks

There are several javascript unit testing frameworks around at the moment which run in the browser and provide the ability to write assertions on our code.

I have been using http://docs.jquery.com/QUnit[QUnit] and http://github.com/nkallen/screw-unit/tree/master[screw-unit] and while they work reasonably well for simple tests, neither seems to be at the level of JUnit or NUnit for example. I'm sure this will come as they mature.

Other frameworks I've heard about but not tried: http://code.google.com/p/rhinounit/[RhinoUnit], http://www.valleyhighlands.com/testingframeworks/[JSNUnit], http://www.jsunit.net/[JSUnit], no doubt there are others I haven't heard about yet.

== Selenium IDE

The http://seleniumhq.org/projects/ide/[sometimes forgotten Firefox plugin] is very useful for quickly creating repeatable scenarios to see the impact that code changes have had.

The beauty of this approach is that it takes out the manual steps in the process, so we can just make our changes and then re-run the test. The runner lights up green or red, taking out the need to manually verify the correctness of our assertions. +

== Alert

The http://www.mediacollege.com/internet/javascript/basic/alert.html['alert'] function is perhaps most useful when we want to quickly verify the path being taken through a piece of code without having to step through it using the Firebug debugger.

It's probably more useful for proving our assumptions than actual debugging and it's certainly quick and easy to set up.
C#'s Lambda ForEach: Only on Lists?
Date: 2008-12-15 23:52:17

One of my favourite things introduced into C# recently is the new http://blog.jemm.net/2008/01/16/c-comparing-ways-to-iterate-lists-in-c-and-some-lambda-expression-examples/[ForEach] method which can be applied to (apparently only!) lists.

Last week we had a situation where we wanted to make use of the ForEach method on an IDictionary which we were using to store a collection of http://seleniumhq.org/[Selenium] clients.

[source,csharp]
----

IDictionary<string, ISelenium> seleniumClients = new Dictionary<string, ISelenium>();
----

We wanted to write a piece of code to exit all of the clients when our tests had completed. We thought the following would do the trick:

[source,csharp]
----

seleniumClients.Values.ForEach(client => client.Stop());
----

The problem is that code doesn't actually compile!

'seleniumClients.Values' returns an ICollection which extends IEnumerable so we thought ForEach should be available.

We eventually got around the problem by putting the collection into a list and then applying the ForEach method but it seems like there should be a better way to do this.

[source,csharp]
----

new List<ISelenium>(seleniumClients.Values).ForEach(client => client.Stop());
----

Is there?
JUnit Theories: First Thoughts
Date: 2008-12-12 00:34:17

One of my favourite additions to http://www.testingreflections.com/node/view/5736[JUnit 4.4] was the @Theory annotation which allows us to write parameterised tests rather than having to recreate the same test multiple times with different data values or creating one test and iterating through our own collection of data values.

Previously, as far as I'm aware, it was only possible to parameterise tests by using the http://testng.org/doc/[TestNG] library which has some nice ideas around grouping tests but had horrible reporting the last time I used it.

To create parameterisable tests using Theories we need to write some code like the following:

[source,java]
----

import org.junit.Test;
import org.junit.experimental.theories.DataPoints;
import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.runner.RunWith;

@RunWith(Theories.class)
public class SomeTest {
	@Theory
	public void testTheNewTheoriesStuff(int value) {
		// test which involves int value	
	}

	public static @DataPoints int[] values = {1,2,3,4,5};
}
----

The 'testTheNewTheoriesStuff' Theory is then executed with each of the values defined in the values array decorated with the @DataPoints annotation.

The error message reported for a failure is reasonably good and makes it quite easy to figure out which one of the data points causes the problem.

An example error message for an assertion which failed inside a theory might look like this:

[source,text]
----

org.junit.experimental.theories.internal.ParameterizedAssertionError: testTheNewTheoriesStuff(values[1])
----

It's 0 indexed so this error message tells us that there was an error when running the theory with the 2nd data point, therefore allowing us to go and work out why that's the case and fix it.

This approach is actually particularly useful for testing the scope in which classes we pull from a dependency injection container are available from in our application.

Another potential use for this would be to test the edge cases of our classes - perhaps this would work best if we can randomise the data it uses.

This seems to be more the approach Microsoft are taking with the the http://research.microsoft.com/Pex/[Pex] framework, a similar idea in the .NET space.
Testing First vs Testing Last
Date: 2008-12-22 21:39:22

I recently posted about http://www.markhneedham.com/blog/2008/11/28/tdd-suffering-from-testing-last/[my experiences of testing last] where it became clear to me how important writing the test before the code is.

If we view the tests purely as a way of determining whether or not our code works correctly for a given set of examples then it doesn't make much difference whether we test before or after we have written the code.

If on the other hand we want to http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/12/18/getting-value-out-of-your-unit-tests.aspx[get more value out of our tests] such as having them  the tests act as documentation, drive the design of our APIs and generally prove useful reading to ourself and others in future then a *test first approach is the way to go*.

Testing last means we've applied http://www.code-magazine.com/article.aspx?quickid=0805061&page=2[assumption driven development] when we wrote the code and now we're trying to work out how to use the API rather than driving out the API with some examples.

In a way writing tests first is applying the http://c2.com/xp/YouArentGonnaNeedIt.html[YAGNI] concept to this area of development. Since we are only writing code to satisfy the examples/tests that we have written it is likely to include much less 'just in case' code and therefore lead to a simpler solution. Incrementally improving the code with small steps works particularly well for keeping the code simple.

As http://blog.scottbellware.com/2008/12/testing-and-reverse-engineering.html[Scott Bellware points out], the costs of testing after the code has been written is much higher than we would imagine and we probably won't cover as many scenarios as we would have done had we taken a test first approach.

I think we also spend less time thinking about exactly where the best place to test a bit of functionality is and therefore don't end up writing the most useful tests.

Obviously sometimes we want to just try out a piece of code to see whether or not an approach is going to work but when we have gained this knowledge it makes sense to go back and test drive the code again.

As has been said many times, TDD isn't about the testing, it's much more.
TDD: Does it make you slower?
Date: 2008-12-25 09:41:50

There have been several times where we have been writing code in a test driven way and it has been suggested that we would be able to go much quicker if we stopped writing the tests and just wrote the code.

I feel this is a very short term way of looking at the problem and it does eventually come back to haunt you.

One of the problems seems to be that in many organisations *only the first release of a piece of software is considered*, and in this case then yes maybe it would be quicker to develop code in a non TDD fashion.

The issue you have is that the majority of the overall cost of software does not come in that first release - if we assume a total life time for a piece of software to be 3 years and the first release takes 6 months (being generous here!) then if we go at full speed in those first 6 months and don't write a good suite of tests, we leave ourselves with 2 1/2 years of maintenance hell.

This is where the real cost in software lies. The end of development on a piece of software is very rarely after that first release - bugs need to be fixed, new requirements come in and changes have to be made. Without the tests in the former we are left fixing something and hoping it works - I have broken stuff in production by making changes in non test driven code unaware that it would break elsewhere.

Even if we look at the development cycle of a single release, at some stage we are going to have to test the code we've written to ensure it actually works.

The TDD approach to doing this encourages early testing whereas the traditional approach is to do a lot of the testing at the end. The problem with the latter approach is that any *bugs are being discovered quite a long time after the code was written* which means it will take much longer to try and identify where they came from. http://blog.m.artins.net/[Alex] has a nice post showing http://blog.m.artins.net/measuring-test-effort/[the risks we assume when deciding to cut back on testing effort].

In terms of whether or not actual development time takes longer with TDD, Microsoft http://www.m3p.co.uk/blog/2008/12/08/tdd-fewer-bugs-to-production-longer-to-write/[recently released a paper] which suggested that code written using a TDD approach takes longer to write originally but puts less bugs in production.

Since the goal of software development is to get code into production I think perhaps we need to consider the http://blog.scottbellware.com/2008/12/does-test-driven-development-speed-up.html[whole period of time] from when a feature was worked on until it is in production as being development time.

Clearly there are times when time is the biggest driver for when something needs to be released but the majority of the time having software with less bugs is probably preferable and TDD is helpful for achieving this.
Watching a master at work
Date: 2006-09-02 01:01:44

I've always found it fascinating watching people who really excel in their field going about business, be it footballers, tennis players, actors, whoever.

This week at TWU I've been playing around with some Ruby on Rails as I mentioned in the previous post, and yesterday I had the opportunity to watch one of the leading figures in the Ruby on Rails field at work. Take a bow http://obiefernandez.com/[Obie Fernandez], who gave several of the TWU attendees a demonstration of how to develop applications using Ruby on Rails. It was actually bordering on the severely impressive watching the speed at which he thought through concepts and then transformed them into code.

I also realised that the way I'd been using the language previously had been dubious at best. I hadn't realised that you can take care of database creation without using MySQL Administrator, nor had I realised quite how 'clever' Ruby on Rails is at mapping database tables to models created in the application.

It was almost painful watching how simple it is to do arduous tasks, such as creating textboxes and drop down boxes, in Ruby on Rails and it almost made me want to weep as I recalled the many hours I've spend using PHP and C# tweaking interaction between code and stored procedures/queries.

So +1 for Ruby on Rails and I certainly hope to improve my ability with it over the next few weeks.
Inheritance and Delegation
Date: 2006-09-02 01:31:40

One of the major learning points this week at TWU has been understanding when it is appropriate to use http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29[inheritance] and when http://en.wikipedia.org/wiki/Object_composition[delegation] is the better choice.

I had heard stories about how inheritance could be misused but I didn't think I would be stupid enough to fall straight into that trap! We were taught the concept using 'Measurement' as the problem domain. So to translate the previous sentence into English: The aim was to design classes which could handle old school measurement types such as Inches, Feet, Yards, and so on.

I went about the task by first creating a base Measurement class and then created Inch, Foot and Yard as sub classes of this. The code looked pretty slick to me and I was quite pleased with how it had turned out. I was feeling pretty confident that I had nailed the objective of the session. Alas, it was not meant to be!

Upon reviewing the code my partner and I had created, one of the trainers pointed out that the sub classes did not actually do very much at all. They were effectively useless classes and there was barely any difference between them! One of the other requirements for the code was that it should be possible to compare an instance of the Inch class with an instance of the Foot class, an instance of the Yard class with the Inch class and so on. No problem I thought and promptly created methods called 'ConvertToFoot' in my Inch class and 'ConvertToInch' in my Foot class.

One of the cardinal sins of object orientated programming had been committed! I now had 2 methods which did almost the exact same as the other for no additional benefit. What if there were 100 different measurements? That would mean 99 different conversion methods each to convert to all the other types of measurement. Clearly not an optimal solution - I had taken the bait and fallen into the trap of over use of inheritance.

Anyway, the lesson of the session was that in this particular case it was better to use delegation or composition. In this example it means that there is only the need for one Measurement class, each instance of which comprises of a Unit object. The concept of a 'slug' was introduced - no not one of those nasty little insects, but in this case meaning an instance of an object with a private constructor and one public static instance. In other words slugs are like a poor man's Singleton. The code looked something like this:

|===
| classUnit { publicstaticreadonlyUnitINCH = newUnit(1); publicstaticreadonlyUnitFOOT = newUnit(12); }
|===

This made it far easier to add future measurement types, and meant that only two classes were needed instead of a potentially infinite amount.

I read an interesting article on this topic by Robert Martin, titled http://www.objectmentor.com/resources/articles/inheritanceVsDelegation['Template Method & Strategy: Inheritance vs Delegation'] which explains the reasoning much better than I have here along with a code example.
First thoughts on Ruby...
Date: 2006-08-29 20:01:05

I've heard a lot about http://en.wikipedia.org/wiki/Ruby_on_rails[Ruby on Rails] over the last couple of years but I'd never really been intrigued to get it set up on my machine and 'have a play' with it so to speak.

It turned out to be a relatively painless process and after following the instructions on the http://www.rubyonrails.org/[official site] I had it all setup within about half an hour which was a record for me for getting a development environment setup. With a bit of help from the http://www.amazon.co.uk/Programming-Ruby-Pragmatic-Programmers-Guide/dp/0974514055/sr=8-1/qid=1156856404/ref=sr_1_1/026-8829816-9098059?ie=UTF8&s=gateway[Pragmatic Programmers Guide to Ruby] I managed to get some basic pages setup. The design of the URLs and the separation of the code is actually fairly intuitive. Ruby on Rails uses the MVC (Model - View - Controller) Architecture/Design Pattern very strictly and the code for each of these is written in a separate file.

One aspect of this that made sense to me as a PHP programmer was the way that the URLs in Ruby on Rails are constructed in a "/[controller_name]/[action]" format. I also like the fact that everything in Ruby on Rails is an object, even such things as integers and strings. It takes a bit of getting used to but after using it for a bit it seems counter intuitive to do it any other way.

I don't think I'm about to become an advocate for the use of Ruby on Rails for every development project I work on - I'm still a big fan of http://en.wikipedia.org/wiki/C_Sharp[C#] and the http://en.wikipedia.org/wiki/.NET_Framework[.NET] platform and I find it unlikely that I'll change my mind in the near future but we shall see!