ericlavigne

http://vimeo.com/2094487

The difficulty/easiness of an action has six components: time, money, physical effort, brain cycles, social deviance, and non-routine.

Thus, the overall difficulty/easiness of an action depends on the resource profile of the person performing that action. That profile varies wildly from person to person, as well as according to context. Awareness of your own resource profile is important for self-control, and awareness of other people's resource profiles is important for persuasion.

The captology site also discusses using triggers to tilt the odds in your favor. The most effective variety of trigger depends on both difficulty and motivation level.

http://captology.stanford.edu/projects/behaviordesign.html

For now, I need to focused on improving my calculations, fetching all the data I need (what I showed in the article is just the tip of the iceberg), and finding better ways to infer relationships between projects.

This video shows Daniel Pink delivering an 18-minute presentation at TED on the same topic: http://www.ted.com/talks/dan_pink_on_motivation.html

https://github.com/samizdatco/arbor/tree/master/docs/sample-...

Note that while the article deals with similar sources of noise, it also deals with a larger signal. They are trying to time a decryption process, which has a high computational complexity by design. We are talking about timing the difference between checking for equality of the first few characters of a string, versus checking for equality between all characters of strings that are unlikely to be more than 20 characters long.

Chrome tells me that it took 109 milliseconds to load a 50-line stylesheet on my personal website.

http://ericlavigne.net/

A quick and dirty experiment showed that the following comparison of short strings takes between 3.5 and 5.9 milliseconds for 10,000 runs.

(def partial-password "abra")

(def guess1 "abrab")

(time (dotimes [i 10000] (= partial-password guess1)))

Whereas a similar comparison of longer strings takes between 5.8 milliseconds and 6.0 milliseconds.

(def password "abrakadabra")

(def guess2 "abrakadabl")

(time (dotimes [i 10000] (= partial-password guess1)))

So the operation we are trying to time shows a lot of variability even if you can isolate it by running that code directly in a terminal, and a typical small HTTP response takes up about a million times more runtime.

Yes, these are very crude estimates. Good profiling is much harder than this. Still, if I knew this was the only security hole in my application, I'd be feeling very safe.

The password check is a database query that, since there are no indices on the users table, will check for string equality in every row of the table. Timing the response tells you a lot about the number of users, and the instantaneous server load, not so much about how closely the latest guess matches someone's password.

Even with a more optimized program, I'd be surprised if "fairly easy" were an accurate characterization of the effort to separate timing of comparing one extra character of a password from all the other stuff going on during a request: database access, routing, parsing query parameters, load from other requests, garbage collection pauses, network latency... The signal-to-noise ratio is just too low.

After waiting 10 minutes for an opponent, I opened a second tab and played against myself. Until your application becomes immensely popular, and this issue goes away, it would be nice to have an estimate of wait time.

Just keep track of recent "new opponent" events (keeping times of the most recent 10 events is sufficient) such as new visitor arriving, game ending, or server starting up (the last one just handles the edge case when you are the first player to load the application). Time elapsed since the earliest event (including only the 10 most recent events) divided by the number of events (again, this is at most 10) yields a reasonable estimate of wait time.

Alternatively, you could pair someone with a computer player if they've been waiting for more than a minute. https://github.com/ericlavigne/tic-tac-toe/blob/master/src/t...

> The more bugs in the system, the shorter you can think ahead.

Very true. Too many bugs prevent me from thinking ahead, forcing me to program very slowly by trial-and-error.

> If you have to work with some buggy system over which you have little or no control, which is often the case, you are limited in how much you can think ahead.

There are many buggy systems over which I have little or no control. I often, however, can decide not to work with such systems in the first place. Since such buggy systems have so much effect on my productivity, it is worth putting a lot of effort into avoiding them.

> This may be why so many Haskell examples are math-centric: it allows you to look the farthest into the distance.

It may also explain why Haskell has so much built-in error checking, why Haskell programmers have been pioneers with respect to new testing strategies (Quickcheck), and why Haskell programmers try to separate `pure` and `impure` code so that as much of their program as possible can be math-centric. They are trying to spend as little time as possible with buggy code that slows them down.

> That's no doubt true, but that can only get you so far

Thinking ahead is great only under ideal conditions, as you pointed out. If you accept whatever conditions are there, thinking ahead can only get you so far. Taking responsibility for such conditions, and trying to change them, can get you much farther.

--------------

I actually don't use Haskell very much, but Clojure has a lot of similarities. Like Haskell, Clojure has a lot of support for abstraction and allows you to do a lot with very little code. Perhaps even more importantly, Clojure libraries tend to be simpler, easier to understand, and less buggy than their Java counterparts.

I do agree regarding how nice it is to use Heroku. My only issue with them is that they only support Ruby and Node.js, so I need to take my Clojure applications elsewhere.

