I am back, yes I am.

Not sure what prompted the restart for the fourth time. No I am not doing another university course. Maybe the ruptured achilles gave some pause tor thought.

Actually it was the What is Code article by Paul Ford that got me thinking.

Putting a site together takes a bit of understanding and effort. Because I have been working with technology for 30+ years, it is second nature. I understand what technology can and can’t do. So it is easy to quickly cut to the chase and help work out the problem we are trying to solve and what the requirements for the piece of work are.

But I sometimes forget that, when trying to discuss with people in the business.

One of the things I like about git, is the concept of working directory, index and repository. The index, or staging area, is really useful for gathering related changes before committing to the repostitory.

The GitGuys have a good description of the difference between these three.

Sometimes we will have changes in the working directory and/or the index. To compare differences between these different states:

Command	Useful Alias	Working Directory	Index	Repo (HEAD)
git diff	gd	•	•
git diff --cached	gdc		•	•
git diff HEAD	gdh	•		•

If you want to diff a particular file, add -- filename to end of command e.g.

  git diff -- src/sql/update_20140125a.sql
  git diff --cached -- src/sql/update_20140125a.sql
            

To see contents of a file in a particular state

State	Command
Working Directory	cat filename
Index	git show :filename
Repo (HEAD)	git show HEAD:filename

And to get a good understanding of how git works, take a look at Git from the inside out

Over the years I have worked with many programming languages.

For me, it is important that the language be ‘simple’ enough for me to keep thinking about the problem that I am trying to solve.

Note that I did not say solution! If one has to think too much on the mechanics of trying to get the proposed solution to work, we often lose sight of identifying what the real problem is.

However, the language also has to be able to be handle the difficult tasks. To quote Larry Wall, Tom Christiansen and Randal L. Schwartz about Perl:

Perl is designed to make the easy jobs easy, without making the hard jobs impossible.

This is where Groovy is for me. It can be used to do one off scripts and basic data munging to coding in full stack frameworks such as Grails or to an Enterprise build automation system like Gradle.

When trying to solve a problem, I want to be thinking close to the problem domain.

For example, reading a file in groovy is as simple as the following:

  def fileText = new File('path_to_file').text
            

Variable fileText now has the content that I am interested in.

Another example if we want to find all the h4 headings on web page, one quick texty way could be to use

  new URL('http://www.radionz.co.nz/about').text.eachLine {
    if (it.contains('h4')) {
      println  it
    }
  }
            

The following provide useful information on learning about the Groovy Language:

• Groovy Language Site
• Mr Haki
• Groovy in Action 2nd Edition
• Groovy Almanac
• Implementation of examples from Perl Cookbook