I've used Parse extensively as a backed for iOS apps before and lately started trying out Firebase as a replacement. Firebase seems like a decent alternative so far, but there's 2 important features that I'd like to see:

1. Always immediate updates for Remote Config flags - currently Firebase uses old cached flags for up to 12 hours and only allows immediate updates in the "developer mode", but in production, sometimes you need to change a config flag for all users immediately, perhaps to fix a bug, and can't afford having clients still use the old cached values.

Also, it would be nice if Remote Config supported additional data types like arrays, dicts, and dates.

2. A non-realtime key-value datastore - most apps don't require a realtime database, so it'd be great to have a simple datastore where you don't have to worry about managing the number of simultaneous connections.

First of all, I realize this game is very similar to some existing games out there - I drew inspiration from puzzle games such as Candy Crush

Secondly, this game was developed from start to finish in just 2 months' time, owing to Sprite Kit's simplicity and elegance. Though there's not much example code out there for Sprite Kit given how new the framework is, it only took a short time to start drawing some graphics and animations. However, for more advanced things, such as sync'ing and sequencing several groups of actions/animations/sounds on multiple on-screen sprites, that required more custom work on my end (which could be worthwhile to explain in a blog post later on).

Anyway, try it out and let me know what you think. And if there are any other developers out there using Sprite Kit as well, I'd love to chat or get in touch! (especially if anybody has experience porting a Sprite Kit app to Android!)

Thanks! It currently doesn't track user analytics, but that could be something worth looking into

Yea, the current version uses a webview to show the street view, and moving/shifting the street view tended to make the app crash, so that's why it's disabled.

However, now that Google's added street view to their official iOS maps API, I'm planning to integrate that and it may allow features such as moving and zooming.

Yup, it was adapted from geoguessr.com, and I'm trying to extend the concept by adding different game modes and in-game hints

In reply to your questions: 1. What do you mean by similarity measure? Currently, the scoring is just done on a tiered basis on geographic distance, though that scale might be worth adjusting

2. Currently, it uses a webview to show the street view, and moving around is disabled because that tended to crash the app. However, now that Google just added street view to its iOS maps api, I'm planning to integrate that

3. Yes, all of those things you listed can help determine where a landscape is. I haven't thought about formally classifying those features, though it could be something worth exploring

Thanks for the feedback! Will reach out to you if I figure out a way you can help with this!

I'm confused why they decided to immediately remove Summly from the App Store rather than use it to drive traffic to other Yahoo apps - anybody know why they did this?

Cool technical presentation, but trying to optimize moving average trading strategies is a fool's game - you might find a set of parameters that work in all out-sample/cross-validation tests, but there's still a good chance it'll lose money in actual trading going forward - market paradigms can shift, unforeseen world events, t-cost/slippage higher than what the model accounted for (especially with more frequent rebalancing), etc.

If you actually want to trade moving average strategies, your best best is just to diversify and run several different strategies across a variety of parameter sets and across various sectors/asset classes, without trying to overly optimize a single strategy

Certainly that's always a risk. Zipline does however support simulating transaction-costs and slippage so those will be accounted for (as best as possible).

As for market-paradigm shifts, I totally agree. One way to deal with that is to constantly re-optimize the parameters based on recent data. This is also known as walk-forward optimization on which there is a slide at the very end (see http://blog.quantopian.com/parameter-optimization/ for a more information).

Finally, as to running multiple strategies with different parameter settings. The OLMAR paper that describes the algorithm (http://arxiv.org/abs/1206.4626) has a variation of this where they use a range of different-length moving averages, rather than just one.

Also, this is not your standard dual moving average cross-over strategy. Rather, it rebalances its portfolio (optimally) under the assumption that the stocks will revert to their moving average. The eps parameter, which I explored in this talk, influences how aggressively the algo rebalances its portfolio -- smaller values will result in a more stable, conservative strategy.

++ You're right on all counts. You've obviously done this before...

To anyone newly thinking about this topic, it is certainly the most challenging project you can take on. There are no laws of the market like there are laws of physics. You can get your code to work perfectly, but all that means is that your results will be the same as your model's going forward. As for a model, it's likely to need to change fairly frequently, even becoming the opposite of a previously great model for example, and you can never truly account for the effect of politics on markets. One tip is that a sudden catastrophic crash is far more likely than a gigantic surprise to the upside so if you're playing with real money, you need to use options to insure against such an event. Luckily (or not luckily in the case of trading itself) markets are highly correlated, so index options will probably fill this need.

What if my site uses e.stopImmediatePropagation() in any click/event handlers?

Would this still be able to capture those events? And if so, how?

Thanks for the shoutout for BlogRoll! :)

This uses Backbone.js on the frontend, and each time you change sites on the left sidebar, a "pushState" event is triggered, which saves the current state of the page (and the back button will cycle through those saved states)