But then I think you are giving up the main advantage of using mechanical turk over just roughly matching pixels. It is possible matching pixels will get the wrong answer where a human, with the context of being human, will know what the image is supposed to be and get the write answer, captcha style.

Example: an iron fence with a scenic view behind and where the slices are too small for someone to match only two.

Speaking of CAPTCHAs, a smaller version of this would make an excellent one.

Er, well maybe not, given the ease of programmatic solutions.

This would be beat with a very high success rate if it were a captcha.

What about doing the same thing, but fuzzing a few pixels from each edge to avoid pixel distance matching? You could even make the edges just plain black for a few pixels from each edge. The human eye would be able to complete the image (it would just look like it has black bars), but I'm guessing it would be enough to prevent a simple algorithmic solution.

Edit: This is essentially the same idea as the iron fence posted above.

After struggling through using sbt and Maven/Ivy I can say it is categorically worse than what I have used in other languages including ruby-gem python-pip clojure-leiningen (a jvm language) and node-npm. When I say worse I mean doing what the majority of developers want from a module system: easily install modules, not provide a complicated mess of configuration and versions.

This isn't to say scala couldn't adopt a better system, but I don't think the community has an incentive because scala's main appeal is that it has a steep learning curve, but after you get over the hump you can do everything you want and more. I just think that high barrier to entry, as indicated by the post, may not be worth the benefits.

Did you ever try buildr? I've never used sbt, as, coming from a Ruby background, the fact that buildr sits atop of rake appealed to me more than sbt. It uses maven repositories underneath the hood, but then again, as I understand it, so does clojure-leiningen.

Part of me thinks you're conflating two separate things: build systems and package repository systems. Even people who hate Maven's build system (myself included) tend to agree that Maven's package management system is really good, and as you like clojure-leiningen, you must agree in some sense.

Could you go into more detail about what problems you had with sbt? What you describe doesn't really match up with my experience. If you want to use it simply to compile Scala code you can just do 'sbt compile' in the directory containing the Scala files. If you want to add dependencies you just create a file called 'build.sbt' and add lines like:

  libraryDependencies += "org.scala-tools" %% "scala-stm" % "0.3"

Although this may not be clear since sbt presents 2 configuration methods, a simple one (as seen above) and a complex one.

It's interesting that couchdb gets little love (as evidenced by google trends), but it has document storage by index, easy enough to install, copy on write so has no global lock, sharding with bigcouch, and all client access is entirely REST... it may be couch is a little hard to grok, I dunno.

It isnt packaged and marketed as cleanly. It takes hunting and learning on your own to get good with couch, and map reduce is no where as easy to get started with as mongo queries (although the addition of unql may improve things next year).

Also there is no single, central steward and authority on couch. All of this stymies traction and confidence even though the tech is great.

This is true. I think couchdb tries to be all things to all people rather than just focusing on being a great data store. It's a database like mongo, it's a mobile database like sqlite, you can use it to host apps with couchapp, you can use it as a map-reduce cluster like hadoop, etc. I would rather have just a solid no-sql database that solves that problem. I like couch better than mongo for the reasons I mentioned, but I know couch also has problems and still haven't found a good third option.

Which all sounds rather like Postgres. It's harder to use because you have to know what you're doing, and it's not as popular even though it's better on some axes that are significant if you're building something solid.

Couch doesn't have great documentation, and doesn't have official native client drivers. Oh, and it's slow (though you can tune it, and it doesn't crumble under load).

Also, CouchDB is all REST, so many people just write their own drivers.

I think it's also important to add-- writing a "driver" for Couch is, basically, writing an API that essentially calls some HTTP library with some options set, and then parses the resulting JSON data.

For example-- Ektorp, one of the more popular Java libraries? Wraps the Apache HttpClient, and uses the Jackson library to parse JSON. CouchDB4J does something similar, only it uses JSON-lib. A good Java coder could probably write their own fully-functional driver in a day.

jquery.couch.js is basically just a wrapper to $.ajax().

node-couchdb uses the built in client library for node. A good node coder could probably write a fully-functional driver in an hour.

So I don't think it's a matter of "download the official driver" as much as it is "download your platform's preferred JSON parser".

This is true until you realize you'll need to support keepalive and chunked encoding to write a reasonbly good driver. Two things that often require significant effort, if not custom coding, to make work with http libraries.

hmmm, I suppose I've always associated it with some manner of debriefing, i.e. a mission post mortem. But, to avoid confusion I've updated the title.

There's a difference between trusting someone with your physical hardware and handing them your credentials on a silver plate.

There's also a pretty harsh difference between the security practices at Amazon and the practices that Opscode displays in their OSS-code.

And the arms race continues. I expect this will work only as long as law enforcement doesn't recognize it's a ram only box, after which they'd just keep it plugged in or drop it into liquid nitrogen to preserve the bits if they cared enough.

Easier said than done, power can be cut in an instant or even automatically (triggered by unauthorized entrance to a facility, for example).

Dynamic ram refresh intervals are mindbogglingly conservative, especially if you're not running near the upper-temperature limit. In other words, DRAM doesn't lose information anywhere near as fast as the refresh intervals might suggest.

If they get to it in time, that probably won't matter: http://www.nytimes.com/2008/02/22/technology/22chip.html

It will give a whole new meaning for when cops shout "Freeze!".

Personality will make more people love you, but will also make more people hate you. However, both drive page views and attention.

It doesn't have to be theory. Very basic python scripting could help anybody. For example, my sister wanted to reformat the naming of 500 or so photos.

Time to do this by hand: 30 soul crushing minutes

Time to write a python script to do this: 5 minutes

Hash sort is surprisingly fast:

  for x in [0 ... VA.length]
    ind = VA.get(x)-1
    VA.swap(x, ind + VA.length)
  for x in [0 ... VA.length]
    VA.swap(x, x + VA.length)

In 1/2 as many swaps:

  for x in [0 ... VA.length]
    ind = VA.get(x)-1
    while ind != x
      VA.swap(x, ind)
      ind = VA.get(x)-1

That's cheating somehow...

Trading a tremendous amount of memory for speed. Try replacing a list of integers with a list of Images. You might lock up the browser.

That's pretty cool. Is that related to this? http://arxiv.org/abs/cs/0408040