First of all, to everyone who has commented asking for help: you probably have long since needed the answer to the questions that you have asked me, but I plan on answering them as soon as I can. I wish that I had been around to answer this stream of questions as they came in as that would have been much more helpful to you guys. Also, I plan on focusing another post or two on regular expressions and the redirection plugin as that seems to be where most of the questions are coming from.

Second of all, I’m not sure what I’m going to do with this blog. I’m pretty sure that I’m going to be moving most of the popular posts to my new blog (which will be mentioned in a post shortly) and then continuing to use this blog as a personal blog instead of a web development blog. I’m hoping to make the transition as seamless as possible, but bear with me as it occurs.

Third of all, I’m wondering if I still have any subscribers after this long break. So if you still subscribe, please leave a comment! I look forward to hearing from you.

Chances are that you won’t learn using only one of these methods – you’ll have to combine them to get anywhere. This list is mostly relevant to those who do not know PHP (but would want to learn it), but for those who already know it, try to think about how you first learned as you are reading this list.

Methods of learning

1. Classic tutorials

   Tutorials that I classify as “classic” tutorials are the ones that pretty much hold your hand as you first learn the language. They tell you what to do and why you’re doing it and then hope that you remember the reasons and remember how you did things. I’ll be talking more about resources that provide these classic tutorials in the future (I’ll be evaluating all of them to help decide which is the best), but for now check out W3Schools.

2. My tutorials (or similar)

   A few months ago, I tried providing my own tutorials to the community. They didn’t really get that much attention, so I eventually stopped, but a good amount of them already existed. My goal was to try to teach PHP by forcing coders to learn themselves. I don’t really find it that helpful to be told exactly what to do. It’s great when you’re trying to achieve something that is common, but what if you want to do something with PHP that doesn’t have a clear cut tutorial? Instead of providing how-tos, I provided people with a list of what they needed to achieve, and then expected people to search around and teach themselves how to get things done. Here’s a list of the tutorials and their solutions. Also, if anyone has used these tutorials, or wants more of them, please leave a comment!

3. Other non-specific resources

   Instead of using tutorials, you could just teach yourself using other resources. This method is like using my tutorials except you are deciding what you need to achieve on your own. You’re going out to the web and searching for what you need. The best resources here are Google and PHP’s homepage.

4. The assistance of others

   This is probably the least common as a single method but the most common when combined with other methods. Getting assistance from others is very helpful, especially if you have a specific problem. I’m thinking actually talking to them and getting help from them, so reading what others have written wouldn’t fall under this one.

The best method

The best method all depends on your personal learning styles. It also depends on your drive to learn the language and your need to apply the language to what you want to get done. If you are learning the language just to try to expand your knowledge, it might be harder to use the third method since you don’t really have anything that you want to achieve. If you have well defined goals that you want to achieve, you will definitely have the drive that you will need to learn the language using the third method.

Overall, the best method is a combination of all of the methods. Except for the last method, which should be placed wherever it is needed in the process, the different methods could be used in the order above. Actually, I learned using the methods in the order above. I started off using specific tutorials on W3Schools. After that, I started trying to do small tasks that my friend would give me. After I was fairly confident with my coding, I took on a larger project and just used Google or PHP.net whenever I needed something. At first, I was very dependent on these resources, but after a while I was fluent in the language.

If you don’t know PHP and you’re looking to learn it, how do you plan on learning it? If you already know PHP, how did you learn it? Also, if you can think of a method that isn’t on this list (I know that I can think of some), please share. I’m looking forward to hearing your thoughts!

Times to use this

As I said above, separating the back end logic from the front end markup is a great practice. I don’t always do this, though. Unless you’re using a template engine, such as Smarty, it isn’t always practical to separate the back end from the front end. You still should if the project is large enough, but if it isn’t it’s not worth it in my mind.

When I described my method of organization for most projects, I had a directly called ‘elements’ that contained all of the front end elements. The scripts in that folder still contain logic, though. I don’t use a template engine, so it’s impossible to have completely segregate the logic from the markup.

