yellowredblack

This statement confused the heck out of me (wow! magic free memory) but of course, the pointers are being held to the contents of the memory, just not to the start of the object, which is what the GC cares about.

Perhaps the GC could be modified to track pointers not just to the head of object but to any address within it. Alternatively, C-coders working with Ruby could just say "I'm using this gc object" before calling C code.

I don't see this is a fatal flaw at all. Sounds like its just a bug. Now if, as many here assert, this bug is present all over the Ruby VM, then that's pretty unfortunate. Is that the case, or just hyperbole?

And had the 1password article stated that, then I would not have needed to post.

I believe it was changed because the first version caused a massive furor.

I don't believe that dropbox has any intention of screwing people over. Nor do I believe that they had any intention of allowing users to log in to any account without a password. I do believe that the latter incident, and the TOCs, are huge gaffes, and that the 1password guy misrepresented the TOC issue with incorrect facts.

No, I think they completely missed the issue. Which is

* dropbox's customers are not lawyers * serving up people's files without passwords one week reduces people's confidence when the read new TOCs next week.

No, nix that, the real issue is standards of blogging. The author made a claim about what caused the furor, including a quote, and that quote, regardless of whether or not you believe it to be legally equivalent, was not the TOCs that caused the furor.

Had the author made all the same points about, after quoting the original TOCs, then a) I would not have posted and b) you would be right.

It is not significantly different to a lawyer.

Is dropbox's target market lawyers?

to the extent we think it necessary for the Service

vs

to the extent reasonably necessary for the Service. This license is solely to enable us to technically administer, display, and operate the Services.

I am astounded that people here would criticize anyone for erring on the side of caution. If anyone can argue that the former is equivalent "plain english" for the latter, or that the latter is complicated legalese for the former then go ahead and signing contracts to that effect.

Here's my complaint. The author is complaining about a big furor over the TOCs, and then proceeds to show us the TOCs that "seems" to be behind it.

Here are the facts:

  * Dropbox released new TOCs.
  * There was a big furor.
  * Dropbox *modified* the TOCs.
  * Furor ended.

  * The author presents the modified version of the TOCs.
  * The author claims that the modified version caused the furor.

Ah yes, the old "we can fuck you as long as we use nice words while we do it" argument. I made a "civil" argument and was modded down. Censorship isn't civil.

And your 2.8 avg isnt anything to shout about either.

Dont fucking mod me down. The author claims that this is the paragraph that caused the furor:

We sometimes need your permission to do what you ask us to do with your stuff (for example, hosting, making public, or sharing your files). By submitting your stuff to the Services, you grant us (and those we work with to provide the Services) worldwide, non-exclusive, royalty-free, sublicenseable rights to use, copy, distribute, prepare derivative works (such as translations or format conversions) of, perform, or publicly display that stuff to the extent reasonably necessary for the Service. This license is solely to enable us to technically administer, display, and operate the Services. You must ensure you have the rights you need to grant us that permission. [Emphasis added]

When in fact this is the modified version that was posted after the furor. The original version is this:

By submitting your stuff to the Services, you grant us (and those we work with to provide the Services) worldwide, non-exclusive, royalty-free, sublicenseable rights to use, copy, distribute, prepare derivative works (such as translations or format conversions) of, perform, or publicly display that stuff to the extent we think it necessary for the Service.

Significantly different. And it was changed for a reason.

Except that the excerpt you posted is the new, modified version after all the furor.

http://hardware.slashdot.org/story/11/07/02/0515218/Dropbox-...

Compare the above version to this new form: "This license is solely to enable us to technically administer, display, and operate the Services"

It would appear that you didn't look into the issue at all before jumping to the defense of your main service provider. Is this the level of diligence we can expect from your product?

But, hey, welcome to the party.

The big "Play Angry Birds NOW" button in Chrome seems to be evidence to the contrary.

I once pair-programmed an IK animation harness. The math was hard (for me anyway). There were plenty of times where I'd have balked and gone and made a cup of coffee but my partner had the insight and we plowed ahead. Sometimes I was the one with the clarity. The increase in productivity is vastly more than just twice as fast. Sometimes it can mean that a feature that could not be done can now be done. Or take days instead of weeks.

For the other 80% of what goes into any software: total waste of time, or worse. Two people, independently, could get twice as much done. But worse: pairing on something like that can result in over engineering, language battles, just about any kind of drama to make the day more interesting. Seen it happen.

If I had to choose between 100% pair-programming or 100% single-programming, I'd have to choose pair-programming. In this artificial comparison, pair-programming is more productive. Which is why, I think, so many companies fall into this trap. 100% PP teams beat 100% lone-coder teams.

However, teams that pair when appropriate will destroy the zealots of either denomination. Rationality vs religion.

How are regression bugs more dangerous than other kinds of bug?

Here's how I'd rate the "dangerousness" of a bug:

  1. How easy is it to detect?
  2. How easy is it to reproduce?
  3. What are the consequences of it occuring?
  4. How likely is it to happen?

So all the other bugs that your system has right now, are the ones that are left: hard to detect, hard to reproduce, and don't always happen. Now turn on a thousand users. How many users are you hoping to have btw?

Your worst kind of bug:

  * Is not detected for months.
  * Unable to reproduce.
  * Company killer. (Reputation, lawsuits, whatever).
  * Happens once every 40,000,000 sessions.

The complaint:

but unfortunately the culture at RIM does not allow us to speak openly without having to worry about the career-limiting effects

The response:

it is particularly difficult to believe that a “high level employee” in good standing with the company would choose to anonymously publish a letter on the web rather than engage their fellow executives in a constructive manner

Can we PLEASE lose the paper-on-desk metaphor and have a 7 day calendar that always shows the next 7 f&*!@##! days!

Testing: testing is at the forefront of our development philosophy. We never need to check our code coverage to know that it's at 100%: with disciplined TDD, no line of code will be written without a test.

Bravo. In my experience that can be overkill, but with finance, I agree: why risk it. TDD everything.

We don't have a QA team.

WTF?

That might be terrifying when you consider the type of software that we're building, but we're confident that our automated testing is thorough and will catch any regression bugs.

Are regression bugs the only kind of bugs?

We use continuous integration to test every version of every client library against our gateway.

What happens when someone uses your client library in a way you didn't anticipate?

What happens when johnny-botnet hits your API directly without using the client library?

I spent several years developing games, with QA teams that outnumbered the developers. The QA team did not just play the levels through and say "it works!". Sure, they did that for the first hour. Then they'd start doing all those things that they thought someone might try (e.g. in a fit of boredom, or for a laugh). After that they'd just try breaking stuff. What a lot of bugs they would find!

As I write I find it hard to believe that I, a game developer, is having to explain the importance of QA to a financial company.

This is what I learned from a half-day legal seminar in california aimed at startups:

In California, unless the work is for course credit at an established institution, an intern must be paid minimum wage. If not, the intern can do the work, and then file with the state, which will then do all the investigation. The intern doesnt need to get a laywer. They get the state's lawyers looking for a hefty fine, back taxes, and the opportunity to audit the hell out of someone. Start-ups are especially vulnerable to this because programmers who would normally be exempt probably aren't making enough and should be paid overtime. The state doesn't care what those programmers want. They want their back taxes.

Eddie Murphy said it best: http://www.youtube.com/watch?v=zpPdgrr5diM

What's next? a 556 loveseat?

And oh god i had to install it from floppies. I think windows NT was 20 of them.