124816

Most stats providers compute unique visitors using client-side cookies; not entirely accurate, but quite cheap. You're right though, it's a lot easier to use an existing (and free or nearly free) tool than to build your own.

> I'd pay for analytics...

You could just take how much you'd pay for analytics and buy some ads. :-)

Alma Whitten might be uninformed. (Was this talk recorded? Do you have a link to it?) There are some options in the account UI that, if enabled, allow Google to do some analysis of your data.

Link directly to their help center: http://www.google.com/support/analytics/bin/answer.py?hl=en&...

> which is a spurious to start with -- simply documenting making an idea public is just as much of a defense

The idea behind defensive patents isn't that they defend your use of that idea, but that they defend you from competitors who have patents that might affect you. (Since they hopefully allow you to countersue.)

I wonder what percent of those users have a 9700.

I don't think it was ever released, was it?

Many of these cars have a power button -- if the "key" is inside the car, the button is activated. When the car is on, and in park, it will turn off with a simple press of the button, but when in motion that does not work.

(I've been told that holding the power button for several seconds, just like one would a crashed computer, will force a shutdown; can't verify that though.)

Not sure if you saw the graph hidden in the side: "Complaints rose after Toyota recalled 3.8 million vehicles in November..." -- it makes the same case as you.

Let's have an experiment: another manufacturer can institute a fake recall and see what happens.

> Naturally they adamantly deny it

And, thanks to the nature of human memory, after the first few times they aren't even intentionally lying. (A memory is part recall, part imagination. Replay something enough times, it can become more of the latter than the former.)

I know it seems retarded, but things like copying second life cost the company pretty little. Ten or twenty people's work for two years, thrown out and discarded. We're looking at a couple million down the drain. A lot for you or me, but not worth worrying about for them.

Sure, those things might be somewhat embarrassing, but I doubt they have a significant effect in the long term. (Except, that is, when they turn out to be a good idea and succeed.)

Also, for Apple to be a real competitor to Google, they would have to threaten Google's core money-maker, online ads, especially search ads. It's possible iAds will end up being such a competitor, and were I Google, I'd be concerned. But I'd be much more worried that for many people, "the internet" would become "facebook," and thus I wouldn't be able to show them ads.

After several releases of your app, you'll have several wire formats in the wild. One of the main features of libraries like Protocol Buffers is that they can parse old messages, so you don't need to maintain an increasingly hairier parsing routine.

Both protocol buffers and thrift are primarily designed to handle older or newer messages (than your program was compiled with) gracefully. Speed and compactness appear to be secondary goals. (Especially for Thrift, which does not seem concerned with compactness.)

Rather than version your protocol, the generated code is able to parse newer messages. If you modify a field on that message and serialize it, even the parts of the message your binary is unaware of will be retained. (As opposed to dropping them.) This means you don't need to push all changes at once, and you can have binaries talk with older and new binaries without problems.

The basic wire format is [(tag, payload bytes)*]. The tag identifies both the field "number", and the wire-type of the field. Wire types include fixed 32 and 64, length-delimited ranges, and, for protos, variable length integers. The parser knows how to skip fields of all wire types, so any unknown tags are skipped (and retained in memory) during parsing.

Some caveats apply -- you can modify your protocol in several backwards-incompatible ways. For example: add a new required field. Your new binary will reject all serialized messages from your older binaries. Alternatively, change the type of a field. These are pretty easy to avoid, but given enough people on your team, it is bound to happen once or twice.

Going to reply to all your comments at this rate. ;-)

Even with single-byte tags, the overhead can be quite significant; thus the packed = true option. Unfortunately I don't have any public protocols or data to show you, but by switching to packed = true (combined with some extra tricks) I achieved ~40-60% savings on some of our datasets. We use protobufs for our stable storage, and this change certainly saved us more than my yearly compensation package.

> For the next 2048 entries

Yikes! I hope you never have to work with a message type with anywhere near 2048 fields! :-)

In practice, more than half message types have less than 16 fields, which is why the "incredibly arbitrary situation" is justified, and really does end up saving a ton of storage. But, for simplicity, nothing can beat just ntohl and a cast.

