thenonsequitur

The fact that Neil Armstrong's heart rate went up to 150 confirms that.

"However, the act of writing tests first has a powerful benefit: the code you write _must_ be testable. It is hard to understate this benefit. If forces a level of decoupling that most programmers, even very experience programmers, would not otherwise engage in".

I'm sorry but I really find that sentiment to be totally inaccurate. I've never seen a good experienced programmer write hard-to-test or coupled code, regardless of whether they are using TDD or not. A hallmark of when makes them good is that they all have some testing methodology that enforces this and works for them. TDD is one, but there are many others (and yes, that includes good manual-only testing).

I also don't see why you believe TDD is the only way to successfully refactor code, or that only developers who use TDD continually refactor their code to eliminate technical debt and increase productivity. Again, every good programmer does this. TDD is one way to get there. It is not the only way.

You are conflating Ruby with RoR. You start by saying "I think it is necessary hygiene for Ruby." but then go on to say "RoR is very error-prone and a lot of work by comparison" and "So many bits and pieces need to be glued together, from attr_accessible through to update params slicing..." -- that's Rails you're talking about. And I don't blame you for that. As a long-time Ruby developer, I can say with no qualms that Rails is a not a very good web framework, way too buggy and full of magic. But please don't conflate that with Ruby. Ruby with Sinatra is a hell of a lot cleaner and it's much easier to structure your code well.

Having spent altogether way too much time playing this game (so addictive), I disagree. I've played about a dozen sessions with several rounds each, so I've had the chance to play full rounds as well as entering part way through rounds, and I've certainly experienced my share of building up power and dying. I think the game would be no fun if you didn't lose stuff when dying. It wouldn't take long for everyone to build up max powerups, and then it would just be a bombs everywhere shitshow with very little going in the way of tactics or overall strategy. In addition, losing power ups is a huge incentive to avoid dying. In fact, it's the only reason I care.

I agree, however, that it can be really frustrating to spend a precious several minutes farming or searching for power ups only to lose it all in a freak accident, an unlucky wall spawn, or even just getting outplayed by someone. I think somewhere in between would be the best of both worlds -- maybe losing about a third to a half of your power ups would be a good balance. Then you don't lose all the fruits of your efforts in an instance but the incentive to not die is still strong. Yet dying will still happen frequently enough that the overall level of power ups that people have will be low enough to keep game play fun and reasonable.

It actually sounds like you got disillusioned and probably heartbroken and are now scared of intimacy but don't realize it because you've activated a defense mechanism and are rationalizing your fear as "having realistic expectations".

Some of what Putnam reported was flawed, and his book that you cited was interpretative. These "actual mesasurements" that you speak of do not show that in-person social engagement has been in decline -- that is Putnam's interpretation of the data. Others have different interpretations (which I happen to agree with much more). For example, see http://www.theatlantic.com/past/docs/issues/96apr/kicking/ki....

Wow. The "Unknown or expired link" is a horrible solution. How bad is it? So bad that even though I've been browsing hacker news for over a year, only just now after reading this did I realize that the "More" link was inaccessible only because of a timeout. It occurs to me that every single time I clicked More in the past, it was after reading comments on the first page for a while, and so it always timed out for me. But the error page made me just assumed it was a bug and that the next page of results would not be possible to retrieve. Was always surprised when I periodically checked the second page and found that this "bug" was never fixed. Why not just show page two of the results, as they are at the time the more link is clicked? Seems pointless to have an expiration for this. So what if the pagination gets a little off-sync and I either miss a post or re-read something? That's much better than getting an error page.

While the method itself may not be doing in-band signaling, the vulnerability is certainly very related. What was supposed to be strictly data, params[:username], actually becomes an in-band signal -- and that's the exploit.

Was there any way to enter different shipping and billing addresses? Right now I can't have anything shipped to my billing address, and on that form, I didn't see an option to set different addresses, so I couldn't pay for it. If you do this again, I'd recommend having that option (or making it more apparent if it was there).

