AndrewO

Now, if SQL were the new thing and had been developed by a group trying to make a standard API for CRUD operations based on some new generalized "Relational Algebra" concept that they extracted out of a couple of company payroll applications, I'd say he was onto something.

If that's all that OAuth will ever get us, then it's a failure: either because the goals of the spec were infeasible or because developers weren't able to use it to its fullest (I lean toward the later).

OAuth is not about solving password reuse. It's about granting other clients rights to specific resources on your behalf. It's about telling a 3rd party app they can tweet once, and not read my direct messages; they can read my Gmail contacts, but not send; and so on...

I for one believe in the need for this. But the original poster is right: as long as developers request blanket permissions, I'm not going to use their apps. I may be in a small category, but I'll ask again: is this the kind of behavior we want to condition into users?

Honestly, if that's the case, what's the point of OAuth then? Why don't we just go back to handing over usernames & passwords and trusting some 3rd party to not do anything nasty? With everyone constantly complaining about Facebook privacy concerns and hijacked Twitter accounts, how can anyone pretend that conditioning people to allow the maximum set of permissions to a complete stranger is a good thing?

Facebook, on the other hand, has developed a system where nearly every user activity creates a new easily processed and meaningful connection between users or out to the web itself. And those connections are probably closer to representations of some kind of trust than "I email that person a lot".

Anyway, I'm not saying the sky is falling for Google, just that search appears to be changing for the first time in awhile.

Plus, we are talking about a company whose core business demands that it can identify groups of bad-faith voters. Given time, they may find a way to incorporate this data safely into the ranking data (if anyone could, it would be Google).

And I know there are extensions to do this (mine mysteriously stopped working recently), but doing this on the client-side in a way that's bound to a single browser install just seems wrong to me, especially for Google.

1) the ability to bring up a keyboard (I had to lean forward to type something in. C'mon! :-)

2) the ability to pinch-zoom Switcher window previews. One of the frustrating things about Exposé for me is the unpredictable size & location of windows, especially when they look similar shrunk down. I'd like to peak closer at a window before I select it.

One note I had: I originally thought, "this'll be great because I'll be able to have an interactive animated trackpad!" but after using it, I feel like the use-cases for the Trackpad vs. the Switcher & Application chooser are slightly different. As a trackpad, I'm sitting closer to the computer and hardly looking at the iPad (but I do like the extra space), but I feel like the other two modes are better for sitting back and doing more casual surfing activities. Dunno if that's just me getting used to it though.

Anyway, good job and good luck!

I stashed an HTML file in the same folder with a link to the provisioning profile (also in the public folder—when you add new devices this needs to be updated) and the IPA file. Testers could bookmark the page and grab a new version whenever they wanted (or whenever I notified them).

I recommended MMM to a friend when problems at his workplace sounded like things that came up in software design or project management. But when I reviewed the book, I found that a lot of the big-picture concepts required if not understanding, then at least familiarity with programming and/or older computer systems. It's still a good book, but I ended up feeling like he wouldn't get what I got out of it.

I like Steve Martin as a comedian, but he's pretty talented in other areas as well (e.g. banjo). Sounds like a lot of people missed a chance to see another side of him.

I guess it's a mixed blessing if your library becomes part of stlib. On the one hand, it's gotta feel great to have so many people using your code. But on the other, your release cycle is pegged to Ruby's.

On the other hand, there has been some progress. It's good to see MiniTest replace Test::Unit (while also remaining mostly backwards compatible).

http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140...

http://www.c2.com/cgi/wiki?SingletonsAreEvil

I don't know the particulars of how PHP's ArrayObject works, but take Ruby for example: instead of inheriting from Array, to make a class that operates like an array, one mixes in the Enumerable module (similar to a trait) and implements an "each" method to handle the low level access. All of the other methods come along with the module. In this way, the lineage of a class isn't important; rather, it's what it actually does that matters. (How meritocratic! :-)

