This afternoon, I gave another talk at TrueNorth PHP. The talk is a version of a previous talk that I gave on Object Oriented Design. I’ve changed it significantly, so here are the slides.
This afternoon, I gave another talk at TrueNorth PHP. The talk is a version of a previous talk that I gave on Object Oriented Design. I’ve changed it significantly, so here are the slides.
This morning, I gave a talk at TrueNorth PHP. The talk was aimed at explaining the basics of Cryptography as needed for the average developer. It is intended to give a high level understanding of cryptography and cryptographic techniques. So, with no further adue, here’s the slides:
Last week, I was at PHP North West. The conference was incredible to say the least. One of the best I’ve been to in a very long time. But to the point of this post, I did an unconference talk about password hashing in PHP. Since I had my camera with me, I also took video of it. So included in this post is both the slides from the talk, and the video of the talk. So, with no further adue:
Yesterday, I got in an interesting conversation on twitter about object scopes and what constitutes a global scope. The discussion started around a piece of code that I stumbled upon from Fuel 2.0. I am a firm believer that service containers are not a form of Dependency Injection, and are only slightly better than global variables. That led me to make a few comments that elicited a reply from two Fuel developers. That led to a rather interesting debate that just couldn’t fit into 140 characters… So I’m going to go into topics that are tightly related: variable scoping and service locators.
Or anyone else for that matter. Lately, I’ve been getting a lot of feedback about my posts that I’m suggesting things that are going to get less experienced developers into a lot of trouble. Or that people are going to use my posts as justification for bad practices. Or that people are going to cause major issues by putting experimental concepts into production. My initial response is “That’s their problem.”
Today’s post is in response to an article that I read yesterday entitled They Write The Right Stuff
. It’s a very interesting and insightful look into one of the most complex and critical pieces of software ever produced (also one of the most expensive). I think we can learn a lot from what they are doing, but I also think we should avoid copying what they are doing. The point that’s missed is practicality.
Every developer who studies computer science (and most who haven’t) has heard the phrase “Garbage In, Garbage Out
“ before. It’s such a logical concept that it’s almost beyond refuting. Almost. While the phrase still definitely holds true for some situations, it doesn’t hold for most. How can such a logical and straight forward saying lead us down the wrong path?
“Don’t Reinvent The Wheel” is a phrase that we hear used all the time in software development. Usually it’s used in the context where a library exists to do what the user wants, but they are writing their own. While the sentiment is usually correct, I can’t stand the implication of the phrase. Therefore, I can’t stand it when people use that phrase without understanding what it really means. Let me explain:
In this day in age, it seems that the community trend is completely and unequivocally trending towards the use of web application frameworks. So much so that the defacto first comment to someone asking how to do something seems to be “Just use a framework, and it’ll solve the problem for you.” While I completely understand why this is the case, I can’t say that I agree with it. And while I do believe that frameworks serve a purpose, I think that they are vastly over-used. Let me explain why…
Every day I come across code that is insecure. Sometimes the code is so hilariously insecure that any 10 year old could break it. I’ve also gotten into discussions with people who should know better about their practices. It’s very, how to put this, disheartening. It’s sad that the average developer knows (and cares) so little about proper security practices. So, I’ve put together a simple pledge (or manifesto, if you’d like).