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.
I had the same problem (updating content), so I wrote a small script to download deltas from my Dropbox and parse them. Now I can edit my posts with vim:
What'll happen then? My Django-based blog handled hundreds of thousands of visits in a day without breaking a sweat. What it does is basically "fetch the whole page from memcached and serve it".
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).
It can be configured not to expect a database. You just subclass the DjangoTestSuiteRunner to skip setting up and tearing down the DB, then set that as TEST_RUNNER. See here for an example: http://stackoverflow.com/questions/5917587/django-unit-tests...
"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).
The online communities I've seen work best generally:
⚫ Are selective. Actual or de-facto barriers to casual participation exist.
⚫ Are focused around a specific interest. Usually topical, occasionally by geography.
⚫ Are based around discussion from people interested in receiving as well as transmitting. The traditional exceptions to these are trolls and spammers, but I had a brief experience on mailing list that was heavily subscribed by people in the entertainment industry some years back. It was horrible. For, several reasons: people in love with the sound of their own voice, top-post/forward style messages (3 lines on top of 3000 wasn't uncommon), and ultimately far too many participants for the forum. Even though it wasn't spam / trolling / SEO, it was about the worst and most useless forum I'd ever seen.
Having well-established formatting and quoting styles matters. That's one of the things I enjoy about reddit, especially as compared with G+: the richer markdown, and inclusion of blockquote syntax, helps hugely. One idiot on G+ (who I finally blocked, for various reasons) had the habit of using an inline quote/response format, but his marking syntax (python-style quote tagging, I think), was all but impossible to follow. Dealing with his BS and difficult-to-follow style really weren't worth it. Oh, and it'd be nice if HN had a proper blockquote markdown as well ...
Also from G+: I noticed that without a proper "plaza", what you tended to end up with were, effectively, cocktail parties: hosts (users) who has a sufficient level of followers that they'd kick off conversations, as well as a good seed, and policing of guests to keep everything in line. Discussion nucleated around posts and specific users. Not communities, not topics, not pages.
Communities were and are effectively dead outside a very few exceptions, largely due to the inability to filter out crap. And even with the cocktail-party mode, there was a very narrow goldilocks zone: too few followers and discussions wouldn't get off the ground, too many and it rapidly got inane (effectively somewhere between a college kegger and a street brawl), and hosts who were either uninspiring or absentee would (respectively) garner similarly inane commentary and/or have largely directionless commentary.
I find the dynamics of discussions fascinating.
Hrm. I'll take a look at your project, but that website gives a horrible first impression. Try to make your text text. Not some kind of art statement.
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.
"All of these tools have different trade-offs. There are so many trade-offs that simple blog post comparisons don't 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.)"
Absolutely. Someone has to be the designated pseudo-magpie in order to architect the stack. Doing so effectively though requires a dev who can look past the buzzwords and elevator pitches to really get to the core of it. Essentially they have to be magpie and anti-magpie at the same time. Does this new technology really offer me any benefit or is it the same end result wrapped in new clothing?
Right. Because like it or not, justified or not, when new tools are developed, old ones are abandoned. Sometimes if you stay with what you believe is the tried and true, you end up having trouble supporting new features.
This is true mostly for libraries, though. If you switch your main programming language more often than once a decade then you're either a true magpie or you just don't know how to pick them.
Division by zero in floating point is well defined and useful, and does not produce a runtime exception. So why is this a compile time error?
Edit And it produces the wrong result for division by negative zero: http://play.golang.org/p/DKoVG0Vlaf It should be -Inf, not +Inf. Go's floating point math is whack.
Does it only throw a compiler error if you use 0 as a constant? Let's say you have a function that returns an int; does it force you to check if that int is non-zero before using it in division?
It can only throw a compiler error if you use a 0 literal (or constant), because it cannot determine the runtime value of a variable denominator at compile-time (obviously).
It does not force you to check, but if you wanted to "catch" the "exception" (really, "recover from the panic"), here's how you would do that. Note that this is admittedly a somewhat unidiomatic use of recover(): http://play.golang.org/p/dAQ01dus9Y
For others: note that that's only because Queue29 assigned 0 to a variable before using it as the denominator, so there's no way for Go to catch that at compile-time.
If you divide by a literal 0, this is a compile-time error, so there's no panic (and no need to recover()): http://play.golang.org/p/E0jSDAHwtg
I've also heard good things about https://github.com/spf13/cobra and https://github.com/codegangsta/cli.