(I was actually planning on paying $10, until I couldn't see how to enter different shipping addresses, at which point I changed my plan to pay $0 and enter just my shipping address. And then I proceeded to fail at both plans, not submitting the form at all due to my own forgetfulness.)

I made a similar mistake. I saw it, but saw no clear way to post different addresses for shipping and billing. I asked if there was a way on their facebook page, figuring that if I got an answer explaining how, I would pay (was planning on a $10 payment actually), and than if I didn't get an answer, I would just opt for $0 payment and put in my shipping address.

I then went about my business, completely forgot about the question I asked on facebook (because they never answered), and never ended up submitting the form.

Oh well.

The site was in super-alpha. I think it was intentional.

I completely agree. I call myself a "web developer" because that's the most accurate description of what I do. "web programmer", "software engineer", and "systems engineer" are all too narrow.

On top of programming, I also do system ops, ui design, customer service (and client service), project management. Developing a web site takes a lot more than programming, especially if the team is small.

Agreed. Indeed, your argument naturally follows from a "bug fixes are features" type mindset.

Whenever I encounter one of these articles, I just google the title. Easy enough for me.

If I was looking for someone to do web dev work for me, and I went as far as checking out their portfolio site's HTML/CSS/Javascript, I'd say that not minifying code would reflect badly on them. Certainly forgivable if everything else checks out, but still a mark against them.

I think the joke here is actually on CoffeeScript, not Javascript.

And really the joke is on CoffeeScript evangelists, not CoffeeScript.

A little off-topic, but why is your xkcd link using ssl? Really curious, since I didn't think xkcd ever exposed https links, can't see any reason for it, and not sure how you got it.

Did you add the "s" manually, for, I dunno, the sake of art ;) ?

I agree wholeheartedly. I would give it up to them for perfect purity if it weren't the fact that they weren't actually being perfectly pure. They gave up 9 bytes to show the score at the end because it was, in their words, "totally worth it". But then they decide it's a good idea t save 2 bytes at the cost of making the game completely frustratingly unresponsive to the point of unplayability? That's just silly. If you're going to be pure, be pure. If you're going to make concessions, make the ones that matter most first! I'd much rather have a playable game without score than an unplayable game with score.

Rant aside, I actually do applaud them. Impressive bit of engineering here.

I agree with the point about comments being useful for a really long complicated regex, but any really long complicated regex is a coding problem to begin with. Really, instead of comments (or in addition to comments), the regex should be broken up into logical pieces separated by white-space, just like regular code is. Jeff Atwood explains it well in this classic post: http://www.codinghorror.com/blog/2008/06/regular-expressions...

Case in point: the site we're looking at right now.

It's an opinion of course, but I personally find the hacker news design to be dreadfully ugly; yet it's one of the sites I visit and interact with the most frequently. It's simple and very usable. A flashy modern design might make it look better, but if not done well it might also impede functionality, and thus make me visit it less often. And the obvious lack of pretense is psychologically satisfying. Simple and ugly is fine if it's functional.

Actually, the author is inaccurate, comparing apples to oranges. Consider the opposite subtraction than you proposed:

    irb(0main):001:0> Object.methods - Object.new.methods
    => [:allocate, :new, ...]

That means doing "Array.new.methods - Object.methods" is subtracting things that may potentially be methods of an Array instance that should not be subtracted. It just so happens to work in this case because Array has none of those methods. But it doesn't work in the general case.

Consider for example, a "Person" class with a single instance method "name". In this case, "Person.new.methods - Object.methods" will not include "name", because this happens to be a method that applies both to Person instances and the object Object. The correct comparison is what vidarh said, "Array.new.methods - Object.new.methods".

The author's main point, however, was that you can write code like "Array.new.methods" and "Object.methods" at all, and that you can write code to subtract them. And this example shows that nicely.