But particulars of any language aside, I think this is an important step for PHP. Once a language gives the ability to compose the behavior of a class through traits, modules, mixins, etc rather than standard inheritance, it becomes easier to separate the data that a class encapsulates from the behaviors that it provides—and that, I believe, leads to more modular code.

I know this is a single example, but I feel like I've seen bad OOP practices in PHP so many times in the past. This is such a rich feature but it brings with it a lot of potential for misuse.

As in Apache HBase? Not to be too pedantic, but that's not really something that Facebook "built". I'm assuming that was an error on TC's part.

Charles Petzold's "Annotated Turing" has a great run down of this and a bunch of the other mind-blowing things that came out of math in the late 19th/early 20th centuries.

[1] http://en.wikipedia.org/wiki/Cantors_diagonal_argument

Maybe it's just the lighting, but I don't see any difference. But then again, it took me years to figure out that just because you think you're a relaxed person, doesn't mean you should wear relaxed fit jeans.

You can make your own fun though. I swam past a bunch of other tadpoles yelling "Don't go that way! MONSTERS!!!"

I think when it comes down to it, we take these tests for the enjoyment we get in reading about ourselves later. (The Great Facebook Personality Quiz Epidemic of Ought Nine is the foremost recent example of this in action.) It tickles that part of our brains that says "Someone's taken the time to get to know me—I must be important!", even if that someone is really an algorithm. And it's that, combined with all of the parts that are "right", that allows us to overlook the parts that are vague, over-generalized, right-but-with-certain-caveats, or flat-out wrong.

In an interview situation (where you have less time to decide than building an internal team), that could mean going through hypothetical situations and finding out how they would solve a problem, having multiple interviewers, and checking on references. Having them take a personality test beforehand sends a signal that as an employer, you're not willing to take the time to get to know them, which starts everyone off on the wrong foot. Also, IANAL, but it sounds like a lawsuit waiting to happen.

(I'm also a Phlegmatic, and we're a naturally skeptical bunch.)

For all of the "science" that goes into building the models for these tests (not just MBTI), any that rely completely on self-evaluation (especially multiple choice questions), should be taken with a huge grain of salt. They're fine for entertainment, but for anything practical they should be regarded as one step above astrology or haruspicy.

Just to provide an example of the worst case, I've seen companies hold personality test workshops, only to have that bind their thinking and give them reason to quash dissent ("Of course... that's what a XXXX would say" or "I really need a YYYY on this project"). Too many times these things turn into a substitute for actually getting to know your employees' strengths and weaknesses.

I don't want to be seen as overreacting to a simple harmless poll, but I do want to make sure people aren't giving too much credence to their (or others') results.

[1] http://en.wikipedia.org/wiki/Forer_effect

1. The rejection of what some see as an overly complicated and inflexible query language in favor of map-reduce phases or other application-side querying/processing.

2. The rejection of serialized transactions in favor of something like eventual consistency, often with application-specified conflict resolution.

3. Or it could be a rejection of the relational model (especially as it is popularly implemented) in favor of key-value, graph, document, column-oriented, etc. models.

If I read you and the authors right, I think you're thinking more along the lines of 3 and the authors are focussing more on 2.

I think both "sides" are just starting to come to grips with the idea that these design choices can be orthogonal (a relational DB without SQL? an eventually consistent SQL DB? a graph DB with 2-phase commit?) and choosing to reject one part of "the old way" doesn't mean you have to reject all of it. The upshot is, we're going to have a lot more tools to choose from for our own unique problems.

So, I'd say: don't worry about feeling like a curmudgeon! Rigidity will have its place in the beautiful gleaming pluralistic future of datastores that the SQL vs. NoSQL "debate" is building the road towards.

With that one could write a tool that suggests improvements to code as it tests it using this as a sort of crowd-sourced benchmark suite. It may not be 100% accurate, but at least it would give verified data instead of the educated-guess strategy most of us employ now.

Maybe I should have said "managers with a decent technical background" instead.