Many people teach design patterns as a fundamental step to Object Oriented Programming. They are so universally seen as important that almost every single conference that I have been to has had at least one talk about them. They are quite often used as interview questions to test a candidate’s OOP knowledge. However, just like inheritance, they are not needed for OOP. And just like inheritance, they are a distraction rather than a foundation. Instead of focusing on patterns, I suggest focusing on learning about abstraction and communication. Why? Let’s talk it out…

This is a post that I didn’t want to write. Actually, it’s a post that I still don’t want to write. But I find myself in a situation where I feel that I have to say something. So I’m going to just open up here. I’m going to put it all out on the table, and see what happens from there.

Yesterday I was asked a rather interesting question about presenting technical presentations. While I don’t think my method will work for everyone, I feel it’s a good thing to talk about. So here’s my method, and some advice that I would give first time presenters:

I will be speaking several times in the coming months at several conferences in the US and Europe. I hope to see you at one of these events!

Last week at the BlackHat security conference, a new attack on SSL secured content was unveiled. This attack is called BREACH, and has been generating a lot of buz on the internet. Tech blogs have been plastering their sites with articles about how there’s no fix, and how you can try to defend against BREACH. Well respected security people have been writing about it.

And I’m here to say don’t worry about it.

For the past several months I have been struggling to figure out what I want the next step in my career to be. I am still trying to figure the details out, but I had an important revelation last night. I want to share that revelation with you.

At the current point in time there exists a very significant SQL Injection vulnerability in the WordPress code base. I want to make it abundantly clear that this does not affect anyone using WordPress “off the shelf”. It only is exploitable if you use certain WordPress code outside of a WordPress install. So this is not a very “attackable” vulnerability. Or to put it in other terms, this is a high level vulnerability which has a very low threat level. It is also worth noting that it has not been fixed by WordPress (even 90 days after disclosure).

Lately I’ve been playing around with some functional languages and concepts. I have found that some of these concepts are directly applicable in the OOP code that I’ve been writing. One of those concepts that I think is worth talking about is the Monad. This is something that every functional developer tries to write a tutorial on, because it’s such a cool but hard to grasp concept. This post is not really going to be a Monad tutorial per se, but more of a post about bringing the general concept to OOP, and what that looks like.

Yes, you read that right. If your project aims to provide backwards compatibility as a primary goal, you’re a sucker. Tons of popular software projects from PHP to Microsoft Windows have stated goals of providing Backwards Compatibility between releases. And yes, I am here to say that they are doing it wrong.

This past Thursday evening I picked up my Explorer edition of Google Glass. I was lucky enough to have my #ifihadglass tweet chosen to receive the chance to pay an arm and a leg to get them. Needless to say, I did choose to pony up the cash, and on Thursday evening I walked home with my brand new piece of technology dangling off of my right temple. Since first impressions are often strong, but can be misleading, I chose to wait until I had used them for a few days before writing my thoughts. So here they are: