ben_h

Absolutely. At theconversation.edu.au we run a content site—we publish the news, which is the same for everyone. This means we can cache the front page and all the articles as static HTML, and then annotate the page with user info for signed-in commenters, editorial controls for signed-in editors, and so on.

(We have a separate cookie that is present for signed-in users, so the fronted knows whether it should fire the annotation request.)

The result is that we can serve a sudden influx of unauthenticated users (e.g. from Google News or StumbleUpon) from nginx alone, which gives us massive scale from very little hardware. It's likely that the network is actually the bottleneck in this case, and not nginx.

Great post. I didn't understand the role of controllers and directives but this explained them well with a thoughtful walk through.

The idea of wrapping distinct chunks of logic in separate directives that can then be sprinkled around the DOM declaratively is great.

In my view this is a welcome alternative; in my (maybe limited) experience, many other JS frameworks have you writing substantial amounts of glue code (i.e. bug-magnet code) to achieve comparable things.

You can configure `git push` to push just the current branch to its configured remote, by setting 'push.default' to 'upstream'.

`git config --global push.default upstream`

The relevant docs (droplr'd, since you can't anchor-link into the online manpages): http://d.pr/Rlqn

Hope was definitely a bad choice of word. By that I meant, the sort of tight query you'd hope an ORM would deliver.

Anyhow, it's a matter of taste, but what may appear at first as hieroglyphics actually is straightforward. It's just that concision here means some packed meaning and some assumed knowledge, so you have to know how to read it. In this case, that's an easy trade-off for me.

I'm not familiar with SQLAlchemy, so I find your example equally hard to read, compounded by there being much more code to spelunk through to understand.

Different strokes and all that, though. There's room for plenty of frameworks :)

Good point, #merge isn't itself an arel method. I say arel because it's the core sitting behind the #merge / #where / #joins frontend -- but AR::Relation deserves credit too :)

The frame showing Facebook vs Greek debt is particularly good. We ran a piece in a similar vein last week: http://theconversation.edu.au/how-david-beckham-caused-globa...

Good explanation, thanks.

The part I don't understand is the POST hitting the victim app. I don't know django but rails apps require an authenticity token to be included in all non-GET requests. How does the attacking app satisfy this token check?

Worked a treat, cheers.

Agree to disagree :)

The only Flash component is the embedded screencast, which is hosted at Vimeo and downloadable as an mp4: http://vimeo.com/6782671

I should have copied and pasted instead of typing it out :) Thanks for the correction, fixed.

Thanks for submitting this, speek :)

For those that are interested in trying out babushka, here's a 30 second crash course. To install:

    bash -c "`curl -L babushka.me/up`" # If you're on a Mac
    bash -c "`wget -O - babushka.me/up`" # If you're on Ubuntu

Some good examples to start with:

    babushka rubygems # Installs, updates, or adds gem sources as required for your system
    babushka homebrew # Sets you up for sudoless `brew install`s
    babushka Cucumber.tmbundle # Clones the latest, installing / restarting TextMate as required
    babushka Chromium.app # Pulls the latest Chromium nightly to /Applications

If you want to see what will happen without making any changes, use `--dry-run`:

    babushka Transmit.app --dry-run

If you're on a Mac, you can follow along in TextMate too using `--track-blocks` — babushka points out each piece of each dep as it runs them. (This also works with `--dry-run`, so you can inspect the code a tree of deps would run.)

    mate /usr/local/babushka
    babushka 'Ruby on Rails.tmbundle' --track-blocks

Any questions, get in touch with @babushka_app on Twitter, #babushka on Freenode, or email hello@babushka.me.

Cheers — @ben_h

[edit: fixed the babushka.me/up links.]

It's a really good question, and one I probably should answer more directly on the website and in the README.

As I wrote above, I have a lot of time for these other tools—in fact the creators of sprinkle (Marcus Crafter) and deprec (Mike Bailey) are both mates of mine here in Melbourne, Australia—and I don't want to just duplicate their work. I'm trying something different here. Deployment is definitely still important to me with babushka, but I'm trying to build a more general tool that makes it as fast and pleasant as possible to automate getting to some end goal.

And that's one of the other differences—babushka is goal-oriented, not task-oriented. Unless there's some specific incompatibility, you can install babushka on (for example) any Mac in any state with this

    bash -c "`curl -L babushka.me/up`"

And then running this

    babushka homebrew

