h2s

    > Women are like dogs

Fuck off.

Yeah. The hand-wavey reference to advances in parallelisation and cloud runner infrastructure doesn't adequately address the drawbacks of this "post-TDD" approach.

Worth bearing in mind that this is effectively DRM for email, with all the negative connotations that DRM brings.

Better still, it deserves to be replaced with a better name. Comments should not be our first port of call when we notice an issue like this in code. Fix the name. If you can't fix the name, you hang your head in shame and then you write a comment.

See this comment: https://news.ycombinator.com/item?id=7296586

Good commenting is no substitute for good naming. For a variable containing the number 1, "three" is a shitty name.

This is a bloody clever counter-argument as well as an excellent example of the right way to use comments.

Eagerly looking forward to the explanation for this weird juxtaposition.

http://i.imgur.com/huUv09m.png

I don't think there's enough attention on the fact that the strict MVC approach of big old school web frameworks like Rails is an increasingly glaring architectural dead-end. The "model" part of an MVC application is invariably far too complex to crowbar inside a couple of dozen Active Record subclasses. And you can't prescribe a one-size-fits-all architecture for the model from a framework level. That part has to emerge from the business and technical constraints of the specific application in order to be correct.

Rather than an exception, I think this is an example of the precise scenario in which it's most inappropriate to use comments.

    > visually represent logical segments of the code

This is exactly the use case in which function definitions excel. Use functions for this, not comments.

Never write comments that re-state the implementation.

    # Try to read the configuration file.

If this wasn't already obvious without the comment, then the code is a mess. Tidy the code up instead of painting over the problem with comments.

Hell yes. It's a shame that this isn't just conventional wisdom. Having had a colleague recently join and then leave shortly afterwards because of factors that he could have uncovered by asking some of the questions in this list, this is close to home for me.

I'm sure it sucks for people with hire/fire authority to have to let somebody go early on when the decision to hire turns out to have been a bad one. But when it's the other way around, and an otherwise excellent new colleague regrets their end of the decision, the effect on morale is a lot more profound and widespread.

It takes some careful introspection and forethought to figure out what those crucial questions are. If they only come to you after the interview, send an email if you have to! But for Pete's sake, ask!

That's correct, but we should still not allow them to misdirect our attention while they tighten the screws.

Stop calling it a "porn filter". It's censorship of the internet.

If it was actually a "porn filter", its purpose would be to filter pornographic material. In reality, there is a list of categories to be censored, and porn is only one of them. Focusing on the words "porn filtering" was a deliberate strategic move by the government, because it makes it more difficult to oppose convincingly.

Those of us who oppose censorship are playing into their hands by referring to this issue using the favourable terms coined by the government. We should all stop referring to it as "porn filtering" and start referring to it as "internet censorship".

It's funny, my gut reaction to your explanation is one of technological conservatism. "This is a problem that shouldn't exist! Don't use JavaScript for that!", I want to exclaim.

But I remember thinking similar things years ago when Slashdot introduced a bunch of JavaScript enhancements on top of what had been a very spartan HTML-based comment UI. The technologically conservative point of view was wrong then, and I think it'd be equally wrong now.

I have a vague feeling of excitement about the future of JS development in general. Whether or not Meteor is going to be the bringer of that bright future is something I'm not so sure of.

On the topic of constructive criticism, differential.io could really do with ditching that "We work at Cintrifuse" interstitial before the blog post is displayed. In the spirit of being constructive, I will simply say that my experience as a reader would have been vastly better without it.

Couldn't agree more. I made the mistake of using Ruby to build a CLI application too, and distribution is a massive hassle. At the moment I'm still at the awkward stage of distribution via Rubygems which the article advises strongly against, and I'd add "Gem startup time cripples your performance" to the article's point about Rubygems being difficult for non-Rubyists.

While I don't have any ideas, I can at least add my voice to those saying "I will send money to this man if there is a way to do so". I'm dubious of that Journalistic Source Protection Defence Fundraiser that's been posted as it sounds like he needs more than just lawyer money right now.

And I think there are a lot of us out there who will contribute financially as soon as there's a bonafide way of doing so.

When the first line of your article contains an Amazon referral link to buy the book and make you a quick buck, how is anybody expected to take your subsequent glowing praise of the book's contents seriously? Ending the post with a quick disclaimer doesn't mitigate this loss of credibility.

