Yesterday, I read an article about using GPUs to accelerate password hashing: No, Heavy Salting of Passwords Is Not Enough, Use CUDA Accelerated PBKDF2. The article makes some very interesting points about password hashing. But the conclusion of the article really misses a huge point, and get a major point fundamentally wrong (bordering on misunderstanding). Let’s start with the part they got wrong…
Very often when we look at a class diagram for a new application, it’s quite overwhelming. There are tons of classes, all interacting with each other. These interactions are everywhere. It actually resembles a spider web of interaction. Trying to decode this web to figure out what the application is doing can be a lesson in futility for some applications.
How then, can we design an application such that it’s easy to follow? How can we build an application that’s easy to understand on all levels? The answer is deceptively simple: by using layers. Let’s explore how we can use layers to help build our applications in a clean, easy to follow and maintainable manner.
A few weeks ago I was sparked into a twitter conversation with Larry Garfield (@Crell) about the value of comments in code. Really, twitter is not the best place for that conversation, so I decided to write this post to illustrate my beliefs on commenting. Let’s start this story with the tweet from Larry that set off the conversation:
Nothing drives home the need for good code comments like working on code that doesn’t have them.
A pretty innocuous comment that is quite insightful. But that led me to respond with:
Nothing drives home the value of good, clean code by working on code that doesn’t need comments.
That led to an interesting discussion that just couldn’t fit on twitter. So let me explain…
Here are the slides from my presentation at NYPHP on STUPID vs SOLID development. Click through to see the slides.
Time for some more shameless self-promotion… I’ll be doing a talk at the New York PHP group on Tuesday May 22, 2012. I’ll be discussing some Object Oriented design principles and how to apply them to your projects. We’ll specifically discuss the STUPID and SOLID principles. Here’s the full abstract:
The other day I announced the release of my new password hashing library, PasswordLib. As I’ve come to expect, Reddit was full of interesting commentary on the topic. Some was good, some was bad and some surprised me. What surprised me was the insistence on a global salt (otherwise known as a “pepper”). So, I started thinking about it some more, and I figured I’d write a post on why I don’t use peppers in my hashing algorithms (and why you may want to rethink it too).
Lately, I’ve found myself in a number of discussions about Technical Debt and how it applies to project development. Overall, I think it’s a very powerful tool that – when used wisely – can be a great asset to any team. It seems to me that most of the people that I’ve been talking to really don’t agree, and see Technical Debt as a plague that should be eliminated at first sight. So, I figured I’d share my opinions, and see what you think…
The other day I had read an interesting post by 37 Signals entitled Why We Don’t Hire Programmers Based On Puzzles, API Quizzes, Math Riddles or Other Parlor Tricks (say that 10 times fast). Then I was pointed to another article by C for Coding entitled Interview Programming Problems Done Right. That got me thinking about the interview techniques that I’ve used at my current and prior jobs. It’s a different style than either of those two posts, so I figured it was worth talking about.
One of the most frequent questions that I get asked is “How can I become a better developer?” I think that it’s a very good question to ask that deserves a good response. But how can you respond to something like that? Becoming a better developer depends so heavily on past experience (where to grow), interests and rationale (why do you want to grow), that it’s really hard to answer without a fair bit of discussion. This post reflects my experiences from both my own growth and the growth that I’ve seen in others.
When it comes to optimization, there are two competing viewpoints in the PHP community. Some say that optimization should only ever be an after thought and to avoid premature optimization at all costs. Others will say that this is impractical, and you should make your application fast as you write it, since then you won’t have to go back and clean it up to make it faster. While I can understand the viewpoints of both sides, I am firmly in the former category. Given the number of discussions that I’ve had as of late on the topic, I’ve decided to write a post as to why I believe my viewpoint is better and more sustainable in the long run.