Integrating HTML

Instead, here’s a few ways to integrate HTML into your PHP logic while still keeping things clean.

Double quotes and braces

This is probably the method that I use most often. Here’s an example:

echo "<div>{$variableOne}</div>";
echo "<div class=\"class_one\">{$variableTwo}</div>";
echo "<div class=\"class_two\">{$variableThree} to {$variableFour}</div>";

I find that this is really clean and easy to scan. It’s easy to see the variables in the code since they all begin with {$ and end with }. I also use code highlighting, so that helps.

Single quotes and concatenation

This is another popular method. The speeds of this method and the previous have been debated, but I don’t think that it really matters. The difference is in nano seconds. If you really want to optimize things, there are a lot more changes that you could make that would have more of an effect than switching between single quotes and double quotes.

echo '<div>' . $variableOne . '</div>';
echo '<div class="class_one">' . $variableTwo . '</div>';
echo '<div class="class_two"> ' . $variableThree . ' to ' . $variableFour . '</div>';

An advantage of this method is that you don’t have to escape double quotes that may appear in HTML. I find this method harder to read than the previous, especially if there are short strings between variables. It’s hard to quickly tell the difference between $variableThree . ' to ' . $variableFour and $variableThree . 'to' . $variableFour, especially if you include spaces between the periods as I do.

Jump out of PHP

This method is most popular for large blocks of code. It can great really repetitive to just keep outputting HTML from PHP, so why not just write the HTML and then add in the PHP where necessary?

<div>
	<?php echo $variableOne; ?>
</div>
<div class="class_one">
	<?php echo $variableTwo; ?>
</div>
<div class="class_two">
	<?php echo $variableThree; ?> to <?php echo $variableFour; ?>
</div>

An advantage of this method is that it’s much easier to retain the indent structure of HTML. A disadvantage is that it can get repetitive to keep using to output variables. It’s possible to use the shorthand , but that may not work on all servers. It also doesn’t work as well if you have a lot of logic and conditional statements instead of just variables.

A combination of them all

The best choice is probably to just use all of these methods as needed. You should decide on whether you will use single quotes or double quotes and then be consistent with your decision. Then, jump out of PHP where needed and use single quotes or double quotes where needed. Here’s an example of a combination:

<div>
	<?php echo $variableOne; ?>
</div>
<div class="class_one">
	<?php echo $variableTwo; ?>
</div>
<div class="class_two">
	<?php echo "{$variableThree} to {$variableFour}"; ?>
</div>

Since it feels really redundant to jump into PHP, echo a variable, jump out of PHP, output a string, jump back into PHP, echo another variable, jump back out of PHP, I combined that part to just use double quotes. This method probably best represents the way that I code. I may have used double quotes for this, since it would only be three lines, but for the example I expanded it and then added in the PHP.

What about you?

What methods do you use to integrate HTML into PHP? Do you use any methods other than the ones listed here? Please leave a comment, I look forward to hearing your thoughts!

(thumbnail by f-l-e-x, banner by Powerhouse Museum)

The secret to writing clear and understandable code is to have clear logic. You don’t always have to jump straight into writing code. Take the time to determine what needs to be done and the best way to do it. Logic is the very important portion of coding.

Organize your thoughts

You need to find a way to organize your thoughts before you start to code. There’s many ways to do this. Here’s a few examples:

Pseudocode

Pseudocode is essentially code that is written in English (or any other natural language) instead of a programming language. It can help you organize what you need to get done before you actually write the code. For example, if I was making a login script, here’s the pseudocode that I would write:

if nothing has been submitted, then
	the login form is displayed
else if something has been submitted, then
	check if the user that was entered is valid
	if the user is valid, then
		set the cookies and session variables to show that the user has logged in
		redirect the user to the home page
	else if the user isn't valid, then
		display any necessary errors
		display the login form again

