Given Pogue’s large following, I was disappointed by the advice he gave.

A secure password on a laptop isn’t to keep semi-trusted people off of it. It’s to keep it protected in the event that the hard drive is lost. Arguably, the drive could be removed and read without booting it, removing all password protection, but a good password combined with disk encryption can help protect data from theft.

Pogue argues that he doesn’t need a password for security, but any information that is stored on file servers or worse, in his keychain, is accessible with that simple password he is using. Failing to have a secure password not only places his data at risk, but the data of those he might know or work with.

Even if gaining physical access (e.g. finding the computer or stealing it) would grant a person a huge advantage, this is not an excuse to make the password so incredibly simple. And for one of the most well-known technology columnists to suggest otherwise to his 444,666 followers is negligent, bordering on criminal.

Starting June 22nd, I’ll be working for Applied Security. I’ve learned a lot at The Bivings Group, and worked on a lot of great projects, including The Pickens Plan. I’ll miss the friends I made, but I’m glad that I’ll be able to see them again at the developer’s group meetings and conferences.

Good luck to the folks at The Bivings Group. See you soon.

This afternoon, while hanging out in a lesser known channel, I was kicked out for no reason besides the whim of the operator, Derick Rethans. No warning, no rude comment on my part, just a joke followed by a kick. Alison Lunde was also kicked for a seemingly bogus reason. Another person was banned.

How could this be, two weeks after the “community conference,” which Derick himself attended?

I was furious. I felt betrayed, violated, attacked personally for something that shouldn’t have happened. I hadn’t been kicked out of an IRC channel since before I was a teenager; this was a personal insult and by God, I was ready to fight. I talked to a number of my friends in the PHP community and told them that this slight was beyond insulting; I was going to tear Derick a new one on my blog and wash my hands of the community forever. After all, everyone in the channel seemed to support this decision, right? They were all still there, hanging out, perhaps hoping they wouldn’t be next.

But a few hours went by, and a few things started to happen. First, a number of people in the community told me that leaving the community would hurt the community overall. Others told me they were beside themselves at Derick’s action, and wouldn’t be participating in any “elite” channels. I got a number of supportive emails. A number of people said “well if we can’t be a part of that channel, we’ll start our own” and did just that. Not to be exclusive – just to reduce the noise level.

As time went on I realized that the community really is larger than any one person. Even when one person does something inconsiderate or rude, that doesn’t and shouldn’t define the community. I was really ready to let Derick have it, to walk away, and to never be a part of the community ever again. But no one person defines the community, and no one person can shape it, no matter who they are. That’s the point of the PHP community.

Instead I’ll practice some forgiveness. Derick, you’re welcome in any channel I’m in, any time. Xdebug is fantastic and your book on dates and times is perhaps the preeminent work on the topic. Your contributions to the core of PHP and its documentation are unmatched by anyone, and with 130 presentations to your name, you certainly are accomplished. You’re a part of the community, and I welcome you.

For those wondering how to join the community, it’s easy. Show up in IRC, or come to a conference. Find your users group in your area, or join one of PHP’s many project mailing lists. If you need direction, Elizabeth Smith (@auroraeosrose) always has direction on work that needs to be done in the community. Dive in, get involved, don’t be a jerk and meet people. Put on a thick skin, watch out for toes, put on your work clothes and get involved.

Tell them I sent you.

Picture this: you’ve got developers of all levels, working in the same room. They’ve been tasked with working on various open source projects. Only in PHP do you see expert level developers like Eli White, Matthew Turland and Sara Golemon teaching more inexperienced developers (like myself!)

Also in the PHP community: Sara Goleman was having a debate with a younger programmer who insisted that for loops were slower than while and do-while loops. Upon examining the source she discovered that in fact it was wrong – and she promised to look into it. You won’t get that in the Rails community.

The best thing about conferences is the community around them. Non-assuming giants in code and contributions work alongside newbie developers to solve problems and discuss important issues. People are willing to teach and others are eager to learn, making the PHP community grow.

Eli White knocked one out of the park with “Highly Scalable Web Applications” while Wez Furlong did a great job with “Getting It Done.” Liz Smith rocked the house with “SPL To The Rescue,” a talk that was so amazing it was being talked about at the cocktail party that night.

Off to dinner, I had a great conversation with Snipe, and then we went to the cocktail party where we heard presentations of twenty slides, twenty seconds each. A great “first day” (second for those who came to the tutorials) at php|tek.

