mattj

Good news: this isn't true - https://waymo.com/blog/2024/05/fleet-response/

I've built one of these based on the instructions and use it daily (and love it!), but the tone of the site is pretty reflective of the project overall. It's definitely a really impressive hack and I appreciate all the hard work that's gone into it, but could really use a little more user-facing empathy.

I'm not sure if I'd recommend it to someone else - and if I was doing it again I'd probably spend a few hundred more (than the gaggia + parts cost) and just buy an off-the-shelf machine with the same feature set.

I think the grandparent is probably referring to upstate in the Hudson Valley sense of the phrase. Plenty of cute towns, but Hudson / Woodstock / Kingston are definitely in the O(tens) of great restaurant options, comparable to a slice of any single Manhattan / Brooklyn neighborhood most tech people live in.

The other answers cover the math well, but I think the “why do you need attention?” statement is worth making (and answers the more engineering-y question of “how/when?”):

DNNs typically operate on fixed-size tensors (often with a variable batch size, which you can safely ignore). In order to incorporate a non-fixed size tensor, you need some way of converting it into a fixed size. For example, processing a sentence of variable length into a single prediction value. You have many choices for methods of combining the tensors from each token in the sentence - max, min, mean, median, sum, etc etc. Attention is a weighted mean, where the weights are computed based on a query, key, and value. The query might represent something you know about the sentence or the context (“this is a sentence from a toaster review”), the key represents something you know about each token (“this is the word embedding tensor”), and the value is the tensor you want to use for the weighted mean.

This is great - the like / heart button is really slick, and I love how it doesn't get in the way at all. I've used pinboard and others in the past, and the (relatively) heavier bookmarking flow would often stop me from saving things as I didn't want to break my flow.

Excited to see where this ends up!

I agree with you (and love your blog, btw), but I think you're skipping over at least a few benefits you can get out of a mature / well built a/b framework that are hard to build into a bandit approach. The biggest one I've found personally useful is days-in analysis; for example, quantifying the impact of a signup-time experiment on one-week retention. This doesn't really apply to learning ranking functions or other transactional (short-feedback loop) optimization.

That being said, building a "proper" a/b harness is really hard and will be a constant source of bugs / FUD around decision-making (don't believe me? try running an a/a experiment and see how many false positives you get). I've personally built a dead-simple bandit system when starting greenfield and would recommend the same to anyone else.

I think the change here is they're learning the embeddings alongside the feature weights (eg they're part of the same loss function).

This kind of language is very standard. The risks section pretty much always contains obvious platitudes ("An earthquake might destroy all our computers," "All our employees may quit").

Similar experience, but I focused on finding UI elements I liked from native apps or websites and attempted to clone them without looking at the source, then played around with the result to figure out how I could simplify it, how it behaved cross browser, etc etc.

heads up, your math is a little buggy - 1% of $90b is $900m, not $90m

What does this do? I've browsed through the site for a few minutes, and still have no idea what kind of tools you could build with this that you couldn't build before.

Is this for cross-language doc generation? Refactoring tools? Something else?

Are there any concrete examples of a tool built on top of this that would otherwise be impossible / very difficult?

These are both good points. I think it's worth calling out here that this post is really about the infrastructure to perform experiments, not necessarily the means of analysis (although the ui you see in the screenshots performs that analysis).

In terms of these issues, we handle them in a few ways. In particular, experiment review catches many of these issues. Think of it like code review for your experiments.

In order to run an experiment, we require you to have an "experiment helper" sign off on your change. This involves reviewing your group sizes, verifying that you have the statistical power you need to test the magnitude of change your hypothesis expects, verifying you interact with the framework correctly etc.. Training to become an experiment helper is generally not very easy, and involves a combination of shadowing existing reviewers, performing enough reviews across the stack, and taking a test to verify you understand potential errors (the test itself being composed of many experiments where we have made mistakes).

Changes to experiments (increasing group sizes, terminating an experiment, modifying an experiment etc.) all require this review.

A teammate of mine wrote a post about our redshift setup a few months ago with some more details: http://engineering.pinterest.com/post/75186894499/powering-i...

