Kablingy

Today we met with our clients to pitch an idea to them. Since we were very short on preparation time, we didn't have the luxury of putting together a Keynote/Powerpoint presentation. So we mind mapped the whole sales pitch. It was quicker, easier, and it produced the desired result - the client is now further along in the sales cycle.

Here's how we did it.

Our idea was to rebrand the client's website and develop a strategy to tap into a potential new market.

We drew the client's logo at the centre of the mind map, in 3 colours (colour is important when mind mapping). We then split the mind map into 3 branches: idea, strategy, benefits. Note that we use just keywords for the branches, we also draw each main branch in different colours.

Under the idea branch we had smaller branches for untapped market, rebranding, evangelism. These branches then split into further branches. We peppered the mind map with little icons and pictures along the way.

Next, under our strategy branch we had sub branches for newsletter, blog, social networks, website,live chat, screencasts, podcasts. Finally for the benefits branch we had sub branches for customer(how this approach would add value to the customers), and sales (how this would approach would attract more sales).

Each branch had icons/pictures drawn beside them - this is one of the more fun aspects on mind mapping - you get to be 5 years old again.

Here's the interesting thing, I drew the mind map 5 hours ago and have been able to recall 80% without looking at it. This is where the real advantage is. The presentation, if you follow the basic rules of keywords, colour, and pictures, will have a better chance of sticking in your audience's mind than a typical slideshow presentation.

If you want to learn more about mind mapping, try The Mind Map book or have a look at this gallery of mind maps.

photo credit: http://www.buzan.com.au/learning/mindmapgallery.html
 

 

Friend of Kablingy and all round smart fellow Sean O'Donnell tells me that a sizeable chunk of his site traffic is for a blog posting on how to set up Subversion on Debian with Apache 2. Looking at the incantations on this arcane scripture from 2005, I've no idea how he figured it out. I asked him why he hadn't posted one on how to set up git on a server, and he replied that it was too complicated to set up, what with gitosis etc.

I asked him why he hadn't done it the almost easy way (no, not via the brilliant github), and he suggested I should write it up.

So here it goes. Wizard hat on, magic wand in hand, let us call out some incantations. At Kablingy, we favour Ubuntu servers  hosted by the outstanding provider Slicehost. Hopefully these steps shouldn't require too much adjustement for your set up. I shall mark instructions for your local machine with [local] and instructions for your server with [server].

Steps 1 and 2 are for those without a git user on their server, and without a git repository. Readers can probably skip straight to the meat of the article in step 3.

1. SSH Preparation

If you already have a git user on your server with ssh access, you can skip to the next section.

As root, add a user called 'git', and give it ssh access.  This presumes you have already done the ssh public key dance etc. Instructions can be found on the Slicehost Articles

server: sudo adduser git

then set password etc..

give the git user ssh access

server: sudo nano /etc/ssh/sshd_config

add the user to the list of users with ssh access

AllowUsers otheruser anotheruser git

Reload SSH

server: sudo /etc/init.d/ssh reload

Login to the git account and allow your local machine to ssh to that account

server: su git

Put a copy of your local machine's public key into the /home/git/.ssh/authorized_keys file.

Check that ssh access works

local: ssh git@server

This should bring you to the prompt on your server

2. Set up a simple git repository

Let's set up a simple repository. If you already have a git repository, you can skip this step

local: mkdir ~/myapp

local: cd ~/myapp

local: echo hello > myfile.txt

local: git init

local: git add myfile.txt

local: git commit -a -m "my first commit"

3. Upload your git repository to the server (the weird part)

Tell your git repository about your server

git remote add origin ssh://git@server/home/git/myapp.git

If that doesn't work, try it manually. Prepare the git config file

local: cd ~/myapp/.git local: nano config

Paste this sorcery into the git config file. Adjust the line in bold to suit your server.

[core]

  repositoryformatversion = 0

  filemode = true

  bare = false

  logallrefupdates = true

[remote "origin"]

  url = ssh://git@server/home/git/myapp.git

  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]

  remote = origin

  merge = refs/heads/master

Now clone a bare version of the repository into a directory called myapp.git

local: cd ~

local: git clone --bare myapp myapp.git

And move that repository up to your server.

local: scp -r myapp.git git@server:

Don't forget the : at the end of the above statement. If your repository is rather big you might want to zip up the directory first, but you will have to unzip it once it's on the server.

Now test that the local machine repository can talk to the repository on the server:

server: git pull

From ssh://git@server/home/git/myapp

* [new branch] master ->origin/master

Already up-to-date

Let's add another file to the repository

touch Another file > anotherfile.txt

git add anotherfile.txt

git commit -a -m "added another file"

git push

You should see something like:

Counting objects: 4, done.

Compressing objects: 100% (2/2), done.

Writing objects: 100% (3/3), 308 bytes, done.

Total 3 (delta 0), reused 0 (delta 0)

To ssh://git@server/home/git/myapp.git c2985b7..68b18a3 master -> master

To clone your repository from the server, type:

git clone ssh://git@server/home/git/myapp.git myapp

That's it! To give somebody else access to your repository, you can use the above statement, but their ssh public key will have to exist in the server's /home/git/.ssh/authorized_keys file. This is described in step 1.

Credit goes to the Darryl West who wrote this helpful blog posting on setting up git for flex projects.

Finally kind reader, please let me know of any defects in this article.

Picture borrowed from creative commons images on Flickr