nix

"Slope" implies that the denominator is a distance. In the context of a graph on paper or screen, it is clear how rise and run are mapped to distances. It's a totally sensible definition: slope only makes sense given a choice of axes.

"Rate" implies that the denominator is a timespan. This does not make sense, as there are many slopes which are not rates and which are not presented as rates.

It's kind of a silly thing to worry about, but Khan's answer is unequivocally better.

No ventilation? Have you tried running full blast with a temperature probe present?

"Shift" is a big omission, though you can guess at it from the emphasis on certain numeric keys. One of the great things about Python is that there are fewer chorded characters. It's also one of the worst things about Lisp on a standard keyboard.

you're free to replace one by a facade around a remote service.

RPC rarely lives up to this promise. Starting simple is certainly a good approach, but don't fool yourself about how hard it's going to be when you need to deal with latency and partial failure later.

How is demurrage different from inflation? Isn't the financial system already set up to encourage savers to invest their assets rather than storing value as bills under mattresses?

The Freebase API is a hosted service. MQL is designed for fast HTTP queries that power interactive webapps.

SPARQL is harder to learn and set up, but allows for more complicated queries that might require offline processing.

(I designed the first version of MQL)

This is interesting, but pedantic. Many words have a well-understood meaning that is only loosely connected to their etymology.

Better to say that "present-day publishers work hard to make the cover something you can sell a book by."

Title is wrong. NASA's Blue Marble is about 3.7 gigapixels.

They are using a bad dataset. Some of the discontinuities you see are administrative boundaries between National Weather Service forecast offices.

http://nixweb.com/dust/ is my version, for the SF Bay Area only. It was 15 years ago so pardon my Java applet.

This works by sampling a static scene a very large number of times with a laser flash and a "streak tube" camera that records a picosecond-long movie of the light arriving at a single scanline.

A normal video camera records a frame at a time, this one records a scanline-sized movie at a time. The raw data is noisy but the scene is static so they can sample the same line over many flashes.

After a few minutes of scanning they have a trillion fps video where you can see a wavefront propagate at the speed of light. Amazing.

More data is nice, but the experience with citizen-operated weather stations suggests that the data is useless without extensive quality control. Calibration is hard, and mobile sensors are particularly challenging. What happens when one of the sensors goes into a climate-controlled building, then takes an elevator to the 30th floor?

The Google Apps case is harder because of the existence of a separate "domain administrator" role with some powers over the user account. Many people on Google Apps domains are employees using their work email for personal business. If you want to create durable identities around email addresses, these people are kind of a problem, because the obvious way to do things gives control of their digital identities to their employer's IT department.

A standard here would be very welcome, though I still haven't seen anything I'd call intuitive. Visually distinguishing tap, double-tap, and "long press" is pretty difficult.

The Open Exhibits Gesture Library is another option. It looks like they broke the old link at http://openexhibits.org/gesturelibrary but you can see an example gesture at http://openexhibits.org/support/gestures/35/two-finger-scale and click around for the rest.

The Cue icons will be clearer at small point sizes, but if you have enough pixels the (mostly) graceful hands in the Open Exhibits library feel more appealing than Cue's big fingernail.

Realtors can and do handle price reductions by delisting and relisting the property. This hides the ask price drop, and zeroes the days on market, to the advantage of sellers and realtors. A brief look at Trulia's "methodology" description suggests that they are just mapping these easily gamed MLS numbers.

Neat. It makes sense that you'd have a fast-path for deflecting objects that are suddenly in your face.

Lots of interesting stuff here on factors affecting reaction time: http://biae.clemson.edu/bpc/bp/Lab/110/reaction.htm#Type%20o...

Your experiment must have been set up differently though - the fastest time they mention is 180msec for teenagers.

There's more than enough hacker-appropriate linkbait to fill the front page, if that's what the readership wants.

Large areas south of market.

liquefaction hazards for SF: http://gmw.consrv.ca.gov/SHMP/download/pdf/ozn_sf.pdf other PDFs: http://gmw.consrv.ca.gov/SHMP/html/pdf_maps_no.html

People forget that you can just use C for the simple stuff. Many of these Objective-C classes are slow, verbose, buggy, and poorly documented compared to the equivalent open source C libraries. In many cases the C API is just as nice - maybe slightly less fancy, but polished from years of actual use. Why use ASIHTTPRequest or NSHTTPRequest when libcurl is mature and fast and cross-platform? What do you really gain by wrapping Objective-C around your regex or date handling? You'll find out when you start profiling (or porting to any non-Apple system).

The Objective-C language (Smalltalk in C) was a nice idea (in the 80s...) but newcomers to iOS should be aware that the non-UI parts of the Cocoa/UIKit libraries are garbage compared to what C programmers have built over the past thirty years. I've had to replace enough of the ObjC libraries I've used with plain C that I just start with the C code now.

You infer it from the existence of 10,000 year old musical instruments.

See http://en.wikipedia.org/wiki/Diatonic_scale#Prehistory - which also says that the circle of fifths was described much earlier than I thought.

The drawback to this explanation is that the diatonic scale is 10,000 years older than the "circle of fifths". So it presumably had some appeal to musicians as well as to music theorists.

