2 books I absolutely love and have read cover to cover several times, solved most of the 1000+ problems.
1. Inference - Rohatgi
2. Inference - Stapleton
Why I recommend them ?
The real answer is super long. But the short version is - there are thinkers & there are doers. Basically, the mathematical statistics world has these theory-building Bourbaki type guys who write a LOT, say a LOT, but never get to the fucking point (imho). The opposite view is "math is bunch of tricks. its like chess - more middlegames & endgames you know, higher chance of winning. No real point in learning who originally came up with this particular middle game variation, or why does this opening work etc etc. Just learn the trick & play the game." So that's the eastern (Indian/Chinese) school of thought, which is what I subscribe to.
The 2 inference books listed above are essentially grab-bags of tricks. Do this - it works - now try it on these problems - ok next trick...on & on. So I solved the 1000+ problems & now I know lots of these methods that just work.
eg. recently i was asked - some vc's are evaluating a startup. their valuations are $1 million, $4 M,$10M, $20M, $50M. what's your evaluation & why ?
so i'm thinking - hey isn't this just rohatgi taxicar ? so i quickly said- sum is 85, times 1/5 is 17. Whereas largest observed is 50, times 6/5 is 60, so half is 30. since 50 was max observed, another estimator is half that, ie. 25. if you want doctor's estimate, get rid of 1 and 50, then sum is 34 so times 1/3 is 11.3
so then we have 4 estimators, - the sample mean is 17 million, its the method of moments estimator, clearly unbiased but high mean square error because variance is high. the maximum likelihood estimator is 25 mil, and has smallest variance, but the mse will not be the lowest since it is not unbiased so bias square will add. the 30 mil estimate is also unbiased, but has low variance so it has the lowest mse of the lot. the doctor estimator 11 million is unbiased but high variance and mse is in between. now if you want the absolute lowest mse, i can cook up a 5th estimator which has nonzero bias but mse will be the minimum....
at this point the interviewer interrupts me - you've never seen this problem because we came up with it in our last meeting at our firm. Yet you gave me 4 very good estimators under 2 minutes & want to cook up a 5th one that's even better. And you don't even have a phd. meanwhile i just spoke to an actual phd and asked him this same question, he went on and on for 20 minutes without giving me a single concrete estimator!
so that's the thing. rohatgi, stapleton, these are about real world, down & dirty, how to do stuff. how to solve actual problems.
whereas the gelman bda, the shao, the schervish, the lehman, the bickel & doksum - these were my prescribed textbooks. imho they are absolute garbage, worse than dirt. after the exam i threw them away. such bullcrap. they go on & on without getting anywhere & have practically zero good worked examples.
so that's my 2 cents. i still have the rohatgi & stapleton on my desk. sometimes i tear up when i look at them. they have taught me so, so much!
TL;DR Django models are the database, which makes them the wrong choice for presenting a service-layer interface to the persistence. They are inherently unable to hide, encapsulate, and protect implementation details from consumer that don't care or shouldn't be allowed to access.
The Django model is a representation of the database state. It's an infrastructure-layer object. It's is _very_ tightly coupled to the database.
Your business needs should not be so coupled to the database! While it is very helpful for an RDB to accurately model your data, a database is not an application. They have different jobs.
(The TL;DR of the following paragraph is "encapsulation and interfaces")
Your business logic belongs in the "service layer" or "use case layer". The service layer presents a consistent interface to the rest of the application - whether that is a Kafka producer, the HTTP API views, another service, whatever. Your service layer has sensible, human-understandable methods like "register user" "associate device with user", whatever. These methods are going to contain business logic that often needs to be applied _before_ a database model ever exists, or apply a bunch of business logic after existing models are retrieved in order to present a nice, usable, uncluttered return value. Your service layer hides ugly or unnecessary details of the database state from the rest of the application. Consumers shouldn't care about these details, they shouldn't rely on them (so you can fix or change without breaking the interface) , and they very probably should not be presented direct access to edit whatever they want.
If you do not do this and instead choose the fat models method all of the following will happen:
1. You will repeatedly write that business logic everywhere
where you use the models. You'll write it in your serializers, your API views, your queue consumers/producers, etc. You'll never write it the same way twice and you damn sure won't test it everywhere.
2. You'll get tired of writing the same thing and you will add properties or methods on the model. This is the Fat Model! This might be appropriate for convenience property or two that calculates something or decides a flag from the state of the model, but that's it. As soon as you start reaching across domains and implementing something like "register device for user" on the user model, or the device model, you are just reinventing a service layer in a crappy way that will eventually make your model definition 4000 lines long (not even remotely an exaggeration).
3. Every corner of your application will be updating the database - via the model - however it wants. They will rely on it! Whole features will be built on it! Now when it's time to deprecate that database field or implement a new approach, too bad. 20 different parts of your app are built on the assumption that any arbitrary database update allowed by the model is valid and a-ok.
Preferred approach:
1. Each domain gets a service layer, which contains business logic, but also presents an nice reliable interface to anything else that might consume that domain. This interface includes raising business logic errors that mean something related to our business logic. It does not expose "Django.models.DoesNotExist" or "MultipleObjectsReturned". It returns an error that tells the service consumer what went wrong or what they did wrong.
2. The service layer is the only thing that accesses or sees the Django models aka the database state. It completely hides the Django models for its domain from the rest of the application. It returns dataclasses or attrs, or whatever you want to use. The models are no longer running rampant all over the application getting updated and saved willy nilly. The service layer controls what the consumers in the rest of the application can know and do.
You will write more boilerplate. It will be boring. You will write more tests. It will be boring. But it will be reliable and modular and easier to reason about, and you can deliver features and changes faster and with much less fear of breakage.
Your business logic will live one place, completely decoupled, and it can be tested alone with everything else mocked.
How your consumers (like API views)turn service responses and errors into external (like HTTP) responses and errors, lives in one place, completely decoupled, and can be tested alone with everything else mocked.
Your models will not need to be tested because they are just a Django model. They don't do anything that's not already 100% tested and promised by the Django framework.
The most important thing about learning to talk to strangers is practice. Taxi driving gave me lots of new people to talk to every day. Sometimes they weren't new. I didn't remember them, but they remembered me on account of my previous efforts to get information out of them.
[edit: if I was starting this today I'd be a ride share driver. But I've learned enough, and don't feel the need to drive people around again.]
> Here are other ways Nightingall suggests breaking a script.
I figured out where my passengers were going, "Are you going anywhere in particular, or do I get to choose?" No one hires a taxi to take them to a random location.
One lady, who was with her family, said "we can go anywhere you want." Two seconds later she said, "too late, we're going to the movies." 'DRATS! That was my chance!' Thenceforth I resolved to be prepared for when people took me up on my proposal of picking their destination.
One woman said we could go anywhere I wanted, as long as she got to the bus station by 10pm. We had plenty of time, so we went to the 5 & Diner for dessert. When I dropped her off at the station, my passenger said it was the best birthday she'd had in quite some time. (I never heard from her again.)
> If you say something generic, they will say something generic. If you say something specific, they are likely to as well.
I assumed everyone was a native Arizonan. If someone was a transplant I'd ask "Oh, did you move here from [specific city in the upper Midwest]?"
Strictly speaking, there are more people in Arizona from California than [specific city]. But California is 800 miles from Mexico to Oregon, and if they were from California they'd say, "Duh", whereas if they're from [specific city], they're usually either impressed, or they wonder how I knew.
One fellow did not have that upper-midwest vibe, but I'd had experiences where I switched it up but would've been right. He said "no, bunch of damn communists from [upper midwest city], I'm from Oklahoma."
"How'd you find your way to the desert?" IIRC that passenger was in the Army (Green Berets), and they needed an airport with a thick enough runway to support their operation (he didn't say 'in Central America', but I realized he was talking about the Iran/Contra operation). Scottsdale was their airport. He said something about Lt. Col. North getting crucified by Congress, iirc. [0]
"Do you have any food in your apartment, to go with your vodka?" She did not, I stopped the meter and took a detour to McDonald's. That passenger is doing quite well now, and no longer suffers from prison-induced PTSD.
Not all passengers got my usual script. I just got a call from a woman who I first picked up at her parents' house. The Phoenix Police officer said, "have fun with this one." She was in fight-or-flight mode, getting kicked out by her parents (who had custody of her daughter). As soon as we pulled away she broke down. She was a very expensive passenger. I hadn't heard from her for maybe 5 years (when she'd just been approved for SS disability). She found my number last week, it was nice to hear from her.
[0] "North formulated the second part of the plan, which was to divert proceeds from the arms sales to support the Contra rebel groups in Nicaragua, sales which had been specifically prohibited under the Boland Amendment." - https://en.wikipedia.org/wiki/Oliver_North
ok, i will try.
2 books I absolutely love and have read cover to cover several times, solved most of the 1000+ problems.
1. Inference - Rohatgi
2. Inference - Stapleton
Why I recommend them ? The real answer is super long. But the short version is - there are thinkers & there are doers. Basically, the mathematical statistics world has these theory-building Bourbaki type guys who write a LOT, say a LOT, but never get to the fucking point (imho). The opposite view is "math is bunch of tricks. its like chess - more middlegames & endgames you know, higher chance of winning. No real point in learning who originally came up with this particular middle game variation, or why does this opening work etc etc. Just learn the trick & play the game." So that's the eastern (Indian/Chinese) school of thought, which is what I subscribe to.
The 2 inference books listed above are essentially grab-bags of tricks. Do this - it works - now try it on these problems - ok next trick...on & on. So I solved the 1000+ problems & now I know lots of these methods that just work.
eg. recently i was asked - some vc's are evaluating a startup. their valuations are $1 million, $4 M,$10M, $20M, $50M. what's your evaluation & why ?
so i'm thinking - hey isn't this just rohatgi taxicar ? so i quickly said- sum is 85, times 1/5 is 17. Whereas largest observed is 50, times 6/5 is 60, so half is 30. since 50 was max observed, another estimator is half that, ie. 25. if you want doctor's estimate, get rid of 1 and 50, then sum is 34 so times 1/3 is 11.3
so then we have 4 estimators, - the sample mean is 17 million, its the method of moments estimator, clearly unbiased but high mean square error because variance is high. the maximum likelihood estimator is 25 mil, and has smallest variance, but the mse will not be the lowest since it is not unbiased so bias square will add. the 30 mil estimate is also unbiased, but has low variance so it has the lowest mse of the lot. the doctor estimator 11 million is unbiased but high variance and mse is in between. now if you want the absolute lowest mse, i can cook up a 5th estimator which has nonzero bias but mse will be the minimum....
at this point the interviewer interrupts me - you've never seen this problem because we came up with it in our last meeting at our firm. Yet you gave me 4 very good estimators under 2 minutes & want to cook up a 5th one that's even better. And you don't even have a phd. meanwhile i just spoke to an actual phd and asked him this same question, he went on and on for 20 minutes without giving me a single concrete estimator!
so that's the thing. rohatgi, stapleton, these are about real world, down & dirty, how to do stuff. how to solve actual problems.
whereas the gelman bda, the shao, the schervish, the lehman, the bickel & doksum - these were my prescribed textbooks. imho they are absolute garbage, worse than dirt. after the exam i threw them away. such bullcrap. they go on & on without getting anywhere & have practically zero good worked examples.
so that's my 2 cents. i still have the rohatgi & stapleton on my desk. sometimes i tear up when i look at them. they have taught me so, so much!