Scandinavian Developers Conference Report

This is a short report from SDC. My comments are in italics.

Habits for Agility, Kent Beck

Kent changed his topic in the last minute. I would have liked to hear the promised talk on Responsive Design. Instead he talked about more general things.

Attitude

The desire to see reality as it is and to respond. What is reality? Whose reality?

Accountability, take responsibility for your work, no excuses.

Action

Effective teams are biased towards action. If you have a problem, research it, and know instead of think. Try instead of guess.

Time

Find focused time to work. The Pomodoro technique, do something for 25 minutes without interruptions. After finishing something, take some time to reflect before starting on the next task.

Connections

Analogies will help improving communication. Sales people are good at being accountable, because their salary depends on it. Customers are people whose daily lives are affected by your software. Good connections improve understanding between people.

Perspective

A perspective is about the same as an elevator pitch. What do you do? This is essential since this will help you when things get complicated.

Everything that is completely repeatable should be automated. The goal of development is to automate everything.

Support

Good teams find a way to get support, by meeting the needs of the people that can give you support.

Reflection

The cycle goes from action to reflection, ...

Ancient Philosophers and Blowhard Jamborees by Neil Ford

Neil had a nice presentation on the lore of software development.

Those who cannot learn from history are doomed to repeat it.

Books that are part of the lore of software. Smalltalk Best Practice Patterns, Mythical Man Month, The Pragmatic Programmer

Plato invented object orientation. The best way to solve problems is to think.

Aristotele, developed some important ideas like essential properties and accidental properties.

Galileo, didn’t believe anything he was told. Some things are counter-intuitive, anti-patterns.

Occam’s razor, given a set of solutions the simplest one is the best.

Fred Brooks, the second system is the most dangerous to build since you have all the knowledge of what went wrong with the first system it may be too difficult to get started with the second. KISS!

Cloud Computing, John Davies

John Davies talked about mostly about Amazons Web Services and showed how easy it is to set up an EC2 account. He also talked a bit about cloud computing in general. It seems to me that cloud computing is popular because it is easier to set up a new server in the cloud than it it to get the IT-department on the company to set it up. Something is wrong with this picture.

Google App Engine, for application written in Python. Amazon’s Web Services (AWS) include EC2, S3, Elastic Block Service, SimpleDB, and Simple Queue Service.

Advantages of cloud computing are reliability, security, scalability, volume testing, development with continuous integration and version control. It’s simple to setup new machines.

Setting up an EC2 account

• http://aws.amazon.com
• Create x509 certificate
• Download the EC2 API Tools
• Setup some environment variables
• Create a ssh key pair.
• AMI, Amazon Machine Instance
• Run instances, wait a minute, and log in.

Cool Tools

• Elastic Fox – firefox plugin
• ElasticPod – iPhone App

Functional, parallel, and asynchronous programming in F#, Don Syme

Don’s hands on approach to presentation is very nice. He didn’t show much that I hadn’t already seen though.

Why is Microsoft researching functional programming.

• Pleasure
• Economics
• Programmer Productivity

Started with an introduction of the F# language, nothing new. Then the interesting part started, the asynchronous, parallel coding.

let run x = Async.RunSynchronousy x

run(async {return 1+1})

run(ASync.Parallel [{return 2+2}, {return 3+3}])

Simple parallelism.

Outside In – Black Belt TDD/BDD, Niclas Nilsson

Niclas talked about why test first outside-in (or top-down) is better that inside-out. The reason is of course that you don’t create any code that is not necessary and that you know when you are done.

Moder IDEs will also support this style of coding since they can generate the missing method at will.

It is my fault!

I did it! It is my fault! It was my idea that didn’t work! I fucked up!

I say the words and feel the relief flow through my body. Why? Because now the problem is under my control. One of the primary causes of stress is that the problem is beyond our control. So, just by acknowledging that the fault is mine, my stress level will lower and I will be in a better position to solve the problem. Now, when the problem is mine, I have plenty of options.