Yup! My experience with redshift has actually made me curious to try out Postgres (I've always used MySQL before this). The stricter SQL dialect was a little odd at first, but I think I've become more comfortable with it over a few months.

I've gone through a similar transition (hive to redshift) in a very large scale data environment. Raw Hadoop / cascading is still very useful for more complicated workflows, but redshift is so vastly superior to hive it's not even funny. I thought I would miss adding my own UDFs, but this hasn't been an issue at all. I'm under the impression presto is a similar improvement, but I haven't spent any time with it.

One huge advantage of redshift over hive: you can connect with plain old Postgres libraries, so you can build redshift results into your admin interfaces, one off scripts, and anywhere else you're fine trading a few seconds of latency for extra data.

The AI winter is very much over, and we're back to the good old days of selling the future. I bet this team is very sharp, but there's still merit to "over-promise, under-deliver."

"Phoenix, the co-founder, says Vicarious aims beyond image recognition. He said the next milestone will be creating a computer that can understand not just shapes and objects, but the textures associated with them. For example, a computer might understand “chair.” It might also comprehend “ice.” Vicarious wants to create a computer that will understand a request like “show me a chair made of ice.”

Phoenix hopes that, eventually, Vicarious’s computers will learn to how to cure diseases, create cheap, renewable energy, and perform the jobs that employ most human beings. “We tell investors that right now, human beings are doing a lot of things that computers should be able to do,” he says."

I've been hearing good stuff about this for a while - it's awesome to see it open sourced! Setting up a local haproxy to handle service failover / discovery is a really clever solution, and is an awesome approach to encapsulating a bunch of really messy logic.

This is cool, but probably the biggest appeal of docker to me is never having to use puppet again.

(original author of mrjob here)

Steve's post is 100% correct. I originally wrote mrjob as an internal tool at yelp out of my frustration with using dumbo for multi-step jobs. Specifically, I found myself writing the same incantation of "wrap a mapper / reducer function with an encoding scheme" over and over again. I tried to add protocol support into dumbo (so you could specify that your job reads json, uses pickle for intermediate data, and writes thrift), but I had a hard time working with the dumbo codebase (disclaimer: I haven't looked at it since, so it might be easy to do this now). I also wanted to represent mappers and reducers as python generators, which makes writing memory-performant steps natural (eg you normally want to rely on the shuffle / sort to perform the hard work of aggregating by key). Finally, I wanted my jobs to be easy to test both from unittest and from the command line - debugging hadoop streaming jobs is way more of a pain in the ass than it should be.

If they can't afford to pay a market salary, you should be getting at least 0.5% (and probably more like 1%). Still not life changing at 40mm with no dilution (200-400k), but a little more meaningful.

Considering that they're trying to sell to every business in the US, 3 years actually seems like a very long time.

Note this is exactly how a smart spammer would generate text (sampling from a language model, built on a public ally available data set like google ngrams or Wikipedia). If you wanted to catch someone doing this, you're much better off using your own corpus to generate a language model, as a spammer would have to scrape all your data to reconstruct the same thing.

Then, run the model over your data and start playing whack-a-mole (and refining the model).

This is very similar to the hashing trick used in vowpal wabbit (http://hunch.net/~vw/). I haven't used this python module, but vw is absolutely incredible to use.

So the issue here is two-fold: - It's very hard to do 'intelligent routing' at scale. - Random routing plays poorly with request times with a really bad tail (median is 50ms, 99th is 3 seconds)

The solution here is to figure out why your 99th is 3 seconds. Once you solve that, randomized routing won't hurt you anymore. You hit this exact same problem in a non-preemptive multi-tasking system (like gevent or golang).

One big issue here (solvable, but something to think about): this would make messages a source for money laundering, which I'd bet fb would like to avoid.

Then again, they already deal with this with fb credits, so maybe this wouldn't be too taxing to deal with.

I think there's a very non-trivial chance the person who wrote this article knows much more about advertising than you think: http://www.hilarymason.com/about/

I really wish there was a ruby motion demo. I'd be fine with all kinds of restrictions (no iPad, simulator-only, whatever), I'd just really like to try it out before I take the leap.

Background: I wrote an iPhone app back in the dark days (2.0 beta, in the store on launch day), so I'm familiar with old iOS stuff. I'd like to pick it back up, but I'd be interested in trying out rubymotion along with modern (ARC, blocks etc.) obj-c.

I think this neglects a performance consideration: dynamic programming is often simpler for a compiler to optimize, since it's generally a set of nested loops. Sometimes you can vectorize operations, but often you can just exploit locality to keep all the active set in l1 cache (not a compiler optimization per-se).

Memoization, however, is much more of a black-box. Very few compilers will handle the branching present in memoized function calls in the same way they'd handle a loop (which is also a branch, but a more predictable one).

That all being said, memoization is often simpler to reason about and great for infrequent computations.

First off, I really, really like pypy. It's been slowly taking over my data-massaging-type tasks, and consistently yields 5-10x speedups over cpython.

That being said, I'm a little nervous about all the energy being exerted on novel multicore stuff. Pypy has always been somewhat of a research project, but it's so close to being usable in a mainstream setting. I'd love to see them getting it over the final few hurdles (an out of the box as-fast-as-simplejson json module being a major problem, better docs for performance tuning being the two I've noticed).

This is actually pretty straightforward to overcome (and one of the real strengths of the bayesian approach). Rather than using the direct counts of success for each group, add a prior belief that americans will favor baseball and non-americans will favor soccer (you can experiment to determine this number).

You can now evaluate the results conditioned on each group (american / non-american).