jarrett

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.

I really liked the modified Platinum UI from MacOS X DR2 code named Rhapsody, though it could have used some polish

Interesting. I feel like the current OS X UI is just that: Rhapsody with a lot of polish. The core concept seems to be the same.

Which one is your favorite? Googling turned up several.

but they don't age well...In general, a flat icon tends to age better and reduce "eye exhaustion"

Two thoughts on that:

1) Is that just an opinion? (If so, there's obviously nothing wrong with that.) Or is there some objective evidence?

2) How well do icons need to age? Realistically, how many icons in the wild will go 5+ years without a design refresh?

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:

http://www.sequelpro.com/blog/wp-content/uploads/2013/01/seq...

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:

https://atowninblackandwhite.files.wordpress.com/2010/10/big...

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.

Other than the scientific method, how would you propose humankind gather the information needed to make important decisions?

Climate change scepticism is not a fringe view, but moderately widely held

Amongst 1) the general public, 2) scientists in general, or 3) climate scientists specifically?

My take on Ruby vs Python is this:

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:

    echo "GET / HTTP/1.1" | nc localhost 3000

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.

There are a few scenarios where I, as a developer, would find it very helpful to be able to verify real-world identities. For example, I've worked on applications where there were incentives for Mallory to impersonate Alice and attempt to legally bind Alice to something. Having a way to verify that the end user is truly Alice would be great in that type of scenario.

On the other hand, there are lots of apps where you don't really need to be able to verify the end user's identity. Like Twitter. I can imagine a world where such applications require verified ID from all users, just because the government makes it really easy to do so. That would be a big loss for privacy an anonymity. As has been discussed at length elsewhere, providing an anonymous (or pseudonymous) voice for people is one of the Internet's most important function.

Depending on the implementation, it would be possible to limit the government's collection of data to the following:

1) The underlying identity info such as SSN, photo, name, birthdate, etc. Which most governments already have even without this system.

2) A record of each request from a third party to authenticate a user. E.g. if I user my government ID to sign up for Facebook, that signup event will be logged.

Again, it depends on the implementation. The above two would almost certainly be collected in even the most privacy-respecting implementation. But, it's certainly possible to devise an implementation that enables the government to collect far more.

Good to know. In that case, probably the biggest distinction between HuffPo and HN is that HuffPo displays the content on their own site. For some writers, that might be a plus. For others, it might be a minus.

I've heard some professional writers say you should rarely or ever publish anything (e.g. a blog post) without remuneration. Not because it's wrong to do so, but because they consider it bad business. If they're right, I don't know if that should affect our judgment of a publisher who actively solicits unpaid submissions. Maybe the writers are undervaluing themselves, but then maybe the publisher isn't to blame for that.

What are Huffington Post's intellectual property terms? That could be a big distinction between Huffington Post and HN.

On HN, nobody signs over any IP, nor does the copyright holder necessarily grant a license of any sort. (If you doubt that, consider the fact that I can submit anyone's URL to HN. So submitters aren't assumed to have any authority over the IP.)

With periodicals, though, there usually is a contract with writers where rights are assigned to the publisher. Maybe the copyright, maybe just a license. There's usually something along those lines.

So the difference between HN and such periodicals (which may or may not include HuffPo) is the difference between merely sharing a link and signing over IP rights.

Oh yeah, absolutely! I didn't mean to imply you should never ask "How can I get this code to run." I meant that you shouldn't stop there. And it sounds like you're not stopping there.

My knowledge of design patterns is fairly limited

I'd recommend reading articles and books on that. And also reading open-source code. The latter can be very challenging, but also very rewarding. You should study it until you understand not just what design decisions were made, but why they were (most likely) made. If you can't figure it our, ask :)

I tend to churn out projects that work

There's nothing wrong with doing that as a first step. Many programmers will make something that works, and then refactor it into something that works and is nicely architected. Have you tried that approach? Is the issue that you don't have enough time per project?

I think they lack the elegance of many of the open source projects or example githubs I've seen.

It's a good sign that you recognize as much. That means you have an eye for good code, which is huge. What's your biggest obstacle right now? What prevents you making the jump from merely appreciating good code to writing it?

Do you feel like your skills are steadily improving? Do you critically examine your code from a year ago, and have the urge to rewrite it because you could now do better? When you're coding, do you think "What's the best possible way to do this," instead of just "How can I get this code to run?"

If you answered yes to all of the above, then you're probably already a "good" programmer, and you'll only get better. If not, then let's maybe discuss why not. E.g. is there something about your job that's getting in the way of you improving as a coder?

Have you had a discussion with your cofounders and employees about establishing goals for work/life balance in the company? If so, what did they say?

Realistically, I don't think owning a company will give you massively more freedom than being an employee of one. But it does put you in a position to enshrine freedom as a goal for everyone in the company, employees and owners alike. Economic necessity will mean absolute freedom is never possible. But in my experience, it's very possible to have good work/life balance, flexible hours, and a fun workplace so long as the leadership is on board.

You might also consider asking whether you're setting the right expectations with your clients. If you're constantly making promises that force you to work 14-hour days and always be in crisis mode, perhaps that could be adjusted.

The part about being dedicated enough to donate weekends and vacation time struck me. I'm of multiple minds about that mentality when it's applied to a large company. On the one hand, there's something beautiful about having a day job so meaningful you'll happily do more of it for free. On the other hand, I wonder if there's something exploitative about the following situation: Both employees and owners give over their lives, employees get satisfaction, and owners get satisfaction plus the financial rewards of the lives everyone donated. On the other other hand, if the employees enter into that deal consciously and happily, then maybe nobody loses. On the other other other hand, maybe there's also an element of brainwashing--which can, in principle, cause people to consciously and happily enter into exploitative relationships. Clearly, this is a complicated issue, and I don't feel at all qualified to pass moral judgment on it one way or another.

I suspect that collecting on such commissions would be a real challenge. I'm not saying the service's customers are dishonest, but...it's easy to "forget" to pay your commission when it's on the honor system. Other bills come in, other responsibilities push it out of one's mind. Human psychology may thus work against an honor-based commission system.

As a customer who's rooting for the success of Freelance Inbox, I want the subscription fee to stick around. Not to be an elitist, but by its nature, this type of service can only work if it's exclusive. (Too many freelancers, and the fierce competition makes the leads worthless.) Which is why I'm also pleased to see that Freelance Inbox will/does have a membership cap.

If the package maintainer has exposed their private key, and yet the package itself in intact, what harm is there (at the moment)? With the key compromised, you could have been MITMed, but you weren't. You could be MITMed in the future, but that's a problem for another day.