Don't listen to the crowd, they say "jump."
The single best way to respond to a mass shooter is with an immediate, violent response. The vast majority of the time, as soon as a mass shooter meets serious resistance, it bursts their fantasy world bubble. Then they kill themselves or surrender. This has happened over and over again.
Read the whole thing; it's quite long but I think it's worth it. Via An opinion on gun control « Monster Hunter Nation.
Liberals can quote legal precedent, news reports, and exhaustive studies. They can talk about the intentions of the Founders. They can argue at length against the tyranny of the government. And they will, almost without exception, conclude the necessity of respecting, and not restricting, civil liberties.
Except for one: the right to keep and bear arms.
When it comes to discussing the Second Amendment, liberals check rational thought at the door. They dismiss approximately 40% of American households that own one or more guns, and those who fight to protect the Second Amendment, as "gun nuts." They argue for greater restrictions. And they pursue these policies at the risk of alienating voters who might otherwise vote for Democrats.
And they do so in a way that is wholly inconsistent with their approach to all of our other civil liberties.
Those who fight against Second Amendment rights cite statistics about gun violence, as if such numbers are evidence enough that our rights should be restricted. But Chicago and Washington DC, the two cities from which came the most recent Supreme Court decisions on Second Amendment rights, had some of the most restrictive laws in the nation, and also some of the highest rates of violent crime. Clearly, such restrictions do not correlate with preventing crime.
So rather than continuing to fight for greater restrictions on Second Amendment rights, it is time for liberals to defend Second Amendment rights as vigorously as they fight to protect all of our other rights. Because it is by fighting to protect each right that we protect all rights.
via Daily Kos: Why liberals should love the Second Amendment.
We should not wait for our elected officials, in President Obama's good words, "to come together and take meaningful action to prevent more tragedies like this, regardless of the politics." We should do our share. One way to proceed is to mark our homes, apartments and condos, with a "gun free" sign. Parents should notify their friends that they would be reluctant to send their child over for a play date unless the home was safe from guns. Residential communities should pass rules that ban bringing guns onto their premises, clearly marking them as gun free.
Anyone who puts up such signs will become an ambassador for gun control, because they are sure to be challenged by gun advocates to explain their anti-gun positions.
Put your safety where your social stand is. Via Amitai Etzioni: Gun-Free Homes and Communities.
(This is a response to Matthew Weier O'Phinney. Full disclosure: MWOP is both my friend and respected peer. Also, like MWOP, I am a voting member of PHP-FIG, and was directly involved in the recent LoggerInterface discussion among that group.)
Matthew wrote:
My primary problem with the idea of shared interfaces is that I feel there is always room for new thinking and ideas in any given problem space, and that this thinking should not be restricted by what already exists.
By definition, truly new thinking is not generally restricted by what already exists. ;-) If lots of developers adopt new thinking on an old problem, I think it is completely within reason to deprecate an older PSR and write a new one that codifies the new approach.
Even so, I always thought a major point of PHP-FIG was to recognize which things we already do much the same way and codify PSRs around them. (I will admit I continue to be frustrated by the unwillingness of other members to do basic research and discovery of this kind.)
Thus, when we consider functionality ...
... I think it can be very useful to reduce the differences and combine the commonalities into a shared interface.
In the specific case of logging, as Matthew gives, I reviewed each member project's logging interface or base implementation:
True, I was examining them in reference to the string-interpolation portion of the proposed LoggerInterface. But I was struck overall by how similar they really were in terms of the basic notification methods. Differences were minor at best. For something like that, a shared interface sounds to me like an unqualified good.
Matthew also wrote:
Secondarily, I feel that it's okay for a given project to be selective about what capabilities it requires for its internal consumption and consistency, and should not limit itself to a standardized interface.
I completely agree. There's nothing that says a development effort is required to adopt anything from PHP-FIG. If someone thinks their way is better, then by all means ignore any and/or all PSRs entirely.
To sum up (and MWOP, please correct me if I'm not getting what you're saying):
One is able to imagine reasons why having shared interfaces of the kind described above is in opposition to, or at best orthogonal to, better development practices and greater innovation across PHP land.
Even so, I assert that shared interfaces as described, while maybe preventing an imaginable ideal in theory, instead promote an actual good in practice.
The actual good can never be as desirable as the imaginable future ideal, but it does have the benefit of being real and present.
UPDATE: MWOP informs me by private communication that I have missed his point. I await his next missive. Here's his response: http://mwop.net/blog/2012-12-20-on-shared-interfaces.html#comment-744905017
I now want to point out that in fact, while the empirical evidence on the relationship between gun control and homicide is (at this time at least) utterly inconclusive, there certainly are policies out there that we have very solid evidence to believe would reduce gun-related homicides very substantially.
The one at the top of the list, in my view, is to legalize recreational drugs such as marijuana and cocaine.
The theory behind this policy prescription is that illegal markets breed competition-driven violence among suppliers by offering the prospect of monopoly profits and by denying them lawful means for enforcing commercial obligations.
The evidence is ample. In addition to empirical studies of drug-law enforcement and crime rates, it includes the marked increase in homicide rates that attended alcohol prohibition and the subsequent, dramatic deline of it after repeal of the 18th Amendment.
"There are no solutions ... only trade-offs." -- Thomas Sowell
tl;dr: "As a library author it’s tempting to bring in dependencies for various reasons, but as a library user it’s frequently convenient to not have cascading dependency sets. ... If a user already has something they like, make it as easy as possible for them to keep using it without making them install things they don't actually need. That is the kind of duplication we really want to avoid. This applies not only to HTTP response delivery, but to caching, logging, translation, templating, and a host of other functionality."
Recent articles from me and others regarding the Aura project for PHP 5.4+, dependencies, and decoupling have generated a lot of commentary, some of it negative, and some of it misdirected. For reference, the posts are:
In this post, I'll respond to some of that commentary. I will sum up similar comments and address those summaries.
Bernhard "Webmozart" Schussek writes an otherwise good post that, unfortunately, begins by misconstruing my statements:
Aura is creating some buzz that components of PHP frameworks should not have any dependencies.
...
The general attitude of people arguing against dependencies is that dependencies are a bad thing.
Matt Robinson makes a related comment:
You’ve made a judgement call that dependencies should be avoided at all costs – I think that’s going a bit too far.
I can understand how some readers might infer the "dependencies are bad" sentiment from the interviews, especially if they did not read with thoughtful consideration. Their assessment is incorrect.
For the record: dependencies are not a bad thing in and of themselves, nor are they a good thing in and of themselves. Choosing to have one or more dependencies is a trade-off in software development, where the gains and losses from having the dependency must be judged according to the context of the development goals.
If dependencies are neither good nor bad in themselves, why does Aura avoid them so assiduously?
To learn the answer, please recall the origin of the Aura project (which is essentially the second major version of the Solar framework):
One of the repeated questions we got regarding Solar went like this: “I want to use just one part of Solar; can I do that without having to download and configure the whole framework?” Of course the answer to that was “not really.” It was a monolithic framework, where all the pieces were designed to work with each other in a relatively dependent fashion.
So with Aura, we started out from the other direction. We wanted the pieces to be usable on their own, without any other dependencies. Only after that would we build a framework out of the pieces.
As you can see, it is expressly our goal to serve a particular set of users as our primary focus: those who want independent libraries without added dependencies.
As a library author it's tempting to bring in dependencies for various reasons, but as a library user it's frequently convenient to not have cascading dependency sets. Call it a case of taking our audience seriously, and going as far as we can with it.
Matt Robinson asks:
[W]hat’s the real difference between AuraHttpMessageResponse and AuraWebResponse? They look remarkably similar and have significant overlap in interface and purpose. I might be wrong, but it looks like you’ve got this big chunk of duplicated effort for the sake of avoiding one line in a composer.json file. :)
They are remarkably similar, since they serve a similar purpose; that is, to describe an HTTP response. I think "big chunk" is an inaccurate characterization, though; it's 2 classes out of 56 between both packages.
As Matt allows, he is in fact wrong. ;-) The duplication is not for the sake of avoiding one line in a Composer file. It is to make sure that people who want to use Aura.Web package are not required to additionally install the entire Aura.Http package to get access to a single class.
Many library users out there already have HTTP delivery mechanisms of their own choosing, and have neither the desire nor the inclination to drag another one into their codebase. All these users need is a way to describe an HTTP response. It's easy to do that in a single file.
Because of this single class of duplication that exists in Aura.Web, library users can build a relatively small amount of glue code to send the AuraWebResponse using their existing installation of Guzzle, Buzz, the HTTP extension, plain old PHP, or even the Aura.Http package. This is the tradeoff: a single duplicated file, versus many dozens of files of duplicated, unused, and unneeded functionality.
That is the central point for the Aura project: if a user already has something they like, make it as easy as possible for them to keep using it without making them install things they don't actually need. That is the kind of duplication we really want to avoid. This applies not only to HTTP response delivery, but to caching, logging, translation, templating, and a host of other functionality.
Stan, who admittedly is part of the Aura target audience, already knows this:
[T]here are some of us out there that have a hybrid of components tooled together. The more dependencies that are forced on us (guilty by assoc) the harder that is to do. So maybe my app that’s routed by Aura, templated by Twig, works with the DB using Doctrine ODM, utilizes Symfony for the Finder and Yaml components and Zend for the console could find itself in a pickle when more baggage is added to the mix through dependencies that might not be necessary.
Amy Stephen also figured out the point pretty quickly ...
Disagree with Paul’s assertion in the comments that such a strategy does not lead to some duplication of code or function or that the methodology means some functionality be sacrificed. Of course, it does. That’s the ying and the yang of it – get one thing clean and another dirty – the cost, time, quality triangle – It’s math. It’s always a balancing act building software.
... although to be fair, I didn't say "does not lead to some duplication"; I said duplicated code was "almost nonexistent." ;-) Perhaps that too was a mischaracterization: a few classes here and there, among hundreds of classes and a dozen packages, seems rather small to me. Others may disagree.
Some commenters claim that this approach promotes "NIH" syndrome. Drak said:
Seems to me like you are promoting NIH. The very concept that a decoupled component cant have dependencies means you have to invent everything yourself.
Webmozart similarly opined:
I think this needs some urgent clarification before this way of thinking becomes mainstream and PHP creeps back into its NIH-hole.
I would argue that the offering decoupled packages in the way the Aura does leads away from not-invented-here syndrome, not toward it.
Recall that one of the driving motivations behind Aura was to extract the parts of Solar that users wanted as separate packages. Those users wanted very badly not to engage in NIH by using Solar, but could not, because it was delivered as a monolithic whole. Those users can now download independent, decoupled Aura packages and avoid rewriting the functionality contained therein.
Bertrand lobbed a shot over the net at, I guess, the Symfony crowd, when he said:
Ha, ha, who’s got the NIH syndrom ?
Event_Dispatcher, written in 2005, 3 years before the one in your example...
This is a comment I sympathize with. It seems to me that many accusations of NIH-ism are more complaints and frustrations that the accused is not using the libraries and packages the accuser prefers.
Some commenters were dissatsifed with my use of unit testing requirements to discover what a package really depends on, as opposed to what its composer.json file states. Webmozart said:
There’s a distinction between required dependencies and optional, supported libraries. For example, the Symfony2 Validator optionally supports annotations, in which case you need DoctrineCommon (why should it reinvent annotation parsing?). You can use the Validator without any of these supported libraries.
Obviously, the support for these libraries is tested, so for running the tests you also need the supported libraries (doh). I fail to see how this is bad.
Lukas covered this as well:
[T]he issue is that the way [Paul] was comparing. Paul was making a very incorrect conclusion that anything that is needed to run the tests illustrates “cross-package dependencies”. Yet if you look at the composer.json (which I would have expected Paul to be familiar with) then you would notice that infact the Validator component has ZERO dependencies beyond PHP itself:
https://github.com/symfony/Validator/blob/master/composer.json
This was a topic I had hoped I would not have to address. All my other statements regarding dependencies have been as clinical as I could make them, without reference to words like "good" or "bad" in describing the various practices. For this topic, though, I must make some statements that others will find negative or perjorative. Because of that, I am going to do it in an entirely separate post, so as not to pollute this commentary thread too harshly. Look for it in a few days.
Thanks to everyone for their comments and critique, and please be sure to check out the Aura project!
Late last night we released version 1.0.0-beta4 of the full-stack system, which composes all the independent Aura packages into a coherent framework using the Aura.Framework package in a project skeleton. We have extracted the “hello world” portions into their own Aura.Demo package so that it can be removed or disabled when you begin your project. Download it and take it for a spin!
via New System Release, Including Aura.Framework and Aura.Demo.
An affluent resident of an upper middle class town, Lanza had exactly the kind of resources that you would want for taking care of a kid with these kinds of problems. His parents had all the money he needed to get him help, and his school did everything they could to help him cope, according to the Wall Stret Journal: "Not long into his freshman year, Adam Lanza caught the attention of Newtown High School staff members, who assigned him a high-school psychologist, while teachers, counselors and security officers helped monitor the skinny, socially awkward teen, according to a former school official.
...
"Make more mental health resources available" or "early identification and treatment of troubled children" is a fine answer to many cases, but Adam Lanza had all that you could wish for in terms of resources. It didn't stop him from picking up a gun and going to that school.
What Lanza shows us is the limits of the obvious policy responses. He had all the mental health resources he needed--and he did it anyway. The law stopped him from buying a gun--and he did it anyway. The school had an intercom system aimed at stopping unauthorized entry--and he did it anyway. Any practical, easy-to-implement solution to school shootings that you could propose, along with several that were not at all easy to implement, was already in place. Somehow, Lanza blew through them all.
via There's Little We Can Do to Prevent Another Massacre - The Daily Beast.
Big news in pensions today: Silverdex, a major US-based conglomerate with fingers in just about every economic pie, from mining to solar cells, turns out to have been stuffing its main pension fund full of . . . it's own corporate bonds. For decades. It's still not clear how this happened without anyone noticing, but essentially the pensions that current workers have been counting on for thirty years turn out to be backed by nothing more solid than the company's promise to pay. Amazingly, when confronted by reporters about this behavior, a representative declared that this was a big fuss over nothing.
"It is perfectly legal to invest a pension fund in corporate bonds. That is what we have done. These bonds are backed by the full faith and credit of Silverdex, and it is defamatory to suggest that they will not be paid."
Silverdex is still pretty profitable after all these years, but "defamatory" seems absurd; obviously, it's quite conceivable that the firm will run out of money, and the workers will be left with no jobs, no pensions, and no retirement. Though no charges have yet been filed, a congressional hearing is scheduled for next week, and observers expect high-level resignations from the Pension Benefit Guaranty Corp, which regulates pensions, to follow.
I don't really know how to say this, but sorry, I lied a little bit. I'm not talking about a private company at all, because of course, if a private company did this, it would be completely and totally illegal. Regulators would have shut this down decades ago and probably at least a few lower-level executives would have spent a little time in the pokey. Instead this is, of course, a description of how the United States Social Security "trust fund" works.
(Emphasis mine.) As usual, if a corporation did what the Federal government does, people would be howling for blood. But it's the government, so somehow it's OK. Via Assets in Name Only - The Daily Beast.
When every area of life becomes politicized, and political conversations are filled with elaborate terminology laced with virtually incomprehensible numbers, voters aren’t going to rush out and master macro-economics, or learn how to do math with ten-figure sums. They’re going to decide which candidate they like more, and trust him to get everything right on their behalf. Or, perhaps more pertinently given the nature of the 2012 contest, they’re going to back away from the candidate they dislike, and therefore distrust. Those eyebrow-raising 100-percent-Obama voting districts in the 2012 election were cultural achievements, not the result of successful political arguments.
File under "politics is not about policy." Via Buying into the culture war | Conservative News, Views & Books.
