HN user

jmathes

380 karma
Posts18
Comments73
View on HN
saucelabs.com 14y ago

PHPUnit getting parallelism in 3.7

jmathes
5pts0
saucelabs.com 14y ago

The Surprising Worst Browser

jmathes
72pts30
saucelabs.com 14y ago

Super easy A/B testing

jmathes
3pts0
saucelabs.com 15y ago

We've been watching you (and we have graphs)

jmathes
10pts0
news.ycombinator.com 16y ago

Save me from myself

jmathes
5pts8
sfappeal.com 17y ago

Company tries to scam iphone developer, claiming they own public data

jmathes
25pts7
aegisknight.org 17y ago

Visualizing Python Import Dependencies

jmathes
3pts0
startuplessonslearned.blogspot.com 17y ago

Validated learning about customers (for startups)

jmathes
22pts0
www.reddit.com 17y ago

An introduction to Beziers based on a presentation at GDC

jmathes
2pts0
joblivious.wordpress.com 17y ago

3D Graphics 101: Affine Transforms

jmathes
3pts0
joblivious.wordpress.com 17y ago

Lessons from GDC: Restrictions Fuel Creativity, And That’s Why Stealth Games Were Invented

jmathes
14pts0
joblivious.wordpress.com 17y ago

Continuous Integration Does Not Cause Low Quality

jmathes
3pts0
joblivious.wordpress.com 17y ago

Almost Everybody is Stupid

jmathes
3pts0
joblivious.wordpress.com 17y ago

Making TDD Work: Integrating 3rd Party Services

jmathes
1pts0
joblivious.wordpress.com 17y ago

Doing agile right: TDD and A/B experiments

jmathes
1pts0
joblivious.wordpress.com 17y ago

Handling Intermittence: How to Survive Test Driven Development

jmathes
21pts17
joblivious.wordpress.com 17y ago

The Obsessive Programmer’s Guide to Surviving A Real Job

jmathes
2pts0
joblivious.wordpress.com 17y ago

Highest Paid Person's Opinion: Slaying the HiPPO (with science)

jmathes
1pts0

I think TDD is best in the situations I enumerated because writing tests for single behaviors of single functions is easy, fast, forces you to discover errors that cause your tests to trivially test, and forces you to discover bugs in your understanding of the problem.

Continuous "Deployment", I guess. The term may have existed before I realize, but it certainly wasn't in popular use before this:

http://timothyfitz.com/2009/02/10/continuous-deployment-at-i...

The most important thing you can do for your career is:

* Accept a job somewhere