There’s obviously many different ways to write pseudocode. My method of writing it is very casual and it barely resembles a program. Pseudocode can also be written so that it resembles the program that is going to be written but leaves out details that a person would not need to understand the code. You can learn more about pseudocode on Wikipedia.

Flowcharting

Flowcharting is pretty much the visual alternative to writing pseudocode. Here’s a simple example of a flow chart, similar to the example that I gave above.

Flowcharting is helpful because it’s really easy to follow the flow of the logic and see what should happen when the script is executed. You can learn more about flow charting on Wikipedia. Also, DrawAnywhere is the tool that I used to make the example flowchart.

Referencing applications already in action

This isn’t really a method of organizing your logic, but instead a method of coming up with your logic in the first place. If you have never worked with whatever you are working on in the past, you may not know what to put into your pseudocode or flowchart. To help you figure things out, you can reference other sites that have already implemented the system that you are trying to set up. This works for anything that’s general and is already used somewhere on the web, such as a login system.

To do this, just find an example of what you are trying to do, and then try all of the possibilities. See what the script does to react to your input. You won’t be able to see what’s happening on the back end, but you should be able to figure out the overall flow of the script by just viewing the front end.

Write code that reflects your organization

It’s great if you do do something that I listed above to organize your thoughts, but you still need to make your code reflect that organization. Otherwise, you’ll just end up with a mess of code that seems to not have been planned out at all.

If you have written pseudocode, then you already have a basic structure for your code. For example, if I was writing code based on the pseudocode posted above, I would write:

<?php

	if( !isset( $_POST['submit'] ) ) {					// if nothing has been submitted, then
		require_once( 'login_form.php' );					// the login form is displayed
	} else {								// else if something has been submitted, then
		$username = mysql_real_escape_string( $_POST['username'] );	// check if the user that was entered is valid
		$not_valid = check_username( $username );
		if( $not_valid == false ) {						// if the user is valid, then
			setcookie( ... );							// set the cookies and session variables to show that the user has logged in
			header( 'Location: index.php' );					// redirect the user to the home page
		} else {								// else if the user isn't valid, then
			echo $not_valid;							// display any necessary errors
			require_once( 'login_form.php' );					// display the login form again
		}
	}

?>

Note how the pseudocode corresponds directly with the actual code. By the way, this is just a really simple example to show you how things correspond, it’s not actual code that would work.

After getting used to doing this, you should be able to visualize the psuedocode or flowchart in your head, and then just go straight to writing the code. It’s definitely very helpful if you actually create the pseudocode or flowchart if you aren’t yet at that point.

Questions? Comments? Please leave a comment! I look forward to hearing your thoughts.

Overview of brace styles

Many language constructs in PHP use braces, such as for,while, if, switch, etc. Where should the braces be placed? All of the different styles have different reasons behind them. I’m going to talk about all of the different styles individually and then assess the situation as a whole.

K&R style

This style was first introduced by Kernighan and Ritchie’s book The C Programming Language. It puts braces on the same line as the control statements. Here’s an example:

	if( $conditionOne ) {
		functionOne();
		$variableOne = 1;
	} else {
		functionTwo();
		while( $conditionTwo ) {
			functionThree();
			$variableTwo++;
		}
	}
	functionFour();

The advantages of this style are that the braces line up with the control statements that “own” them.

It could be viewed that the actual “owner” of the closing brace is the opening brace, so it should line up with that. Another advantage is that code takes up less space since braces do not require lines on their own. A disadvantage is that it’s harder to scan for beginning and ending braces when using this style. I don’t really agree that that is a disadvantage though, I find it quite easy to find the opening brace from the closing brace. Since everything inside of the control statement is indented, you just have to go straight up from the closing brace to find the line with the opening brace. In my opinion, the control statement is much more important than the brace itself, so it’s better than when you follow the closing brace straight up you find the control statement.

Allman style

