Fark’s Drew Curtis is interviewed by the O’Reilly team and has some good insights on how to succeed with internet advertising.

It’s not the model. It’s the pricing. That sounds obvious, but it all comes down to effective sales methods. Digital salespeople are slowly building a narrative that not all ad impressions are equal, and those that are wrapped around compelling content are more valuable than, say, impressions that rip by when you poke someone on Facebook.

…

it’s not really any one metric. It’s more about what ratio of uniques to visits to page views is the best. Ideally, you want a large number of uniques who visit on a regular basis and consume 3-5 page views per visit.

And a few ideas on improving sales:

• Change the sales narrative — Not all impressions are created equal. Not all audiences have the same value.
• Reduce industry-wide available inventory
• Augment with subscription content of some kind — Any kind.
• If you have a community, do an annual event.
• If you have a content niche, sell product on it.
• Cut overhead dramatically — Legacy media was used to having individual regional monopolies with 40-percent profit margins

There is a lot more in the article.

Presentation from the authors of the book “Agile Retrospectives - Making Good Teams Great” at Google. Lots of great tips on how to improve your sprint & project retrospectives.

One tip I picked up on was to ask “how was the energy for this sprint?” rather than the bland “how are you feeling?”.

Their structure for a retrospective is:

• Set the Stage
• Gather Data
• Generate Insights
• Decide What to Do
• Close the Retrospective

The way to succeed with a process such as agile is through continuous improvement. The forum for reviewing what needs to be improved and to decide on how to improve things is the sprint retrospectives.

Retrospectives are critical for having a successful project.

Hopefully this isn’t something you need to do. The server that I’ve been using to collaborate on a few git projects with had the domain name expire. This meant finding a way of migrating the local repositories to get back in sync.

Update: Thanks to @mawolf for pointing out there is an easy way with recent git versions (post Feb, 2010):

git remote set-url origin ssh://newhost.com/usr/local/gitroot/myproject.git

See the man page for details.

If you’re on an older version, then try this:

As a caveat, this works only as it is the same server, just with different names.

Assuming that the new hostname is “newhost.com”, and the old one was “oldhost.com”, the change is quite simple.

Edit the .git/config file in your working directory. You should see something like:

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = ssh://oldhost.com/usr/local/gitroot/myproject.git

Change oldhost.com to newhost.com, save the file and you’re done.

From my limited testing (git pull origin; git push origin; gitx) everything seems in order. And yes, I know it is bad form to mess with git internals.

A/B Testing is how sites like Amazon, Yahoo, Google, Facebook and others became the best in the world. They used data to drive decisions about content, layout, wording and other aspects of their sites.

Smashing magazine covers the details of A/B testing in this post.

At its core, A/B testing is exactly what it sounds like: you have two versions of an element (A and B) and a metric that defines success. To determine which version is better, you subject both versions to experimentation simultaneously. In the end, you measure which version was more successful and select that version for real-world use.

37signals tested the headline on its pricing page. It found that “30-Day Free Trial on All Accounts” generated 30% more sign-ups than the original “Start a Highrise Account.”

Dustin found that “You should follow me on Twitter here” worked 173% better than his control text, “I’m on Twitter.”

Along with its other A/B tests, CareLogger increased its conversion rate by 34% simply by changing the color of the sign-up button from green to red!

The article covers the results from others of testing, as well as details on how to get started for your own site.

What I find interesting is that the tools that used to require significant investment in time and development are increasingly available as easy to use, free solutions.

The new Google Command Line opens up some interesting possibilities. One that I wanted to explore was using TextMate to edit basic Google Docs.

First, install Google’s Command Line tool. Details are on their wiki for each OS. There are lots of tips in the comments and even a packaged installer. (I used ports to install)

The next step is to create a symlink from the “mate” command to “mate_wait”. What this does is default the wait argument to true. This is needed for the Google script to detect changes to your document.

sudo ln -s /usr/bin/mate /usr/bin/mate_wait

You can now open a document in TextMate:

google docs edit --title "Ideas" --editor "mate_wait"

If you select a title for a document that doesn’t exist, it will be created. Once you close the file in TextMate, control returns to the shell and the document is updated on Google’s servers.

You are only able to edit in text only mode. So it works best on documents without any formatting.

To list your existing documents, try:

google docs list