Yesterday I signed up for the free 21 day trial of Peashoot, a campaign manager for links you post on Twitter, Facebook and your blog. It’s created by Yongfook who some of you might be familiar with as the coder behind Sweetcron, one of the first open source lifestreaming applications.

What does it do?

Peashoot allows you to create and monitor link campaigns, i.e. a link you post to your Twitter stream of Facebook page. Creating campaigns are straightforward thanks to a clean and usable interface. It also allows you to associate goals with your campaigns. One example of a goal might be to reach 100 people from Germany, another might be to receive 10 retweets of your link.

Reporting

Each campaign has an extensive report screen detailing the number of clicks, tweets, conversions (you are able to hook into your own Google Analytics account) and revenue. It also offers a number of graphs and charts dissecting where and when your link was clicked. The real time updating Google map is a nice touch.

In order to do this Peashoot uses it’s own URL shortening service. All links will start with http://pea.to/ although you can use a custom domain for your links if you have access to your domain’s DNS settings. If you associate your Google Analytics account with Peashoot all links will include campaign details which will then be tracked.

Other nice features include the ability to collect mentions of your link from social media services and the option of tracking keywords associated with your brand on Twitter.

Another reporting tool?

As many of you are aware services like http://bit.ly, a free service, offer excellent tracking facilities (just enter a + sign after any bit.ly URL to see the stats for that link).

In my opinion Peashoot is different. The ability to create campaigns, link it into Google Analytics and the extensive tracking and reporting tools make it a nice complimentary tool to statistics offered by services like bit.ly.

Issues

When signing up you do have to enter your payment details upfront, therefore you will get billed after the 21 days unless you remember to cancel. It’s a small point but one worth mentioning. I also encountered a slight issue with integrating Google Analytics. The settings screen states I am connected but the detail page does not list any accounts.

Pricing

Three plans are available. Basic $17 a month, Pro $25 a month or Pro Yearly for $149 a month.

Verdict: Recommended

It’s a nice addition to your statistics and tracking software arsenal. Paying yearly brings the cost down to around $12.40 a month which is pretty good value if you use services like Twitter to publish links and need a way of working out how effective they are.

Tried it?

If you have tried Peashoot and have a different opinion or hints and tips to share please leave a comment.

In this talk at The Future of Web Apps London, Simon gave clever insight into where cloud hosting and computing is headed, and what it means for your web app. He also talks about ‘Private Clouds’ and interoperability between cloud computing solutions.

Based on Twitter feedback, it was one of the most entertaining and interesting talks of the day, so we think you’ll enjoy it :)

You’ll learn …

1. What ‘Private Clouds’ are and how they’ll affect your web app
2. How standards in cloud computing will change the way your app is setup
3. Future developments in Cloud hosting and computing that you should be aware of

Editor’s Note: You won’t want to miss Twitter, Mozilla, Mint.com, Reddit, Alex Payne, Fred Wilson, Gary Vaynerchuk, John Resig, Molly Holzschlag, Steve Huffman and Tara Hunt at The Future of Web Apps Miami.

At FOWA London 2009 Bruce Lawson gave an introduction to HTML 5 and how it might be used in the future.

The HTML 5 spec was originally called “Web Applications 1.0″. Most of the attention has been on the new markup elements, but in his talk he takes a further look at the applications side of the spec, covering:

1. Dynamic images and graphs with canvas
2. Eliminating much forms validation with webforms 2.0
3. Local storage automagically saving your data
4. Geolocation
5. Building toolbars and menus.

Editor’s Note: We’ll be covering “How HTML 5 is Going to Completely Change your Web App” at The Future of Web Apps in Miami.

You can jump straight to the video, view the slides, read the transcript (thanks @joeloverton for doing this!), or check out the resources he demos in the talk:

• Eye-candy canvas
• canvas first-person shooter
• canvas first-person gifter
• the excanvas library to port canvas to Internet Explorer
• Filament Group’s jQuerty plugin using canvas for graphing data tables
• Raphaël JavaScript Library to make SVG that also works in Internet Explorer
• SVG Web is a JavaScript library which provides SVG support on Internet Explorer (Alpha code: not ready for production)
• My HTML5 forms demo, including range, date, placeholder, regex validation (Try in Opera and Chrome)
• modernizr – A small HTML5 capability detection library
• HTML5demos.com – Remy Sharp’s demos of geolocation, offline storage and web database and many others
• Video demos