Both tutorials were great, with the Subversion tutorial being the more useful of the two for myself. Afterwards we all went out for some deep dish Chicago-style pizza which is an experience in itself. Deep dish Chicago piza is a pizza with a semi-thick crust and about two inches of cheese. The sauce is placed on top of the pizza (rather than between the crust and the cheese) to keep the cheese from drying out. It’s truly an experience.

Today starts the formal conference, and we’ll have some great sessions by Eli White, Chris Shiflett, Elizabeth Smith and others. I can’t wait!

Every day I’ll be blogging, tweeting and generally writing about how the conference is going. It will be fresh, fast, and relevant.

Also, in conjunction with John Bafford and my company, The Bivings Group, we’ve set up an auto-updating php|tek Twitter feed at http://twitter.bivings.com/. Note: Internet Explorer doesn’t work 100% well with this site, but Firefox, Chrome and Safari work perfectly.

So come and join us, in person, on Twitter, online. We’ll see you there!

Remember, these are licensed under the Creative Commons license: http://creativecommons.org/licenses/by-nc-sa/3.0/ or compatible license such as GPL. Please attribute me and don’t sell this content!

Download the slides here: Wordpress Caching

To that end, here are five things that I believe commenting is and five things that commenting is not.

5 Things Commenting IS NOT:

1. Commenting is not an excuse for bad code. Bad code is bad code, whether you comment it or not. If you’re going to write bade code, please stop and instead learn how to write good code. Good comments won’t make bad code any better. So commenting is not a crutch for bad code.
2. Commenting doesn’t eliminate refactoring. A lot of the argument seemed to focus on refactoring code. Refactoring is good. Commenting is certainly not an excuse to abandon refactoring, assuming that someone who comes along next can just read the comments and understand. Comments cannot be used to try and remove the need for legitimate refactoring.
3. Commenting is not for explaining every little thing about your code. Commenting is not for explaining what an if-else statement does. It’s for explaining WHY you have an if-else statement there. Good code should be commented only to explain the reasons behind something, not how something works. Programmers are logical, and they can figure it out.
4. Commenting is not for justifying poor decisions. Bad code is second only to bad decisions. Architect your application well, rather than writing comments explaining why you didn’t.
5. Commenting is not for documentation. This might get me into a bit of trouble, but listen closely: despite the fact that great applications exist (like phpDocumentor) commenting is not the same thing as documenting. Documenting involves discussing the signature, the return value, and the purpose. Commenting is leaving little notes about what you’re doing and why.

5 Things Commenting IS:

1. Commenting is for leaving yourself notes. I often leave myself a note in the code. A to-do. A warning. A “hey this is not right but you didn’t have time to fix it this time around.” These are important. Code is always a work in progress, even if it’s production code (that’s why there’s versions of something – you’re going to eventually make it better).
2. Commenting is for reminding yourself of decisions. If you’ve spent any time in programming you’ve come back to some code you wrote and gone “why did I do that?” Then you spend an hour trying to refactor it only to discover that it was right the first time, because you spent the same hour doing this a week ago. Why? Because there might be only one logical way to do something. Save yourself the time and write a reminder.
3. Commenting is for cluing others to the decisions you made. If you’ve ever been asked to implement a relatively simple feature in a fairly complicated and complete application that you’ve never worked with before, you know the struggle it is to not introduce a bug. Comments can clue you in to why a developer made a particular decision (”a dependency over in X function needs this”) and avoid new bugs (or rewriting good code because you think it’s bad!).
4. Commenting is for highlighting your weaknesses for future correcton. Lots of times you may not have a great solution but you implement something that’s going to need fixing later. Rather than leaving no comments and having the next developer think you’re stupid, you can give them an idea that you know it’s not the best answer. You also can immediately highlight weak spots that you identified when you wrote it the first time.
5. Commenting is for passing messages between the generations. Keith Casey reminded us in the last conversation that anywhere from 50% to 90% of the software lifecycle is maintaining that code once you’ve written it, and most of the time you’re not going to be the one to maintain it. Comments allow you to pass notes between your generation and the future. If you’re maintaining a software package, or developing a new version, you can leave comments to warn about some ridiculously odd backwards compatibility hack you wrote. You can use comments to alert them to a function that supports a legacy operation. You can leave comments to tell the future programmers important things about your code.

Not doing these things is the accrual of technical debt in the way I described it last week. Because not commenting for these reasons makes your code harder to understand and your application more difficult to maintain, incurring an “interest payment” in order to gain understanding.

