Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
akeefer
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
22 ms
·
181.
▲
by
akeefer
17y ago
That's true . . . but it's also true that if you want to have more equals to trade with, one good way to do that is to mentor younger employees, and that requires sharing time and knowledge with people who are not yet equals.
182.
▲
by
akeefer
17y ago
> It's also not in their Plurk's interest to go legal as it will be a distraction from building software. I think it's your last point that's the most important one here. From a purely pragmatic standpoint, lawsuits are a massive, mass
183.
▲
by
akeefer
17y ago
MLB does put their games online, but it's a pay service. Similarly, you can buy a cable/satellite package to watch out of town NFL/NHL/NBA games but those are all fairly expensive packages.
184.
▲
by
akeefer
17y ago
I think you're saying, then, that starting from the question of "are there rights to intellectual property" is the wrong way to go about things; trying to make an argument that "you can't have rights to intellectual property because of X,"
185.
▲
by
akeefer
17y ago
I also don't agree with bundling all types of intellectual property in the same boat, but there is a fundamental difference: physical property is a rival, excludable good while intellectual property is a non-rival, non-excludable good. The
186.
▲
by
akeefer
17y ago
Point taken regarding calling them out before the situation is resolved: it would be far more respectful to allow the provider a reasonable amount of time to correct the error before explicitly attacking them. In this situation, I can und
187.
▲
by
akeefer
17y ago
How is it pointing fingers if your hosting provider lost your site plus their backups of your site? They were being paid to provide a service, and they failed at it in basically the worst possible way (i.e. total data loss, rather than jus
188.
▲
by
akeefer
17y ago
Patterns are primarily useful when you refactor to a pattern once you've gotten through the implementation to the point where you realize that applying the pattern would improve the code you've already written and make it clearer/more flexi
189.
▲
by
akeefer
17y ago
First-class methods would be a win, but the syntax leaves a little bit to be desired. Closures would be much more of a syntactic eyesore if they A) had context-based type inference on the arguments, so that if I'm passing a closure to a me
190.
▲
by
akeefer
17y ago
As someone who's implementing closures in a JVM-based language, I can tell you there's no technical limitations on the JVM side: there are decisions to be made as to how you want to implement them, but it's certainly doable with enough com
191.
▲
by
akeefer
17y ago
No such law was ever passed, but Indiana did come close back in 1897, apparently: http://www.straightdope.com/columns/read/805/did-a-state-leg... Apparently the trend of legislators voting for things that sounded good but that they didn't
192.
▲
by
akeefer
17y ago
As far as guidelines go, my personal rule is "test at the highest level of abstraction possible." That could also be phrased as "test those invariants that are the least likely to change." In practice, the two guidelines turn out to be pr
193.
▲
by
akeefer
17y ago
The tradeoffs largely depend on 1) your deployment model and 2) the cost of the bug itself. If you're running a web service, diagnosing and fixing bugs is a whole lot easier than if you're shipping pre-packaged, installed software. If the
194.
▲
by
akeefer
17y ago
Retention is a very good reason to do so; replacing someone good is always hard (and expensive) in terms of hiring and ramp-up times. If you don't adjust your employees' salaries to reduce the incentive to job-hop in order to get a raise,
195.
▲
by
akeefer
17y ago
All very valid points. I might suggest that the longer you're with a company the easier it is to discern success from failure, at least. Something that looks like a good idea in year one might look terrible by year three or four. I have n
196.
▲
by
akeefer
17y ago
To expand on your last point there: if you do work for a startup, pay attention to everything, and learn from all the things that get done well and all the things that don't. There's a lot to learn and a lot to screw up. For example: Di
197.
▲
by
akeefer
17y ago
I would disagree about not using wrist braces; my doctor recommended I use one when I was experiencing wrist pain several years ago, and it helped a lot. A lot of RSI conditions are caused by pinched nerves, and the immobilization of the w
198.
▲
by
akeefer
17y ago
Azul systems ( http://www.azulsystems.com/ ) has a special-purpose Java processor, and they do indeed get some impressive speed benefits from it. For example, having single-instruction write barriers in hardware allows them to have nearly-
199.
▲
by
akeefer
17y ago
Fair enough; you're not obligated to disclose everything up front if they don't ask. But that's a world different from making a deliberately misleading statement. If someone says "We're actively developing this" I'm not going to just assum
200.
▲
by
akeefer
17y ago
Deciding which facts are "relevant" to the customer is a pretty dicey proposition: why do you assume that the fact that no code has been written is irrelevant to the customer? Just because the sales guy wants it to be irrelevant doesn't m
201.
▲
by
akeefer
17y ago
Starting with prototypes and mockups? Great idea. Definitely the only way to go. Deliberately misleading customers into thinking those are actual screenshots instead of mockups? Ugh. Part of the reason it's so hard to sell software is t
202.
▲
by
akeefer
17y ago
The Windup Bird Chronicle - Haruki Murakami Cryptonomicon - Neal Stephenson . . . and really, basically anything else by either of them.
203.
▲
by
akeefer
17y ago
I'd definitely agree that TDD leads to testable code, which is usually a good thing. If you know how to write testable code, it's not as much of a win (in my opinion), since you tend to write with testing in mind. If you don't have experi
204.
▲
by
akeefer
17y ago
The research I've seen on TDD seems to essentially point to two things: quality and productivity is positively correlated with the number of tests, and people who use TDD tend to write more tests. People who write the same number of tests
205.
▲
by
akeefer
17y ago
Whatever terminology you'd like to choose, I think it's still a useful distinction to be aware of and to consider. To rephrase the article . . . there are two reasons to execute two things in parallel. 1) To reduce latency by executing t
206.
▲
by
akeefer
17y ago
Actually, it's more or less a summary pragmatism, which is a philosophy that grew out of the American civil war in response to fact that ideas people held strongly tended to lead to them murdering each other on a large scale. According to p
207.
▲
by
akeefer
17y ago
They break down because UI testing tends to rely on Strings: either labels for controls or embedded ids of them. It's really, really easy to have those change on you, and when they do the tests become difficult to debug: if the button wi
208.
▲
by
akeefer
17y ago
My company has always pretty explicitly discouraged working nights or weekends, though obviously some people will always end up working more because they want to. While burnout and recruitment are both good reasons (you don't want core peop
209.
▲
by
akeefer
17y ago
As a developer, the main problems with software patents are that 1) pretty much any combination of things you're doing could currently be patented by someone else, 2) it's impossible to tell if you're infringing something until you get sued
210.
▲
by
akeefer
17y ago
We've had the same thing happen to us, though in our case there was no attempt to negotiate beforehand or to buy us out: we found out we were being sued when the other company issued a press release about it. Classy. They're just trying
More ›