Other useful resources:

• SVG vs. Canvas on Trivial Drawing Application: a comparison of canvas and SVG
• HTML5 Authors spec
• A video of Dean Edwards demoing his unreleased JavaScript library that detects and plugs the holes in current browsers’ HTML5 support

There are some great beginner canvast tutorials on the Opera Developer:

1. HTML 5 canvas – the basics
2. Creating an HTML 5 canvas painting application
3. Creating pseudo 3D games with HTML 5 canvas and raycasting
4. Creating pseudo 3D games with HTML 5 canvas and raycasting: Part 2

The video

Full transcription available at joeloverton.com/html5. We’d like to say a HUGE thank you to @joeloverton for doing this transcription!

The slides

Gary Vaynerchuk delivered this passionate and powerful speech at FOWA London 09 and it rocked the house. If you need a bit of inspiration (and a slight kick in the ass) don’t miss this one. Warning: Strong language

You can also listen to just the audio here or subscribe to the audio podcast of all the talks.

Just announced: Gary will be speaking at FOWA Miami 2010. There are only three Super Early Bird passes left (save 29%). Hope to see you there!

In this talk from FOWA London, Alex Hunter takes you through the DOs and DO NOTs of developing a powerful and positive brand on the web. This was a favorite among the crowd at FOWA, so don’t miss it.

By the way, there’s only 26 early bird passes left to The Future of Web Apps Miami. With speakers like Twitter, Facebook, Mint.com, Fred Wilson, Molly Holzschlag, John Resig and Reddit, it’s going to sell out quick. Hope to see you there!

In this video from The Future of Web Apps London (FOWA), Kevin Rose, founder of Digg, WeFollow and Revision3, shares 9 things he did to increase his users to 1,000,000 and beyond.

Here’s a quick bullet-point summary. You can watch the video, view the presentation slides or download the audio.

If you enjoy this article, you’ll love The Future of Web Apps Miami. Speakers include: Twitter, Mint.com, Gary Vaynerchuk, jQuery, Reddit and more. Buy your ticket now.

#1. Ego

1. Ask yourself: Does this feature increase the users self-worth or stoke the ego?
2. If a user is contributing to my system, what emotional rewards do they walk away with? What (visible) rewards will they receive?

#2. Simplicity

1. Stop over building features
2. Pick 2-3 things to focus on
3. Ask yourself: Is there anything I can take out of this feature?

#3. Build & Release

1. Stop thinking you understand your users
2. Learn from what they’re actually doing on your site, not what you think they’ll do
3. Decide on what you’re going to build… and build it (avoid analysis paralysis)
4. Build, release, iterate, and repeat

#4. Hack The Press

1. Invite only system (Pownce, Digg v3)
2. Talk to the junior bloggers
3. Attend parties for events you can’t afford – network w/influencers, bring a demo

#5. Connect with your community

1. Start a podcast (it’s OK if not everyone listens)
2. Throw a launch party, then yearly/quarterly  events – invite the press/influencers personally – don’t tell the bar
3. Engage w/the community, be an active participant your own ecosystem

#6. Advisors

1. What technical problems are you going to have?
2. Advisors can be helpful in a whole slew of areas (marketing/hiring/bizdev)
3. Stock compensation, typically not a board seat, solid advisors help during fund raising

#7. Leverage your userbase to spread the word

#8. Does your product provide value for 3rd party sites?

#9. Analyze your traffic

1. Install Google analytics
2. Entrance sources (search?)
3. Paths through site
4. Top exit pages

The Video

Dave McClure gave a killer talk at FOWA London that gave some great advice for web start-ups. If that’s you, make sure not to miss this talk. You can also view the slides or download the audio. Enjoy!

Also, we’ve just launched FOWA Miami! There are only 7 early bird tickets left (after just one day on sale), so they’re going to go quick.

The Video

The slides

The Audio

You can download the complete audio from the talk here or subscribe to the podcast of all the audio.

In this video from FOWA London 2009, Francisco Tolmasky will demo Atlas, a new visual tool for building web apps and desktop apps. It will blow your mind and change what you thought was possible with web apps. This is new footage that has not been shown to the public ever before.

Editor’s Note: Only eight hours till we launch FOWA Miami 2010! There’s only 20 Super Early Bird tickets at 47% off, so be quick (only 440 seats total, so the show will definitely sell out early). Speakers include: Twitter, Reddit, Mint.com, jQuery, Palm Pre, FreshBooks, Opera and PayPal. Keep an eye on events.carsonified.com for the launch at 9am EST.

You may have heard some hubbub over distributed version control systems recently. You may dismiss it as the next hot thing, the newest flavor of kool-aid currently quenching the collective thirst of the bandwagon jumpers. You, however, have been using Subversion quite happily for some time now. It has treated you pretty well, you know it just fine and you are comfortable with it – I mean, it’s just version control, right?

You may want to give it a second look. Not just at distributed version control systems, but at the real role of version control in your creative toolkit. In this article, I’m going to introduce you to Git, my favorite DVCS, and hopefully show you why it is not only a better version control system than Subversion, but also a revolutionary way to think about how you get your work done.

Now, this isn’t really a how-to on Git – I won’t be going over a lot of specific commands or get you up and running. This is a list of arguments on why you should be seriously considering Git if you’re currently using SVN. To learn Git, there is a free online book called Pro Git that I wrote that will walk you through Git step by step, should this article entice you. For each point I make here, I will be linking to the appropriate section of that book, should you want to find out more about that specific feature of Git.So, first we’re going to look at the inherent advantages of distributed systems over centralized ones. These are things that systems like Subversion simply cannot do. Then we’ll cover the powerful context switching and file crafting tools that are technically possible to do with Subversion, but which Git makes easy enough that you would actually use them. These tools should completely change the way you work and the way you think about working.

The Advantages of Being Distributed

Git is a distributed version control system. So what does “distributed” actually mean? Well it means that instead of running `svn checkout (url)` to get the latest version of your repository, with Git you run `git clone (url)`, which gives you a complete copy of the entire history of that project. This means that immediately after the clone, there is basically no information about that project that the server you cloned from has that you do not have. Interertingly, Subversion is so inefficient at this that in general it’s nearly as fast to clone an entire repository over Git as it is to checkout a single version of the same repository over Subversion.

Now, this gives you a couple of immediate advantages. One is that nearly every operation is now done off data on your local disk, meaning that it is both unbeliveably fast and can be done offline. This means that you can do commits, diffs, logs, branches, merges, file annotation and more – entirely offline, off VPN and generally instantly. Most commands you run in Git take longer to type then they do to execute. Now stop for a moment and try to remember how many times you’ve gone to get a cup of coffee while Subversion has been running some command. Or jot down a quick list of occasions on which you’ve wanted to commit but didn’t have an internet connection or couldn’t connect to your corporate VPN.

The other implicit advantage of this model is that your workflow does not have a single point of failure. Since every person working on your project has what is essentially a full backup of the project data, losing your collaboration servers is a minor inconvenience at best. Imagine for a moment your SVN server having a hard drive corruption – when was your last backup and how many hours will it take to get to the point where your team can start working again? In Git, any team member can push to any server where every member has SSH access and the whole team can be easily up and running in a matter of minutes.

The final advantage I’ll cover of distributed systems are the incredible workflows that are now available to you. Git does not depend on a centralized server, but does have the ability to syncronize with other Git repositories – to push and pull changes between them. This means that you can add multiple remote repositories to your project, some read-only and some possibly with write access as well, meaning you can have nearly any type of workflow you can think of.

You can continue to use a centralized workflow, with one central server that everyone pushes to and pulls from. However, you can also do more interesting things. For example, you can have a remote repository for each user or sub-team in your group that they have write access to, then a designated maintainer or QA team or integrator can then pull their work together and push it to a ‘gold’ repository that is deployed from.

You can build any sort of heirarchical or peer-based workflow model with Git that you can think of, in addition to being able to use it as a centralized hub as in SVN. Your workflow can grow and adapt with your business model.

You can also use it in other ways – an interesting example of this is deploying on the Ruby hosting company Heroku. To deploy to their systems, you simply push to your ‘heroku’ remote repository. You can develop and collaborate on other remote repositories, but then when you actually want to deploy your code to running servers, you push to the Heroku Git repository instead. Imagine trying to do that with Subversion.

Lightweight Branches: Frictionless Context Switching