The Allman style is sometimes referred to as the “ANSI style”. It puts braces on lines of their own and indents them to be aligned with the control statement. Here’s an example:

	if( $conditionOne )
	{
		functionOne();
		$variableOne = 1;
	}
	else
	{
		functionTwo();
		while( $conditionTwo )
		{
			functionThree();
			$variableTwo++;
		}
	}
	functionFour();

Instead of the brace lining up with only the control statement, it lines up with the opening brace too.

An advantage is that the control statement can be commented out to still have syntactically correct code. For example:

	// if( $conditionOne )
	{
		functionOne();
		$variableOne = 1;
	}

A disadvantage is that each brace takes up a line of its own. This was a problem back when programmers were limited to working from terminal with small resolutions, but today it isn’t much a problem. Code readability is more important than code length.

Whitesmiths style

The Whitesmiths style is essentially the same as the Allman style, but braces are indented to be aligned with the body of code instead of the control statement. Here’s an example:

if( $conditionOne )
	{
	functionOne();
	$variableOne = 1;
	}
else
	{
	functionTwo();
	while( $conditionTwo )
		{
		functionThree();
		$variableTwo++;
		}
	}
functionFour();

I’m not going to highlight how things are aligned for this one. It’s pretty much the same as the previous except that things are indented a little differently. It has the same advantages and disadvantages.

GNU style

This style is the average of the previous two. The braces are indented to be in the middle of the control statement and the body of code. Here’s an example:

if( $conditionOne )
  {
	functionOne();
	$variableOne = 1;
  }
else
  {
	functionTwo();
	while( $conditionTwo )
	  {
		functionThree();
		$variableTwo++;
	  }
  }
functionFour();

Since a tab block is equal to four spaces, the braces are indented two spaces or one half of a tab block. This one has the same advantages and disadvantages as the last two. It’s a little easy to see the control statements and the different blocks of code in this one. Plus, all of the braces are indented so that they aren’t aligned with anything else, so it’s easy to see where the control blocks begin and end.

Horstmann style

The Horstmann style is similar to the Allman style. The only difference is that the first statement in the code body is placed on the same line of the opening brace. Here’s an example:

if( $conditionOne )
{	functionOne();
	$variableOne = 1;
}
else
{	functionTwo();
	while( $conditionTwo )
	{	functionThree();
		$variableTwo++;
	}
}
functionFour();

An advantage of this is that it saves space. A disadvantage is that it’s harder to see where things start. Things are pretty much more cluttered. As I said earlier, readability is more important than the conservation of space.

Banner style

Banner style is pretty much K&R style except that the closing braces are also indented. Here’s what it would look like:

if( $conditionOne ) {
	functionOne();
	$variableOne = 1;
	}
else {
	functionTwo();
	while( $conditionTwo ) {
		functionThree();
		$variableTwo++;
		}
	}
functionFour();

I don’t really think that there are any advantages to this style. Most people who use it do so because it makes it easier to see the control statements. The closing braces are indented because they aren’t as significant as the opening control statements.

Pico style

This is the final style. It’s used mostly with the Pico programming language. It’s similar to the Hortstmann style, but the closing brace is put on the same line as the last control statement. Here’s an example:

if( $conditionOne )
{	functionOne();
	$variableOne = 1; }
else
{	functionTwo();
	while( $conditionTwo )
	{	functionThree();
		$variableTwo++; } }
functionFour();

This is the most compressed style, but that doesn’t mean that it is the best. I find it very hard to read – it’s over compressed.

The best style

Which style do you prefer? That’s pretty much what it comes down to. There isn’t a single best style. All of the different styles have their advantages and disadvantages. Moreover, these are styles, not rules or regulations. Just as no one can dictate your clothing style, no one can dictate your coding style. You don’t have to use any of the styles listed here – they are just the most popular styles.

My favorite is the K&R style. I find it easiest to read. At this point, I’m so accustomed to using it that I don’t think about it.

What style do you use? Why do you use it? Please leave a comment, I look forward to hearing your thoughts!