Commenting should be used with care. Commenting is not a crutch, and it’s not a fix for bad programming. But when used effectively, it can and does provide a powerful way to communicate ideas, without bloating your code, as some have suggested. And though each programmer’s style might be different, and each shop might hold a different set of rules, the one theme that should ring true is that commenting should be used for helping programmers. That’s what it’s there for.

Acknowledgments for this blog entry really belong to the whole community. Your comments, suggestions, criticisms, and ideas formed the five points for each, and though I’m the one who assembled them in one place, it was truly a community effort.

Some people take a different view of commenting than others. Most recently, Eli White wrote an article called “Commenting on Commenting” in which he argued for commenting virtually every single line of code. He talked about working for a company where they stripped the code out and turned the comments into line-by-line documentation. But commenting to me is important for a different reason:

Failure to comment is simply the accrual of technical debt.

Technical debt is the cost of fixing things that you didn’t fix at a particular point because it would have been too costly. This cost can be in time or money, but represents additional effort that must be made. How does this apply to commenting?

Assume it takes one additional hour per file to write clear, complete comments. To save that hour now, you do not comment your code (before or after you write it), delivering the product faster. However, the next developer to come along and work on that code is going to have to learn about it. Assuming that it would take them an hour to learn about it with comments, and four hours to learn about it without comments, the two hours you saved by not commenting (the hour to comment, and the hour to read them) has cost you four hours of a developer relearning your code, for a total cost of 2 extra hours.

This clearly isn’t worth it.

Undoubtedly somewhere out there someone is going to say something like “wait a minute, Brandon! What if it takes less time?” If it actually takes less time, fine. You got lucky. Think back on your prior experiences, though. The cleanest code you’ve ever seen written by somebody else – how long did it take you to learn? The problem comes not because we write bad code or are sloppy in our design. It comes because we’re human beings and we have to understand the logic before we can modify it. It’s the same reason a doctor who specializes in the heart must understand the other body systems before he can do surgery – even if he never treats any other organs, he must understand how they work together. In the same way, a programmer must understand the logic behind code before they can modify it, and failure to adequately justify your architecture incurs a cost.

This myth of self-documenting code needs to be squashed once and for all. Commenting is important, and unless your code does nothing other than display “Hello World!” it’s going to need some explanation.

Marco Tabini, a man I deeply respect, posted a rebuttal to my argument here. I recommend you read it, as he made some really great points.

The five I picked have been influential in my development as a programmer, and I owe each of them a debt of gratitude. I wanted to highlight them, as they’re A-list members of the PHP community and people everyone should know. So, in no particular order…

Matthew Turland (@elazar)
Matthew Turland is the Researcher. Matt always has an article or blog entry about something I’m thinking about, and he’s known among his peers as being someone who carefully researches things, and writes and works carefully. I’ve learned from Matt that there’s probably someone else who’s already thought about my problem, and that a little bit of good research goes a long way. As Keith Casey put it, “Matt is meticulous, precise, and always working to understand it better.”

As a community member, Matt has contributed Phergie, an IRC bot that runs around on Freenode in many of the PHP channels. His contribution is certainly appreciated…if not painful (I’ve been “popped” many-a-time by that bot ;-)).

Cal Evans (@calevans)
When it comes to encouragement, Cal Evans has it nailed. Cal is the Encourager. Cal always has a friendly word and has always encouraged me. From introducing me to colleagues to talking about ideas and projects, I can count on Cal for a friendly smile and a word of encouragement. Cal’s blog is always full of small bits of wisdom and I really like that he’s active in the community. Cal was best known as Zend’s Community Guy before he moved over to iBuildings, where we miss him dearly (since he’s in the Netherlands).

Cal really embodies the idea that you catch more flies with honey rather than vinegar. I’ve learned from him that a dollop of encouragement goes miles farther than a pound of anger or yelling. His posts on management style are particularly useful for the day when I’ll have to lead a team. Cal’s an invaluable member of the PHP community.

Keith Casey (@caseysoftware)
From my own personal experience, Keith Casey is the Enforcer. Keith never hesitates to smack me around when I need it, and he doesn’t put up with much guff. This is a good thing, because I’m known to be a bit of a pain in the ass. But not with Keith. He’s smart, sees through crap, doesn’t put up with much, is willing to tell it like it is, has unimpeachable honesty and integrity, and is above reproach. The community is better off because Keith is in it, and I’m a better programmer because I know him.