Same goes for --ignore-space-at-eol

The better solution would be to teach people to stop being careless about trailing whitespace in their commits.

There's a sliding scale of HATEOAS-ness. I've seen a much more extreme form of it described elsewhere. Mark Seemann (http://blog.ploeh.dk/2013/05/01/rest-lesson-learned-avoid-ha...) describes an approach that encrypts all URLs so that clients have no choice but to follow links because generating URLs from templates is impossible.

So instead of

    http://foo.ploeh.dk/customers/1234/orders

You'd have

    http://foo.ploeh.dk/DC884298C70C41798ABE9052DC69CAEE

And you'd have to get that URL out of the response to another request you'd already made. I never liked this idea, and the linked article provides a really strong counterargument to this approach to HATEOAS.

    When browsing a website, decisions on what links will be
    clicked are made at run time. However, with an API, decisions
    as to what requests will be sent are made when the API
    integration code is written, not at run time. Could the
    decisions be deferred to run time? Sure, however, there isn't
    much to gain going down that route as code would still not be
    able to handle significant API changes without breaking.

This is a great resource. Feels like the next step after Matt Gemmell's post "API Design" (http://mattgemmell.com/2012/05/24/api-design/) where he called APIs "UX for developers".

Finally, DRM for email!

    Using the right framework for the right reason is a productivity boost.

I agree. The difficulty with this is in the long term. Things change: new opportunities, new technologies, new developers, new functionality. Even if you were 100% certain of your choice on day one, it's difficult to measure the precise point beyond which your framework is no longer the "right" framework. I'm interested in solutions to this problem.

I'm sad to say that I gave up reading it before it was finished because of exactly this. On a large screen, it's really disorientating.

Apart from being based on a piece of programming terminology, the twelfth item in the list seems not to be about programming at all, but rather a flagrant plug for a book.

How is this the first time I have noticed that?

Unfortunately they are becoming more and more prevalent in the PHP community. For example, here they are in the Symfony project's coding standards: http://symfony.com/doc/current/contributing/code/standards.h...

The rationale is that they make it a compiler error if you accidentally perform an assignment operation ("xyz" = $name) instead of a comparison ("xyz" === $name). The thing is, this is only a significant risk if you adopt the bad habit of performing assignment operations within conditional statements, like this:

    if (null !== ($charset = $env->getCharset())) {

The above style has been popularised in PHP by the Symfony project. I think it's hideous, and that the idea of adopting one ugly style choice (Yoda Expressions) to mitigate the risk introduced by another ugly style choice (assignment in conditional operations) is reminiscent of the children's song about the old lady who swallowed a fly.

Personally, I'm glad I co-operated with my previous employer by delving into the specific factors that led to my decision to leave. Despite the fact that I obviously left, I really liked those people, and sometimes you go out on a limb for people you like.

My feedback provided a written-down justification for investing in some much-needed improvements to the way they built software. A few things tangibly improved as a direct result, and that is valuable to me.

That deleted one was posted by me. After I posted it I felt guilty about triggering yet another gossipy discussion about Linus, so I deleted it. Not that I was blameless, choosing such a gossipy link to submit.

This is by far the number one API design anti-pattern in terms of how widespread it is. It's like bad kerning: once you've seen it, it's everywhere, and nobody seems to notice.

It usually results from writing code with a short-sighted focus on achieving some bespoke functionality in the least possible time. Somebody wants to disable a piece of behaviour in a function, they know where the code is, they wrap it in an if statement and throw another optional boolean parameter onto the pile.

It's symptomatic of functions, methods or subroutines that are too long. Functions should do one thing at one level of abstraction, and the very possibility of a boolean parameter means that your function is doing at least two things.

This is standard practice. MPs receive a lot of letters from their constituents and it isn't practical to send individual responses.

As well, Amber Rudd and Damien Green are conservative MPs, so they can be considered supporters of this proposal. I would hardly expect their replies to do anything other than make positive statements about the proposal.

There's more to democracy than voting and writing to MPs. For example, in light of the leaks about GCHQ and this proposed internet censorship, I have started supporting Pirate Party UK. They are the only party with a satisfactorily strong anti-surveillance and anti-censorship stance. Put your money where your mouth is.