Learning JS is very different from other languages in that there's greater amounts of misinformation (lots of people know it, but prefer to use it as little as possible), and it changes faster. For example, in 2015:
- you won't find any Python new articles that tell you to use Python 1's 'strings' module
- You'll still see things like <script> tag soup, 'JS isn't object oriented', globals and patchable-ES3-isms in new JS articles.
Kyle Simpson is a well known JS speaker and O Reilly author - his books are a great source of current best practice.
I've read the book and even contributed a tiny tiny bit with issues in GH (the book is managed through GH). While I didn't learn much I did gain perspective about things so I'd say reading it was definitely worth my time.
what a shitty comment.
did you try to use some Adobe product on case sensitive version of HFS+?
let me guess, no you didn't. because if you would, you would find out that some programs simply doesnt work on case sensitive HFS+, most likely because people like you, who simply "know" whats better for end user
It's almost certainly a bug in a build script somewhere, and they're dynamically linking against something via the wrong name. I once linked against Quicktime.framework, and it worked on everything but my case-sensitive Mac. QuickTime.framework worked everywhere.
So your Adobe example is flawed. They should be testing on case-sensitive volumes, but the vast majority of normal users don't want a file named README and readme in the same directory, and enforcing that invariant seems reasonable to me.
It is a bad article. The author uses a quote from 2002 to criticize the Finder, in order to support his claim that today's Apple software is bad in general, and therefore HFS+ sucks.
Which it does indeed, pretty badly. You would be hard pressed to find a worse FS still in use, excluding FAT, which will just never die.
Except the article doesn't contribute to the discussion and the quotes from Linus are unfortunately not newsworthy. Instead of a deep critique, perhaps pointing what it should learn from Btrfs and ZFS, he acuses Apple of not shipping a consumer case sensitive FS and criticizes its string and slash encoding, which although bad, are successfully abstracted even from most developers.
It then ends stating that Apple, like the weather, pays no attention to criticism. As empty an analysis as can be.
> So don't worry about it. Have fun. Do what makes you happy.
i find it very hard to keep this attitude and also believe that i ll be successful. its either one or the other. i am doing what makes me happy, mostly, but there are also lots of things i simply have to do to be successful, one day. but i can't "not worry about it", i can't "have fun" when i know that i have to work harder now to be successful and to be able to do the other two things later.
I'd be fine with the swearing if it'd be backed up by some knowledge and experience, but that smug attitude is just incredibly irritating when coupled with such level of ignorance.
First decide what are you going to bash. Some libraries, some applications, the entire programming environment ?
Using induction from DBI->quote/CGI and a few old apps to bash the entire Perl ecosystem is just boringly stupid.
It is fine and useful to patch those old apps, but to give an arrogant lecture as if all programmers use the same broken approaches in 2014 is just ignorant.
It is extensively documented to prefer placeholders when working with DBI, that is, if you even use DBI directly and not via an OO mapper.
CGI as an approach is entirely deprecated on all languages/platforms not just Perl.
List expansion ? It is a feature, use it or leave it. You have the option to use references.
If you prefer Python, just use Python. It's like bashing C for having pointers.
So, what else ? Try PHP with those examples. Find some Ruby apps prone to sql injection. Bash some NodeJS libraries.
If Perl is dead already, be a rockstar bashing the new stuff, why even bother with the ghosts ?
I think it is because deep down all Pythonistas know that Perl is a far superior platform and they all carry a deep ancestral envy.
Otherwise they'd just be happy with their choice already. :)
An easy solution to this is to have your scrapers on one network and a fleet of squid proxies on another. As and when an IP gets banned you just cycle in another squid instance on a new VM with a fresh IP (which can be from a completely different netblock/geolocation if you want). You don't have to touch the rest of the scraping apparatus.
I deal with this every day. Eventually we gave up on the proxy pool idea, and started running the headless browsers in the pool as Selenium nodes. It's definitely not easy- for example, we've also had to build infrastructure that helps keep track of IPs and their history.