Perhaps the most important aspect is that Keith doesn’t seem to hold a grudge. The same guy who smacks me around also drinks alongside me at the monthly Beverage Subgroups and is still a lot of fun to be with. Opinionated, honest, and usually right, Keith is one of my most valued influences.

Eli White (@eliw)
If you ever see PHP code that has 10,000 lines of commenting and runs thousands of loops a second without breaking, it was probably done by PHP’s MacGyver, Eli White. Eli’s time as an employee of Digg gave him a look at systems many of us will never get, and the opportunity to solve problems most of us will never experience. But it also made Eli into one of PHP’s pre-eminent developers. As Eli will probably tell you, we’ve had many a debate where I’ve said something as a blanket statement and he’s corrected me – and he’s almost always 100% right.

Eli has taught me that there’s a lot you can do with PHP if you’re creative enough to figure it out. And that there sometimes is an exception to a well established rule (e.g. running MySQL queries inside a loop). Without him, I don’t think I’d have tried some of the things that I have tried, and I know that I’d be a worse off developer. Eli’s contribution has been invaluable.

Barry Austin (@barryaustin)
My experience with Barry Austin has led me to see him as being Wise. Barry always presents a well-thought response to any query, thinks carefully, and has excellent advice. When you ask Barry something, he’s going to think about it before he gives you his answer. He’s got lots of experience in security, managing teams, and working with people, and his thoughtful responses always reflect his experience. Barry has taught me the value of careful contemplation, and I deeply respect this about him. I know that I can ask Barry about anything and the response he’ll give me will be well considered and match the wisdom I have come to know from him.

As a community member, Barry is an important voice for strategy and direction. The DC PHP developer’s group is better because of Barry, and anyone that knows him would agree.

So who are your strongest influences? These are mine, but everyone has people that influence them . While I’m not going to try and start a meme, whereby these five now have to write about it, thanking people never goes out of style. So take some time and thank those that matter to you, that have invested in your career, that have mentored you.

Happy Friday.

Technical people seem particularly bad at marketing effectively. I think this is because we’re fact-oriented, focused on the features and neat ideas our products include. We’ll spend pages and pages talking about the cool things that our tool or application can do. And then we’ll wonder why our client didn’t buy it.

Why do we do this? Because we forget that marketing isn’t about features it’s about meeting needs.

Consider if you were going to market a pen. Would you talk about the features of the pen – it’s ability to write upside down, it’s ability to write in black, and the fact that it would last for three months? No, you’d talk about how good it feels in your hand, how great it makes your pocket look, and how writing with that pen is going to get you a promotion. Why? Because features don’t sell products – meeting needs do. In this case, your marketing would meet the need of comfort, security, and exclusivity.

Hierarchy of Needs

These principles are extremely important, but often overlooked by technical individuals. The person isn’t likely to buy just because our product has great features. It has to meet a need that they have. It has to fulfill some deep seeded concern – whether it be for job security, appreciation of others, or something similar. This isn’t license to be dishonest – don’t promise that your application will do things it cannot do or fulfill needs that it will not – but your marketing should be geared towards the hierarchy of needs.

Good luck!

The modern age has brought us lots of new ways to take a growing site and scale it. From Amazon Web Services to cloud computing and grid computing, to Mosso and Akamai, there are lots of options we should consider. This article won’t make a recommendation as to which you should pick; it will simply discuss what each service has to offer and leave it up to you.

The Old Fashioned Way: New Hardware
Your first option is the old standby, buying new hardware. This may be a viable and necessary option. For example, if the site is a local intranet, you may need to invest in hardware because you want to maintain the servers in house. You may also determine that your site needs new hardware regardless of how you scale in the cloud or on the grid. Adding your own hardware is probably your most expensive option, however, and requires a massive capital investment on your part. Still, it is an option that you may want to consider.

The New-Fashioned Way: Dedicated Hosted Servers
Joseph Scott pointed out a deficiency with this article, and that is that I failed to discuss dedicated hosted servers. I am correcting this deficiency, after his comment was posted. It is possible to rent dedicated servers that are hosted elsewhere. This has the benefit of the dedicated servers purchased above, but the added benefit of not having the capital expense associated with buying a new server. Many companies exist that do this, including two of the largest, Rackspace and MediaTemple.