Before I begin explaining this, which is actually my favorite feature of Git, I need you to do me a favor. Forget everthing you know about branches. Your knowledge of what a ‘branch’ means in Subversion is poisonous, especially if you internalized it pre-1.5, like I did, before Subversion finally grew some basic merge tracking capabilities. Forget how painful it was to merge, forget how long it took to switch branches, forget how impossible it was to merge from a branch more than once – Git gives you a whole new world when it comes to branching and merging.

In Git, branches are not a dirty word – they are used often and merged often, in many cases developers will create one for each feature they are working on and merge between them possibly multiple times a day, and it’s generally painless. This is what hooked me on Git in the first place, and in fact has changed the entire way I approach my development.

When you create a branch in Git, it does so locally and it happens very fast. Here is an example of creating a branch and then switching to your new branch to start doing development.

$ time git branch myidea
real	0m0.009s
user	0m0.002s
sys 	0m0.005s

$ time git checkout myidea
Switched to branch "myidea"
real	0m0.298s
user	0m0.004s
sys 	0m0.017s

It took about a third of a second for both commands together. Think for a second about the equivalent in Subversion – running a `copy` and then a `switch`

$ time svn copy -m 'my idea' https://svn.example.com/trunk \

https://svn.example.com/svn/branches/myidea

real	0m5.172s
user	0m0.033s
sys	0m0.016s

$ time svn switch https://svn.example.com/branches/myidea
real	0m8.404s
user	0m0.153s
sys	0m0.835s

Now the difference between 1/3 of a second and 13 seconds (not to mention the time it takes to remember each long URL) may not seem huge at first, but there is a significant psychological difference there. Add to that the fact that your network speed, server load and connectivity status are all factors in Subversion, where it always takes 1/3 of a second in Git and that makes a pretty big difference. Also, branching is considered a fast operation in Subversion – you will see even more pronounced speed differences in other common operations like log and diff.

However, that is not the real power of Git branches. The real power is how you use them, the raw speed and ease of the commands just makes it more likely that you will. In Git, a common use case is to create a new local branch for everything you work on. Each feature, each idea, each bugfix – you can easily create a new branch quickly, do a few commits on that branch and then either merge it into your mainline work or throw it away. You don’t have to mess up the mainline just to save your experimental ideas, you don’t have to be online to do it and most importantly, you can context switch almost instantly.

Now, once you have work on a couple of branches, what about merging? If you’re from the world of Subversion, you may cringe at that word, ‘merge’. Since Git records your commit history as a directed graph of commits, it’s generally easy for it to automatically figure out the best merge base to do a 3 way merge with. Most Subversion users are used to having to figure that out manually, which is an error prone and time consuming process – Git makes it trivial. Furthermore, you can merge from the same branch multiple times and not have to resolve the same conflicts over and over again. I often do dozens of merges a day on certain Git projects of mine and rarely have even trivial merge conflicts – certainly nothing that isn’t predictable. Raise your hand if you’ve ever done a dozen branch merges on a Subversion project at least once a week and didn’t end each day by drinking heavily.

As an anecdotal case study, take my Pro Git book. I put the Markdown source of the book on GitHub, the social code hosting site that I work for. Within a few days, I started getting dozens of people forking my project and contributing

copy edits, errata fixes and even translations. In Git, each of these forks is treated as a branch which I could pull down and merge individually. I spend a few minutes once or twice a week to pull down all the work that has happened, inspect each branch and merge the approved ones into my mainline.

As of the time of writing this article, I’ve done 34 merges in about 2 weeks – I sit down in the morning and merge in all the branches that look good. As an example, during the last merge session I inspected and merged 5 seperate branches in 13 minutes. Once again, I will leave it as an exercise to the reader to contemplate how that would have gone in Subversion.

Becoming a Code Artist

You get home on Friday after a long week of working. While sitting in your bean bag chair drinking a beer and eating Cheetos you have a mind blowing idea. So, you whip out your laptop and proceed to work on your great idea the entire weekend, touching half the files in your project and making the entire thing 87 times more amazing. Now you get into work and connect to the VPN and can finally commit. The question now is what do you do? One great big honking commit? What are your other options?

In Git, this is not a problem. Git has a feature that is pretty unique called a “staging area”, meaning you can craft each commit at the very last minute, making it easy to turn your weekend of frenzied work into a series of well thought out, logically separate changesets. If you’ve edited a bunch of files and you want to create several commits of just a few files each, you simply have to stage just the ones you want before you commit and repeat that a few times.