Supposedly there is a mathematical reason for the 2-2-1-2-2-2-1 spacing of the major scale. If you take all possible pairs of notes in the diatonic scale, you get a richer distribution of intervals than you can produce with any other seven-note selection from the twelve note scale. Similarly, the classic pentatonic scale provides the best set of intervals for any five-note selection from the twelve. A better set of intervals might lead to a better choice of chords too.

This is my somewhat fuzzy recollection from a paper I read a long time ago. Someone out there can check with three lines of R, right?

My admittedly biased view: I spent two years of my life trying to make the JVM communicate gracefully with Javascript - there were plenty of us at Netscape who thought that bytecode was a better foundation for mobile code. But Sun made it very difficult, building their complete bloated software stack from scratch. They didn't want Java to cooperate with anything else, let alone make it embeddable into another piece of software. They wrote their string handling code in an interpreted language rather than taint themselves with C! As far as I can tell, Sun viewed Netscape - Java's only significant customer at the time - as a mere vector for their Windows replacement fantasies. Anybody who actually tried to use Java would just have to suffer.

Meanwhile Brendan was doing the work of ten engineers and three customer support people, and paying attention to things that mattered to web authors, like mixing JS code into HTML, instant loading, integration with the rest of the browser, and working with other browser vendors to make JS an open standard.

So now JS is the x86 assembler of the web - not as pretty as it might be, but it gets the job done (GWT is the most hilarious case in point). It would be a classic case of worse is better except that Java only looked better from the bottom up. Meanwhile JS turned out to be pretty awesome. Good luck trying to displace it.

SWF was the other interesting bytecode contender, but I don't know much about the history there. Microsoft's x86 virtualization tech was also pretty cool but they couldn't make it stick alone.

When the continuation gets invoked by the event-handling loop, the stack is reset.

You're not compiling to C here: "the stack" may be a chain of heap-allocated activation records that are still live as far as GC is concerned. What you're describing might work but you'd want to test it to be sure.

EDIT: On reflection I agree that the setTimeout() approach should free the stack, however it's implemented.

What the author is missing: tail recursion in constant space is an implicit requirement for practical use of CPS transformations. In fact this is probably the single biggest reason for wanting efficient tail calls in a language.

ECMA doesn't require efficient tail recursion. Caveat programmer.

The word "visualize" makes this a somewhat leading question (though personally my process is visual/tactile).

The best book I know of about this is Jacques Hadamard's The Psychology of Invention in the Mathematical Field. He asked this same question of the important mathematicians of his day - and because he was Jacques Hadamard, they answered. Einstein's response in particular is fascinating. Although math is published in symbolic form, nearly all the mathematicians surveyed reported that they thought in images, sounds, or movements. Only Polya believed that his creative process involved symbol manipulation.

Seymour Papert's Mindstorms is good reading too - the Logo turtle was very deliberately designed to transfer physical expertise into programming skill.

Plan to arrive wet with a change of clothes. If you wear waterproofs you'll just drench your clothes from the inside: Gore-tex and other so-called "waterproof breathable" materials can't dissipate 3 miles of perspiration, let alone 15 miles. Instead, find something that is windproof, stays warm when wet, and dries quickly so it's ready by the time you head out again.

+1 on the importance of fenders and mudflap. Road water is nasty.

The #! declares to crawlers that a crawlable version of the page is also available from the server by replacing "#!" with "?_escaped_fragment=".

This mapping is needed because the fragment string is never passed to the server, so it has to be encoded elsewhere and the query section is the only available place.

The "!" is needed because otherwise crawlers would start fruitlessly hammering all the existing sites that use '#' but don't support the '?escaped_fragment=" hack.

Muscles Get Tired, Bones Don't.

This is simply incorrect, as are most of the conclusions that follow from it. Basically, many muscles can trade off individual contractile fibers to remain under tension all day without perceived tiredness.

You are not a stack of blocks and you can hurt yourself by pretending that you are. Your body includes tensile as well as compressive structures and the whole thing is tied together with a control system. You are not meant to stand up without reflex muscle contraction! (You also aren't meant to sit or stand in one position for very long, but that's a longer discussion).

I trained as an Alexander Technique Teacher, but for the technically inclined I'd recommend reading Moshe Feldenkrais's Awareness Through Movement as an antidote to this way of thinking. See Understanding Balance by Tristan Roberts for more detailed information about postural reflexes.

Note that the USPTO is asking for comments on how it should comply with the Bilski decision, not for rants about software patents in general. Your comments will presumably carry more weight if you can explain why many software patents have more in common with business methods than with machines or transformations.

This looks like a good place to start: http://en.swpat.org/wiki/Bilski:_analysis_of_Supreme_Court_d...

I think the real argument for testing vs. types is that for most jobs "programmer productivity" has to do with producing code that works in practice rather than code that is perfect under all possible circumstances. Most of us are not developing satellites, nuclear power plants, or pacemakers. Premature optimization for robustness probably wastes more programmer-hours than premature optimization for speed.

That said, if you haven't used something like ML or Haskell you can't possibly imagine how many subtle bugs can be caught by a type checker, particularly edge and corner cases that will eventually dominate your test suite - in the unlikely event that your code lives that long.