Developing your own styles

There are a few advantages to developing your own coding styles.

1. If you develop your own coding styles you will be coding in a way that works for you. You have complete control over the way that you code, so you can choose to do things in a way that makes sense to you. It’s fairly easy to change your coding styles if your preferences change. You shouldn’t make changes while working on the same project, but it’s fine to do things differently from project to project until you find what you like best.
2. If you are doing things the way that you want to do them, it will probably take you less time. This one could go either way, though. You could develop your own habits that you will be very familiar with and able to implement quickly. Or, you could utilize the styles of others that would take a little while to learn in the beginning but save you time in the long run.
3. It’s much easier to develop your own styles. You don’t have to worry about deciding if something fits the style guidelines that you are trying to meet, you just have to make sure that things are consistent. Developing your own styles doesn’t require any extra learning, only applying what you know in a manner that makes sense to you.

Using the styles of others

There are also a few advantages to using the styles of others. By the way, by “using the styles of others” I mean following the coding guidelines that I featured in this previous post or following similar guidelines.

1. Your coding style may be more accepted if you follow the standards used by others. Your code won’t be something that you just hacked up, it will be something that follows a respected set of guidelines. It’s very possible to create clean and understandable code while using your own guidelines, but if you use an already established set of guidelines it’s pretty much guaranteed that your code will be understood by others.
2. You will be more prepared to work with others if you use coding standards that you may not be completely comfortable with. Chances are that if you make the transition from working alone to working with a team, you will no longer be able to do things as you want them done. You will have to follow the coding standards that everyone else on the team also follows. If you become accustomed to doing this while working on your own projects, you won’t have to adjust.
3. It’s a lot easier to follow standards if you have a set list of standards in front of you. If you are making your own standards, it can be difficult to keep track of all of the different rules. When using the styles of others, you have a definite list.

What’s the difference?

There really isn’t one. It all depends on how much you value the style of your code. If you are very concerned with writing clean code, you may pay more attention that if you just want to get the job done. Moreover, it’s not that hard to adjust between developing your own styles or using the styles of others. If you are used to putting braces at the end of lines, and then you suddenly have to change your style and put them on new lines of their own, it won’t take you very long to adjust to hitting the enter key.

Clean Code by Robert C. Martin

As suggested by AllanC on a previous post, Clean Code is a book written to help you improve your coding habits. It covers a wide range of topics (such as meaningful names, pertinence of comments, code formatting, etc). Martin gives in-depth explanation for every point that he makes and includes real world examples. I haven’t read the book myself (it’s on my todo list!), but I’ve heard that it’s a difficult read. Some experience with Java is needed to fully appreciate the examples given. This book will definitely change your viewpoint on programming and what it means to have “clean code”. You can find the book on Amazon. Also, here’s a table of contents and (if you scroll down to the comments) a few reviews of the book.

Wikipedia: Programming style

Wikipedia’s article on programming style has all sorts of information on coding habits and styles. It focuses on the appearance of the code more so than the logic behind the code. It covers a large amount of practices, such as the use of whitespace and indenting. The great part of this resource is that the page links out to many other pages that are focused on more specific topics. The information on Wikipedia on programming style is not limited to just this article – it includes much, much more.

Zend Framework’s Coding Standards

The reference guide of the Zend Framework includes a whole section dedicated to coding standards and style. You don’t have to follow the coding standards there strictly unless you are contributing code to the project, but you can still read the recommendations that are made and learn from them. Everything is covered in this in-depth guide. The guide also includes PHP examples, which is great if you are working with PHP.

CodeIgniter’s Style Guide

CodeIgniter’s style guide is similar in purpose to the Zend Framework reference. It provides people guidelines to use when submitting code to the open source project. As with the Zend Framework guide, you can still follow the coding standards even if you aren’t contributing to the project. This guide is helpful in that it gives examples of what doesn’t follow the coding standards as well as what does.

Drupal’s Coding Standards

