Do you recommend any particular alternative to New Relic? In particular, I'd be interested in something that helps answer the questions "How much memory am I using, and what's using it?" New Relic helps a lot with the latter question, as it can aggregate request time by Rails action. E.g. it can say "30% of your Apache workers' time is spent in this one Rails action." Which helps you understand what's driving the need for more Apache workers, and thus the need for more memory.
I think most people would be OK with an additional flat fee so long as the notice is clear and conspicuous. For example, if I were renting a space daily and had to tack on a flat cleaning fee, I might write something like this:
$99 per day, plus $20 flat fee
In other words, you can develop whatever fee structure you want. You just have to adequately explain it to customers so they can make an informed decision.
Hypothetically, what if you actually believed it in every instance? That is, what if you genuinely felt (as I do) that nearly all jobs are hard. Granted, some may be harder than others, but I've never met anyone who worked a job I would describe as "not hard."
> common tooling like benchmarking and profiling tools
And might I add: A debugger! For both shaders and the entire GL state. Yes, 3rd party tools exist. But more often than not, I find they won't even compile or execute on a given platform.
Philosophically or practically: What's the justification for nearly everyone switching to flat design? Is there any articulable reason it's "better" than the rich, three-dimensional style[1] that was previously popular? Or is it just an arbitrary trend?
Some say the change is driven by high-DPI displays. I disagree. I don't see any intrinsic reason that flat designs look better than rich, three-dimensional designs on a high-DPI display. Without a doubt, flat can look nice, but so can things like this:
Another justification I've heard is that it's a reaction to the excesses of the previous trend. People often point to the leather motif in certain Apple applications as an example of such excess. But first of all, those examples are outliers; few designs actually went that far. Second, the existence of a questionable use of a given style is not an effective argument against that style in general. Third, "some things were extremely 3d, so now we'll be extremely flat" seems like contrarianism for contrarianism's sake.
[1] Some call this skeuomorphism. I tend not to, because the term technically means something narrower than what we're talking about: http://en.wikipedia.org/wiki/Skeuomorph
> I can't think of any better way of describing black.
That's probably the most precise and scientific definition of true black, but it's not how most people imagine a black material.
Any black material you'll encounter in everyday life is still quite reflective in comparison to this high-tech, superblack material. If you see a man in a black suit, you can still see the buttonholes, the lapels, the wrinkles, and the three-dimensionality of the man's body. That's because it's actually reflecting a lot of light.
But if the suit were sufficiently light-absorbent, you wouldn't see any of that. It would look like a homogenous blob of solid color--just a silhouette. One can simulate that experience to a certain degree with photography:
In person, one can also get a sense of that by looking at an extremely high-contrast scene, e.g. a person in a black outfit with strong backlighting. But such a picture feels much more natural to us than would a suit of true black in a room with normal lighting.
It's not a Rails vs Django feature comparison that gives Rails the edge. Convergent evolution means they're pretty much on par with each other all the time.
The difference is in the size of the ecosystem as a whole. The Ruby web dev world appears to have more (or more visible) participants. Which affects things like Stack Overflow, web-specific packages on Github, blog posts, etc.
It's not an order-of-magnitude difference, as far as I can tell. But still significant.
I think we have almost the same opinion, actually. I said Ruby's "web dev ecosystem...feels much larger to me." I agree that Ruby's strongest niche is web dev. And I think it has an edge of Python there. Outside web dev, I don't see Ruby dominating any particular niche.
> Silencing the ongoing debate, even if one side or the other is obviously delusional, is completely contrary to the spirit of science.
A news outfit does not have the power to silence scientific debate. Real, productive scientific debate does not occur in 5-minute talk show segments. That's just entertainment. Scientific debate occurs in less glamorous venues, such as conferences, journals, and labs. And it involves a great deal more time and technical detail than what you get on a news show. News organizations don't control those venues.
Now, one can of course raise valid concerns about process in the scientific community. Much has been written along those lines as of late. But that's entirely separate from the BBC's policy, and out of the scope of this discussion.
While Python has a healthy web dev ecosystem, Ruby's feels much larger to me. That's almost certainly because Rails is so wildly popular. And Rails is an excellent, mature framework. So for web dev, I would consider Ruby the winner.
Python is the clear winner for scientific computing. That's not really due to anything
inherent in the language. It's an ecosystem thing. If you were using Fortran before,
you might be working in a problem domain where Python dominates.
Both are excellent for miscellaneous scripting work. E.g. reading in a CSV file and doing something with each row; batch-processing a bunch of images; renaming 1000 files according to some ruleset; gathering some system data and sending nightly status emails.
In terms of syntax and features, they're very very similar. Python has meaningful
whitespace, which you may like or dislike. (I think it's good for enforcing proper
formatting, but you're free to disagree.) Ruby has multiple ways of expressing the
mathematical concept of a function (methods, blocks, and procs), which has its pros and
cons. Both have metaprogramming facilities, though I find Ruby's more pleasant. If I remember correctly, it was in large part the metaprogramming that made DHH pick Ruby for Rails.
For any given fringe view that the media properly marginalizes, some people will go on believing it. But that doesn't mean the number of believers (or undecided people) will stay the same. It's quite possible, and in my view probable, that reducing airtime from fringe views will substantially reduce the number of people who hold or lean towards those views.
Apparently it's being used at Facebook. If they actively injected life into the D ecosystem to the same extent Google does with Go, the momentum might pick up substantially. Look at how late Go arrived--it was announced in 2009--and how popular it already is. Now, that doesn't mean Go or D can necessarily become the next big thing, i.e. the C++/Java killer. But even if they got as far as Python or Ruby, that would be a significant change to the programming landscape.
True--in principle any language can be executed in the JS runtime. A lot of them can even be executed reasonably quickly. Though I suppose the parent comment was asking whether a mature compiler from D to JS currently exists.
> Most of this frameworks enable sessions by default
True, but in my experience, the major frameworks don't automatically lock out users with cookies disabled. For example, on a Rails app with no before_filter on the homepage, you can start the server and do this:
I understood this to be something different from what Schneier describes. (Though I could be mistaken.) I took this to be primarily an API for Internet applications to verify an end user's identity claims. I realize there are physical cards involved, and those could be problematic, but the API part sounds better.
The failure modes Scheier describes would still be applicable, of course. But as a developer, I might still appreciate having the system available. I couldn't trust its responses beyond a reasonable doubt. But still it might be valuable to have some extra degree of certainty about a user's identity, in some scenarios.
Let's say, for example, I'm developing an online liquor store. Let's say I accept various forms of payment, some of which don't come with age verification. I might appreciate a simple, unified ID API for that purpose. Granted, it would still be possible for minors to exploit the vulnerabilities Schneier describes and buy alcohol from me. But conceivably, if that happened, the law might grant me immunity, because I checked against the government API and the failure was on the government's part. Which would be a valuable assurance for me as the developer or business owner.
