This blog has been moved

by Theo15. October 2013 10:13

I've moved my blog to github pages (using jekyll/octopress).

 

try www.nettreo.com instead

Tags:

Resources for understanding git

by Theo22. July 2012 17:44

To be good at using git, you need not only to learn it but you need to understand it. Git's working seems like magic until you understand why it does what it does.

This is the three best resources i've found for understanding how git works. I've you use git and don't know these, i suggest you take a look. 

The Git Parable - (blogpost: http://tom.preston-werner.com/2009/05/19/the-git-parable.html)
Tom Preston-Werner has written a great blogpost describing how you might come to design a VCS like git. Now this is a made up story, but provides insights into the reasoning on the design  for git. 

Git for Ages 5 and Up - (presentation: http://www.youtube.com/watch?v=YwIwi80bXX4)
As you probably already know, git works internally with its commits in a graph-structure. This presentation explains and runs through examples in git while illustrating what git does using Tinker Toys. This may sound weird but is actually a great way to understand git's internal structure.

Think Like A Git - (website: http://think-like-a-git.net/)
A site that more directly describes git for "Advances beginners".

Using unit tests in IOS development

by Theo27. April 2012 21:57

Using unit tests in XCode you have the posibility to have two test targets (sub-projects) set up; one for logic tests and one for application tests. So whats the difference?

Logic tests run without the Application running, so you wont be able to reach your app-delegate or anything UI related, but you will be able to test POOC's (Plain Old Obj-C Classes). The Application Tests target, will start up the simulator and use it to run your unit tests.

When i develop, i normally use the logic tests target for the classes providing domain behaviour. Not having to start up the simulator makes theses tests fast to run, making the feedback cycle shorter and you always want as short a feedback cycle as you can get. So when implementing a new feature i start up with the base domain behaviour and make it run with the logic tests. I then i move to the GUI, which uses this new feature and implement it with tests in the Application tests target. With this working i can then wire up the nibs or similar and start up the simulator to check that the feature works as it should.

It did initially seem a bit odd to have two unit test targets, but being that the one needs the simulator to run it makes sense.

Ignoring already committed files

by Theo18. October 2011 09:24

Ever added a file to .gitignore and found that it still kept being added to the index? Well this is because git will only ignore files not currently under source control, or only files that its not already tracking.

To fix this, tell git to stop tracking the file:

git rm –cached filename

This is usable for when you discover a file thats already been commited which should be ignored.

source: stackoverflow

James Shore's - Lets Play TDD screencasts

by Theo7. June 2011 20:33

I recently discovered James Shore's most excellent "Lets Play TDD" series. It's a series of screencasts all of around 15 minuttes, which shows the building of a java application from the start with TDD - and this live, with all the choices and hick-ups and whatever included. 

I'm only just reached episode 22 so far, and he's made over a 100 at the time of writing this post. I will highly recommend this to anyone that wants to learn more about TDD in a real project.

As with Kent Becks TDD screencasts, its always great to see the different styles of TDD, i find it a great way to learn more. And James seems to almost produce episodes faster than i have time to watch them :).

First blog post about the series:http://jamesshore.com/Blog/Lets-Play/Lets-Play-Test-Driven-Development.html

Links to all the posts: http://jamesshore.com/Blog/Lets-Play/

..great stuff

Kent Beck TDD screencasts

by Theo15. February 2011 21:14

A good resource for anybody wanting to learn more about Test Driven Development, is the 4 screencasts by Kent Beck, which can be bought from The Pragmatic Bookshelf site.
http://pragprog.com/screencasts/v-kbtdd/test-driven-development

This is Kent Beck describing the workflow he uses when doing TDD and is a great way to learn a bit more about it.

Here’s Mark Needham’s comments of the screencasts:
http://www.markhneedham.com...kent-becks-test-driven-development-screencasts/

Interesting points to notice about the approach

  • He starts of writing the code inside the test, and first pulls it out into its own class when its justified to do so. This way its easier to start, as we don’t have to find out how we want the design of the class/classes, before we have the code to put in there.
  • Smaller tests are removed, when bigger tests cover the same parts. As tests must be maintained, it makes sense not to have multiple test covering the same areas.
  • Kent tries to Call hits shots, when running the unit tests, meaning that he tries to predict if the test is going to evaluate to red or green, as a exercise when TDD’ing.

Using unit-tests to shorten the feedback cycle

by Theo14. November 2010 20:30

The speed of development can be measured in how long it takes to write code, and then how long it takes to test that it works.

Now the normal way of testing is running the system and poke around in the area of the change, to confirm that the change works as it should. This can be very slow if you have to enter multiple hierarchy's  of nested pages or because the system simply takes a while to load and enter. This is where unit tests can be of help.

Even though you don’t buy into the whole idea of covering everything with unit-tests, shortening the feedback cycle will shorten the time i takes to find out if your change works as it should, and this can be helped by testing through a unit-test instead of though the actual system.

I experienced this my self, when building a component that would allow other systems to integrate data our. In this case every request needed to convert input data, validate it, run validation against another external source (returned as json), and then save in the database. Now in this case, i found that creating simple unit tests, for testing the parts allowed me to build this more in component, and much faster, as i was shortening the feedback cycle. Now not every piece of code is straight forward to unit test. But at least evaluating the quickest/easiest way to test a piece of code, should be on every pragmatic programmers backbone.

A very basic unit test

by Theo23. June 2010 19:33

Today i realized what the most basic form of a unit-test is.

It's this:

// If the account's type is normal,
// the account must be reapproved
if(Account.Type == AccountType.Normal)
{
Account.ApprovalExpiryDate = DateTime.Now;
}

I was looking at a similar piece of code on the project i'm currently developer on at work, and was wondering why the first line of comments were there (i hate unnecessary comments, which clutter the meaning of the code). And then i realized that even though the first line of comments is clearly repeating whats really easily read in the expression in the if statement, it is making sure that that's what should be in the if-expression. If someone were to change the expression we would still have that line of code to make sure that the expression was what was originally intended.

Normally i wouldn't write the first line of comments, but only the second as it describes why we set the accounts ApprovalExpiryDate to the current DateTime, which isn't very clear. Even better would though be to extract the line in the if into a method that expressed what we try to explain in that comment line (SetAccountToBeReapproved() or something).

Now this is a stupid example yes, but the testing mindset is there. The best solution, and next step would then be to have a unit test check this, and enforce it automatically instead .

VS2008 .suo file rant

by Theo30. March 2010 10:25

Recently Visual Studio 2008 has begun to act very slowly, taking minutes to start and shutdown whilst showing the grayed "not responding" at the same time, because windows can't figure out what it's doing either. I started uninstalling plugins as CodeRush, GitExtensions etc, but it didn't help. Then googling the problem i found a suggestion as to remove the .suo file that lies in the same folder as the .sln file, and it worked! :S

Removing the .suo file which was about 50mb, took the visual studio ram usage from just over 1gb to 100mb, and Visual Studio is now much more responsive also. Very odd, but it seems a lot of people has the same experience. Sure hope this becomes better / more solid in VS2010.

So if Visual Studio begins to slow up, and take a lot of ram, then try renaming the .suo to .suoold or something, and see if it doesn't help the performance. :)

Quick-quick guide to the VI-editior in Git bash

by Theo20. March 2010 01:10

Two modes: command (the initial) and type

Commands:

‘i’goes to Type-mode (where you can type like a normal notepad document)
‘esc’Goes to Command-mode

Quitting: (from command-mode)

‘:wq’ + enterQuit and save
‘:q!’ + enterQuit and don’t save

Theo Andersen

Hi, you've reached my blog on software development.

I use this blog mostly for my own purpose of remembering stuff, so i only put things here once in a while when i get the time.

My current focus is on TDD, unit testing, object oriented code and IOS development.