A subset of the dedicated hosted server is the dedicated virtual server, which may offer the same performance for a bit less money. Rackspace’s subsidiary, Slicehost provides this sort of service, and hosts BrandonSavage.net with no trouble.

Dedicated hosted and virtual servers are great because you don’t have to worry about uptime (that’s handled for you) and, in many cases, the software is installed for you by the company that owns the server. Still you have full control over the system, with the ability to configure it, and the server is usually a dedicated box reserved just for you, meaning you get the full benefit of the processor, RAM, and storage. And if something goes wrong at 3 am it’s someone else’s responsibility to fix it – and you can usually call them for help.

There are some drawbacks to virtual or dedicated servers. Namely, in the long run it can cost more to host than to own your own servers, especially if you already have a data center (though when you factor in the costs of renting data center space, connecting the servers and paying a systems administrator this might not be true). Also, getting a second server set up can sometimes take some time – I remember a particular example where a company I worked for had a fast growing site that needed to scale immediately and was told by one company that it would take seven days to install a load balancer. “Seven days!” they exclaimed. “We need this in seven HOURS.” (The company was ultimately able to work with our timeframe.)

Using The Cloud: Amazon Web Services
Amazon has a number of new web services that allow you to create virtual servers almost on command. These servers can be started up and shut down at will, meaning they make it easier to scale up and down as needed. Amazon charges by the hour for these services, as well as by how much data you’re using and how much space you need. You can check out the full compliment of Amazon services by going to their website, http://aws.amazon.com/. Amazon offers virtual servers, a data store, and hosting in both the United States and Europe (for an additional charge).

The benefit of using Amazon’s web services is that you can scale up more quickly, your data is less prone to hardware failure, and you have the ability to create instances of servers on a whim while paying only for the time you actually use. The drawbacks are that your servers are hosted by someone else; the services can also be expensive if you have a high traffic site, and the servers do have some time to start up meaning you have to monitor load and anticipate additional needs. Also, Amazon does not yet provide an automatic load balancer, so you’ll still have to add new servers to your pool.

Automated Scaling: Services Like Mosso
It’s becoming popular now to use services that are capable of scaling on demand – that is, they can accept more traffic and allocate more resources to your site as they are needed. The obvious benefit is that your site will always be able to handle new traffic, but the drawback is that these services are somewhat expensive.

Mosso is one service that does this. They advertise that you’ll always have space, bandwidth and processors to handle traffic. Mosso is owned by Rackspace, who has a fantastic reputation amongst the development community and is well trusted. Some users at the DC PHP Developer’s Group reported that Mosso has some latency issues, however, from the database and PHP servers being different from the web servers, so this may be a concern to some users. Still, this option provides the ability to scale quickly and without monitoring.

Delivering Content: CDNs
Not using a Content Delivery Network (CDN)? Why not? CDNs are great for many things: delivering content that never changes (static pages), reducing server load, and reducing latency for people who are located around the world.

In short, a CDN is a service that distributes your content and delivers it to individuals based on their location. So someone in Asia sees your content on a server based in Asia, while someone in Brooklyn sees it on a server based in Upstate New York. CDNs also allow you to send your content to their servers to be cached, reducing the number of hits to your servers.

Akamai is probably one of the biggest CDNs around the world. Their rates are reasonable, and they have lots of servers. Some of their clients include Google and Myspace, so they’re well known and reliable. There are others, which you can find with a Google search.

The benefits of a CDN are that your files are delivered faster to people seeking your site and your traffic to your actual servers is reduced, as the CDN takes on much of the processing power required to serve pages. The drawback is that dynamic pages cannot be delivered very effectively by a CDN, meaning that for dynamic pages you’ll still have to send people to your site, for the most part. Still, in terms of delivering images, static content, and files, CDNs can be reliable and reasonable for reducing the load on your servers.

Conclusion
This is a lot of information to digest, and there’s a lot of different options out there for you to consider. You should pick the one (or combination of the ones) that suit your application and needs the best. Don’t try and implement everything, as you’ll never succeed; instead, study carefully, and invest well. You’ll be on your way to scaling your site in no time.

One thing that strikes me as odd is the number of people who send cover letters riddled with errors.

For example:

dear sirs,

Im interested in applying for the position your advertising. I have 5 years experience developing applications. I attach a copy of my resume for your consideration.

Thanks.

Two things to note: first, this was made up, based on a common set of mistakes. Second, I’m presuming for the moment that the developer applying is a native English speaker and not someone from another country.

I’ve heard the argument that developers aren’t necessarily great writers, nor do they need to be. But I reject that argument for two reasons. First, email communications are critical to business and yes, though the message was communicated effectively, the message is still riddled with errors.

Second, poor English reflects on your programming abilities.

How so?

Programming languages are not that different from actual languages: each has a set of syntactical rules, a set of conventions, a set of best practices, and a way of doing things that’s specific to that language.

If you haven’t taken the time to learn how to communicate in your native language, what makes me think you’re going to be a capable programmer?

Developers, as you prepare cover letters and resumes, please read through them and have others do so, as well. Syntax is as important in English as it is in PHP; knowing the difference between your and you’re or there/their/they’re does matter, as does proper form in a formal letter (even if it’s being sent through email). Don’t jeopardize your chances by writing a crappy cover letter or resume.

Turns out that it’s great they didn’t ask for a code sample.

Here’s the actual code from the page that displays the entries…

<?php
session_start();
$path = getcwd();
$path = $path.'/includes/';

$page = 'entry';

include_once($path.'header.inc.php');
include_once($path.'dblogin.inc.php');
include_once($path.'functions.inc.php');
echo '<script type="text/javascript" src="ajax.js"></script>';
echo '<script type="text/javascript" src="motionpack.js"></script>';

if(isset($_SESSION['admin']) AND $_SESSION['admin'] > 0)
	{
	echo '<script type="text/javascript" src="admin_ajax.js"></script>';
	}

if(!isset($_GET['entryid']) OR $_GET['entryid'] == false) { echo $err_1; include_once($path.'footer.inc.php'); die; }

if(isset($_SESSION['loggedin'])) { $permissions = $_SESSION['permissions']; } ELSE { $permissions = '1'; }
$entryid = (int)$_GET['entryid'];

$query = mysql_query("SELECT * FROM bb_entry WHERE id = '$entryid' AND permissions <= '$permissions'");

if(mysql_numrows($query) == 0) { 

		echo '<p align="center"><font color="#FF0000"><b>Error!</b> You must log in before reading this entry.</font></p>';

		echo '<form method=post action="login.php">';
		echo '<p align="center"><b>Username:</b> <input type=text name=username size=14 maxlength=16></p>';
		echo '<p align="center"><b>Password:</b> <input type=password name=password size=14 maxlength=16></p>';
		echo '<p align=center><input type=submit name=submit value=Submit></p>';
		echo '<p align="center" class="menu"><a href="forgot_password.php">Forgot Your Password?</a></p></form>';

include_once($path.'footer.inc.php'); die; }

if(empty($_SESSION['admin']) OR $_SESSION['admin'] != 1) {
mysql_query("UPDATE bb_count SET count = count + 1 WHERE id = '$entryid'"); }

if(isset($_SESSION['username']) AND $_SESSION['admin'] != 1) { $user = $_SESSION['username'];
if(mysql_numrows(mysql_query("SELECT entryid FROM bb_count_users WHERE user = '$user' AND entryid = '$entryid'")) == 0 AND isset($user))
	{
	mysql_query("INSERT INTO bb_count_users (user,entryid) VALUES ('$user','$entryid')");
	}}

if(isset($_SESSION['admin']) AND $_SESSION['admin'] == 1)
	{

	$raw_count = mysql_query("SELECT count FROM bb_count WHERE id = '$entryid'");
	$raw = mysql_result($raw_count,0,0);

	$string = '<p>[ <b>Raw Count:</b> '.$raw.' | <a href="seevisits.php?entryid='.$entryid.'">See All Data</a>] [ <a href="makeentry.php?entryid='.$entryid.'">Edit</a> | <a href="deleteentry.php?entryid=172">Delete</a> ]<p>';

	}
	ELSE
	{
	$string = false;
	}
?>

(This isn’t the entire file, as it would fill an entire 201 lines, but just a taste.)

I couldn’t believe this code. It was amazing to me that I wrote this! There are no functions, it’s completely procedural, and it’s a disaster.

But you know what? I learned something.

It helped me to realize how far I’ve come. It helped me to realize the improvements I’ve made. This was written in a time when I had no concept of objects, array or string functions, or even virtual hosts. That was a long time ago.

Take some time today and look at some of your old code. What can you learn from it? What does it tell you about the progress you’ve made and where you’re going? Relish in the old code, and the creativity it showed, and then remember how you felt when you wrote it. I know I’ll be doing the same thing.

Happy Friday!