ajessup

PM on App Engine here. We'll continue to be using (and monitoring) the Google Code issue tracker until we have a robust alternative available.

We have plans for this, we're just not ready to talk about them yet.

Freedom from your job, commute and sorting out your kids by 8pm seems like a good deal for most working dads

Autoscaler will respond differently to different traffic patterns, but won't go as far as identifying a particular traffic pattern as malicious and refusing to grow resources to accommodate it (most architectures filter malicious requests upstream of the instance itself, eg. at the load balancer or via a proxy).

Even if you could identify malicious usage, it's still a matter of policy on how you want to respond to it - given that if it can reach your VM it will likely be affecting legitimate traffic too.

It's worth noting that the GCE Autoscaler is configured quite differently to the AWS one. For the latter you define explicit scale conditions and triggers. On the former you define a utilisation metric and a target.

PM for GCE Autoscaling here. On protection from malicious traffic spikes - you can set a max-instances threshold to prevent over-spend which you can change at any time.

Ultimately though, from an instance's perspective, there's not a lot of difference between a malicious DDoS and a genuine traffic spike. You can mitigate this (a) by setting low max-instances thresholds when you aren't expecting high traffic, and (b) upstream filtering or QOS management to filter our DDoS traffic from legitimate traffic.

"The problem for Google is [...] they’re an ad company, but the key to native advertising on the Internet is the capability of producing immersive content within which to place the ad [...] Google has nothing in this regard (with the notable exception of YouTube"

Google has plenty of other assets here to build immersive advertising experiences on top of if they chose to leverage them, not the least of which is the most popular mobile OS in the world.

"Moreover, all of the things that make Google great [...] translate to the more touchy-feely qualities that make a social service or content site compelling."

Google has the best asset of all here - an empowered sales force that has direct relationships exactly the agencies, creatives and buyers that would be the first to jump on an innovative immersive ad format.

These conclusions seem to be focused on a very 19th century vision of "work", where productivity is just a function of efficiency and not, say, creativity or risk-taking.

One way to spur adoption, let's see a Yocto BSB for this

This.

I remember sitting opposite Nikki in co-working spaces (Fishburners) and incubators (Pollenizer) back in Sydney throughout 2010 and 2011. Her gumption, determination and focus back then was (and is) a force to be reckoned with. If there is anyone who's failure I would never question - it would be hers.

It's heartbreaking to hear these stories, even more so when it's someone you know. But Nikki - thanks for sharing. We're all made a little stronger for it. For the rest of us it should serve as a reminder that no matter how hard we strive there will be always be forces outside our control that shape our destiny.

Gabe's posts have had strong impact on a relatively small audience. It's hard to realistically imagine it's had a significant impact on Surface sales one way or the other.

On the other hand when he blogs about the future direction that they are taking then this is all data that competitors will gobble up, and in many cases can bring to market ahead of MS.

Quite possibly the PR gain here is offset by the future opportunity cost by giving competitors a heads up on future strategy.

OP, surprised that MS (as with any large company) didn't require you to sign an NDA to not discuss unannounced features during development. Bold (and encouraging) move on their part if they didn't.

This talk at GitHub makes good watching http://www.youtube.com/watch?v=8syV5t2_3QI&feature=youtu.be

It's certainly slower, and more durable, than local disk for writes. For reads/stat()ing this is mitigated to a certain extent by optimistic caching in memcache.

You also get the advantage, for asset pipelines, in that GCS can serve the generated file directly.

Actually, the policy is:

"Google will announce if we intend to discontinue or make backwards incompatible changes to this API or Service. We will use commercially reasonable efforts to continue to operate that Service without these changes until the later of: (i) one year after the announcement or (ii) April 20, 2015"

So you have a year, at a minimum.

Writing to files is hardly App Engine specific. Here's an example:

$fp = fopen("gs://my_bucket/some_file.txt", "w"); fwrite($fp, "Hello"); fclose($fp);

You can use many forum products today if you use Cloud SQL as your storage service (and it's pretty cheap, it starts at ~$10/month).

eg. phpBB - http://fredsa.allen-sauer.com/2013/07/standing-up-phpbb-inst...

Hey folks - App Engine actually has an explicit deprecation policy spelled out to make sure this can't happen. See https://developers.google.com/appengine/terms

Google Cloud storage is a great place for uploaded media (it's pretty efficient at serving), and the PHP runtime integrates quite cleanly into GCS (you can fwrite() to a GCS object, for example).

https://developers.google.com/appengine/docs/php/googlestora...

We're working with a couple of Wordpress developers on a plugin to integrate Wordpress media uploads with Google Cloud Storage.

Thanks, will fix :)

AJ here, a PM on App Engine (and the guy who wrote the tutorial). The Batcache plugin (which caches to Memcache) works on GAE out of the box, and gives a predictable improvement to performance, especially when you've got a lot of DB-heavy plugins.

I like Chris' writing, but putting aside from the (pretty > prowess)? argument, I don't feel he has correctly mapped cause to effect here.

The reason that UX has become more critical for certain classes of software is because (a) consumers rather than business have become the predominant driver of spending for desktop computers over the last 15 years, and (b) because the web and app stores removed distribution and sales channels as competitive advantages, leaving price and experience.

Product design is now more important, sure, but it's because the playing field has been flattened and because more consumers are buying. NOT because of some broader macroeconomic trend that can be applied to all markets.

I'd be interested to hear any insights as to why Facebook hasn't yet pushed to build a display advertising network for third party publishers (a la DoubleClick). That way it could leverage the assets that it does have (behavioral profiles) against an asset it doesn't (users with direct purchase intent).

On a side note - I'd take issue with your suggestion that the information on Facebook is largely useless to an advertiser.

There doesn't have to be any explicit "truth" to the action being measured (whether it's what a user happens to press Like on, or some abstract measure like their ratio of likes to logins), all that matters is that it's a measurable predicate of some other behavior that advertisers care about - like the language you're likely to respond to, what stage in your life you're at, your self image, what the rest of your peer group is into.

