Why is this better than Django or Flask, web2Py or CherryPy ect.

Doesn't want to be better but more generative, so quicker first app results. Idea is to add many rails-alike helpers like pagination, observation, etc... Easing small apps life .;)

How much better really, if the current one wasn't working well you would find out real quick.

More sophisticated programs (fewer false positives and false negatives), smaller devices, batteries that last longer between charges, etc.

Yes, you would be burning with such a power source in a consumer electronic device.

CloudFront is pretty good, just make sure you are able to config your asset source in one line. Otherwise you have to use a tool to invalidate the cloudfront cache frequently during dev and it's not instant.

Invalidation is for suckers. A fresh new URL is much safer.

Note that you can now configure CloudFront to take query strings into account when caching files. Tweaking the query string is basically instant, unlike waiting for the invalidation tool...

Doesn't seem very scalable. Unless you have a way to run and record multiple games on one machine.

If this gains some traction (aka $) I have ideas on how to scale it. I also have a theory for multiple on a machine, just haven't had time/resources to proof of concept it.

I've used the dropbox API before to automatically upload photos in a dropbox folder to Flickr. It occurs on an interval (cron job every 2 mins). I'm sure you could do the same thing using FTP or a custom API that exists on your destination server.

They released a delta API recently. It's a bit of a pain to perform this task as you can't differentiate between a new file and a renamed file or a file that's been moved from one location to another.

In all cases you get a delete (if the file isn't new) and then a new file event.

I implemented it, and it kinda sucks for this sort of thing. The purpose seems to maintain local state to mirror the state on Dropbox. Not terribly interested in that...I just want to subscribe to specific events (webhooks, anyone?).

This was their solution to the frequently requested webhooks. It falls short. Way short.

ifttt.com has a dropbox-to-flickr recipe (http://ifttt.com/recipes/6804). Their dropbox channel provides 2 triggers, one for any new file in your public folder, and one specifically for new photos in your public folder (it doesn't say exactly what the definition of "photo" is, though).

I haven't tried it, so I don't know how gracefully it handles renames or moves.

The fact that people have to constantly defend PHP says something in itself.

That people constantly attack PHP?

In all seriousness, it just works when your building for the web (unless it doesn't.)

Is it often messy? Absolutely. Is it sometimes a bit verbose? Sure. Can it sometimes be like laying a snare, only to accidentally step back into it? Yes, but it's not alone, just seems to make it a little easier to occur.

It doesn't have to be that way, it just tends to be like that.

I prefer Python and Scheme, but I don't enjoy them when it comes to working with web development. There are frameworks that help with this, but it's still a pain. PHP is quick and easy, in that area and works 95% of the time in about 99% places you stick it.

I've been trying for years to embrace Python in web development, but it just annoys me during the setup. PHP gets out of the way, in that area, and let's me go.

What language do you use?

If you had a bunch of influential yet hopelessly ignorant people writing blog posts about how awful that language is and possibly devaluing your skill set because of it, you'd want to correct things as well.

The fact that the majority of complaints about PHP as a language boil down to your comment says A LOT about the ignorance of most of the complainers.

Sure. It says PHP is popular enough and mainstream enough so that people feel attacking it would not be pointless and would bring them some clicks. And it says there are arguments in defense of it - otherwise there would be nobody to defend it.

You have just mixed HTML and server code. You fail.

That's php, just cleaner. If we don't recognize that as one of php's strength we're doomed to fail.

Of course once you master it, you separate the code from the html and call it from the view like this:

hello.nxt

    name = request.get('name','world')
    list = ['this','language','rocks']
    response.render('hello.html',name,list)

hello.html

    <h1>Hello {{ name.upper }}</h1>
    <ul>
    {% for item in list %}
        <li>{{ item }}</li>
    {% endfor %}
    </ul>

But what do I know about language design or human behavior?

Funny mixing PHP into HTML is one of the things I hate the very most. And is one of the first problems usually solved by PHP web frameworks. Well, templating is actually generally a primary component of "all pieces included" web frameworks in any language.

Exactly, but that's the easiest way to start learning. That's how everybody got their feet wet in web development. Then you jump to MVC and best practices.

My point is, the language has to be designed as a web framework from the get go, routers, templates, models, everything should be right there so noobs feel confident from day one. That's the only way to conquer the world.

In a few years most NEW projects will probably not be made in PHP. You are suffering from Cognitive Dissonance, PHP is not good.

Uh... You're quite wrong about that statement. If I could find you in real life I'd love to make $1,000 bet with you.

You also missed my point entirely. Good job.

And you are suffering from cognitive bias?