motter

It's certainly worth looking at the standard flag package (http://golang.org/pkg/flag/) if you just need flag parsing.

I've also heard good things about https://github.com/spf13/cobra and https://github.com/codegangsta/cli.

That's a nice solution, though I've gone for a markdown admin widget instead.

This one if I remember correctly: https://github.com/timmyomahony/django-pagedown

I'm in the process of moving away from a static site for my website.

Simply put, a web interface is often more convenient so I can update things easier on the go, and it's good to have a place to host experiments too.

I have used various static site generators but none of them seemed to be significantly less work to get going than a small django app on heroku. Though I've been using Django for a few years, so there is simply no learning curve left.

It's surprisingly easy, though I believe the tests expect one to be configured (I haven't checked precisely why, or if it can be configured not to expect a database).

We whipped the landing page together quickly, it is definitely not a good indicator of the project design.

Our new design looks like this: http://test.lfgss.com/. We focused heavily on clear typography.

It's not quite finished, so parts of it don't work yet. But you get the idea. Feedback appreciated.

"How to Write Go Code" shows you this, and is a good read: http://golang.org/doc/code.html

"Social networks -- real social networks, not the online instantiations of them -- work best when the groups are relatively small, Dunbar's number is respected, and there's a level of insularity around any given group."

Agreed, and to add to your point, group identity is also a strong motivator for close-knit networks.

Forums are a good example of this. It's partly why I think communities (and the software they use) centred around a specific interest or activity will, for certain kinds of community, ultimately win over what we now call social networks.

It's the tools that are lacking: at the moment it seems far easier to set up a facebook group than work out what a community needs and provide it without technical knowledge.

(I have an interest in this area because tools for communities are what I left my job to work on: http://microco.sm).

I agree with the main conclusion here, but it's a stretch to reduce technology choices to a simple "new or not" dichotomy.

Let's say you're writing a new web service in Java, because it has features aplenty and is also the language your team is most familiar with. You're confident the JVM is a platform you want to build on.

Now you need to:

1. Choose a set of libraries or a framework. Do you go for Spring or Java EE, or for something newer like Play or Dropwizard?

2. Choose a build tool. Maven? Ant? Gradle? Maybe we'll write some scala, so SBT?

3. Choose tools for deployment, config management, etc.

4. A database.

5. And so on.

All of these tools have different trade-offs. There are so many trade-offs that I don't think blog post comparisons (or whatever) cut it. And so you have the "magpies" who try and figure out some of these trade-offs for themselves by experimentation. (That is what, in my opinion, hack days and 20% time are for, not your new production system.)

But don't listen to me, we wrote our new web service in Go ;)

More seriously, it was a major decision and I couldn't possibly write a few hundred words on my blog to justify it. I may write a few thousand, though.

`go vet` (checks correctness) and golint (https://github.com/golang/lint) are also extremely useful.

As a whole the toolchain makes working with Go code very convenient.

If you're in London, you might like to come to the Go user group which I run with John Graham-Cumming:

http://www.meetup.com/Go-London-User-Group/events/147685182/

Don't worry about the waitlist, people always drop out nearer the time.

There's go-wiki: https://code.google.com/p/go-wiki/w/list

Another good resource for new Go programmers is Dave Cheney's list: http://dave.cheney.net/resources-for-new-go-programmers

And (shameless plug), the archive for the Go newsletter, e.g.: http://www.golangweekly.com/archive/go-newsletter-issue-9/

Thanks for pointing that out. The static routes in the talk are just for illustration -- we use nginx to serve them in production.

One thing I haven't touched on at all is html template rendering, something I'd like to take a look at in detail at some point.

Would like to hear more about your experience with Go -- is there a writeup somewhere?

In that case, I don't know a number that can be used for that comparison. 18k is the total number of lines in the source code files; the SLOC will be different.

In hindsight, I should've left this number out. It was intended to give background to the overall program size, but it's a small detail that shouldn't be the focus of this discussion.

High compared to what?

It's just the output of

    wc -l `find microcosm/ -name *.go`

so is really just a rough indication of the size of the project.

None of the links work in the embedded version, but if you download the PDF they're fine.

Or you could fork selfstarter[1], which is what we used to allow users to reserve their username on http://microco.sm

[1] https://github.com/lockitron/selfstarter

"...it's better for us to focus our intent on excellence in our own right, rather than our impact on someone else's product."

This, in my view, is the salient point for startups when faced with competition. It's too easy to get distracted by zero-sum thinking.

Here goes: http://nightweb.net/#type=user&userhash=4zfhmwiio7kdp5oc...

How does the protocol differ from, say, tent.io?

Just in case anyone has the same issue: on my device (Nexus 4) it took a while for the UI to become responsive when first opening the app. Patience solved this one :)

This talk was given at the Go London User Group yesterday -- if you're in London, come along to the next one: http://www.meetup.com/Go-London-User-Group/