equark

Both derby and meteor don't support relational databases. Give me a realtime graph or relational database.

Sense (http://www.senseplatform.com, http://angel.co/sense) - San Francisco

Sense is a next-generation platform for data analysis, statistical modeling, and business analytics. We're building amazing technology and need help at all parts of the stack.

We're a tiny company of three. You will be a core team member building amazing technology in a fast paced, drama free, intellectually stimulating, environment. Competitive salary and equity.

= Lead Full Stack Web Developer =

* Experience building highly interactive, client-side, web applications (Backbone/AngularJS/Ember/etc).

* Deep knowledge of JavaScript / NodeJS.

* Experience building large systems on AWS.

* Highly productive and independent.

= Lead UI Designer =

* Fluent in Adobe Creative Suite.

* Pixel perfect design for print, mobile, and web UI.

* Ability to lead entire UI design and branding effort.

* Knowledge of JavaScript/HTML/CSS a plus but not required.

* Interest in data visualization a plus.

= Senior Technical Developer =

* Deep knowledge of numerical and statistical computing and familiarity with existing tools R/Matlab/SAS/SPSS/Stata.

* Experience building big data systems.

* Fluent in C++.

* Knowledge of JavaScript/V8/NodeJS a plus.

* Love of Bayesian statistics and MCMC samplers a plus.

* Experience with OpenCL and LLVM a plus.

* PhD a plus but not required.

Email: tristan@senseplatform.com

It's coming soon and much more: http://angel.co/sense, http://www.senseplatform.com. Three of us, full time, for over a year.

Both are correct but they target different things. The disagreement is around what is the target should be and the advantages and disadvantages of choosing these targets. Bayesians are interested in p(unknown|data) and frequentists are interested in p(data|unknown = H0). Inference can be framed either way but means different things.

Impressively fast. Is the voice recognition being done exclusively on Google's servers or is there a local component?

They are creating decentralized mechanisms for free individuals to find individually and socially beneficial outcomes. The free market organized by the U.S. legal system is one such mechanism, but certainly not the only one.

I'd recommend using as many real examples as possible. Things like forecasting, product recommendations, topic modeling, etc. While you can conceptually explain how Bayesian statistics is a unified recipe, it's incredibly hard to have this sink in with toy problems. This is especially true since many people using traditional tools are actually using advanced methods to solve real problems, so when they start reading about urns or doors it all comes across as rather academic. That's sad because the benefit of Bayesian coherency is mostly that it leads to a highly productive mode of practical data analysis.

Definitely shoot me an email at tristan@senseplatform.com if you're interested in the computational side of this area. At Sense (http://www.senseplatform.com), we're working on making applied Bayesian analysis as amazing as it should be.

My problem with books like this is that they have almost no connection to why Bayesian statistics is successful: Bayesian statistics provides a unified recipe to tackle complex data analysis problems. Arguably the only known unified recipe.

The Bayesian book I want should emphasize how Bayes is a recipe for studying complex problems and teach a broad range of model ingredients. Learning Bayesian statistics is about becoming fluent in describing scientific problems in probabilistic language. This requires knowing how to express and compose traditional models and build new ones based on first principles.

An unfortunate reality is that you still need to know computational methods too, but that should change soon enough.

You could come work at Sense (http://www.senseplatform.com) or email me tristan@senseplatform.com. Not Google scale, but the same technological challenges without the legacy bagage.

I'm really not sure this is true. I'd like to see evidence of it because certainly the people I know who buy android do it for features. That's also how they evangelize. It seems to work. Apple has a great marketing strategy but that doesn't mean the best competitive response is to mimic it.

This would be very interesting to lots of people. There are lots of half-baked sandbox solutions so seeing what you guys did you be interesting.

A lot of comments suggest that Apple and maybe even Google are deliberately keeping HTML5 performance subpar. I think this misses a key fact: Google has struggled for years to make native Android apps match iOS performance, even for simple things like scrolling a list. The fact is Apple set a standard with iOS that is incredibly hard to meet regardless of the technology.

The conclusion is sound though. Companies that build mobile apps using HTML5 in 2012 will almost certainly face the fate of companies that built web apps using Java applets in 1998.

Unfortunately it still feels broken on ios.

Unfortunately no, but you're welcome to email me at tristan@senseplatform.com.

Another key fact is that "big data" is actually not that common, especially when it gets to the analysis stage.

The median job size at Microsoft and Yahoo is only 15GB. And 90% of Hadoop jobs at Facebook are under 100GB. Clearly you want to be able to crunch large log files, but in terms of day-to-day analysis the files are much smaller than that. (cite: http://research.microsoft.com/pubs/163083/hotcbp12%20final.p...).

At Sense (http://www.senseplatform.com) most of the clients we work with are struggling not with the size of their data but with tricky modeling problems that don't fit into standard black boxes and with integrating analytics into actual production systems. Adopting something like Hadoop for these tasks is not very productive.

"Off-Topic: Most stories about politics, or crime, or sports, unless they're evidence of some interesting new phenomenon."

As far as I can tell derby has zero story for datastores outside their json racer implementation. There's too much focus on realtime sync in all these frameworks. Even a realtime app like twitter needs complicated relational data. I want a framework that could build github. Derby does get major points for solving the seo and page load issue though.

So far it seems like Meteor is focused on data syncing and live UI elements. That's neat when done well, but the main pain points for client-side heavy apps is the mismatch between the server and client and between the traditional URLs structure of web pages and the MVC structure of apps.

I'm looking for:

* Complete parity between server and client-side rendering for content. This is required both for first-page performance, caching, and SEO.

* URLs as the foundational organizing principle of the app. The mismatch between clicks, back buttons and external links makes code hard to organize and apps behave strangely without serious work.

* Database agnostic. Relational datastores remain incredibly productive and proven for the vast majority of apps.

It's absolutely a step back and the Node community is way too harsh on those that point this out. But they are probably making the right call by not forking JavaScript. If you want a synchronous style its easy enough with node-fibers. The problem is mostly that there isn't a cultural consensus around a node-fibers based ecosystem of libraries.

It's too bad Windows support is not a priority. Half the point of Dropbox is to keep files synced across all computers.

What prevents you from doing this with ajax post on every existing website?

Obviously epsilon-greedy is not optimal. But I think the point is it's surprisingly effective and probably better than A/B testing in most applications. Most alternatives get very complicated very quickly.

Even your thought experiment is not conclusive. First, it will take some time to be convinced which variation is better. The lost revenue during the 50/50 experimentation phase may outweigh the long-run benefit if your discount rate is high. This can happen in markets where customer acquisition is slow and expensive (i.e. a niche targeted via AdWords). Second, except in the unrealistic 0% vs 100% case, you could get stuck on wrong choice forever if you pass a statistical significance test by chance. Epsilon-greedy will correct itself over time and is asymptotically guaranteed to make the correct choice most of the time. A/B testing only has this asymptotic guarantee if you spend asymptotically long experimenting, which defeats the whole exercise.

This is the most important critique of A/B testing. It far outweighs the traditional hoopla about simultaneous inference and Bonferonni corrections.

Epsilon greedy does well on k-armed bandit problems, but in most applications you likely can do significantly better by customizing the strategy to individual users. That's a contextual bandit and there are simple strategies that to pretty well here too. For instance:

http://hunch.net/?p=298

http://hunch.net/~exploration_learning/main.pdf

http://web.mit.edu/hauser/www/Papers/Hauser_Urban_Liberali_B...

Frequentist statistics is about determining the repeated sampling properties of a procedure/statistic/estimator. It's about evaluation not estimation. "Optimizing \theta" or whatever you're envisioning is just one possible procedure you might be interested in evaluating. You can use the repeated sampling properties of your procedure to do frequentist inference or to evaluate other properties like unbiasedness, consistency, risk, etc. Typically the goal is to find procedures that have "good" frequentist (repeated sampling) properties. Most Bayesian-inclined statisticians would tend to argue that many frequentist properties are not important to applied data analysis or optimal decision making.

It sounds like you're just saying that if you want to know the frequentist properties of an estimator you have to be frequentist. That's a tautology.

The harder question is whether there are any decisions you'd prefer to make using a non-Bayesian procedure. That's basically a tautology in the other direction though.

The sampling distribution is not the likelihood. It's the fundamental basis of all frequentist inference. Amazingly, even though this is typically taught in introductory statistics virtually no students actually digest its importance. You literally cannot understand frequentist statistics without understanding the idea of a sampling distribution.

The sampling distribution is the distribution of your statistic (MLE estimate, mean, EAP, MAP, or whatever you want) under repeated sampling from the population distribution. Frequentism is an evaluation procedure, which can be applied to any estimator whether it be Bayesian or something like MLE. Frequentists are interested in whether this distribution has "good" properties. Supposedly good properties include things like unbiasedness, consistency, minimum variance, etc. Inference is typically expressed as a function of this distribution (confidence intervals) or by comparing the sampling distribution under some restriction (the null hypothesis) to the actual value of the statistic in the observed sample.

Given that you can't typically sample from the population distribution, the practical question becomes how do you approximate the sampling distribution. Typically this is done by appealing to a central limit theorem. Bootstrapping provides another intuitive approximation.

There are all sorts of problem with this approach to statistics despite its success.

There are times when, even as a Bayesian, one is interested in calibration. Model checking without a specified alternative is an example. Frequentist ideas -- sampling from the model and comparing it to the observed distribution -- can be helpful here. I'm thinking of Rubin (1984): http://www.cs.princeton.edu/courses/archive/fall11/cos597C/r...

I don't think this is a worthwhile distinction, even if it's historically accurate. Both Bayesian and Frequentists focus on point estimation and distributions. EAP and MAP are just as Bayesian and the full posterior distribution. And the sampling distribution is just as important to Frequentists as the posterior distribution is to a Bayesian.

The key difference is whether inference is based on the sampling distribution or the posterior distribution.

While it is sometimes important to be able to manipulate large datasets, every single competition on Kaggle can fit in a laptop's memory.

ShareJS is a good example. However I don't think this is the right approach necessarily. The FireBase API is a lot simpler and in casual tests it's much faster too.