@TheKeyboard Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

Welcome to the 4th and final day of reader feedback week here. Today’s topic is one that comes up over and over and over and over again: web application performance. In particular, I wanted to discuss web application performance and frameworks.

After seeing a slide from a presentation at FrOSCON about CakePHP’s performance in the incredibly-unrealistic-and-irrelevant “Hello World” competition against vanilla PHP and other PHP frameworks I came up with that very aggressive statement you see above. That prompted a flurry of tweets by other people about their thoughts on that matter, and so on and so forth. I believe my earlier statements were misunderstood, so I shall clarify them here.

I stand by the statement “frameworks are about increasing development speed, not application speed”. I’ve talked about frameworks plenty in the past, and they all promise you this: if you build things according to their rules (and this is the really important thing to remember) then you will gain a significant increase in application development speed. If you fight against those rules, why are you even bothering to use the framework? The goal is to speed up development time by following a set of conventions on how the application is put together.

So, if you’ve had enough courage to build you application with your framework of choice, you should have a working application. That doesn’t mean it is as fast as it could be, but remember the mantra I shared earlier: “make it work, then make it work better”. Where frameworks typically fall down is in the “make it work better” part of that statement. Travis Swicegood pointed out to me when it comes to frameworks “…actually, a really good one should have mechanics in place to do both” (referring to increased development speed and application speed).

So, if you have a framework that actually cares about application performance (perhaps unfairly some frameworks have decided that performance is sole responsibility of the developer, not the framework itself) then it should come with things to make your application a little more responses. Things like built-in output caching, or features in their ORM/ADM that cache your schema, things like that. But in the end, there is only so much you can to make a framework-built application run really fast. Sometimes you can do it with just the additional features I mentioned above. Sometimes you can’t do it because the architecture you’ve chosen for your application won’t let you. And sometimes, you can’t do anything about it because it’s too hard to modify the framework itself. These things happen. Look at Twitter and all the contortions they have gone through trying to take what was initially a Rails application and push it’s performance up to it’s current level.

There are also lots of 3rd-party solutions to help you make your application perform better. Memcached for caching data (ask me some time about my Memached story at an old job). Alternative PHP Cache if you’re running PHP. Squid. nginx. Mongrel. Those are just the ones I can think of off the top of my head. Some of them are even framework agnostic.

Having a framework that lets you BUILD things fast and RUN things fast is the perfect situation, but not too common. I used to get mad when I’d see people asking if can scale, because I felt it revealed a certain level of ignorance in the person asking the question. I’ve now come to the conclusion that what they are really asking is if can scale without them doing any extra work. Usually, the answer to that question is FUCK NO (emphasis mine) because scaling is an issue that goes far beyond just a simple framework.

See, not every framework is slow. Some frameworks, due to their internal structure, are faster than others. I’m okay with that now, not so okay in the past. In a lot of cases, the bottlenecks in your application aren’t code-related. I’ve come to understand that too, especially in the new Javascript-driven world web applications have started to run in. If you think Twitter is slow because they chose Rails, I think that you do not have a firm understanding of how Twitter actually works. Or maybe you don’t care because it’s easy to make fun of Rails and Twitter.

Luckily, we have lots of free and easy-to-use tools at our disposal that let us look at our up-and-running web application (remember, Just Build It, Damnit!) and see how it’s performing. Things like Siege and YSlow are just two tools that their use will give you huge insights into the actual performance of your web application.

You shouldn’t be GUESSING how your application performs, you should KNOW what is going on.

Welcome to the 3rd installment of me answering reader feedback questions. Today we deal with a topic that I deal with every day at my day job — working with XML in PHP.

First of all, I do all this in PHP 5. SimpleXML makes it so easy to manipulate XML. For my main work project, I’ve written a PHP application front end that talks to eXist, an open source XML database. Since we deal with XML all day long it was decided that we needed to eat our own dog food and go with an XML database to store the information that the application generates. So a lot of my code does some of the following things:

• Do a call to a xQuery script running on the database that returns info that I’m looking for, usually both comma and pipe-separated data
• Load a specific document into a SimpleXML object and pull out some specific info
• Load a specific document into a SimpleXML object and then use it’s XPath functions to pull some information out.

Those 3 techniques seem to work well for me when dealing with XML data in PHP. If I had to go back and redo some of the earlier code, I’d probably change things a little differently in how I’m using eXist to simulate how some of our other products work:

1. Use eXist to give me a list of documents that contain the info I am looking for
2. Load those documents into SimpleXML
3. Use Xpath to grab the data I needed

But in the interest of Getting Things Done, what I’ve done works pretty good and the code is really not horrible.

Welcome to Day 2 of my answering reader feedback questions here in the month of August. I was asked to share my experiences with Django. I will confess that I am a complete n00b when it comes to Python (wrote a few scripts for work-related stuff) and got an early alpha of my baseball road-trip planning site actually working using Django. Sure, it was ugly and very rough around the edges but I got it to work. But I will say this: if I had the opportunity to start working with Python and Django every day (and for the same pay I’m getting now) I would take it in a heartbeat. Seriously.

