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/

I really appreciate the prominently placed policies about credential and data storage.

I've increased the contrast in the hope that it will be easier to read.

Fixed, thanks for letting me know.

Edit: parent comment was deleted; I'll look to update the template when I'm at a desk to make it easier to read.

I haven't managed to put an RSS feed up yet (sorry), but you should always be able find the latest issue at this link:

http://golangweekly.com/archive/golang-weekly-latest-issue.h...

Also, for Londoners, there has been some interest in starting a local user group:

http://news.ycombinator.com/item?id=5220389

I'm not sure what is happening with this right now, but it would be worth keeping an eye out.

Versioning ASTs -- very interesting. Are you documenting the development anywhere? I'd love to hear more.

I've been quite fascinated by ASTs (and verification thereof) ever since poking around Python's approach to it.

I currently use a modified version of https://github.com/philwareham/responsive-email as the template for http://coderweekly.com, but may move to these.

As you can see, I'm already using Foundation on the main website. I've found it excellent.

Take a look at Oracle Berkeley DB:

"Berkeley DB is not exposed to the end-user. It is totally hidden below the SQLite APIs. It acts as the storage engine in place of SQLite's own BTREE. An application written to use the SQLite version 3 API can switch to Oracle Berkeley DB with no code changes, simply re-link against Berkeley DB."

http://www.oracle.com/technetwork/database/berkeleydb/overvi...

I haven't had time to read the full paper, but it looks very interesting.

Pinboard's founder seems (understandably) a little unsure as to the future of that part of the service:

"I am optimistic that Twitter will clarify their terms of service with regard to personal backups. In 2012, it remains impossible for a Twitter user to do a full export from their Twitter account. The only way to effectively store and search tweets is through third-party sites."

http://blog.pinboard.in/2012/09/twitter_and_pinboard/

Looks interesting. Is there a limit on document size?

Note the warning from the README:

"Although this is a major upgrade version of pgModeler it is recommended NOT EXPORT the models created directly to production environments. Not all possible code generation were tested in this way, is its your own risk export the models into environments that are not intended for testing. The project's author is not responsible for any possible loss of data due the inappropriate use of this tool."

https://github.com/pgmodeler/pgmodeler#warning