I prefer my unit tests to test everything all the way down.
They already have that, that's called integration testing. Unit testing is trying to test as small of a unit of code as possible - this helps you identify exactly where the error is. If all of your tests are integration tests and something fails, you have no idea which part of your stack the problem is in.
Obviously different projects require different kinds and amounts of test cases, but I prefer a mixture of both unit tests and integration tests (unit tests for small, complex blocks of logic, integration tests for most of the other stuff).
If all of your tests are integration tests and something fails, you have no idea which part of your stack the problem is in.
Not necessarily, because if you have a lot of integration tests then probably multiple ones will fail given a bug in a certain module, and the pattern of the failures might be all you need to locate the source of the problem.
One of the most successful projects I ever worked on, in robustness/quality terms, didn't really have any unit tests at all, but it had a comprehensive suite of end-to-end test cases that could be run automatically. Many of those didn't (and couldn't) have an absolute true/false outcome, either, but looking at the results they generated and applying various heuristics developed from experience, they were remarkably useful for similar reasons to unit tests.
At work recently we reinvented something that already existed - but I think we had a good reason to.
There's a node package called "request" [1] that's a very, very popular third-party library to simplify HTTP requests. If you look at the code, though, it's really, really nasty - the whole thing is filled with global state. After I spent 6 hours in one day debugging issues in the library and filing bugs (some of which included things such as "if you try to set a querystring parameter, request can no longer follow redirects"), we decided that enough was enough and we rewrote it from scratch [2].
I think that rewriting it took us about as much time as we spent debugging it, but we were left with a project that's a drop-in replacement (as long as you're not using any of the advanced features) and has a codebase that's 1/10th (!!!) as many lines of code while implementing near 80% of its features.
I don't think NIH counts as NIH when you have a very clear and justifiable rationale. The best projects document their rationale and provide a direct, unbiased comparison to allow developers to make a better decision on which to use, as you have. The worst (and true NIH) projects pretend that the original project does not exist or document a biased comparison without acknowledging the points that are subjective.
There is one improvement I'd make. Your story here (spent hours debugging and filing bugs; spending the same amount of time rewriting got you further) is the most convincing reason to me. I'd document this in your comparison!
I doubt that many people say with a straight face "I rebuilt it because I didn't write the original", even if that's the real reason: there is always an excuse.
I think roughly 40% of the remaining code implements the last 20% of the features, and the other 50% is just random bloat.
Request has a lot of extra code to deal with the global state. It's written as one giant class that sets all of its properties on itself (e.g. this.method = options.method, etc., etc., followed by "http.request this"). Further, when it handles HTTP redirects, rather than instantiate a new instance of itself or something it just calls its init method a second time and has to make sure that it resets all of its properties to their default state (e.g. this.method = 'GET'). This is where most of the bugs come in, as well as most of the bloat.
In contrast, our's is a method that calls itself again with new options based on the context when it needs to handle HTTP redirects so we don't need to worry about that sort of stuff.
Nowhere does he say that it's justified. Cut the man some slack.
My interpretation from reading this whole thread, the associated article, and some comments is that there's an option for users to invite their Twitter followers/share activity, but the messaging around it is unclear or something (maybe a bug?) so people didn't realize they were doing it. And now it's being fixed.
That's hardly intentional unethical behavior. Saying someone is "in a state of delusion, blinded to ethics and respect" is WAY out of line for someone whose product had either a UX or technical bug, who apologized for it, and who is now trying to fix it.
I actually read his Twitter feed before posting. It was massively vandalized by Prismatic, who was clearly impersonating him.
The claimed bug is that the were not clear in getting permissions. That is completely irrelevant to the core of the principle here. They are fraudulently impersonating him, using his own account. That is a fact and it is a verifiable fact.
Given that you feel motivated to justify it, I have added your company Clever to my list of dodgy companies I will have nothing to do with. Thank you for informing me of your questionable ethics.
To quote The Princess Bride: "You keep using that word. I do not think it means what you think it means."
You say that both me and the guy from Prismatic are trying to "justify" his actions, but that's completely false. Nowhere did I say that doing something like that was acceptable behavior, nor did he. I agree that impersonating a user and posting to their social media accounts without their approval is unethical and immoral.
However, he said that it was an accident, a bug - that the intended behavior was not this unethical and immoral action, but something else entirely. You proceeded to accuse him of justifying it and being "in a state of delusion, blinded to ethics and respect".
And now you said that same thing to me, more or less.
If anyone here has questionable ethics, it's you. You COMPLTELY MADE UP these actions of other people, MALICIOUSLY, and used it to libel them.
Can you provide the verified facts? I've yet to see where a granted permission is _fraudulently_ used. I've yet to even see or see reproduced these supposed facts. In fact, the token granted from Twitter is a non-rate-limited permission to tweet indefinitely; the only abuse here is a user's trust; but that shouldn't preclude Prismatic from making good on a mistake before they are chastised forevermore.
If you read the chat log he posted, it actually makes him look bad more than anyone else. Yes, it's bad, shady practice to require someone to call you to get a refund you promise, especially if you don't list that they have to call you anywhere.
But again, looking at the chat log, the 99 Designs guy is very apologetic and helpful and Andrew immediately says "OK, I think I'll blog about this and post it to Hacker News and see what everyone else thinks." (This is in response to "Justin" from 99 Designs apologizing for the inconvenience of requiring a phone call).
I don't even see a big deal about requiring a call, as long as the call itself goes smoothly and they don't give you the runaround or use bullying tactics to talk you out of it. They offer refunds if you contact them... that on its own doesn't sound shady or like a bad practice in any way. I'm not sure why the author feels entitled to an automated refund process--the biggest impression I get from the post and chat log are that he just really doesn't like talking to people on the phone.
Yeah. Requiring a call in for cancellation is shady but the guy just seemed like he was looking to whine/complain. This guy must write a lot of blog posts about every company who makes you call vs email. I hope he never has to do anything with the DMV- They make you go in person some things! shudder
I work for Clever, a YCS12 company. It's quite honestly the best job I've ever had. Every day I get to solve fun and interesting problems in a market (education) where I can actually tell people that I'm trying to make the world better.
This "Google has no support" is a myth that I see consistently repeated on Hacker News that I can't understand it's repeated. Google's support situation is actually the same as Microsoft's: if you pay (i.e. have a Google Apps for Business) account, you get 24/7 phone support. I'm pretty sure that it's for any service linked to your Google Apps for Business account (including Voice), but not completely sure since I've never had to use it.
I've used Google Apps paid support and had disappointing experiences. Apps is only one of many Google products, many of which have no paid support options. I've had mediocre support experiences with support for other (expensive) products, like DFP. Overall, whenever I hit a wall (bad/missing/unclear documentation, apparent bugs, etc) with a Google service, I wince because I've learned to expect some pain.
What are you talking about? I posted a link with their support options and your response is "No, you can't get support". Clearly, you can - I linked to it. If I go there with my free apps account it's crystal clear, in big letters: "Email and phone support: Not available for the free edition of Google Apps. Find out about upgrading to Google Apps for Business."
The difference is that tax shelters usually aren't used to deprive your staff of salary, they're used to deprive the government of tax revenue. This is both.
Except that it doesn't work for avoiding taxes. If you charge ten million in internal advertising to an account, you're advertising division is still making a profit.
There are lots of other tricks for avoiding taxes, but what is described is purely for screwing the artists.
But you don't charge your own company, you buy services from a seemingly external company (that is actually operated by you). That's one way to generate a loss while actually just moving money around.
You generate a loss for one company, but income for another company. I don't see how this avoids taxes, just moves them from one entity to another. (so if the second entity is in a tax-friendly jurisdiction, it's obvious how that helps, but it doesn't simply generate a loss and that's the end of the story.)
But then the shell company could just be collapsed, and all its debt obligations (which is really to yourself) could be all moot. Thus, you avoid paying tax like that as well?
Such tax loopholes might exist (I am not a tax person), but generally the answer is no:
If you take a loan, and don't return it for whatever reason (e.g. because the person to whom you owe it has died and has no heirs; or the bank that gave you the loan decides not to collect), the loan you previously received is instantly converted for tax purposes into your income, and you have to pay income tax on that.
I thought the article was clear on this point. The director was paid 5% of net. Net was negative -- the director got shafted.
The directors I know are unlikely getting shafted by this method, as their portfolios consist of mainly live births, cattle auctions, and high school sports. Still Art Institute graduates though.
No, the article wasn't clear on the point. It gave an example of one specific director, Scott Derrickson, getting shafted. No offense to Scott, but as a casual movie watcher, I haven't heard of him. And if casual movie watchers haven't heard of him, he can be easily replaced, and therefore easily shafted.