If you have a choice in framework, I'd actually recommend not learning Ruby through Rails. I'd learn it through Sinatra. Sinatra is a lightweight web framework (Rails is a heavyweight), and it has a lot less "magic", so it's more plain Ruby and less connecting framework components together.

Not knocking Rails, it's just that you'll get a really narrow and somewhat skewed perception of Ruby if you learn it through Rails (you'll have no way of easily separating the Rails magic from plain Ruby as you learn things).

I personally agree that copying answers where the copier knows how to do it is a victimless act. But to take the position of devil's advocate here, one could say that there are actually potential victims.

One potential victim is an employer who believes they are hiring someone with objectively-evaluated qualifications. I think this argument is easily shot down; institutional evaluations are not actually objective, and in fact the person doing the copying is actually in a better position to evaluate their abilities than the institution. But, someone else may believe differently on these points than me.

Another potential victim is the person being copied from. They may feel socially pressured to allow someone to copy from them whether they actually want to allow it or not, and they may submit to that social pressure (and this isn't made up -- in certain circles it would be considered a little rude to not allow your friends to copy your answers). But if the institution finds out about it, both parties (copier and copiee) may get in trouble. While this is probably a rare case, it's still true that a person knowingly using that social pressure to their advantage is doing something unethical.

Anyway, I basically agree with you on this point, but it's fair to say that this issue is not as definitively clear-cut as you make it out to be.

Contrast this with ordering something from Amazon with a Prime account -- you can usually place an order, pay, and receive the physical product within 24-48 hours.

It's absurd that Adobe can't even do this for a digital product.

I think the illusion is reinforced by virtue of the square itself being flush with the right-hand edge of the image, but offset from the bottom edge.

No need to limit it to self-taught/trade-taught programmers, CS people, and EE people.

I once worked with a brilliant programmer who was studying Classics and English Literature and he had an entirely novel approach too, and brought real value to the team.

That's the cool thing about programming -- it's an abstract thinking skill, so anybody with any sort of formal training will bring their specific ways of working and thinking into the game.

Given the amount of focus the physics world is putting on string theory right now, and given that hidden dimensions offer us the possibility of a mathematical basis for warp drive, I wouldn't be shocked if a theoretical blueprint for an actual warp drive is created sometime this century. Even if that happens though, I doubt it will become viable technology this century simply because the energy requirements to bend space-time (at a macro level) via a hidden dimension are literally astronomical. I'd wager that coming up with an energy source for warp technology is actually a harder problem than warp technology itself.

As for transporter technology, I don't even think we have the beginning of the science behind that, so I think that's even more distant from today's science than warp drive engineering.

Well it doesn't have to be a symbol, just something that would not be likely to start a real tweet.

Just as an example let's say "q", followed by a space, followed by the command with the appropriate number of parameters, e.g., "q get username". That would allow otherwise-reasonable tweets that are currently being mis-interpreted ("get better" vs. "q get better").

That's just an example. There are other ways around the problem too without making things too inconvenient on a smartphone user. And sure it's possible someone somewhere will want to write a real tweet that says "q get better", but that's far far less likely than someone somewhere wanting to tweet "get better". And the point is that allowing a non-trivial portion of the tweet-space overlap with the command-space is a bad decision. A trivial overlap (like "q get better") would have been a much better decision.

The parameter count is enforced for each command. For GET, it needs exactly one parameter or it won't be treated as a command. So from your examples above, the longer lines would tweet fine.

I agree with treetrouble, however, this was a really bad engineering decision. They should have come up with a tweet prefix to mean "command", some symbol that would not ever start a real tweet.

I agree.

But I'd add that even tasks that only require a quick-and-dirty solution can frequently benefit from quick-and-dirty automation. A few throw-away lines in an interpreter environment like irb, for example can often shave several minutes of certain tasks, and throwing a lit bit of code into such tasks can certainly make some otherwise dull processes more interesting.