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.
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.
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 [email protected] 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.
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.
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.
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.
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.