Well the lighter solution and more Pythonic solution is strong typing. If a Unicode string and a byte string could not be combined then the problem would not exist AFAIK. For example "a" + 1 is an error, why is u"a" + "s" not an error?
I had some advanced requirements and couldn't just throw it into my app in its most basic form. All the requirements for javascript includes blew my mind. I agree with another poster that something like this should be built into the browser.
Varnish is just a proxy, or webcache, as I believe they like to call it. Nginx is needed because Varnish won't talk directly to the uwsgi processes, Varnish only understands http. The data that Varnish need to cache has to be supplied by a webserver somewhere and nginx is pretty nice and easily configurable. So I would assume that the idea is to use nginx as the webserver, not the cache/proxy.
nginx is a much weaker proxy and doesn't allow as much customization as Varnish does. A coworker also ran into some basic HTTP compliance issues with nginx's cache and Vary headers - IIRC it simply ignores them outright. If you need more than very basic caching it's usually better to use Varnish because it's obsessively focused on doing that job well.
Depending on how you choose to implement it, this may also result in cleaner architecture if you have Varnish as a simple HTTP brick with little knowledge of the backend implementation, leaving all of the gory details to nginx.
Well i think the gist is that serving files and running applications have different resource requirements. Therefore it is common to have a proxy serve statics and proxy in addition to an application server running python. The advantage with uwsgi as i understand it is that the proxy protocol is faster than http.
No, uWSGI has nothing to do with performance. Its strength is in the features and operational modes. Each application is diferent from the others and (could) requires specific tuning.
This is the spirit of the project, that is at the opposite of solutions like gunicorn. There is no "best choice", it depends on how you approach to system administration/development. Saying uWSGI is better than gunicorn (or the opposite) is like comparing bananas with oranges.
I have only used apache as an application server with mod wsgi behind nginx. I have not used gunicorn or uwsgi. Yhanks for the correction, I should have just stopped my explanation before that.
This is a good devil's advocate summary, except feasibility of remote development with a GUI. I don't agree with a few of these points though.
"Someone who has either invested or going to invested 100's of hours to properly learn the iOS/Mac frameworks"
I think a lot of people will just want to experiment with something, or see some app, in my case I need to fix a bug in a desktop app I use. The kind of bug that I think just requires running a build and then searching forums, etc. for the error. I think the 100s of hours would have been wasted setting up virtualization and the toolchain but I can pay 20-50 a month to have that done for me.
"someone who is either unable to afford an older mac mini ($200-300 as noted in other comments) OR someone who has no cheap way to deliver older mac hardware to his home country."
A lot of people will want to try things out. There is a huge convenience value to just paying a monthly fee and logging in to a virtual system that is already setup versus the hassle of buying a mac mini, connecting it all up, setting up a virtualization, installing all the junk you need for development, etc. Not to mention the upfront cost of buying a mac mini will most likely be more than experimenting for 2-3 months. I'll need to update the software on it regularly, etc. And lastly, it is just another thing to take up space on my desk that I don't use that often that: collecting dust, taking up plug space, needing to not spill coffee on, etc.
The real question I have is developing in a GUI over remote access even feasible? How good does your inet connection really have to be? How much can be done via non-GUI ?
You're right - I missed the "feasibility of remote development with GUI" part.
Re: your other comments - sure, I totally see who the service will appeal to some customers. The market is certainly there.
What I'm concerned about is the market _size_: I still believe that any current/future iOS/Mac developers will buy a Mac eventually, and there may be not many people like who only need a Mac to fix an occasional bug in an open-source Mac app, which by itself requires a significant skill.
Have other sites done this? I think its a solid idea, very based on the real world as well as supply and demand. I have a large supply of mediocre(or worse) things to say but in the real world if I walk around saying those to people that provide me an opportunity to talk they will eventually stop providing me those opportunities. Seems that the devil might be in the details on this one though.
Is karma the right thing for this? Maybe there should be a new thing called a "leave a comment" ticket. Every comment will consume a ticket. Every comment that gains strictly greater than 1 karma will gain you 2 "leave a comment" tickets but you can never pool more than 4 "leave a comment" tickets. I've left pure supply and demand here though and I've capped profit, maybe its more like supply and demand with government oversight. Every 3 days (tunable, like all prior #s) if you don't have any tickets you get a ticket(Socialism?). I think people will either quit being mediocre or will stop coming to the site, for better or worse. All this is under the assumption that other hackers don't like to read mediocre comments. I think all is lost if such an assumption is false anyways. BTW I have no idea how the HN comment system works now so someone correct me if this idea is perpendicular to the current system.
