Recently, there has been a spout of attention about how to deal with eval(base64_decode("blah")); style attacks. A number of posts about “The Dreaded eval(base64_decode()) - And how to protect your site and visitors” have appeared lately. They have been suggesting how to mitigate the attacks. This is downright bad.

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…

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!

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.

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.

A few days ago, I posted a video about how to become a better developer. There were a few interesting comments made, but one in particular from the Reddit thread ( http://www.reddit.com/r/PHP/comments/... ) peaked my interest. So I decided to do a reply. Check it out:

In today’s episode, I talk a little bit about what it takes to become a better developer. Nobody will ever expect you to know everything, but you better know how to find it…

I’m trying out a new format with this video. Less scripted, more free-form, and with less visuals. This is not going to replace the other format (which I’m still working on), but instead compliment it from time to time. Let me know what you think in the comments below! Check it out:

It’s been a little while since I’ve posted anything here or on YouTube. I’ve been working on some interesting ideas that hopefully will be pretty decent, so it wasn’t time wasted. But I figured now would be a good time to tell you about some upcoming speaking engagements that I have, and where I’ll be over the next few months. So with no further adue:

About three months ago I decided to start shooting videos teaching programming concepts to put on YouTube. When I first started it, I didn’t think it would take off. In fact, I thought it’d be just another failed attempt at trying something new. But three months, 11 videos, nearly 700 subscribers, over 17,000 views and 1.5 man-months of viewership later, I can’t really complain. I’ve missed a few videos over the past few weeks, and missed another one today. And I feel that you deserve to know why.

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!