theWold
Joined 11 years ago
Joined 11 years ago
But if you really want a trackpad, yep, nothing beats an Apple Touchpad. (or at least what I have used / seen)
Monogatari (Anime Series) - It is a jumbled mess that is a jumpy as it is deep. If you don't want to see any fan service at all in your anime I would skip over this. If you don't mind that (or enjoy it) this is a great anime. It doesn't knock my favorite anime (Cowboy Bebop) off of my Number one slot, but this one is a great that I would wager will stand for the future. (Bakemonogatari is the first season).
Don't Panic - There's a reason it is written in big bold red letters on the universe's best selling book.
Speak your problems logically and show that you've given some thought to them when you talk with your boss.
My biggest inspiration (other than taking a perfect shot at a whitetail deer and him just dropping dead) was a good PDF about shotGroups over on the CRAN[1]. It is a little dry and statistically heavy (meaning you need to have some statistical background to make sense of it), but well enough detailed for the info that triggered me to pursue this pet project.
I would love to write it at a level where if a person with no statistical background would be able to read through it and be able to understand it "enough". (Which requires a lot of rewriting on my part to make sure I'm also not boring a person with statistics background to death too explaining what Standard Deviation is :P)
[1] https://cran.r-project.org/web/packages/shotGroups/vignettes...
True:
> no discussion of how one might interpret this model, what its assumptions are, and how to assess validity or fit?
Quoting OP from the comments in his blog:
> Hey Victor, thanks for reading! You’re absolutely right, I should have taken some time to talk about the assumptions of linear regression. I tried to mention them in passing, but I’ll try to be more explicit next time. I should have brought up the pearson correlation coefficient. I tried to write this from a more machine learning point of view, not as much statistics.
Either way it was a decently written post and would read more in the future (though I would like to see more statistics side of things rather than just me thinking Alex here is waving his hands saying 'you see nothing!' when we look at the mathematical assumptions / 'pure' statistics).
In other thoughts:
I'm currently in the process of writing a blog series on the analytics of Firearm projectiles (What ammo is most accurate from a Ruger American 308 Win.). Seeing other statistical posts like this help me figure out how to make mine better. So thanks Alex!
I also keep up with friends/acquaintances (typically people on the 'business' side of things). Though most of my software/programming buds and gals we connect elsewhere (typically through Steam).
But if what you are after is insight into how a computer works I found that I had my 'ah-ha' moment while learning C, Assembly (intel), and writing a compiler. I did have to have a slight basis in computer architecture, but that compiler project I worked on made everything click.
(side note on writing a compiler. Read, Decode, Execute. There are no short cuts around those series of steps).
If you are looking for a book I would recommend the 'Dragon Book'
http://www.amazon.com/Compilers-Principles-Techniques-Tools-...
I found a paper copy of the international version for cheap (like $10 US if I remember) that was amazing.
I have debian on my NAS and 'stable' backup box. I keep this thing rock solid.
If I actually want to do anything crazy, I'll either whip up a VM or I have a clunker of a laptop I keep around for experimenting and other things (along with other single board computers).
My two cents in keeping something stable is don't do anything to it. Keep it as vanilla as possible unless you are 100% sure what you are doing.
Good post and read.
I feel like this is more obvious in software. Errors are handled and reported in the logs, but it still works. Sure they, the errors, need to be fixed. But problems that cause things to crash (contextual pun) need to be fixed first.
Though I did like that post :D
I took a COBOL course just two years ago in a Texas Public University. It was considered the 'I didn't get any offers anywhere else' or 'I am too lazy to apply' if you were picked up by IBM as a COBOL engineer. I was trying to pull up the online syllabus. Seems like they have finally gotten rid of that course (or maybe the professor who taught it finally passed away).
As annoying as COBOL was, it was unique and interesting in the way it handled IO processing. From what I understood from talking with those who had gone the COBOl engineer route from my school, was that it was never quite learning COBOL, but rather all the jank years of programmers added into the codebase. COBOL is annoying, but when you have the equivalent of jank similar to badly designed #define 's all over the place that makes you want to thrash out at everything and anything when you realize what is happening ... that is, from what I have been told, a major reason COBOL sucks.
It wasn't my cup of tea, thus I didn't pursue it, but to fellow classmates, they quite enjoyed it as one would when you program in C. It had a certain elegance to it.