kingfishr

Oh, that'll be great! That's not quite the same as a sliding window of last 5 minutes, but it'll definitely work for my use case.

(Intuitively, a sliding window seems very hard/impossible -- how do you discard old events without keeping a complete record?)

Hey, this is very close to something I've been needing recently (and in Go, nonetheless).

Is there any way to get a similar thing for a sliding window of a stream? For example, to be able to report (estimated) 90th percentile latencies for server requests in the last 5 minutes, hour, and day.

Great demo!

This is probably obvious, but for the first time it occurs to me that motion blur is essentially the same as anti-aliasing. They are eye-tricking hacks to work around a lack of resolution in the medium -- screen resolution, in the case of pixel anti-aliasing, or "time" (framerate) resolution in the case of motion blur.

Recently I've been wondering if as very high-resolution displays become commonplace, anti-aliasing will become obsolete. If I could play an FPS video game on a 500dps monitor, would anti-aliasing make any perceptible difference? At some pixel pitch, even text anti-aliasing won't matter.

The same thing seems to apply here. If we had 5000Hz screens (and could run our animations quickly enough to keep up), would applying artificial motion blur buy you anything?

ATI?

You could also do this without a server at all. You could just have a script put your data into the html/js template and open up the page with something like bcat.

http://rtomayko.github.com/bcat/

Oh shoot:

http://gist.io/3135754

http://bl.ocks.org/1353700

Two of my favorite gist frontends, broken :(

Really? I feel pretty much the exact opposite way. I find the docs to be thorough, accurate, and concise.

I had this problem right when I started using rbenv. Eventually with some help I realized that just starting bash was slightly slow, and that all the various bash scripts that rbenv runs were compounding this for a 2+ second startup.

In my case, everything was fixed by moving the the things that only need to be run in login shells out of my ~/.bashrc (where they should have been in the first place).

See the bug I filed against rbenv at the time:

https://github.com/sstephenson/rbenv/issues/70

Since that time, I've been using rbenv exclusively (development and production) and it's been great.

This is a cool idea, and I love the convenience of deploying a single-binary app when using Go for servers.

When deploying web servers, though, I'd prefer to leave the images and other static resources out of my binary, because this means I can use an rsync-based deployment with --copy-dest and --link-dest. --copy-dest means that deployments are blazingly fast (I only have to copy changed files) and --link-dest means that deployments are cheap on space (unchanged files are hardlinked to the copies). Granted, bandwidth and storage are cheap and getting cheaper, but it still adds up, particularly for large server clusters.

I believe this also includes the bitmap marking GC changes which will make the GC copy-on-write friendly. This is pretty important for a lot of folks running Ruby web servers.

See, for example:

http://patshaughnessy.net/2012/3/23/why-you-should-be-excite...

Readline has vi mode, and it's amazing. I use vi mode in zsh, bash, ruby, python, mysql, etc. and I can't live without it any more.

I still have fit-of-rage moments when I try to use things that either (a) try to roll their own line editing or (b) use some inferior readline clone.

rlwrap is nice, but typically the shells I'm using have other functionality that I miss too much (tab-completion) if I use it. For instance, I've given up using rlwrap with the Scala repl for this reason.

We don't have immediate plans for other VCSs.

None of the people who built Barkeep use other VCSs on a regular basis, and we initially built it around our own needs.

Right now our code is tightly tied to grit (https://github.com/mojombo/grit/). We plan on moving off of grit at some point (perhaps to libgit2/rugged), and that would be a good time to abstract our VCS layer, opening up the possibility for use with other systems besides git.

I'm American, and I've never paid for an SMS in my life.

You can block texts via your carrier so that people can't cost you 20 cents or whatever by sending you a text. I'm pretty sure that all phone companies have this. This is what I did before the age of smartphones.

Now I still block texts, but I use Google Voice and only give people my Google voice number, never my real phone number. I receive texts through the gvoice app on my phone. Calls go through gvoice (and I can filter/redirect them). I never have to bitch about people costing me money by sending me texts :)

And it has 'pragmatic control' :D

I don't know much about Django/Flask, but the arguments presented seem to apply to Rails as well. At my company we're moving off of Rails completely in favor of SOA structured architectures where the web views and APIs are built on Sinatra.