Will get you all set up with homebrew. But what it does is achieve the end goal of having homebrew set up—which might mean doing nothing, or cloning a git repo, or possibly just doing a `git reset --hard` to drop a binary in place. It depends on the system. The upshot though, is that if you're working on some other problem and a new colleague needs homebrew, you can run one command and you're done, instead of getting sidetracked for 15 minutes.

In focusing on that, I sacrifice usability in other areas—for example, right now there's not really any such thing as an unattended run using babushka, because most complex dep trees require user input at runtime. It's still very much a hands-on process. And that's cool with me—there are already tools out there that solve those problems, and solve them well.

I'm looking at working on deployment with babushka more with @glenmaddern, @dgoodlad and some other Melbourne hackers soon. But I'm very conscious of all the existing tools out there, and I'm a strong believer in deferring to the right tool for the job whenever possible. So I'm looking to integrate with existing tools where it makes sense, and solving old problems in novel and awesome ways whenever I can. :)

Hey, that's cool—pretty tempting to start using that reference retrospectively. Maybe a few canvas-animated butterflies on the website? :)

Cheers!

Hi, great questions.

Chef and puppet have a lot to offer. In particular, there are things that chef and puppet can do that babushka can't, like orchestrating ecosystems of multiple machines, and provisioning new hardware automatically.

Deployment is a problem that I'm very interested in, being a web developer and maintaining my own production machines, and I think babushka has a lot to offer in that area. However, I don't think of babushka as a deployment tool. I think of it as a "remember what I researched or learned the first time" tool, and part of that is deployment.

In building it, I'm aiming to build the most concise, powerful DSL I can for automating chores, and at focusing it as hard as I can towards the "no job too small" end of the scale.

My other main motivation is making babushka immediately useful and approachable, both as a user and a contributor—i.e. I want you to be running deps and seeing results within 2 minutes of discovering the app. And I want you to be able to write your own deps as easily and quickly as possible, push them to github with a single command, and have anyone else run or incorporate them into their own trees of deps equally easily. Most of that is already possible today using automatic dep sources, and the remainder I'm working on. :)

For example, Josh Bassett has been building a template for installing vim plugins: http://github.com/nullobject/babushka-deps/blob/master/vim_p... - which means you can automate the installation of your own plugins by writing a babushka dep like Josh's:

    vim_plugin "vim-cucumber" do
      source "git://github.com/tpope/vim-cucumber.git"
    end

You can run that dep with a single command, even if you've never used Josh's dep source before:

    babushka nullobject/vim-cucumber

And so on, to configure anything and everything you like. It's already doing this job, which I'm really excited about. http://twitter.com/harvinius/status/13116470017

Similar things are already working well for textmate bundles, OS X app bundles and installer packages, git repos, and so on. The idea is that babushka is purely the engine (plus enough deps for it to install itself), and it should be as fast and pleasant as possible to not only write deps like the vim-cucumber one above, but to create new templates and make new tasks I've never thought of. You can extend the DSL using the DSL. :)

So — I have a lot of time for tools like chef, and probably have a lot to learn from them too. I'm building babushka to be complementary to those tools. For example, part of larger deployments is doing specific, more focused jobs at certain points, which is something that babushka is just right for.

Yep, I was aware of that :)

I chose babushka because here in Australia at least, the nested Russian dolls are known as babushka dolls. (Also, Matryoshka is kind of already taken by the video container format http://www.matroska.org/).

And hey, I'm cool with babushka being a kindly grandmother that helps you remember things you've researched, as long as you explain them in its DSL first :)

Speculation, but I think it makes sense:

http://blog.acooper.org/2009/12/speculation-the-real-villain...

tl;dr: Labor are using the filter as a political means to an end, to court the conservative Christian senator Steve Fielding's vote on the ETS (Fielding is more or less a climate change sceptic). Fielding, along with independent Nick Xenophon, hold disproportinate power in the Senate.

(the irritating html-escaping bug will be fixed as soon as voting's over - couldn't squeeze the fix inside 10 lines!)

I was in a team of four, we built Twippet: http://railsrumble.twippet.com

It's code sharing over the twitter network. Throw up some code snippets, enter your twitter creds (pass not stored) to verify your twitter account and scrape your followings, and then you get a twitter-feed-esque list of searchable, taggable code snippets.

If you're going to serve Javascript over SSL, you need a full SSL setup including a valid certificate, etc. If you have that, you may as well just serve the login form itself over HTTPS, redirecting back to HTTP after logging the user in, and forget the Javascript altogether.