Have you run benchmarks on this? If so, can you link me to them?

It would be relatively easy to modify protobuf's parsing code to operate on the encoded byte rather than decoding field tags. If it's worth doing I'll do it.

BTW, the default parsing code has no loops in the fast-path. I don't remember off the top of my head, but I think both 1 and 2 byte cases are inlined. (Avoiding the loops is great for these cases, since default branch prediction will often be wrong.) All tags under 16 are one byte.

Also, in my experience IO has always been the bottleneck -- my CPU can easily keep up with 1 or 10 gig pipes I have access to.

Protobufs allow you to define your service, but no RPC system is included.

That weird new(T* )T(...) syntax is how you ask c++ to run the constructor of T on an existing T* .

(In this case that T* would point to the stack.)

Note that the memory at the T* shouldn't be a real T; or if it is, its destructor ought to be run first.

Good post. Another focus of Thrift (and Google's "protocol buffers", its inspiration) is that modifying your RPCs in a forward compatible way should be easy and have well defined semantics. (Thus the need for a tagged-base stream.) And, old clients should continue to handle new data in an acceptable manner. (i.e. They should not discard new fields that they do not know about.)

IMO Thrift/protobufs also add a lot of value having a single file to describe the shared protocol, compared to e.g. JSON, where it tends to be more ad-hoc or "look at example results for reference."

Looks like the main author of this is T.V. Raman:

http://en.wikipedia.org/wiki/T._V._Raman

Pretty awesome dude.

This blog post is pretty incoherent. Backstory at: https://bugzilla.redhat.com/show_bug.cgi?id=581256

Looks like the Chrome guys want privs so they can increase the chance of renderer processes being killed if the OS runs out of memory. (e.g. instead of Xorg.)

OP arrives after a while and writes a bunch of sentences that are about as confusing and disconnect as the linked article. Proceeds to throw a tantrum. Gets "butthurt" and posts link here?

Fin.

Refresh often disables the cache, or at least does a bunch of if-modified-since requests. Better to type the url again and hit enter.

I'm missing the back story -- tell me more about Peter Norvig's solver?

Thanks for the tip. European law is relevant in this case as well, and I'm not sure it requires a strict monopoly over the market. That said, clearly if iPhones were a small part of the mobile ad platforms, nobody would care if Apple limited the ads that could be shown on them. I don't think that's the case though.

The point I was trying to make was: If we switched this around, and Microsoft had the number one smartphone, and they did something like this, regulators (though you're right, probably not American ones) would have them bent over a table.

I have never seen "anti-competitive" being used in a positive light. A quick search shows it has mainly been used by prosecutors and plaintiffs to describe their adversary.

You don't need to believe me though, here: http://en.wikipedia.org/wiki/Anti-competitive_practices (We can /all/ trust wikipedia, right?) "Barriers to entry" is relevant.

It would be interesting to know how coarse the data exposed to mobile ad providers is -- does anyone have any experience here?

Were I implementing mobile ads, the precise location would stay on the device, and the information sent to the ad server would be city or at least zip level.

Nope, sorry. This has very little if anything to do with the user.

Apple wanted to buy Admob, but Google got them instead. This change will prevent Admob ads from being well targeted on iPhone, and will prop up their (assumed to be upcoming) rebranded Quattro mobile ads.

This smacks of anti-competitive practices. (That is, assuming Quattro ads are allowed to use location aware targeting.)

This is fine, if you're OK with missing bounces. If the page takes a long time to load, or hangs, then it's likely the user will close the window before the script runs.

Several browsers, including many versions of Firefox, had a bug relating to the status bar. The "waiting for ..." would only update after the first byte had been received from the next file. Thus, a slow resource would leave the status bar blaming www.google-analytics.com.

The bug has since been fixed in Firefox -- I don't have the url handy though.

IMO this is the main benefit of the async snippet -- random server problems won't lead inaccurate metrics.

(This is most visible with adwords campaigns -- you can see the number of clicks you paid for, but the number of visits they lead to is less. Typically due to a combination of high bounce rate plus slow loading pages.)