Never said it had to be memorized. I almost agreed with the blog author when I couldn't remember how to do BFS. But thought I'd challenge myself and figured it out in about 15 seconds, with the deque and all.

How many people can actually write BFS on the spot, without preparing for it in advance?

While I agree with the sentiment (was rejected several times a few months ago), knowing basic algorithms is rather important. I would assume most competent programmers can write BFS on the spot. But I agree that interviews could be improved. I've had luck with simple interviews at very small companies/start-ups; no BigCorps for me

Github? Bitbucket? Gitlab? Tons of services. But if you're not using them already... chances are you aren't using a CVS either. So read up on those - almost as important as the code itself.

Unlikely; why would the defend their arch enemy? If anything, they'd have a dilemma.

The whole point is the author does not want to be identified, for their own safety. You would know if you read the document.

Neat *snap*

Not once had I such a problem with mercurial. With git I have to recheck out every couple of weeks because it broke in a weird way.

Palemoon, everybody. The Firefox of the yesteryear. Same great features and extensions without the stupidity of Mozilla.

What do you mean "submit it through $_POST"? I don't think it supports $purifier->purify($_POST) if that's what you're doing. In any case, you'll have better luck on stack overflow.

Python all the way. It let's you get things done rather than having to worry about verbose syntax. You can't avoid Java in the long term, but Python is the best way to start. As for others recommending C, it's a terrible choice for first language. You need to know how it works, but please don't use it on a regular basis unless you're hacking kernels.

^{C die-hards shouldn't feel personally offended, but you can't deny that a huge chunk of bugs in all software comes from people (from newbs to pros) making silly mistakes when managing memory. Just take a look at a random sample of CVEs, I can guarantee you at least half have to do with bad memory access. I always discourage C usage unless it's for embedded or performance critical parts. C++ is a step in the right direction.}

It's only leakable if you set your proxy connection in your browser. OS or higher (router) configurations are not affected.

Basically anything that let's you access arbitrary memory. In unsafe languages array[length+20] will not necessarily crash and might read meaningful data. In safe languages you'll get an array index out of bounds error of some sort. Basically see heartbleed. Such a bug would not be possible if OpenSSL was using a better language.

I would only allow C/C++ usage for low level programming like kernels/drivers/embedded. Even then you could probably use something like rust which touts itself as being safe. All userspace code should be written in safe languages imo.

Tell that to all those employers looking for COBOL experience.

Minimum 30 years experience.

• Don't use unsafe languages like C and C++ to avoid the entire class of buffer overflow errors
• Never trust input, even if you're digging up old input from a database
• Watch out for timing attacks - use constant time string comparison for hashes
• Rate limit online services
• Always use memory-heavy hashing functions with unique salts for passwords
• Watch out for race conditions
• Use white-lists as opposed to blacklists

First few things that come to mind.