We have an enhancement opened with Apple to have a way to delete .cstemp files if the tool runs into them. You'd think we could just add a `find . -name '*.cstemp' -exec rm {} \;` to our build toolchains before building, but we're in a large mono-repo and that would add a lot of time to our builds. Having something like a `--force` to delete the .cstemp files instead of quitting and reporting an error would make us change to this tool pretty quickly I'd think.
In my case, sentry events that represent crash logs for Adobe Digital Video applications. I’m trying to remember off the top of my head, but I think it was in the gigabytes for a single event.
Someone downvoted you, I upvoted because I think you have a good point but it would be nice to back it up. I think I agree with you, but I have only used concurrent.futures with threads.
I remember maybe circa 2004 debating Postgres and mysql with a colleague. I told him to unplug the machine that was hosting his mysql instance. He did and corrupted his database. He said it didn't matter, he had backups, speed was more important :p This was before mysql had the innodb storage engine, after that it wasn't so bad. I have always stood by Postgres though, it's a fantastic piece of open source software.
To your point, I replaced an LSTM that required ~$100k of infrastructure with XGBoost that required no more infrastructure (we created and used the model at query time on existing infrastructure we already had for query loads) and only lost about 2% accuracy (LSTM: 98%, XGBoost: 96%). This was two years ago and it's still in use.
I used to introduce people new to machine learning with a python-converted version of ISL that I was developing. I never finished converting all of ISLR so this is very welcome!
Bishop is going to be more theoretical than ISL. It is true that Bishop is taught as an introduction to ML in many universities, but if you want more hands on to start with, ISL is an excellent option. There is another text called "Elements of Statistical Learning" that pairs well with ISL for a more theoretical treatment. I haven't looked at ESL in a long time, the only concern I'd have is if they aren't covering some introductory deep learning topics. Most of ISL, ESL, and Bishop are more traditional machine learning, covering a wide variety of algorithms, so bear that in mind.
ISL is a more introductory book than Bishop or Murphy. There's no reason not to read all of them, they're all excellent books that cover different topics. I'd also throw in Elements of Statistical Learning from the same authors as ISL(R/P). I've read ISL, ESL, and Bishop, started Murphy but didn't finish it (no real reason, just lost track of it when I got busy). I highly recommend any and all of these texts.
Integrate this into Grafana as an app plugin and you’d have me. I don’t want to leave Grafana where I have all my other operational dashboards for this.
If you want to understand the theory, that's true. If you want to develop an intuitive understanding without having to understand all the nuts and bolts (and I understand that can be a big ask for how some people learn/understand), give this a try: https://karpathy.ai/zero-to-hero.html
I was where you're at about ... oh wow, it's been almost ten years since I jumped into machine learning. Mind you, I've been learning on the side most of this time other than a theoretical class at the University of Minnesota. But, that aside, and depending on where you're at in your understanding, this is a great resource for catching up if you're really interested: https://karpathy.ai/zero-to-hero.html it was posted on HN a couple of weeks ago and I have to say it's a really good introduction and Andrej Karpathy is a passionate and excellent teacher. You may want to brush up on some intro Calculus, but it's very understandable.
I’m a touch typist and don’t find that argument valid either for vi or emacs. And I’ve used emacs for over 30 years now and still do use vi occasionally on production servers where I’m not going to load my full emacs config just for sys admin work.