* Get promoted (doesn't matter how)

* let yourself get hired away from your current company

Getting hired away from your current company is the only way to get a fair raise based on increased experience. Companies never give substantial raises to current employees.

TDD is best when you're writing code that talks to other code. So APIs, database models, etc. Pure functions, and code that has dependencies you can inject and mock. You should never abandon TDD in situations like this.

It's true that it's harder to write TDD for code with side effects or that draws UI. It doesn't really make sense to use TDD for this.

You shouldn't conflate the two. Also, "always pass the majority of tests" is a trap. You should always pass all the tests.

Source: I've been managing and working in automated testing and continuous integration systems for 8 years, dating back to before the term was coined. I was the manager of the system, at IMVU, that coined the term "continuous integration". I've also worked on testing at Sauce Labs and Google.

Continued advancement doesn't mean that it is accelerating, and even if this does represent an unexpected achievement that doesn't mean that future development will maintain that pace.

Advancement faster than predictions does mean accelerating advancement, coupled with the (true) fact that people's predictions tend to assume a constant rate of advancement [citation needed]. Actually, all you'd need to show accelerating advancement is a trend of conservative predictions and the fact that these predictions assume a non-decreasing rate of advancement; if we're predicting accelerating advancement and still underestimating its rate, advancement must still be accelerating.

It even seems like this latter case is where we're at, since people who assume an accelerating rate of advancement see to assume that the rate is (loosely) quadratic. However, given that the rate of advancement tends to be based on the current level of advancement (a fair approximation, since so many advancements themselves help with research and development), we should expect it to be exponential. That's what exponential means.

However, the reality seems like it might be even faster than exponential. This is what the singularitarians think. When you plot humanity's advancements using whatever definition you like, look at the length of time between them to approximate rate, and then try to fit this rate to a regression, it tends to fit regressions with vertical asymptotes.

It sounds like the point of this story is to illustrate by analogy that starting from first principles is sometimes a silly way to approach a problem, and by extrapolation that it's a silly way to make an AI that plays Go well.

Making an AI that plays Go well is not (and has never been) the real goal. They're trying to learn how to build a AI that can solve any problem.

24 men never chanted "show us your tits"

Perhaps it was an attempt at nodding to the Las Vegas themed "bad behaviour" after dark, combined with a nerdy attempt at being funny

Switching from it-never-happened to maybe-she-misunderstood pretty quickly, no? Evidence of the latter would be enough to cost you $500. But It's pretty wild that you think someone who understands and plays the audience that well would misunderstand their intent.

I get the feeling that you actually realize how little you know about the event, and I encourage that. Weird things happen all the time, especially in Vegas.

FWIW, the event in question actually did happen - I'm not just taking sides in an internet argument here; I know it for a fact.

That is a monumentally stupid thing to say, and that's coming from a guy who's an active reader of /r/mensrights. I know the author personally and she's telling the truth.

Women with careers who accuse others of rape are telling the truth. False rape claims always come from someone who believes she stands to gain, and women with careers ruin their careers by reporting rape. Because of mouthbreathers like you. Go climb back under your rock.

We try to show ads that people will click on AND THEN buy/use whatever's on the other end. This maximizes advertiser value, long-term Google profit, and user experience all at once.

So we're trying to show you ads that you want to see, rather than ads that try to provoke you into clicking (like Buzzfeed articles)

This is because (as I think you implied) HN, in a show of consistency with other online forums, is fond of reaching conclusions that are contrary to (any) conventional wisdom. This is a source of bias: I'm a current Googler who thinks Google is great, but this opinion doesn't change anyone's mind.

But this bias is a good thing. It causes internal disagreement, hindering solidarity, but it increases the rate at which we learn new things.

This seems like a great article, but I missed the part where it's relevant to hacker news. Did the community's focus shift or broaden in the months I've been away?

Writing is an art form. You did to this guy's writing exactly what he said you'd do. And here I am, doing the same to you. And of course it's best to be happy without other peoples' approval, but it's harder, so it's less frequently accomplished. Hence the link with depression.

Hacker Fair 3 14 years ago

Reversing the format of Job Fair is a great idea, because the bay area job market is backwards; employers have to chase potential employees. It's refreshing to finally see a(ny) traditional institution updated to meet a changing context.

This is a great idea, but it needs some polish. A native speaker needs to proofread the English, and the problems are underspecified

I'm with you. I added parallel test execution to PHPUnit, which its maintainers have been promising since 2005. When I started writing it, they found me and encouraged me along. So I spent two weeks on it at 16 hours a day. When I was done, they invented reasons not to merge. When I was done fixing the reasons they had invented, they said they didn't want to merge it because they were going to write it themselves.

'Sexist' has as many definitions as there are English-speakers. It's not a useful word unless you're a politician or a journalist.

If you thought women never used words longer than three letters, then you could design some very useful features for them, like smarter autocomplete, spell check, and inserting the space automatically after three characters. Then you'd do what everyone building a product should do - try to sell it, and if it won't sell, try to find out why. You'd quickly learn that women can use big words just fine, and you'd redesign your product accordingly.

I used an example misconception in which you underestimated women, because in the other direction it'd be politically incorrect. But, you need to be objective about what you see. You can't be afraid of the political ramifications of knowing the truth about your market. If the data were to tell you something drastically politically incorrect, like that Brits and Canadians never buy your word processor because they're too busy eating babies, you still need to redesign your product to fit your customers, and your spell checker should not accept "colour", "lorry", or "hockey".

I just tried fish for the first time, and it couldn't do the very first thing I tried to do, which was source my .zshrc. It doesn't have 'export', has some kind of nonstandard syntax for 'alias', and that was enough to get me to give up.

Since there are many fish fanboys here, and since it seems like it would be cool if it worked, I'm hoping someone can tell me the simple obvious thing I should have done. Can you help?

Goodbye, CouchDB 14 years ago

It was colorful language, not dismissal out of hand. It can be hard to communicate emotion online, so it's easy to take offense where none was meant. I think that's what happened here.

Goodbye, CouchDB 14 years ago

'A properly normalized and "constrained" database prevents data loss from stupid mistakes.'

A properly written application layer also prevents data loss from stupid mistakes. A stupid mistake made while setting up a properly normalized database also causes data loss.

You have to be very smart to be able to design a normalized constrained DB well. The fact that only smart people can do it doesn't mean that people who don't do it aren't smart.

Fully agree. Since maybe it wasn't clear, I wasn't objecting to the approach of "let's decide what our firmly written rule is" but to the seemingly-implied rationale given in support. "Let's decide our primary responsibility" sounds like it's more concerned with responsibility than utility. Having those priorities is the thing with which I disagree.

> I think one of the questions you have to ask yourself is whether your primary responsibility to protect the interests of your real users (the non-patent trolls) or to take a stand against people you don't like.

Using the phrase "primary responsibility" doesn't change the fact that helping unethical people do unethical things puts evil into the world. It sounds like you (and Less Annoying) are subconsciously reasoning with the goal of never being held responsible for evil. That's different from minimizing evil.

A clearer way to make your case would be to say that taking a stand is too expensive (vs not-my-problem.) Maybe the company's resources are better spent assisting ethical customers. Maybe this assistance yields more revenue, further increasing the ability to assist ethical customers. Now you have an exponential growth rate of net good, so you have a big-O notation argument for not policing evil. (... actually, exponential growth rates of small business revenue are really sigmoidal, not exponential, so it will probably be better to switch back to thinking about ethics when you approach market saturation)

I don't feel like I owe sympathy to people who are concerned with culpability rather than with utility, and I doubt you do either.

I think Less Annoying was most interested in making an easy rule for themselves to follow, in the expectation that they'd have to make similar decisions in the future. "Is it legal," they decided, is easier to answer than "is it unethical." If they decided in the other direction, they'd have to evaluate the ethics of each of their customers. This, in their opinion, would drain their resources. If they're right, they made a decision that increases their ability to assist their ethical customers in doing good. So the net effect of the decision to draw the line at legality might still be positive from a preference-utility point of view.

It's not clear that this is the thinking they were using, and it's a false dichotomy. There might be any number of easy rules to follow that do a better job of approximating ethical judgement than "is it legal." A possible reason not to try for one of these might be because it's impractical. Less Annoying employees are people, and people tend to have irrationally-strongly-held beliefs about ethics. They are in the habit of not questioning the law or other peoples' religions, but this would step outside those boundaries. You end up with a company full of people who think it's their duty to force the company's ethics to be consistent with their own.

It did occur to me. When I said their "negotiating position is so bad that they use suicide to opt out," the choice I was talking about was between working at Foxconn and trying to find another job. I said "opt out" to mean inserting their own third option; suicide. I chose this language explicitly with the goal of showing that I realize that they have at least three options, because I expected you to argue this point with me otherwise. I'm sorry for my lack of clarity. It's something I'm working on.

Whether their plan to suicide is a bluff is relevant to our apparant disagreement. I think it is at least partly not a bluff, because Foxconn employees have a history of killing themselves. Given that their employees commit suicide based on their working conditions and perceived lack of alternative, I don't think you can rationally think it's good for them to be in this situation. I am not telling you that you should feel sympathy for them, although I certainly do. What I mean is that it is possible for a person to be in a business negotiation position that is bad in the same sense of the word "bad" that being raped is bad. The fact that they have multiple options and that the options involve money is not enough to absolve their malefactors. If I were forced to choose between paid to amputate my own body parts and starving to death for lack of money, and the person asking me to amputate my limbs could pay me without amputating my limbs at no cost to themselves, I would call that unethical. I would say so even if they were not themselves amputating my limbs, killing me, or actively restricting my other options.

> This is business. ... Let them hash it out.

When is a disagreement not business? Why should we be unwilling to take sides in a negotiating even when it is "business?" When a person's negotiating position is so bad that they use suicide to opt out, I feel sympathy, and I suspect that humanity might me better off if their position were improved by non-capitalist intervention of some kind.

Silly Python riddle 15 years ago

f = lambda: g(""")

f()

technically not two commands, and it will look like:

>>> f = lambda: g(""")

. . . f()

Planes are extra expensive because only coorporations buy them. There isn't infrastructure to sell them to individuals. That raises the price and difficulty of buying them, and also makes it a more sound political strategy to make stricter laws requiring airplane safety, which further makes it inconvenient to operate your own plane.

Some very rich people still own private jets, but it's rarer than it would be if more people were rich.

TDD does work, and I use it in practice. I know a whole company full of people who all use it in practice, and it works.

I have a guess about why HN likes to upvote opinion pieces that hate on TDD. TDD initially feels like it takes discipline. It's natural to dislike things that require discipline. I think people are trying TDD, finding that it doesn't work as advertised, and gravitating towards the most pleasant explanation: that TDD sucks. They never consider the alternate explanation: you're doing it wrong.