return to OCLUG Web Site
A Django site.
June 18, 2012

Rob Echlin
echlin
Talk Software
» OCLUG and “The Art of Community” by Jono Bacon

I have started reading this book, I am about half way through.
I have already found useful info that I can use in OCLUG.

I consider my role as President of OCLUG to be similar to the role of Community Manager that Bacon describes. The committees that we struck at the AGM have “objectives” that would be “objectives” for the club, as the book defines them. We would need to add other objectives as defined at the AGM and in recent board meetings, but this is a great start on a “Strategic Plan”.

As someone said in a committee meeting recently, “talking about mission … again”. Well, maybe. Jono Bacon considers a Mission Statement to be useful, but I think we have one already. It’s somewhere in the minutes and I will make it more prominent Real Soon Now(tm, but not by me).

The book is a detailed how-to, a tool for planning, executing on the plan, tracking progress on the plan, and reporting. In fact, I intend to take his notes on “Reporting”, and use them at work. I will also apply his recommendations on reporting transparently at work and in the club.

Speaking of work – Bacon even tells a story of what not to take from work and apply to community, thereby highlighting that this can be an issue, and to remember it.

I appreciate the work that Jono Bacon has put into this book. It will be a reference that I will keep and refer to, and recommend to others involved in leadership of any sort of community, from festival to software project.

I must note that my copy is missing all its “Figures”, which probably means it is a pre-release copy. I am curious to see several of them, (What does the “dot” family look like?) but it has not hindered my learning.

I have learned about organising a group from one of the best – Toastmasters International – and from numerous short training courses. This book brings together a lot that I have learned, packages it for theoretical consistency, and adds new material that I can act on. And I still have half of it to read yet.


Tagged: process, review, team tools

April 3, 2011

Rob Echlin
echlin
Talk Software
» Learning about Git

Origins

Git was invented by Linus Torvalds to use with the Linux kernel. There were performance and political, aka licensing, issues with the previous version control system that the kernel used.

Selected Features, from Wikipedia

  • Strong support for non-linear development
  • Distributed development
  • Efficient handling of large projects
  • Pluggable merge strategies
  • Toolkit-based design

Description

Git is a distributed system, modeled on a file system with built in versioning. Linus wrote it for speed in the use-cases he cared about with the kernel:

  • Patches supplied by email or grab from other user’s repositories
  • Pick and choose among patches provided
  • Merging many patches per day
  • All users comfortable with the command line

I have used it for about a year, and found it very useful, with a few caveats. I use it at home a lot. It allows me to propagate data between systems very quickly, so I use it as backup for my own work at home. I started with a single repository containing several small unrelated projects and non-software files, such as my career-tools folder which contains resumes, personal cards, graphics and sample letters. I learned the hard way that putting it on a USB key requires keeping free space on the stick greater than the total size of the repository. I haven’t gotten around to breaking it up into a couple dozen separate repositories, but I will. Also, I learned that a 600MB repo takes a long boring while to update on really slow media such as a USB stick.

When using Git, you grab a copy of the whole repository on your local machine. That’s what makes it a “distributed” version control system. You “commit” your changes to your copy of the repository. To share them with others, you then “push” them to a central repository when you are ready, or ask others to “pull” from your repository. This basically means committing all changes twice: locally, then centrally.

At work I used Git with a small team of three people. I learned that, like using a stick-shift transmission, Git requires a commitment to learning that is higher than on an automatic transmission.

Some people use manual transmissions inefficiently and in ways that I cringe at, shifting too often or not often enough, not matching revs, and have no idea how or when to double clutch. Modern car transmissions are designed to survive this treatment. Keep those people away from trucks.

Git is like a manual transmission. You should commit to learning more about it than you think you need to know. There is always more to learn. Also, you can use “work flows” with it that are difficult to do with Subversion or most other VCS’s.

The Linux kernel team has thousands of developers who contribute to it, hundreds who contribute frequently, from sites around the world. Their work flow might not work in a centralized repository. A simplified version of their work flow (assuming the change is perfect) goes like this. You grab a copy of the latest “blessed” kernel code from the canonical git repository on GitHub, make changes, test them, and then tell the person in charge of that part of the kernel. This person grabs the code from your GitHub copy of the kernel repository, or receives it from you by email, examines it, tests it, merges it with other changes in the same part of the code and submits it upstream to one of Linus’s main “lieutenants”. This gatekeeper will similarly examine it, merge it with other changes, test it, and promote it to Linus who may choose to accept it.

This work flow is very different from a “small” environment where, of maybe a hundred developers on a project, 5 or 20 are working on one part of a project and have that part of the code to themselves. Git works with these teams as well. It is fast and supports complex merges.

Git also supports different work flows that you may not be used to. For instance, I knew a team that used git internally, and then submitted changes centrally to the corporate Subversion repository. This had several advantages. The team leader could filter submissions from new employees. They could do local commits to their own repository frequently, say at 5 minute intervals on a temporary branch, share with their team mates on a common branch when a small change was ready, and not be delayed by the slow submit time to the Subversion server in England. Changes could be “summarized” in the corporate Subversion repository, so that all those unfinished changes in the 5 minute commits were not seen, and failed, by the Continuous Integration server.

Git also supports using a central repository that people can push their changes to. This is a repository that has no “working copy”, just the repository database.

“Tags” and “branches” are a local idea in git. This means you have to push your tags manually so that other people can see them. Also, if you don’t explicitly copy  your branch to the server, git will happily push your changes but you will not be able to find them easily as they are not on a branch on the central repository.

How to lose your changes in git: Create a new branch locally, make changes, push them to the server that does not have that branch, and delete that branch locally, forgetting to merge to a main branch. That’s a bit like trying to shift down from third to second on an uphill, taking too long and then stalling because the truck is going too slow for second gear when you finally complete the shift. In this case, my co-worker recovered because he found the commit ID on a scrollback log in the terminal window where he did the commit.

Git works best when someone on your team is an expert and everyone takes time to learn more than the minimum.

Main Git web pages

  • http://en.wikipedia.org/wiki/Git_(software)
  • http://git-scm.com/
  • http://whygitisbetterthanx.com/
  • http://unspecified.wordpress.com/2010/03/26/why-git-aint-better-than-x/

GUI tools for Git

There are now GUI tools for Windows, and plugins for many IDE’s.

  • http://en.wikipedia.org/wiki/Git_(software)#External_links

 


Tagged: Linux, software, team tools

October 13, 2010

Rob Echlin
echlin
Talk Software
» News from Agile Ottawa meeting

Yup, it was a good meeting, and I took away an idea or two…

But what I am most excited to tell you about are future events:

And the ideas I took away are centered around Dmitry’s suggestion that Agile design decisions should be documented with light-weight tools, such as the development team’s existing issue tracker.


Tagged: groups, Ottawa, process

October 5, 2010

Rob Echlin
echlin
Talk Software
» Agile Ottawa meeting: Tuesday Oct 12

* Group: Agile Ottawa
* Subject: Announcement from Agile Ottawa: October event, Tuesday Oct 12

“Better together: How user experience design can help Agile teams”

Networking from 6:00-6:30pm; presentation from 6:30-8:00pm. Location is Adobe’s offices on Preston Street.


June 7, 2010

Rob Echlin
echlin
Talk Software
» CMM-1 is like ‘pray as you go’

Or at least I thought so when I saw it on the church sign. So here’s the pic!

And the links:


Tagged: development, process

March 10, 2010

Rob Echlin
echlin
Talk Software
» Prize: Best use of a 5 year plan

So, the new book from 37 signals, Rework, is out.

Now, I don’t watch videos much, so maybe I’m not the best judge, but 41 seconds is short enough to match my attention span, and those videos take the prize for “best use of a 5 year plan”.


Tagged: humor

March 7, 2010

Rob Echlin
echlin
Talk Software
» New tagline, eh?

Quote: “Co-ops hopped up on sugar can find a lot of bugs”


Tagged: site