Preventing CSRF Attacks

There’s been a bit of noise in the past week about the proper way to prevent Cross-Site-Request-Forgery (CSRF) attacks. It seemed to have started with this post. There’s been discussion in the comments, and on Twitter about it, and there seems to be several opposing viewpoints on the matter. I want to start off by saying that I agree completely with the post in question. But I figured I’d write a post to explain WHY I agree with it.

Don't Be Afraid To Be Silly

When was the last time you were silly? Well, more specifically, when was the last time that you wrote code that was downright silly? I’m not talking about writing code that’s dirty, or hacking something together. I’m talking about writing code that you know before writing won’t work, or is wrong or is just plain silly… I’m talking about the kind of code that you think that if you show other developers, they’ll just sit back and go "Why the #@$% would you do that in the first place?"… Well, I do it quite often, and let me tell you why you should do it more as well!

Response: Private Methods Considered Harmful

Brandon Savage has recently posted two blog posts portraying his opinion that using private visibility on class methods can be considered harmful in a lot of situations. While I understand the point he is trying to make, I can’t say that I agree with it. I do like private visibility and think that it’s actually under-used in a lot of software. But it’s not because I think Brandon is wrong…

Change: A Two Faced Devil

There’s nothing as universally controversial in this world as change. Change can be (in aggregate) for the better or for the worse, yet people will always be split down the middle. Some will believe that the change is a good thing, and others will see it as a bad thing. Often your view points will be dictated by your perspective and how the change will directly effect you. When it comes to software projects and change, what’s the right thing to do?