No that was the other side who made all the mistakes. The tobacco side is held to a much higher standard (as they should being evil ****s for half a century).

Marketing data is the same boat. I was given a fun exercise to figure out a value of an award a company I worked for received. It was something like "most liked" or something.

They were kind enough to give us a nice paper explaining the "statistical" methods they used, which was basically some upside-down partial differentiation that had exactly one white paper buried deep in Google Scholar, had no working examples, and no references to it anywhere else.

After a day of pushing around numbers, I discovered that the process went like this:

- Find 4 companies, preferably 4 that are small.
- Arbitrarily vote. One or two votes wins the award.

It was suspicious because this paper was totally unexpected, no customer told us about it beforehand, and no 100 lb gorilla was included in the awards.

Without using a mass of zeroes, there was no way to get the data to match their pretty charts and "normalized percentages."

this is a great story

My other favorite thing I did there (pretty sure I've told this story before, but I'm pushing 50 so I guess I'm allowed to start repeating myself) - I was given a list of vehicle vin #s that an opposing researcher had determined were "most likely" a result of Ford ignition switch fires. These fires could either start on the road or after the car had been parked and turned off.

We got hold of a State Farm accident database and I started running queries to match the vin #s. I found a few that were obviously not ignition switch fires. IE - the accident report stated that the claimaint found a squirrel nest under the hood. So I started running some queries to swap zero with O, and 1 with I, or just match on 11 out of 12 digits, etc. - on the assumption that data can easily be mis-entered. Then I would compare the cars, owners, or any other information I had to prove it was the same vehicle. I found a whole bunch more matches.

I came up with a packet of like 30 spurious fires - out of less than 100 that the opposing analyst had claimed were most likely the result of ignition switch fires. They took that into a deposition, got the analyst to repeat his claim, then just started hammering him one after another with the cases I had come up with - not giving away how many more they had in the tank.

The opposing lawyer got so flustered he had a mild heart attack and they had to stop the deposition. He was ok, otherwise this would be a much less fun story. Also his name was Beverly. You never forget a thing like that.

you did him a favor. obviously needed some toughening up

I used to work in Novato. (nothing related to patents though)

Also random, complaint of the day: I am upset at the number of stupid bugs I've tracked down lately to writing code like this:

Do you see the bug? (probably, because I'm a moron JS noob)

You shouldn't be binding inside of the jsx, do it in the constructor. Problem solved.

That doesn't help with this situation where I'm specifically trying to bind the function with different arguments in different JSX elements, though. I'm wondering if I should just avoid bind altogether outside constructors and use arrow functions instead.

I don't normally use bind except for binding "this" but you could also use _.partial, which is exclusively for binding arguments.

goofy,

why not just:

with arrow functions there's generally never a reason to use bind anymore. i haven't used react for a long time, so maybe i missing something...

Theoretical question:

Suppose a forum has a log-in feature and if you add spaces to the end of your password, it still logs you in. What would that mean?

It would mean it's trimming the password - which is fairly standard for most form fields. There really is no legitimate use case to have a space at the beginning or end of a password (or in the middle really).

Nah, that's a good solution (as is candybar's). I need to just train myself to not use bind for situations where I really am trying to do partial application, because I'll probably **** it up.

i think you can literally use the rule "never use bind" and just use arrow functions (or factory functions) all the time. there might be some use case that bind is still needed for, but i don't think so. it has the added benefit of being more readable.

I've been doing something in constructors with bind I think I posted about earlier, which I think I picked up from Facebook's React documentation as a recommended practice:

object oriented programming in javascript is cancer

I've always preferred "const self = this;" myself though I follow whatever conventions in the code base I'm in.

Edit: I guess this is harder to do now inside of a class, since you'd need to do this in every method. lol JS/ES.

Had an interview today with a company that wanted to go contract to hire in case I hated that their product people were "out of control" process wise... Very weird.

RED FLAG

Proceed with extreme caution.

Possibly but I've worked with some of these folks at my last company and after 4 months twiddling my thumbs it would have to be a lot worse than product people changing requirements to turn down a job, particularly one that didn't include a 15% salary cut.

I forget how I found myself watching a Crockford talk on Youtube one day, but he was talking about how he doesn't use new anymore (he doesn't have to, because he doesn't use "this" anymore, and also doesn't use Object.assign()? idk how he makes objects or what he does with them) and people who use the new class features in JavaScript will "never know how miserable they are."

He's right! I don't get why that's bad. I'm open to reading more on the topic to try to understand.

He explains it in that talk, I think. If you give me something you think you need a class for I'll rewrite it in crockford style. The problem is that within a framework like react that is buying into those features (they didn't have to, but they chose to), you're fighting an uphill battle to write in the crockford style. But for your domain objects you absolutely can.

You definitely shouldn't use "new". You can take any ordinary js constructor function intended to be used with new and add this as the first line inside the function body:

which will allow you to call it without using "new" but it will do the same thing.

As for "this", I think that's more a matter of taste.

The crucial thing is that your objects are immutable and you don't use implementation inheritance. As long as you're doing that, the rest is basically a taste war. Which is fine. But not really important.

It's fun to read this knowing how all of this was a great mystery to me as well.

Have you implemented user log in yet?

I sometimes wish I did not post under my real name. But it's probably for the best.

https://en.wikipedia.org/wiki/Rusty_Brooks