Developers as a whole suck at API design. We don’t suck at making APIs. We don’t suck at implementing them. We don’t suck at using them (well, some more than others). But we do suck at designing them. In fact, we suck so much that we’ve made entire disciplines around trying to design better ones (BDD, DDD, TDD, etc). There are lots of reasons for this, but there are a few that I really want to focus on.
Last week I published a post called Alternatives To MVC. In it, I described some alternatives to MVC and why they all suck as application architectures (or more specifically, are not application architectures). I left a pretty big teaser at the end towards a next post. Well, I’m still working on it. It’s a lot bigger job than I realized. But I did want to make a comment on a comment that was left on the last post.
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.
A few days ago, I wrote An Open Letter to PHP-FIG. Largely the feedback on it was positive, but not all. So I feel like I do have a few more things to say.
What follows is a collection of followups to specific points of contention raised about my post. I’m going to ignore the politics and any non-technical discussion here.
Dear PHP-FIG,
Please stop trying to solve generic problems. Solve the 50% problem, not the 99% problem.
Signed,
Anthony
PS:
…
There is a lesson that I was taught many years ago that I think everybody who contributes to Open Source projects should learn. Back when I was a volunteer firefighter, I had a rather interesting conversation with one of our ex-chiefs. Let’s teleport back to when I was 21 years old.
This is the fourth post in my “Beyond” series. The previous three posts focused on re-imagining OOP and questioning some of the core beliefs that we have come to take for granted. This one is going to be slightly different, in that I want to talk about another angle of writing code: the process itself. We always talk about how code should be clean, but how do you write clean code?
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.
Today, I’m doing a talk at DrupalCon Portland 2013 on Static analysis and code metrics. Here are the slides for that talk. When the videos are posted, I’ll make a followup post that links to it. Click through for the slides!
Last weekend I was at the True North PHP conference in Toronto, Canada. Aside from being an incredible experience (really, it was an incredible conference, huge props to Chris Hartjes (@grmpyprogrammer) and Peter Meth (@mrpmeth)), it was an inspiration. I was particularly inspired by both of the keynote speakers. They both really took really unique spins on programming and how the culture of open source inspires, enables and empowers programmers to do cool and important things. The problem with all of this is that I hate the term programmer. I think it unfairly paints a picture of what we do. Let me elaborate.