So why all the love for Django and Python? As a guy who’s used PHP for a very long time, I’m really blind to the syntax of it. All the griping about needle vs. haystack and “PHP is ugly” is just wasted on me. Just so much pissing and moaning by people who should know better and lack the courage to learn the language they way they should. I heard it described by Evan from Identi.ca as being “the working man’s language”. Nothing wrong with that, as PHP is great at Getting Things Done. But Python…Python is vastly different from PHP. It’s about objects. It’s about consistency. It’s about the most amazing interactive interpreter I’ve seen since I was a kid fooling around on my VIC-20 typing in programs from Compute! magazine. Bet you didn’t think I’d been using computers for that long. To shift into bragging mode, I first got paid for programming when I wrote a program for my mother’s school (she’s a teacher) to create the salary grid for the teachers. I was 12. I think.

Also, there’s a dirty little secret about using frameworks that nobody really tells you. After a while, it makes you lazy. You forget how to do certain things because, well, the framework does it for you. The other day there was a tweet from someone asking about the best way to sanitize data before you put it into the database. My first thought was “sheesh, that’s built into the framework” and then I stopped myself and said “you are getting goddamn lazy!”. My response was “try using mysql_real_escape_string(…)” but was also told about using PDO’s binding of parameters as another way to do it. See, those things are all done by the framework meaning lazy old Chris doesn’t have to remember how to do it. Until the time he’s confronted with non-framework code that he cannot simply rewrite as part of a framework. *gulp*. So, since Python and Django are so different from the other frameworks I’ve used it forces me to STOP being lazy and actually learn how not only Django itself works but how the insides of it work as well.

Now, being an old hand at frameworks means using Django is not that big a stretch. I spent a lot time googling around for the “Python (or Django) Way” to do things. Except for a few concepts that are not familiar to a long time PHP guy (generators?) it wasn’t that hard to get up and running with Django. The documentation is awesome, and once you learn to stop writing PHP code in Python and instead embrace doing things the Python way, it becomes a lot easier.

In the end it’s still datasource-backed models talking to some controller code and passing it onto some template. I find the Django templates to be very limiting after my initial experiences and my “PHP is the template” background, and I think that as I get deeper into it I really have to find out how to do things the Django way. What CakePHP calls Model-View-Controller, Django calls Model-View-Template, but it’s really the same thing.

When I compare Ruby to Python, I don’t get the feeling that I will have to resort to dynamic functions and closures to Get Things Done in Django like I see happening in Rails. Besides, they seem to be two very different communities. That’s probably because the leaders of the Django community are so different in temperament and I don’t see the same type of “Django rules, everything else sucks!” mind sets that I saw in the Rails community. Maybe I’m just looking in the wrong places, but I feel more at ease in the Django community than the Rails community, albeit from the outer fringes of it.

So don’t be lazy and complacent about the tools that you use. Go and checkout Django and you might feel the same way about it as I do.

With August winding down to a close and the insane August family event schedule over with (5 birthdays and my wedding anniversary) I now have the time to answer some of the reader feedback questions I had solicited at the beginning of the month. So, to give something back I will be answering one question each day this week. Today’s first topic is Personal Project Management.

As I never get tired of telling people, my employer is one of the enlightened few who lets their employees telecommute 100% of the time, so there are some different challenges in play. I understand that some people could not “handle the pressure” (their words, not mine, although I am paraphrasing) of working from home. At this point I could not imagine going BACK to working in an office.

So, with your boss always around on IRC and just a phone call away, how does your grumpy correspondent stay on top of his tasks since he knows the boss will never show up at my desk asking me a question? You may be surprised at the answer if you know me in real life: through self-discipline.

Yes, I can already feel the immense amount of eye-rolling (including my mother) but it really is true. If you are the type of person who needs to be constantly told what to do, you are not going to cut it in a telecommute environment because you WILL be left alone for long periods of time to Get Things Done Without Constant Supervision. The only way to make sure you are able to function without simply going upstairs and watching TV when you are supposed to be working is to, well, act like the professional coder you are supposed to be. So, how do I handle this? Please be aware that this is a method that works for me and probably only for me. Copy it at your own peril.

I tend to approach programming assignments as if it was Big Problem that can be solved by breaking it down into Little Problems. This is why when confronted with the question “is there any programming challenge you solved that you are really proud of?” I tend to draw a blank because, well, despite all my bluster and accusations of being an asshole, I don’t really look at the stuff I do and say “goddamn, that was amazing work”. To me, it’s really just solving a bunch of smaller problems that make up a bigger problem. I guess you thought I’m a shameless self-promoter of my work. I try to do go

I mean, not every programming task I complete is what I would call exceptional work because sometimes you just can’t figure out an exceptional way to do it. Plus, I can’t bring myself to be such an asshole as to expect everything I do to be perfect. Not everyone is at their best all the time. Therefore, I try to follow a policy that was explained to me by gwoo from the CakePHP project: “Make it work, then make it work better”. I can’t think of a better philosophy for the type of work I do every day.

Everything beyond how I approach solving problems is really just non-important. I make lots of notes, but I’m not a compulsive note organizer. I don’t have any system for keeping track of what I’m working on beyond a simple list of items in a spiral notebook that I cross off and scratch away at while I work. Hate to disappoint people, but I try to keep it very simple. Whenever I veer off into the land of Complex Task Tracking, I spend more time tracking tasks than doing them. Keep it simple, keep it something I can use each day and every day.

So, that’s my approach to personal project management:

• Be professional since you are, you know, being paid to do it.
• Keep your solutions simple
• Adopt organizational practices you can follow every day.
• Try and do your best work whenever you can, but understand when you are not at your best