There’s not much to say about Drupal’s coding standards that hasn’t been already said. This guide isn’t as in-depth as the previous but it still provides standards that can be followed.

Basically, the best way to utilize these resources is to look through them until you find standards that you like. You can then learn the standards and perfect them. The most important thing is that you are consistent. If you start off a project planning to follow specific standards, you should continue following those standards throughout the project.

But what if you would rather develop your own set of standards instead of following the standards created by others? I’ll be doing a post on this in the near future – stay tuned.

The Story

I was working on a post a few days back when I accidentally hit the ‘Publish’ button. The post (which was only a small way towards being finished) was automatically added to my blog index and my blog’s feed. Feedburner, being the antsy antelope that it is, added it to my Feedburner feed only minutes after. I quickly removed the new post, but it still appeared in my Feedburner feed.

Feedburner caches feeds so that it doesn’t have to download them every time someone accesses them. Once the cache was updated to include my fraction of a post that I had published, it stayed there even after I removed the post from my blog’s feed by making it a draft again.

I figured out a way to delete items from a Feedburner feed. It’s actually pretty simple. Here goes nothing.

Deleting an Item From Your Feed

Follow these steps to delete an item from your feed:

1. Remove the item from your blog’s feed. When dealing with WordPress, there’s two ways of doing this. You can either set the item to be a draft again, or delete it. If you aren’t dealing with WordPress, this is a fairly simple task so you can probably figure it out for yourself. ;) In general, if the post does not appear on your blog’s index, it probably isn’t in your feed.
2. “Nuke” your feed in Feedburner. You can do this by heading over to Feedburner and then clicking on the ‘Troubleshootize’ tab. Scroll down until you see the header ‘The Nuclear Option: “Resyncing” your feed’ and click the button to ‘Resync Now’. It’s kind of odd to find this option here, so that’s why I’m making a blog post about it. It was the last place that I decided to look. The option is also hidden under the page fold so it’s harder to find.

It’s as simple as that. The resync option is played up to be a catastrophic event (“nuking” your feed), but it’s painless. Your feed will be rebuilt from your updated blog feed that does not include the extra post instantly.

Questions? Having trouble? Leave a comment!

(source)

I started using this method a few months ago. It isn’t perfect, but it works for fairly small web applications that I build on the fly.

Directory Structure

My directory structure looks like this:

Here’s a brief rundown of what goes in each directory:

1. styles/ – Everything frontend goes here. Nothing is at the root of the directory usually, only in subfolders.
   1. styles/css/ – Fairly self explanatory, all of the CSS files go here.
   2. styles/img/ – Again, fairly self explanatory, all of the images go here.
2. support/ – Everything backend goes here. Nothing is at the root of the directory usually, only in subfolders.
   1. support/ajax/ – Any scripts that are accessed via AJAX are put here. I like to segregate these from other scripts so that they all have similar include patterns. They will require files from the support/config/ directory, so I may have a script that includes all of these files and then is included by one of the scripts that is directly accessed via AJAX.
   2. support/config/ – All and any configuration files go here.
   3. support/element/ – This is where all of the individual page elements go. I’ll talk about these a little bit more later. This is pretty much the area where front end meets backend.
   4. support/includes/ – This is where all of the ‘support’ scripts go. These will be scripts containing functions or classes that are used by the page element scripts.
   5. support/js/ – The JavaScript files are found here. In my opinion, this could go in either spot. If you look at the organization as styles vs support, as the directory names suggest, this would go in the support folder. If you look at it as frontend vs backend, it would go in the frontend folder. Put it wherever you think it should go.
3. index.php – This script handles all incoming requests. Using Apache’s mod_rewrite, I rewrite all URLs to point to this script. All of the information about the page being accessed is transformed in $_GET variables by mod_rewrite.

Index.php – The Handler

Here’s an example of what index.php may look like:

<?php

	require_once( 'support/config/general.php' );
	// (other configuration and includes scripts are required here)

	$controller = $_GET['cont'];
	$action = $_GET['act'];
	$argument = $_GET['arg'];

	if( empty( $controller ) ) {
		require_once( 'support/elements/home.php' );
	} elseif( $controller == 'users' ) {
		require_once( 'support/elements/users.php' );
	} elseif( $controller == 'extras' ) {
		require_once( 'support/elements/extras.php' );
	}
?>

This script does all of the core includes and sets things up for the next script. Then, it sets up all of the variables that determine what is displayed. I split up every request into three parts: the controller, action, and argument. The controller and action are required for all requests. If either do not appear, they are usually assumed to be home and index, respectfully. The argument is optional. These three variables can describe just about any request that is made. Trying to view someone’s user profile? The controller would be users, the action would be profile, and the argument would the id of the user that you’re trying to view. Trying to post a topic? The controller would be forums, the action would be newtopic, and the argument would be the parent forum that you are trying to post under.

Index.php decides which element (all of the elements are essentially controllers) and then includes the necessary files. When the element script takes over from there, it determines what to do according to the action and argument.

Why I Like This System

I find that this system simplifies the process. Every directory has a certain type of scripts or files that it contains. All of these scripts or files have the same purpose. I believe that the directories are set up logically while still keeping it simple. This could be a lot more complicated, but it doesn’t have to be. It isn’t designed to be used for large scale web applications, only medium to small ones.

Things are extremely easy to debug when using this system. If there is a problem with a certain module, I can open up the controller script for that module and see what the problem is. As long as global functions (in the includes/ directory) are kept simple, and don’t do a larger job than they have to, things can pretty much only go wrong with each individual module.

What’s your method of organizing projects? Do you like my method? Please leave a comment!

1. Twitter API
   Ah, Twitter. As little as I care about how Ryan Seacrest is eating a green apple, Twitter is a popular service and including it in your web application usually adds to the success of it. Twitter has a robust API that will give you access to just about anything that you need.
2. Last.fm API
   When it comes to music, Last.fm is just about unbeatable. Using their web services, you can access a large amount of data, including artists and their popular tracks, images of artists, and play counts of popular tracks.
3. Amazon Product Advertising API
   Amazon’s Product Advertising API, one of many web services offered by Amazon, is an easy way to get information of products. It can also be used to sell items and earn money through Amazon’s affiliate program. You can find their documentation here. Also, check out a post that I did recently covering a little bit about using their API.
4. Google Maps API
   Using the Google Maps API, you can embed Google Maps in any web page. There isn’t an easier way to display maps to your users. The API is well documented and easy to use. You can find the documentation for the Google Maps API here.
5. Facebook API
   With Facebook being even more popular than Twitter, it’s obvious why the Facebook API is important. The Facebook API is an important part of developing Facebook Applications. You can find the documentation here.
6. YouTube API
   YouTube is the most popular video site on the web. They have a fairly simple API with two core parts – the data API, which lets you search for videos or upload them, and the player API, which lets you embed YouTube videos in your web pages. You can find the documentation for both APIs here.
7. OAuth
   OAuth is a protocol that allows 3rd party applications to interact with service providers. An example of this is Twitter. A user can visit a web application with OAuth and login to their Twitter account without giving their password to the application. The application can then access whatever it needs from Twitter. You can learn more about OAuth here.
8. Yahoo! Maps Web Service
   The Yahoo! Maps Web Service is a web service similar to Google Maps. It allows you to embed maps on your website or geocode addresses. I would consider using it over the Google Maps service if all that I needed was geocoding. Yahoo! offers a really simple geocoding API. You can find the documentation for the whole API here.
9. MediaWiki API
   The MediaWiki API gives you access to the largest encyclopedia on the web: Wikipedia. You can use it to fetch articles, edit articles, add new articles, or do just about anything else. You can find the documentation for the MediaWiki API here.

Have you ever used any of these web services? How have they helped you? What do you think the tenth web service in the list should be? Please leave a comment!