In many ways this a lot like a first date as well, in that the things your partner may embellish or overcompensate for might actually tell you quite a lot about what sort of person they really are.

Hadoop is not a cloud solution - most organizations deploy it on their own infrastructure. Some folks (eg. Amazon AWS) offer a "hosted" version.

I think any corporate data warehouse is an area that Hadoop+Pig/Hive could add a huge amount of value. Here's why. Conventional data warehouses are built from running ETL transforms against existing sources, where you are carefully selecting which attributes you want to transform in. These transforms are tricky to set up and even trickier to change if you decide you need a new piece of data (which happens every day in big BI implementations). And if the source system isn't permanently preserving the data (eg. log files) then pulling in data retrospectively often isn't possible.

With a HDFS cluster you can cost effectively dump undifferentiated data from existing sources into a "data lake" without worrying about complex and highly selective transforms, and then use tools like Pig and Hive to do ad-hoc interrogations of the data.

Most data warehouse implementations fail to a large extent because of the ETL problem - Hadoop could help solve that in a big way.

Further reading (no connection to me) http://www.pentaho.com/hadoop/

No, most of these do. To build a search engine for example, you need to collect a massive amount of data (say, every web page on the internet), and perform a relatively trivial amount of computation on it (building a TF/IDF term index of each term, computing PageRank, etc.) to build your indexes.

While building a search index is computationally intensive, the number of CPU cycles exercised per GB of data is relatively low. So if you wanted to 'distribute' this problem by farming out the data across a high latency connection to have it processed on another node, and then have it returned to you would actually be slower in many cases than just processing locally on a decent machine.

In distributed computing, which is the kind of computing that tends to go on in data centres, there are two types of problem - large amounts of CPU on relatively small amounts of data, or small amounts of CPU on a relatively large amount of data.

The former is generally found in scientific computing (say, protein folding studies, or SETI@Home). In these kinds of problems, it's acceptable to have a widely distributed system with significant latency between nodes, because even though it takes you a long time to move the data across to another node, it's offset by the time you save in having another CPU perform work on it.

The latter is generally what you find in the business and web applications that are generating most of the heat in data centres today. These are things like stats aggregation, building search indicies, or plain old DB seeks. In these cases, it often doesn't make sense to distribute the work out over a connection with high latency, since by the time you've done that, performed a relatively cheap CPU operation on it, and sent it back down the wire, it would have been quicker just to queue it up locally and let the same node deal with when it had some CPU slots spare.

In other words the higher the latency between nodes, the less efficient the entire system becomes, and the less economical horizontal scaling becomes. In addition, there's a ton of extra overhead to maintain concurrency when latency is high.

It could be great for some niche problems though - like CDN, P2P relays, or local backup for nearby machines.

Depends what you're trying to keep concurrent, and your concurrency policy. OT is great for optimistic concurrency on complex structured documents, but probably overkill for simple models (like to-do items) with simple attributes (like title, is-done etc.). For that you could get away with - eg. a revision counter on the model.

Because of the performance implications of different concurrency, you probably don't want it baked too deeply into any framework, since there's some stuff you definitely want strict conflict/error resolution on, and other things you don't.

Hey I'm Andrew, co-founder of Noosbox (http://noosbox.com). We were one of the first batch of Startmate companies. Happy to share some insight and war stories. Reach me at ajessup _AT_ noosbox.com. We're based in Sydney @ Fishburners.

How would you use it in an IDE? For pair programming?

Certainly can't imagine it would replace source control - it would be incredibly frustrating having other devs break your codebase all the time, you'd be debugging all their mistakes as well as yours, and as a team we'd be disincentives from making any big changes since it would halt anyone else's work while the change is being worked on.

There's a reason we create abstractions like commits and branches, and don't all just work from a share drive.

One would assume that since they got accepted into YC that they had a pretty good hypothesis of what their target market could be. But it's not clear from their website what it is (and it doesn't look like it's an IDE).

The OT technology that powers stuff like this is interesting but is being rapidly commoditized by JS libraries (check out the awesome ShareJS http://sharejs.org/ for an example). So what makes these guys interesting hopefully isn't the tech itself, but the market they want to bring it to.