$ git add file1.c file2.c file3.c
$ git commit -m 'files 1-3 for feature A'
$ git add file4.c file5.c file6.c
$ git commit -m 'files 4-6 for feature B'

This allows other people trying to figure out what you’ve done to more easily peer-review your work. If you’ve changed three logically different things in your project, you can commit them as three different reviewable changesets as late as possible.

Not only that, which is pretty powerful in itself, but Git also makes it easy to stage parts of files. This is a feature that has prevented coworkercide in my professional past. If someone has changed 100 lines of a file, where 96 of them were whitespace and comment formatting modifications, while the remaining 4 were significant business logic changes, peer-reviewing that if committed as one change is a nightmare. Being able to stage the whitespace changes in one commit with an appropriate message, then staging and committing the business logic changes seperately is a life saver (literally, it may save your life from your peers). To do this, you can use Git’s patch staging feature that asks you if you want to stage the changes to a file one hunk at a time (git add -p).

These tools allow you to craft your commits to be easily reviewable, cherry-pickable, logically seperate changes to your project. The advantages to thinking of your project history this way and having the tools to easily maintain that discipline without having to carefully plan out every commit more than a few seconds before you need to create them gives you a freedom and flexibility that is very empowering.

In Subversion the only real way to accomplish the same thing is with a complicated system of diffing to temporary files, reverting and partially applying those temporary files again. Raise your hand if you’ve ever actually taken the time to do that and if you would consider the process ‘easy’ in any way. Git users often do this type of operation on a daily basis and you need nothing outside of Git itself to accomplish it.

Not Just for Teams of Coders

I hear from individuals all the time that this could not possibly be worth switching because they don’t work in large teams or don’t collaborate with other people at all. Or perhaps you’re not really a programmer, but a designer or a writer.

Well, on the individual versus a team front, I would argue that nearly everything I love about Git, much of which I’ve written about here, I love because it helps me, not because it helps my teammates. Screw them.

Local branching and frictionless context switching is entirely useful to an individual and probably the most unique and revolutionary feature of Git. In fact, I very often use Git like you might use RCS – just fire it up on some local directory and check stuff in every once in a while, having no remote repositories at all. Creating commits as logically seperate changesets is also helpful to you to remember why you did something a month ago, so those tools are also helpful on an individual level and finally, speed and backups are always a good thing, team or individual.

If you’re not really a software developer, I’ve already listed an example of using Git to collaborate on a book. Pro Git is being published by Apress, a major publishing company, and most of the writing and review of the book was done in Markdown using Git to collaborate. All the errata and translations are being handled in Git branches. You don’t know real writing bliss until you merge in a technical reviewers or copy editors modifications with something as simple as `git merge`.

In Closing…

In closing, this is really just the tip of the iceburg of awesome that is Git. There are tons of fantastic and powerful features in Git that help with debugging, complex diffing and merging and more. There is also a great developer community to tap into and become a part of and a number of really good free resources online to help you learn and use Git. The few things I’ve mentioned here are simply the features that most changed the way I think about working and version control. They are the major reasons I could never go back to a system like Subversion. It wouldn’t be like saying to me “you have to use a Toyota instead of a Mercedes”, it would be like saying “you have to use a typewriter instead of a computer” – it has forever changed the way I approach and think about creating things.

I want to share with you the concept that you can think about version control not as a neccesary inconvenience that you need to put up with in order to collaborate, but rather as a powerful framework for managing your work seperately in contexts, for being able to switch and merge between those contexts quickly and easily, for being able to make decisions late and craft your work without having to pre-plan everything all the time. Git makes all of these things easy and prioritizes them and should change the way you think about how to approach a problem in any of your projects and version control itself.

Earlier this month Ryan announced that Think Vitamin had teamed up with TechCrunch for the 2009 Web App Survey. The survey runs until September 4th so there are only 10 days left to submit your responses.

Aimed at Web App owners and Web Start-ups the survey is anonymous, although you can provide details if you wish, and asks questions about your userbase, traffic, financials, team and more. The more we share the more we will all learn and benefit.

The results will be announced live at the Future of Web Apps London by Michael Arrington and an accompanying web site and free PDF will be made live a week after his presentation.

You can complete the survey right here on Think Vitamin. If you have any problems viewing the form, please fill it in here.