h2s

    > Women are like dogs

Fuck off.

h2s

12년 전discuss

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

h2s

12년 전discuss

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

h2s

12년 전discuss

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.

h2s

12년 전discuss

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.

h2s

12년 전discuss

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

h2s

12년 전discuss

Eagerly looking forward to the explanation for this weird juxtaposition.

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

h2s

13년 전discuss

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.

h2s

13년 전discuss

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.

h2s

13년 전discuss

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.

h2s

13년 전discuss

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!

h2s

13년 전discuss

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

h2s

13년 전discuss

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".

h2s

13년 전discuss

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.

h2s

13년 전discuss

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.

h2s

13년 전discuss

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.

h2s

13년 전discuss

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.

h2s

13년 전discuss

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.

h2s

13년 전discuss

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.

h2s

13년 전discuss

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.

Submissions

Whitespace Sins

2012: A Year in PHP

Show HN: ppl - The Command Line Address Book

On Being Childish; An Apology

Yes, You Need Timestamps

comments