It sounds like you know what you're talking about. Would you mind to take a look at my issue/question on the appengine django skeleton[1]. The Problems start after you've pointed your database to cloud sql und start using GAE specific features like task queue etc.

[1] https://github.com/GoogleCloudPlatform/appengine-django-skel...

For your first question (playing with Cloud SQL) you've got two options. Directly interact with Cloud SQL from your laptop or like you said have a "development MySQL" separate from prod / staging.

Pointing at your Cloud SQL instance (maybe using a staging or development database) can be done in settings.py. The switch between modes let's you specify the IP address for your Cloud SQL instance when you're not on App Engine (which uses a special UNIX domain socket). We also recommend you connect over SSL when doing so outside (see more at the link I provided, or search for cloud sql ssl).

Having a local environment for MySQL is also easy enough depending on your box, but has the usual difficulty of needing to have a good test suite / being populated with useful data. I think it's worthwhile if you can pull it off, but I've seen companies big and small decide its not worth it (and instead use a separate table or database on the same server, maybe as a different user as another line of "don't screw up prod").

Finally, the interaction between Django's development server and the App Engine one isn't great. My response was intended to remind people that if you're not looking to use App Engine specific APIs you really can just get going and almost not notice. But you should be able to run your migrations speaking to Cloud SQL remotely without needing to import say Task Queues. So my workflow was to use manage.py for things like that, while using the dev_appserver when I actually needed to emulate App Engine (as opposed to the Django runserver command).

Does that help?

Edit: I forgot to add that we're working on decoupling the "emulation" of our services so that this kind of interop works better. See https://cloud.google.com/sdk/gcloud/reference/beta/emulators... for Datastore and PubSub (and more on the way).

OT: I'm wondering what that big screen in the back of the header video on their company website is for and how it works. http://reaktor.com/

It's a huge multi-user touchscreen. Nasdaq's got one as well: http://reaktor.com/work/nasdaq/ We (I work at Reaktor) use it to keep tabs on our projects and see who's doing what: http://multitouch.reaktor.com/visual-asset-management-tool

The actual screen is built by Multitaction (http://www.multitaction.com/) and Reaktor creates custom software for it.

nice, thx larry!

Zürich community radio http://gds.fm/ :)

wheelchair from scalevo (ETH zurich), similar "segway tech." including stairclimbing https://www.youtube.com/watch?v=3lb_8nmy90c

scalevo appears to use a joystick, the hands-free nature of ogo is what I find the most interesting.

Ya when I watched I pictured the user being able to carry their baby while moving down the street or in a mall.

no offense, but I am the only one who thinks this MVC style isn't an option anymore after things like react?

Er, adding an option doesn't delete all the other options.

MVC is a decades old, tried and tested pattern for building user interfaces. Whatever its merits, I suspect it will survive react.

This is not a critique of MVC, but rather the particular implementation that Backbone provides. With React you still have your models (and controllers).

And adding a new option may make an existing one obsolete. Remember ES3? I do, but I wouldn't want to write new code in it. Once new options were added (ES5, and then ES6), they made the old one obsolete. It desn't mean you can't use the old options, but why would you if the new ones are superior?

I missed the word 'this' in the GP, so this is fair enough.

Even if we're just talking about Backbone, however, it's a little off: I mean, people use react with the non-view parts of Backbone. Often you're going to need some way to talk to APIs (say), and Backbone gives you a cheap and well-known solution for that. I'm no Backbone fanboy, but significant things have been achieved with it, and they are not now suddenly impossible because there's a new view layer on the scene.

Is the ES3 vs. ES5/ES6 comparison valid? The latter were subsequent versions of the former, kind of like Angular 2 vs Angular 1. Whereas Backbone, Ember, React, etc. are all different, each with its own "way" of doing things.

I used ES5/6 because those are (I hope) in the eyes of the HN community clear improvements over ES3. I personally wouldn't use ES5/6 nowadays, and instead use TypeScript or PureScript. Both of which are IMO even bigger improvements. Backwards compatibility does not matter in this comparison, what matters is the relative ordering: Backbone.View < React, ES3 < ES5 < ES6, and IMO: ESx < TypeScript/PureScript.

Well, "things like react" are not more than the V in your MVC ;)

Sure, but it suggests a component hierarchy which blurs the already ambiguous line between view and controller. Which is why there's flux and all of its variants, and things like falcor in the works - the missing model in data-component architecture.

On the ambiguous line between view and controller: a piece of code belongs to the controller when it touch the model, and to the view when it touch the DOM, the corollary being "don't write code that touch both the controller and the model". Put that way it doesn't seems that ambiguous.

The fact that react suggests you organize the views in a component's hierarchy has nothing to do, imho, with people calling the models from those components. It's just bad practices, whatever is the view library being used.

But I get your point nonetheless: flux & all do try to make it clearer that react should only get called from events and update the DOM as a consequence.

For the record, there's also good things being done in that field by the clojurescript community (Om/Reagent for example).

this book is old. It was written before React. I even do not understand why it is so high voted here. But many thanks for Addy writing it and making it open!!!

You're not alone. Use Vieux architecture instead: Vieux.io :)

interesting sound choice in the video...

Always loved to put some epic music in my demos :)

Zürich, Switzerland is trying to do the same since 30 years. http://www.tagesanzeiger.ch/zuerich/stadt/Schwamendingen-mus...

me too! for music there are good and paid consumer solutions. i like popcorn, because they are (at least i hope) pushing the movie industry into the right direction...