Point 7 - Port Binding: I'm interested in hearing anyone else's views on this. How would you even do this for a Django app? And is this really better than just using WSGI? Is anyone using Tornado with Django in production? Google showed a couple proof of concept demos, but nothing serious.
At the moment, I have some apps deployed with nginx > uwsgi > django, taking advantage of the fact that nginx has built in support for uwsgi these days. This breaks rule 7, since my app isn't just binding to a port - but would I really be better off by using nginx > tornado > django?
Point 3 - Config: The claim is that you shouldn't have a config file that you don't check into source control like Rails' config/database.yaml, or the common Django settings_local.py. Instead you should use environment variables. Um. I see the point,but I also see two problems with this.
1) I'm certainly not going to set env variables with database passwords and such by hand. I'm going to have a script to do it for me. I might even call it, oh, I dunno, settings_local.py. In which case, I'm right back at square one, needing to not check this into source control. In other words, how do you avoid having the database passwords in SOME file, SOMEWHERE? Does it "fix" anything if it's named "fabfile.py" instead of "settings_local.py"? I can't see how.
2) How do I deploy multiple apps to the same server? Let's say I've got a linode (or EC2 instance, or whatever) running a test, dev, and production deployment of three different apps. With config files, I just have a different settings_local.py file in each deployments project directory. With environment variables...what, do I use prefixes? app1_test_dbpass = 'foo'; app2_prod_dbpass = 'bar', and so on? Except they say NOT to group stuff together into environments by name. So uh...how do you manage name collisions?
Basically, they seem to have identified a real problem, then proposed a solution that doesn't fix it and doesn't work. What am I missing?
I recently switched from various settings.yml files to a bash script. I can't believe I hadn't made the move sooner! Such a huuuge improvement.
A few good reasons:
1) Language agnostic -- I can use common configuration for Ruby, Node.js, Makefiles, Bash scripts, etc. Without having to find/use a parser for my config file settings, nor worrying about executing a Ruby script from a Python process, or whatever.
2) Real programming constructs -- I can easily test a boolean condition, interpolate variables, and otherwise minimize copy/paste between configuration sections.
3) Available at bootstrap -- Don't need to install Ruby or Python or anything like that. The very first scripts I run can use the environment without compromise. Particularly useful because machines are bootstrapped with Makefiles, which play well with the environment.
I modeled my app env script on the behavior of the `env` command (in fact, I delegate to it). See an example script in this gist:
1. Have a script that defines environment variables your app uses, and name that script ~/.bashrc, user accounts are cheap and provide an excellent way to have isolated environments.
2. Check an example copy into the project itself. The application does not source this script itself. This documents the dependencies of the app.
Disclaimer: I've never deployed on anything that wasn't unix-like.
I use chef and runit's chpst (like envdir) to set the environment variables.
The production / staging environment chef configuration is stored in a tightly-locked down git repository that can only be accessed from production.
Chef reads the production configuration information, puts the environment variables into envdir-complaint files in a directory, runit uses chpst/envdir to start the process with the correct environment settings... and that's pretty much it.
The main thing is your configs lives somewhere different than the code. They can both be source control somewhere. Though I generally keep a localhost config with my code.
Just define an env variable or something that contains the location of settings.py, a directory thats managed by something like chef/puppet.
Yeah, that part didn't make much sense to me. Say I have 5 different projects, which when developing may need 5 different sets of environment settings on my local computer.
So obviously I need something that contains and applies these settings. What makes this any less likely for me to accidentally commit that than the files they're objecting to?
Objectively, her work is not that great. She wrote simple stories with repetitive plots and cardboard characters. And yet...
It's tempting to try and compare one of her books to, say, one of Louis McMaster Bujold's works, and sneer that McCaffrey was just a hack. And perhaps she was, but that rather misses the point. Bujold started writing in a world that already had McCaffrey in it (and McCaffrey blurbed some of Bujold's early work very positively too).
McCaffrey was a pioneer. No, she wasn't the first, but she was one OF the first, and one of the first to be widely popular, and certainly one of the first female authors to be widely popular. All of which are major achievements.
I couldn't begin to imagine how many kids got their first taste of sci-fi/fantasy because their local library had a pile of McCaffrey's Dragonrider books. And if many of them went on to "better books" later in life, and have barely gave McCaffrey's work another thought in the years since, well...it doesn't change McCaffrey's contribution. There's a non-zero number of readers (and, come to that, authors) who wouldn't be around reading (and writing) if it wasn't for McCaffrey.
I don't think the word ideological means what you think it means. Ideological behaviour is behaviour motivated by ideas, not profits. Corporate lobbying is essentially always motivated by profit, not ideas. Can you name a company who lobbies for policies they honestly think will lower their profits?
I think it's fair to say that nobody at Universal has any idea if Grooveshark is actually raising or lowering their profits. Nobody has conducted any kind of inquiry to see whether the sales lost via Grooveshark are compensated by the value provided to music-owning consumers (upload, play anywhere) and the free publicity gained, and nobody cares to.
Rather, the industry decided long ago that it would take it as an a priori truth that any kind of piracy costs them money, and act accordingly. That's an ideological stance.
This lawsuit is likely not pertaining to cost but rather to control.
Grooveshark is not really "piracy" since every content owner gets paid regardless of the origin of the content. Whether it cannibalizes other revenue sources is up for debate.
However, copyright is also about control and owners want complete control of their catalogs.. for a good reason.
Grooveshark crowdsources catalogs without permission from copyright owners and then only lets them manage the content via DMCA takedowns. The labels have to relinquish control to the users for this system to work and that is what they are objecting too.
Money and control is what copyright is about. Big media are ideologically against Grooveshark paying their users to seed the system without the owners consent.
To use an analogy: Grooveshark is a grocery store where the customers personally stock the shelves with Coca-cola products but the company doesn't get to decide which products are available. Maybe the customers don't like Coke Zero and refuse to stock it. Coca-cola can't do anything except remove stock they don't want there.
Except the analogy falls down since Grooveshark is digital and the shelf space is infinite. The labels can add their entire catalog themselves, but they don't want to.
If a band is touring the world to promote an album, their presence in a given country has a huge impact on sales in that country.
If music is leaked across the internet way in advance of the tour/pr/marketing drive, then sales of the album drop precipitously. It's not possible to be everywhere on Earth at once, so it's then impossible to effectively market the album.
Agree - it's really the cabal of old guys looking to screw over a young upstart competitors.
Crooked movie/entertainment businessmen? Sounds just like those old gangster/movie tycoons in the old Raymond Chandler novels I've been rereading since moving to LA!
It's always motivated by expected profit. "Ideological" just means it's not about next quarter's profit, but about creating an environment more conducive to profit in the long term.
These rankings assume that signing a law that creates a new entitlement that will entail large payoffs in future decades is "free". Being in office when those promises come due is profligate. In reality, we should be using accrual accounting, and book liabilities when they are incurred. This would more or less upend the rankings. (Mind you, this would be very difficult. The magnitude of the liabilities from PPACA are essentially incalculable at this point.)
And on a related note, the rankings also assumes that there is no lag in terms of fiscal policy. A president is responsible for everything done by the government from the moment he takes office to the moment he leaves. But of course, this is absurd. It may take a couple years to enact a new policy, and another couple of years for the effects to start showing up in government accounts. A big tax cut (or tax raise) might take a decade to work its way through the economy, once you include knock-on effects like changes in consumption or investment. More generally, it's trivially obvious that the deficit in any given year is not only (or even mainly) the result of policy enacted that year, or even during that administration (especially for the first year or two of an administration).
And as other commentators have noted, all of this is assuming that presidents even have control over the budget, taxation, and spending. They don't. At best they can sometimes convince Congress to give their ideas a respectful hearing, but rarely (if ever) will Congress simply enact a Presidential policy or budget. (And that's when the same party controls the White House and Congress. When they don't, they'll often enact the opposite policy just on general principle.)
According to the article, this is a proposed amendment to ban corporations from making political donations or expenditures. It's not clear from context if that means companies donating to a political campaign, or if it extends to independent expenditures that would influence an election. Let's examine each possibility in turn.
If it just covers donation, then, under current law (which has been upheld by the Supreme Court) corporations may only contribute a maximum of $5,000 per candidate. To put that in context, Obama may raise $1 billion dollars this cycle; the Republican challenger will likely do similarly. Is $5,000 from Exxon or whatever really worth worrying about? (Besides, under Supreme Court precedent, you could probably ban all corporate donations if you wanted, instead of just capping them. Nobody's tried, because honestly, who cares?)
Alternatively, if covers ALL corporate expenditures that may influence an electionm then it would also remove all free speech protections from such things as: The New York Times, Michael Moore's movies, MSNBC, Greenpeace, and more. (Yes, Greenpeace, according the the proposed text of the amendment.) Or rather, they would have free speech protections as long as didn't say anything about any political figure or issue, such as the economy, the environment, or foreign policy.
And that's really the only two options. Either the amendment does absolutely nothing worthwhile (stopping the scourge of Exxon being able to donate $5k to a candidate), or it eviscerates pretty much every vestige of a free press left in America. There's just no way to interpret this as a good idea.
Further, if it DOES stop all corporate expenditures, the only people this amendment would really benefit is the rich. The 99% can't get our message out without the help of other people, banding together to help each other. By removing one of the main ways people group together to get their message out, you muzzle the little guys. But billionaires face NO restrictions! Nothing in the amendment stops the Koch brothers from spending an effectively unlimited amount of money on promoting their favoured candidates and ideas as long as they do it from "personal" funds. What do you call an amendment that stops me from donating to Greenpeace so they can run a pro-solar power ad, but doesn't stop the Koch brothers from running pro-oil ads?)
(Note: I've used left-wing examples as the good guys, and right-wing examples as the bad guys. If it helps, swap them. Consider the damage done to Fox News and the NRA, while it lets George Soros spend with impunity, if that's more alarming. I think this proposed amendment should give everyone something to hate.)
It's fairly new but feel free to browse the code; it should be pretty straightforward to you. I've tried to provide good examples to make it easy to learn/use on phzbox.com/moka/.
Google and Microsoft have a huuuge list of projects they jumped into, and failed, leaving the competition stronger than before. All sorts of half-baked apps and ideas - from Google Knols to Microsoft Frontpage.
(Yeah, okay, Adobe isn't exactly a small company. But they're a lot smaller than Microsoft, but Dreamworks has consolidated its position, and Microsoft killed off Frontpage...)
This is a little bit like, oh... Opera writing a blog post about how you shouldn't use Firefox because it won't display any Google page.
...ie, it would be very important and interesting if true, but it's 1) not true, and 2) trivially verifiable as not true.
Groupon works in the precise opposite way of how Womply claims they do; they provide payment to the vendors well AFTER the voucher is used, not BEFORE the voucher is used. Every single point and conclusion made by Womply is not just wrong, but describes a world precisely opposite to the one we actually inhabit.
I have never heard of Womply before, but apparently they're run by fools. At best they have no clue how their competition does business. More likely they do know, but assume that their customers don't, and feel no compunction about lying. Either way...
At the moment, I have some apps deployed with nginx > uwsgi > django, taking advantage of the fact that nginx has built in support for uwsgi these days. This breaks rule 7, since my app isn't just binding to a port - but would I really be better off by using nginx > tornado > django?