Yes; for people participating in an employee stock purchase program, it is called a Disqualifying Disposition. It puts you in the short-term capital gains bracket (with about 15% higher tax).
However, it's still a VERY good idea to do if you plan on holding stock.
I know stories of several people who were exercised options on 7 figures of stock, only to see the price collapse before they were able to sell. The taxes they owed because of that eclipsed their net worth several times over.
Agreed. His argument is essentially that you can't meet deadlines with Scrum, because you must always be in a 'shippable' state at the end of each sprint.
I'd argue that if you can't meet deadlines with scrum, there's no way you'd meet them without it. His definition of 'shippable' is very narrow--like you said, just because it doesn't meet console certifications doesn't mean that it's not "doing scrum".
I wouldn't put the app I've got after the first dev sprint on the app store, either. It's not done.
On the contrary: in a world filled with a cacophony of malicious and intentionally misleading statements, the silence caused by the criminalization of lies seems welcome.
And Ebay was the first mover in the online auction space. I'm sure we can cherrypick counterexamples all day, but in general the first mover enjoys an advantage those that come after do not.
MtGox should absolutely have known about this issue. Everyone building anything related to BTC should know not to make assumptions about the protocol, and to treat every input as hostile.
You'd think they'd have at least one guy dedicated to nothing but breaking their software. They make my salary every day with transaction fees (well, maybe until recently) so you can't say they're unable to afford it.
Edit: Rereading this, it sounds more accusatory than I intended. I think your clarification was perfect, but at the same time that MtGox is at fault.
Is there any interest in a Chrome plugin that would passively report anonymized download speed for things like YouTube or Amazon? I can imagine that kind of info would be useful.
And that's where I have to ask: what do you do when they say no? I followed this advice a year back or so and it essentially put the brakes on any serious side-projects. I work for a big company that you've absolutely heard of.
+1 to parent post. It looks awesome, the fade-in is kinda distracting. It also re-fades the main area when you switch between categories.
To the coders: Nice job on using multiple URLs to allow pages to be viewed without JS enabled. Having to reload each page when it is requested is not trendy, but it's nice to know Mailpile will work on locked-down browsers. Kudos!
A hybrid system sounds reasonable, but I'm more interested in how they think that Dagger is ASIC-proof. I can't tell without a real description of the algorithm, but what is presented doesn't seem hard to parallelize.
I'm interested in seeing a real explanation of the Dagger algorithm.
In brief: the only source I can find (that page) just contains a few sloppy lines of pseudocode. Where is real description and proof of its properties?
You sound knowledgeable, so perhaps you could clean up their algorithm for me? There are a number of problems with their description that make it hard for me to evaluate. Having tried designing a memory-hard algorithm, I'd like to see what their key insight was, but there are a number of problems with their article. They use confusing operators, the wrong terms, and seemingly random constants.
How did they come up with the numbers 2, 3, 11, 2^21, and 2^22, for example? Is D the hash function or the underlying data? Or is 'data' the underlying data? Does + mean addition or string concatenation? What about "++"? They never even use "||", which they defined as string concatenation... Where does the nonce N come in? Is that actually supposed to be 'n'? How do they justify that the optimal algorithm is the naive one? There is essentially no proof of this claim in the article.
In short, I'm very suspicious of their "memory-hard" algorithm. It took a fairly dense, multi-page whitepaper to explain Scrypt, and yet their 'superior' version is just a couple of sloppy lines of pseudocode with no justification.
Here is what they wrote, for reference:
Let D be the underlying data (eg. in Bitcoin's case the block header), N be the nonce and || be the string concatenation operator (ie. 'foo' || 'bar' == 'foobar') . The entire code for the algorithm is as follows:
