But that begs the question, what does making an impact mean?

Making an impact.

It's coming out the door - swinging. So much of a developers role, especially in a start up, is determined by their first 3 days. Day 1, yes, come in, settle down, welcome aboard. Day 2, start asking all of the questions you had from day 1, and for heavens sake, do something besides look busy.

Day 3, you better have your shit together, and you should be swinging for the fences.

Don't ask for something to do, demand a project. And while you're doing, don't ask questions the very second you think you don't know something.

Look for the answer first.

It's this mentality that I find so damn frustrating - all of the answers should be in the code base. Run a damn grep on your project base, and find an answer. There's no excuse for any mid, to upper mid level programmer to be asking stupid questions. By stupid question, I'm refering to in the inabilty to traverse the code base in search of functions, methods, answers.

Make an impact, 3 days.

So here you go, my quick tip on what you really want to know about mod_rewrite.

If you want an actual explanation of what is going on here it's at the bottom.

Solution 1:

File: .htaccess

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+) /index.php [L]

File: index.php

$urlArray = explode("/",$_SERVER['REQUEST_URI']);

array_shift($urlArray); // Gets rid of the blank first param.

Now you have an array with all of your parts, and you can map them accordingly.

Solution 1.a (more elegant):
File: .htaccess

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

That version just checks to make sure the module is installed.

Solution 2:
If you have just a couple of pages that you want to look prettier:

File: .htaccess

Options +FollowSymLinks
RewriteEngine on
RewriteRule ^home$ index.php
RewriteRule ^about$ about.php

And you just keep adding RewriteRule's for each page. This is really only helpful when you just have a set of static looking pages for a site.

Explanation:

Options +FollowSymLinks

Tells Apache to follow sym links (usually on anyways...)

RewriteEngine on

Tells apache to turn on the RewriteEngine for this folder

RewriteCond %{REQUEST_FILENAME} !-f

Read this as: Condtion, If the file we're requesting is not a file...

RewriteCond %{REQUEST_FILENAME} !-d

Read this as: Condtion, If the file we're requesting is not a directory...

RewriteRule . /index.php [L]

Then Rewrite this url to index.php ([L] forces it to be the last redirect)

Too often I run into reviewing or helping a "professional" developer, and I can't help but mutter "you're doing it wrong..."

I feel the most important attribute that separates one developer from another is when they write for usability and maintainability.

So let's take a look at some extremely simple steps you can take to make your project's code more flexible.

1. For the love of all that there is, seperate your header and footer files. Yes, I'm still seeing this happen, often. All content that is above your generated page needs to go into a header file, and all the content below it into a footer file. So when you need to modify one line, you do it only once.

<?php
require_once(dirname(__FILE__).'/includes/header.php');
?>

<?php
	// script runs
?>


<?php
require_once(dirname(__FILE__).'/includes/footer.php');
?>

2. Create a function to generate your navigation. And when I say generate, I mean you give it some flexibility as well. This can be done even with the smallest of sites. Example:

<?php
$site_pages = array();
$site_pages[] = array('text' => 'home', 'link' => 'home.php');
$site_pages[] = array('text' => 'about', 'link' => 'about.php');
$site_pages[] = array('text' => 'partner', 'link' => 'http://www.example.domain.com/');

function buildNav($links)
{
	$output = '';
	foreach($links as $page)
	{
		$output .= "<a href=\"{$page['link']}\" title=\"{$page['text']}\">{$page['text']}</a>\n";
	}
 	return $output;
}
?>

The example above could easily be modified to allow optional values to the array, like 'enabled' => false to turn off a link. Or you could define a link "template", and use str_replace() to substitute values.

This means if you, or the customer (with any know how) can quickly update the links at any time. For more advanced sites/projects this can obviously become more complicated, but it saves even more time.

3. If you're not going to use OOP, at least use functions. Any common task or specific sequence should be placed in it's own function. An example would be our navigation function from #2. Another example would be running a query for a specific item. If you ever need to modify your table structure you'll regret having to hunt down all of your inline queries.

4. When you create 'admin' features, take the 5 minutes to create a function that actually checks if the person accessing that "super hidden" directory filled with scripts that just accept anything.

I've seen this happen even on large global community sites.

Some developers will stuff their admin scripts in a folder such as /admin/, and just assume that if data is posted there then it's ok.

The least you should do is place a session check, and place it in a function.

<?php
function isAdmin()
{
	if(!isset($_SESSION['user_name']) || !isset($_SESSION['user_id']))
	{
		return false;
	}
	else
	{
		$sql = "SELECT COUNT(*) as cnt FROM user_table WHERE user_id = ".intval($_SESSION['user_id']);
		// do the query, check it, etc.
		return true;
	}
}
?>

Then when it comes time to run your script, simply:

<?php
if(isAdmin() === false)
{
	die('Log back in');
}
?>

5. Create a wrapper for handling escape strings. If you're not using a database class (like PDO) to handle this, you'll need to do this.

Just assume that your client could have their PHP configuration change, or they change hosts, or any possible combination of changes take place.

Create a simple wrapper that will check of magic quotes, and escape for your database insert.

<?php
function cleanString($input)
{
	if(get_magic_quotes_gpc())
	{
		$input = stripslashes($input);
	}
	$output = mysql_real_escape_string(trim($input));

	return $output;
}
?>

6. Create a configuration file so you can update common yet critical variables. An example of this would be paths. Your system quickly gains adaptability if you just create a defines.php file, and place in there your simple variables.

The overall approach you should have to any project you take is that you should use an establish tool chain you have developed. It doesn't take much time or effort to create a simple set of classes that can handle just about any thing you need to create. If you wish to use functions, you can do the same. The idea is that you write once, and write it in such a manner that you can tweak it later on.

I've seen people respond with some seriously incorrect solutions, such as 'Simply load all of the results into an array and only show X amount' or 'Simple run another query without the LIMIT clause and count those rows.'

Those two, common, solutions are sadly not the best solution.

Read on to discover my solution.

Take for example the following query:

$sql = "SELECT id as id, name as name, full_title as title FROM articles ORDER BY id LIMIT 0,10";

Now, that looks all fine and dandy, you have probably used something very similar to that query many times. Now, say we want to actually show how many articles we have in our database?

We would simply change that query to:


$sql = "SELECT SQL_CALC_FOUND_ROWS id as id, name as name, full_title as title FROM articles ORDER BY id LIMIT 0,10";
$get = mysql_query($sql) or die(mysql_error());
$sql_2 = "SELECT FOUND_ROWS();";
$found_rows = mysql_query($sql_2) or die(mysql_error());


Now yes, we're running two queries, but we're not actually queries against any rows. So therefore, this solution is more elegant and ultimately more important, it's not attempting to scan any tables for data.

So next time you're looking to do a quick and pagination script, go ahead and try this technique out.

Interesting... so, if so many web devs and IT personnel have such a problem with problem solving, perhaps they're just not thinking? Let's explore some of the problems I've seen people encounter, and how I was baffled they lacked the problem solving skills to complete their tasks.

All too often, a situation will appear in just one or two flavors. One being, "Hey, this should be working but it's not..." or, "Hey, I'm stuck." Sometimes you get the nice and juicy combo. But, that being said, let's explore how I most commonly find myself approaching these two generic scenarios.

Number one, "Hey, this should be working but it's not..."

Whenever you get to this point, that usually means a couple things:

1. I have a pretty good idea on what should be happening
2. I know how it should be done
3. I've already solved this problem before, but this time it doesn't seem to be working

Number 3 is always the worst, because as a programmer, you always think back to the last time you faced a similar problem, and basically copy the way you fixed it before. If that is the case, examine what's different this time... versions, updates, different variables, etc etc, these all have an impact.

And what it really comes down to, is back tracking all of your steps.

• Did I upload the latest version of the PHP script?
  • And if so, are the changes reflected on the server side?
• Has someone else made changes to the files in use?
• Have a double checked the process against my flow charts?
• Have I tried basic debugging?
  • This means, rather briefly:
    • Echo out the variables BEFORE they're passed or referenced
    • AND AFTER they are passed or referenced.
    • Have I done a var_dump()
    • Have I turned on error_reporting(E_ALL);
    • Have I checked my error_log
    • Have I checked my mysql_error();

If you go through a simple list like that in your mind, you can quickly determine where you're missing a step.

And please, for the love of all that is holy, please, don't be afraid to TRY something even if you're not sure it'll work. You should take the basic steps to plot out your thoughts before you begin to code. For me, that usually means getting out some paper and a pen, and sketch out my idea with some notes.

Then I begin to code.

If I ever get lost in this new idea of mine, I refer to my original plan. If I realize then that my original plan was FUBAR, I simply make the adjustments to my sketch, and keep on going.

I feel that most web developers somehow feel that they can just jump straight into a project without any planning. It simply doesn't happen. All "great" projects, they start with a little planning. Sure, maybe they didn't have a road map, version control, diagrams, database designs, ticketing systems, et cetera, but they at least had an idea. And I guarantee that idea was at least written down in pseudo code.

Again, the idea here is that you HAVE a plan, and you know how things should work, so stick to your plan. You run into the problem of "It should work but it's not" when you've altered a step somewhere. Check your debugs, check your error logs, check your plan. Rinse repeat until you go mad. And don't be afraid to ask for some fresh eyes on the problem.

Number Two, "I'm stuck."

This comes down to just general programming knowledge. Or rather, how well you understand programming logic. I will often tell people, any one can be a programmer; in fact, everyone is a programmer. Programming is just solving a problem with at last one solution. You do this by breaking it down.

Identify the problem - What do I need to accomplish?
Determine the order - What needs to happen to solve this problem?
How do I apply my solution - What's my plan of action?

Let's take for example, the problem of creating an E-Mail list manager.

Identifying the problem - I know what the solution is -- an email list manager. That's my solution, now what's the problem?  Ok, this e-mail list manager is going to have a set of emails that it sends updates to everyone month. So... the problem is I need to find out how and where the e-mail addresses are stored, and I need to create a way for them to automatically be sent.

Determine the order - Well, I kind of already figured that out. I need to:

1. Get the E-Mail Address
   1. Make sure it's valid
   2. Make sure they are opted in
2. Add that Validated E-Mail address to the 'Send To' array
3. Create the body of my E-Mail
   1. One for Plain Text
   2. One for HTML
4. Apply any templating system that may be needed
5. Do a foreach() on the 'Send To' array
   1. Then send the emails

How do I apply my solution - Well, I'm going to need a CRON script that will run once a month. I will need to create a debugging / status message system so that I can record how many e-mails got sent out, and on what date, and to whom. It's pretty straight forward from there. Create the PHP script, be sure to apply the CLI items, and boom. Start.

What I'm trying to get across here, is that you need to approach things not as strictly code, but as a single thought. This is what I want, this is how I do it.

When you're running a program, you're not just running code, you're running someone's thoughts.  That's the beauty in programming, it's not just about the code, it's about someone else getting to see into your mind.