Seppuku

This will certainly solve the problem. It has unfortunate side-effects though.

Quit

If the problem is work-related, quitting will solve it. I may not get very good references from my employer, but maybe the employer is the problem in the first place. If the problem is not work-related, just decide that it is not worth the effort and quit, get divorced, throw your children out, whatever it takes.

Solve the actual problem

This is the path I usually choose, but it is good to know that the other options exist.

Programming Problems

For programming problems I usually find two gumption traps

I didn’t change anything

Sure I did, checking the status of the files, git status, quickly shows me that I made a number of changes. I can find the problem in one of those changes or I can just revert back to the previous working version and start over. A good reason for frequently checking in working code is that reverting to a previous version is less painful.

The stupid library isn’t working

Sure it is! The assertion is wrong. It should read The stupid library isn’t working as I expect it to! Now, I’m on the right track.

Why isn’t the stupid library working the way I expect it to? Because my expectations are wrong!

Did I RTFM? Yeah, kind of! All of it? Not bloody likely!

Do I know what all the things in the code means or did I just copy them from someone else? I copied some of it. Did the person I copied it from know what they were doing? I don’t know!

Whose fault is it then? Mine!

Is the stupid library really not working? No. Why am I using it? Because it solves a lot of other issues that I need to solve. Is it worth the effort? Yes? No?

Whose fault is it? Mine!

People Problems

People and process problems can be handled in a similar way. I find that many of them go away if we just realize that the problem is ours.

There is nothing wrong with Scrum, hell, there is not even anything wrong with RUP (even though I’ve written that in the past). The problem is ours.

The stupid process is not working! Sure it is! It should read the stupid process is not working as we expect it to!

The stupid process is not working as we expect it to! How do we expect it to work? Well, we don’t know. DOH!

Why is the stupid process not working as we expect it to? Because, we are not making it work as we expect it to.

Whose fault is it? Ours!

Git it on

I switched to Git as my main version control system about five months ago and I haven’t looked back. I’m currently working on a Javascript project where I have to test and develop code both on the Mac and on the Windows VM-Ware images. I have usually had problems with this kind of setup, not so with Git.

Git Basics

I set up my git repository with the usual:

# Create directory
mkdir projectname

# Change to it
cd projectname

# Initialize the repsitory
git init

Then I add a .gitignore file with the specifics for this project.

# Local .gitignore
dist
pkg

And then I add the file to project and commit it.

# Add the .gitignore file
git add .gitignore

# Commit the changes
git commit -m 'initial'

My global ignore file $HOME/.gitignore contains everything that I have common for all projects.

# Global $HOME/.gitignore
*~
.DS_Store
tags
*.gz

Git works with changes, this is important, so you are not actually adding a file to the repository, you are adding the changes. This means that you will have to add files every time you have made a change to them. I like this since it gives me an extra level of control, but if you don’t, you can always use the -a option when you commit and it will include the changes to files that have been added to the repository at least once.

# Add and commit the changes
git commit -a -m 'changes to all added files'

After setting up the initial repository and adding the .gitignore file, I am set to go. I usually start with creating a new branch for development.

# Create the branch but don't switch to it.
git branch dev 

# Or, create the branch and switch to it.
git co -b dev 

# The co above is an alias for checkout, it was created like this
git config --global alias.co "checkout"

After creating, and moving to, this branch I create another branch for the task that I am going to work on. For example

# Create a new branch, setup_tests
git co -b setup_tests

I do what I have to do to get the task done and then I switch to the dev branch and merge the changes in.

# Switch branch to dev
git co dev

# Merge in the changes from setup_tests
git merge setup_tests

If at any point I feel like I need to do something that doesn’t have to do with this task, such as add some utility functions, I just commit the current branch and start a new one from where I am. This gives me very fine-grained control over the source code and it lets me throw away changes that goes bad without parsing and removing the bad changes manually.