There is already a paragraph towards the bottom that discusses how the money will be used. It could also say that you are still researching treatment options. $10,000 is an optimistic estimate for what it will cost to save your arms, and you're collecting up to $30,000 which will help you to get the best medical care possible. Any money not spent on medical care will be returned.

Just throwing out an idea. I've never run a charity campaign and don't know what works. Just make sure to get those links on webcrunchers so everyone knows that it's really you who's asking for help and not some scammer. ;-)

http://www.en2go.com

It is common for celebrities to be impersonated on Twitter, and this is not a verified account.

John Draper is a security expert. His MySpace page has a video of him talking about how to avoid getting scammed online. Surely he understands the need to establish his identity before asking for money online. Yet, I don't see any mention of this situation on his website.

"Captain, it would be great if you connected your known web identity (webcrunchers.com) with your identity on facebook (this account) and/or the donation website. Put a link on the sidebar or something because some people get suspicious.

Hope you get well soon."

http://www.webcrunchers.com/

http://www.myspace.com/jdcrunchman

(Found webcrunchers via Wikipedia http://en.wikipedia.org/wiki/John_Draper and found MySpace via webcrunchers.)

http://common-lisp.net/project/cl-weblocks/

http://common-lisp.net/project/ucw/

http://docs.racket-lang.org/web-server/

Have you gotten much response from businesses that want to use your service? How are you advertising?

Name: Eric Lavigne

Email: lavigne.eric@gmail.com

Twitter: ericlavigne

Something I made: https://github.com/ericlavigne/island-wari

Replace "lazy" with "non-strict" and I think you're on to something. Strict and lazy both specify a particular evaluation order, but you are talking about leaving the evaluation order unspecified and letting the compiler or runtime decide which evaluation order is best.

I love today's GC, which allows me to mostly forget about memory management, but if GC still meant waiting hours for a collection I would be more inclined to manage my own memory.

Clojure's lazy sequences, combined with doall to force strict evaluation when you want it, seem like a nice compromise for now, but will likely seem archaic when a good evaluation-order optimizer is developed.

http://jqfundamentals.com/

(AJAX is chapter 7)

I also wonder if (runtime-checked) pre/post-conditions could bring much of the benefits you speak of, with the option to use them sparingly and avoid the "drag" part. In other words, make the type annotations optional and only put them where it looks like the extra safety is important enough to be worth it.

In any case, I'll cross that bridge when I get to it. Thanks for the heads up.

(I'm more interested in Clojure, and would have gladly paid the $1k in expenses to attend the Clojure Conj if my employer hadn't offered to cover it. http://clojure-conj.org/ That was just a two-day event, rather than a whole month of training.)

It sounds like you said (1) you had a great experience with jQuery, (2) writing Javascript is a much worse experience with Closure Compiler, (3) therefore use the Closure Compiler and not jQuery.

Could you please explain why you like the Closure Compiler, so I can understand the jump to (3)?

(1) "running circles around fellow devs", "JS, with it's loose typing and object notation was just a fast place to write code" (2) "now, I'm writing typed code, in a non-typed language, and there's not much to really like about the language" (3) "Start using the Closure Compiler, and use less jQuery"

http://twitter.com/cemerick/status/28359615311

http://github.com/relevance/functional-koans

Each of the following languages has its own branch: Clojure, FSharp, Haskell, and Scala.

The quote comes from section 1.2 on configuration spaces. http://mitpress.mit.edu/sicm/book-Z-H-9.html

Can somebody explain this? Isn't the number of parameters that specify an orientation two, totaling five?

Pick two atoms in the pin and specify the location of one atom. Now the other atom can only be located on a sphere around the first atom. The sphere is a 2d surface for which you need two parameters.

It is not enough to specify the position of two atoms. You need to specify the positions of three atoms. The first atom can go anywhere, so it contributes 3 parameters. The second atom is limited to the 2-D surface of a sphere around the first atom, so its position only contributes 2 parameters as you said. The third atom is limited to the 1-D edge of a circle around an axis that connects the first two atoms, so its position contributes 1 parameter.

If you choose the position of the point of a pencil, and also a point in the center of the pencil's eraser, the pencil can still spin, with the pencil lead as the axis.

Another problem is that you can encode two real numbers into one, for example by interleaving digits. So you could specify the entire pin with one real number. What exactly is the problem here and how can you eliminate it? You need to impose more conditions than simply continuity, because you can make a continuous bijection [0,1] <-> [0,1]^2?

The concept of dimension of a vector space is handled much more rigorously in proof-oriented linear algebra textbooks. This book gives a loose definition for the dimension of a configuration space, which is just good enough to be able to follow the issues they are talking about. You looked too closely at their definition and discovered a flaw. Dimension is not really the number of parameters required for encoding a position in the space, but this can still be a good enough working definition for many problems if you don't get too fancy about your encoding.