Ever seen this in your production php_error.log?
[16-Dec-2013 10:50:44 America/Denver] Hello there [16-Dec-2013 10:50:44 America/Denver] ...starting loop [16-Dec-2013 10:50:44 America/Denver] stepping through 0 [16-Dec-2013 10:50:44 America/Denver] stepping through 1 [16-Dec-2013 10:50:44 America/Denver] stepping through 2 [16-Dec-2013 10:50:44 America/Denver] stepping through 3 [16-Dec-2013 10:50:44 America/Denver] stepping through 4 [16-Dec-2013 10:50:44 America/Denver] stepping through 5 [16-Dec-2013 10:50:44 America/Denver] ...done [16-Dec-2013 10:50:44 America/Denver] How in the world did we get here?
There’s one thing you can tell about the developer who wrote it – they don’t have a debugger up and running. Or maybe they do, it’s just too big of a hassle to fire it up and get it attached. And I am plenty guilty of this myself, having written my share of debugatory error_log statements over the years. Sometimes it’s just easier to add a trace, refresh, and tail the error_log.
Debuggers, at least those available for macs, are finicky beasts. They’re often difficult to setup, they’re a bit too assertive when you’re not actively debugging, and they don’t always work reliably. Compared with a debugger, error_log() is always there for you, seldom complains, and rarely sticks it’s nose in where it doesn’t belong. Why can’t a debugger be this way? I need to admit that nothing about what I’m going to say is ground breaking. There isn’t a new debugger out there that works better than anything before. There isn’t anything new in Mavericks that makes debugging easier. It’s just the fact that after 5 years of typing error_log(“Here I am”) over and over as my debugging solution, I’ve finally found a debugging setup that works without a lot of fuss. And that seems to be the key for me…in order to use it, it needs to come without a lot of fuss.
First, let’s talk about the elephant in the room… (more…)
One of my favorite parts of my job as a programmer is the ability to listen to music all day long. One day I might be in the mood for some chill indie rock and the next I’ll cue up some dubstep. I’ve even been known to declare some weeks as 90s R&B week. I still have a hard keeping the emotions in when I hear some good Boyz II Men. Music is incredibly inspiring, and speaks to us on a level much deeper than words. I find a good song can inject a surge of motivation that bubbles up from depths I was previously unaware of. Maybe that’s comes from the fact that I’m also a musician, but either way, motivation is good.
It’s a curious phenomenon, but I find that a lot of us in the engineering world are also musicians. If anyone can offer up some reading or research on why that is, I’d be interested in hearing some theories. (more…)
And why would you care? To be honest, I’m not really sure. But it’s fun to think about parallel lessons that can be learned from two dissimilar things, right? Contrary to how Hollywood portrays programmers (think dark rooms, Mountain Dew, weird glasses, frazzled hair), some of us do like to get out from behind our computers and have a little fun in the out of doors (ok, I’ll concede the Mountain Dew). During one of my recent trips to the river, I realized that I could become a better programmer if I simply applied some of my fly fishing principles to programming. …Ok, that may be a stretch. But it would be great if I could convince my employer that it was true. Maybe I could get paid for a day on the water :).
Match The Hatch
Most people don’t ponder the intellectual capacity of a fish, but they are actually pretty clever. They are wise to our schemes of tricking them into taking a bite of a tasty morsel attached to a line, pulling them to shore, flipping them into a net, taking their picture, applying the Nashville effect, and posting it to Instagram. But most of the bigger fish have been around long enough to get big for a reason. So one of the first principles of fly fishing is to match the hatch. This means that you have to be aware of what bugs the fish are currently snacking on, and use a fly that most resembles that bug. For example, if you use a fly resembling a grasshopper in early spring, you’ll likely get a lot of laughs from your fellow fisherman, and probably a few from the fish as well. Grasshoppers generally don’t show up until late summer, and the fish know it. So you have to be pretty selective in choosing your flies. You must consider the fish’s appetite, time of year, time of day, method of presentation, water temperature, what bugs are currently hatching, etc., etc.
Programming can be much the same. I work on custom software applications that are as varied as the day is long. The success of a project starts at the very beginning, starting with choosing the appropriate application framework. Some customers have specific requirements, and some don’t. We have a standard app stack that we use when there are no compelling factors specifying otherwise. But it seems like more often than not, we end up deviating from the standard stack because some other framework is a better fit for the application. We have to consider server architecture, preferred programming language, tools and libraries included in the framework that will speed development time. The right choice can make a big difference in the outcome of a project.
Tangles are the worst. There’s nothing more frustrating than driving a couple hours to the river, getting all geared up, casting a couple times, only to spend the next hour untangling a giant rat’s nest of line. For beginning fisherman, this can be a particular problem as their casting technique hasn’t been refined enough to consistently avoid knots. Knots are a lot easier to create than you think, and even a slight misstep in your cast can lead to a huge mess. The best thing you can do to avoid tangles is to immediately stop casting the minute you notice anything funny, and reset your line. A lot of us have the tendency to keep casting through it and hope the knots magically disappear, but they never do. They only get worse.
Sometimes programming goes the same way. When I set out to solve a problem in code, I’ll come up with a proposed solution, taking into account all the data I have at the time. The excitement builds as I get to the point of being able to test my implementation for the first time, only to find that it’s a huge fail. I’ve either forgotten a critical piece of data or just didn’t think of a certain use case than needs to be handled. If I’m not careful, I’ll continue morphing my original solution and bolting new things onto it to try and fix the shortcomings. This cycle iterates a couple more times, and I eventually end up with a tangled mess of code that makes no sense to me or anyone else who looks at it. The best thing in situations like this is to stop at the first sign of trouble and take another look at the solution as a whole. With the new knowledge gained from the first try, a completely different approach may be warranted. Don’t be afraid to consider something different altogether if the outcome will be a more solid solution in the end. Of course, there is rarely unlimited budget to continually go back to the drawing board, but often times a better solution also results in less code and less time to implement. Once the maintenance and bug fixing time is factored in, you’ll come out way ahead in the end.
Presentation is Key
I don’t consider myself to be a great fly fisherman, as I lack the appropriate touch during the presentation of the fly to the fish. It’s mostly a matter of practicing, but I have a tendency to thump the fly down on the water, scaring off any living thing within a 10′ radius. This is really where the beauty of fly fishing comes in, and it’s not a skill that is easily mastered. I do consider my brother to be a great fly fisherman. He’s been doing it a lot longer than me, and certainly has it down. He’ll lay the fly down on the water as gently as a feather. And as a result, he catches about 4 or 5 times more fish than I do. We can be fishing the exact same spot, and he’ll be pulling fish out one after another while I’m not even getting a strike. It’s a bit frustrating for me, but he’s definitely put a lot more effort into learning than I have.
I’ve observed a similar effect in programming. An elegant and beautiful UI goes a long way in covering the most egregious backend coding. It’s the first thing a client sees, and judgements happen quickly. I’m certainly not advocating a pretty UI at the expense of the backend. Rather, leave time and budget for an appropriate amount of UI polishing once the functional requirements have been met. In a lot of cases, engineers are purely practical, and a purely functional UI is where we stop. Not only that, but budget shortcomings usually end up nixing non-essentials, under which UI polishing usually falls. It certainly takes extra time and effort to create a polished and streamlined UI, but it’s worth it. It’s the face of the app, and you’ll end up catching a lot more clients if your portfolio is striking.
Image from LoozrBoy
In my last post, I talked about the benefits of going all SSL for a webapp. There were plenty of benefits, not the least of which was securing your users’ data. However, there still exists that one pesky drawback that prevents most of us from using SSL more often…performance.
There’s no denying that SSL has overhead. The handshaking that happens between a client and server requires 2 complete roundtrips to complete before HTTP can take over. For connections with a lot of latency, this can add up quickly. In the future, I’m sure we’ll see better performing security protocols, and the gap between secure and non-secure requests will be dramatically reduced. For now, we’re stuck with what’s available. So as developers, what can we do to reduce the impact all ssl webapps? Here are a few reminders:
Use Persistent Connections
Setting the Connection: keep-alive header will allow the browser to keep a connection open, bypassing the SSL handshaking for subsequent requests. Given that the handshake consists of 2 full roundtrips, anytime this can be skipped without comprising security is good.
Allow infrequently changing content to be cached locally by the client. Use cache control headers wisely.
If you’ve got a bunch of small icons on your site, consider combining them into a single image sprite. Obviously, reducing 10 calls for images down to a single call will have a nice performance boost. Not only are you avoiding the SSL handshake, but you only endure the network latency once.
The processing power required to decrypt responses from the server depends on the size of the data to decrypt. The less data, the less time and effort is needed to decrypt it. Plus, you don’t have to send as much data over the wire. Win Win.
Use CDNs or Caching Proxies for Static Content
Offload static payload to other servers so your application server doesn’t have to waste CPU cycles. Technically, this falls under the category of reducing the work my server has to do, rather than reducing the overall work that has to be done. But shoot, if those CDNs will help us out, then all the better. If your application server doesn’t have to mess around with those pesky static files, then your app will be quicker to respond.
Keep in mind that unless your user base is geographically diverse, a CDN is probably overkill. You’ll have to put up with long TTLs while the changes propagate, with no apparent gain. In this case, a caching proxy is probably a better fit.
Again, this isn’t anything new. Although we’re talking about performance tuning within the context of an all SSL site, these really are just general webapp tuning principles. The name of the game is reducing requests, reducing data, and utlimately, reducing time.