If I forget to do my fine-grained branching, Git allows me to just add some of the changes from a file. The simplest way to do this is via the interactive add command.

# Enter git interactive add 
git add -i

Another command I find myself using more and more is stash. If the change that I need to do is totally unrelated to what I am doing now and I just need to fix it, I stash my current branch on the stash-stack and move to the branch where I need the change.

# Saves the changes on the stash stack
git stash

# Switch branch, change, and commit
git co development
git commit -a -m 'urgent change'

#Switch back, and apply the stash.
git co setup_tests
git stash apply

Like I said, the stash is a stack and the command git stash apply applies the top of the stack. If you have the need to apply a stash that is not on top, this is also possible. See the help, git help stash, for information on this.

Cross-VM Workflow

When I need to test my changes on Windows, especially on the awful IE6, I switch to this virtual machine and then I clone the repository.

# Clone the repository
git clone path_to_my_local_mac_directory

Now, I have a perfect copy of my repository and I can test and make the needed changes at will. After this I just push the changes back to the Mac again and pull them back to windows from now on.

# Pushes the current branch
git push 

# Pull the changes back
git pull

I usually find doing this in the development branch the best way to go and then I reserve the merging into the master branch to the repository that I have designated as main, the one on the Mac.

At the moment I am developing on my main repository and there is one caveat with this. If you push changes into this repository the working directory will not be updated. Thus, if you have local changes in your working directory and just commit them without checking the status. You will revert the changes that have been made on the remote repository. This is by no means a fatal problem since you can just revert your changes and move on, but it is still annoying. The lesson to learn is to always use git status before you commit.

# Shows the status of the repository
git status

Parallel Branches

In addition to working on a Project with Javascript, I am also developing a course in it. It is called Javascript, the Esperanto of the Web because that is what Javascript has become. When Java didn’t cut it as the language for the web, Javascript was there and that was all that it took.

When developing this course I have the usual issues with keeping questions in sync with the answers. Git solves this without any problems at all. All I do is to keep to branches of the tree, master, and solution. I do all the course development in the solution-branch and then I just merge it into the master branch where I remove all the correct answers. After that I move back to developing in the solution-branch.

If you want to get started with Git I can highly recommend the series of screencasts at “Gitcasts”: Start with the RailsConf Git Talk, it gives a good overview. If you’re on Windows and like GUI tools move on with the Git on Windows Talk. I use the Cygwin version for my windows version of Git since I have these tools installed anyway.

Time for Smalltalk again

March 24th, I’ll be giving another presentation on Smalltalk at the Scandinavian Developers Conference

The presentation will include:

• An introduction to Smalltalk.
• An overview of the language.
• A very basic enumeration of the persistence options in Smalltalk.
• Highlights from Seaside, templating in Smalltalk, and continuations.
• Finally I will wrap up with the reason the Smalltalk is still the best language when it comes to small and medium scale development. The living environment than enables refactoring and the complete availability of open classes that allows putting functionality in its proper place.

The presentation will be a mix between live demos and slides.

Are your lights on?

I just read the book Are your lights on?, by Donald C. Gaus and Gerald M. Weinberg. In it there are some interesting sayings about problem solving.

• A problem is a difference between things as desired and things as perceived.
• You can never be sure that you have a correct definition, but don’t ever stop trying to get one.
• Don’t solve other people’s problems if they are perfectly capable of doing it themselves.
• If it’s their problem, make it their problem.
• If a person is in a position to do something about a problem, but doesn’t have the problem, then do something so he does.
• There are two kinds of people in the world, those who do work and those who take credit. Keep in the first group, there is much less competition there.
• Do we really want to solve the problem?

There are som many options available when solving a problem.

The first quote, for example,

A problem is a difference between things as desired and things as perceived.

gives us the options of solving the problem by changing the desire or the perception of the problem instead of actually changing the reality to what is desired.