I don't see the point in attempting to choose a language/framework for the next decade. I would think that different languages and frameworks will be a natural fit for specific applications and perhaps the reason the author is struggling to make a decision is that he's attempting to make it based solely on the abstract rather than a concrete application.
I'm not the only one who'd like people to choose frameworks and languages on something other than gut feel and googlefight results, right?
I am not a lawyer but like the new no evil license clause Doug Crawford put on various packages this I'm not sure that "do what the fuck you want" is particularly meaningful in a legal context. You know people have been saying "don't roll your own crypto" lately?
Don't write your own license.
Don't write your own contracts.
Don't write your own legal documents.
There are plenty of solid, well written and unambiguous licenses out there that one can use to offer your users the same freedoms without the WTF.
Being a Pythonista and working with Chef for the last year I think that this is makes some sense. We've been recently contemplating the same migration.
Of course, this case the number of servers being managed is low enough that there isn't really a going to be much of a performance difference between Chef or Salt so this is likely just the preference of the current maintainers.
PyPy has folks actively working on getting Py3k support. Check out their status updates on py3k and consider donating to the PyPy project to make this happen.
+1 for actually giving me a couple reasons to try zsh. Of course I'd be surprised if many of these features aren't already hacked into some bash guru's dotfiles but, that said, more autocompletions without writing them myself is always nice.
Ah, you don't respond to the user until the DB interactions for a given user have been processed as a batch. I was under the impression that on a write you were: updating the in memory dataset so that the user could immediately read their data after the write, queuing a write to MySQL, and then responding to the user (200 OK) even though the data had not been committed.
So my concern regarding consistency was that during this period after responding to the user but before your queue committed data that a bug or hardware failure would result in some users thinking that there requests were successful but none of their work would be saved.
As long as the user doesn't receive a response until data has been committed to your DB this makes sense.
Now that I understand the flow a bit better I agree that it makes sense. This is similar to what folks were trying to do with MySQL-Proxy. I still think that you're asking for trouble by coupling your components together in the same process and would really encourage you to take it to the next level by factoring out caching and proxying/batching of db access into their own services.
The more I think about this the more it seems like it would be reasonable to build as a separate twisted process and exposed through a api compatible with twisted.enterprise.adbapi... Figuring out reasonable (and general) ways to determine which statements can be safely batched could be quite challenging though.
I'm sure they'll piss a bunch of people off when the inevitably raise prices again. However, in 6 months when those people realize that cable still sucks and there is no viable competition they'll sign back up.
If netflix cost exactly the same thing as cable I would happily pay because they distributes content in a way that is convenient for me and they don't run commercials to subsidize their income at the cost of my enjoyment.
It's a great idea except: You're now eventually consistent. You've reimplemented a ton of database logic in his application. The database already reorders inserts and checks for conflicts. The database is also already doing its best to be durable (write-ahead logs for example).
You can't run more than one server due to the custom batching and reordering logic and in memory caching and a hardware failure will result in loss of data.
You've put all your data in one basket. Anything happening to the application server results in data loss. Of course hardware failures happen and all the batching behavior here seems like it exacerbates the problem. A single server handling all writes and reads also makes it particularly difficult to update that server at any point in time. When is it safe to restart this server to apply an update or fix a bug?
Basically the author has avoided using a NoSQL database by reinvented a bunch of things to provide all of the downsides of a NoSQL database (eventual consistency, no ACID semantics) without any of the upsides (high availability, replication).
Alternative solutions to the "handle many requests" on top of a SQL server problem?
Have more application servers. You don't need to service all user requests from a single machine. You don't need to have user 10 wait on user 1s database write if they're independent. Multiple servers have other benefits like rolling updates...
Use memcache.
Use a (durable) message queue to offload work from a the web servers and do non-essential updates/inserts offline.
And of course: Just use a NoSQL database and design your application appropriately.
“Apple had redesigned the iPhone’s screen at the last minute, forcing an assembly-line overhaul. New screens began arriving at the [Chinese] plant near midnight. A foreman immediately roused 8,000 workers inside the company’s dormitories, according to the executive. Each employee was given a biscuit and a cup of tea, guided to a workstation and within half an hour started a 12-hour shift fitting glass screens into beveled frames. Within 96 hours, the plant was producing over 10,000 iPhones a day. ‘The speed and flexibility is breathtaking,’ the executive said. ‘There’s no American plant that can match that.’ ”
Ah yes, at midnight I'll just go walk over to my "dormitories" on my "plantation" and wake my "employees" and tell them to get to work harvesting cotton. In exchange for their 12 hour work day (and a comfy dormitory in which to live) I'll give them tea and a biscuit!
I don't understand why the "Average" American won't come work for me given these perks.
Your numbers are also consistent with the GP point that calorie restriction works in the short term until your body decides it's being starved and your weight plateaus. What's your data say about users that have used your app for 8 weeks, 16 weeks, 52 weeks, etc.
I think the article is buying into the notion that the web can never be as rich an experience as the native application. I think that the last few years of explosive growth in terms of cloud services and web applications have made it pretty clear that web applications are a viable alternative. Why won't web applications work for mobile devices as well?
Is the argument simply that the app market is less crowded? Is a comparison of the number of websites on the internet(apples) to the number of android applications(oranges) that compelling?
As much as I'd love to believe it's dead I suspect the real thought process here is "Let's rebrand this turkey." They're going to let people calm down and resubmit the bill next month with a new name.