In this post, I'll be covering documenting your API -- techniques you can use to indicate what HTTP operations are allowed, as well as convey the full documentation on what endpoints are available, what they accept, and what you can expect them to return. [...] hy Document? If you're asking this question, you've either never consumed software, or your software is perfect and self-documenting. I frankly don't believe either one.

He covers a few reasons why you should document your API and where he thinks it should live to be the most useful. He includes a few different ideas and two things he definitely thinks should exist for your API - the use of OPTIONS and end-user documentation. The first is a HTTP header (ZF2 code example included) that tells the API consumer what they can do with an endpoint. The second type is more useful for the human reader, giving them a better overall perspective on what the API can do - still served through the API but in a bit more understandable format.

Over the years I've built many different types of websites. These range from being a few pages, to being very customized with advanced features. I've learned there is no clear definition in the best way to create a website. But I do think there are advantages and disadvantages to pursuing different methods. This article takes an analytical look at each option. Let's take a closer look at the different approaches in building a website.

He includes a brief summary talking about each method and mentions things like benefits and downfalls of the approach and what can be involved in their development.

Two of the more complicated components in Symfony2 is the Form and Validator component. The Validator is created in such a way it "always" need an Domain Object with Constraints associated through metadata. This is explained in detail here. But there is another way. A way that resemble's the symfony1 forms. Where you could specify the validations directly in your form class.

Code is included in the post to show how to load in a few of the validators (like NotBlank, Email and Choice) and how to use them in the settings defined in the "getDefaultOptions" method.

When you need data input in a web context, you send a GET/POST request to your script. On the command line, things work differently. In this blog post, we will talk obout input and output in php-cli.

The post is broken up into a few different sections:

• Handling arguments
• File descriptors
• Interactive input
• Resources mentioned in the post

Tools mentioned include everything from getopt and PEAR's' Console_Getopt out to using file descriptors and working with readline.

Enter the newcomer to the world of PHP deployment options: Platform as a Service (PaaS). You may be rolling your eyes at the introduction of yet another buzzword and acronym, but before you dismiss it, consider how it might fit in to your application hosting strategy. I've heard Platform as a Service described as a "layer above the cloud," that is, it builds on the existing cloud infrastructure, like Amazon's EC2, but abstracts away all the setup and maintenance tasks of running an entire server. As David Coallier described it to me, the goal is to "deploy apps, not servers."

Joel mentions two different offerings that have popped up recently - PHPFog and Orchestra. Both services have some nice features that he gets into including application templates, git integration and configuration for specific kinds of technologies (like database support and memcache availability).

I've got a problem. I haven't found the perfect IDE for me. Yet. I've got problems with every software. Now I will try to explain the problems I have and maybe someone shows me the light and helps me to discover the perfect editor/IDE.

His needs include that it be able to run on Linux, that it include code auto-completion, syntax highlighting and a built-in debugger. He tried out a whole list of IDEs including Zend Studio 7, Eclipse PDT, Netbeans and Vim. For each he describes his opinions and talks about what's right and wrong as far as his needs. If you're on a quest for that "perfect IDE" for yourself, you might read his thoughts as well as the suggestions of others on the comments.

Configuring PHP is easy. You can change almost any aspect of the interpreter within the php.ini configuration file, e.g. modify error handling, increase memory usage, etc. Unfortunately, problems can occur when you move your application to a live hosting environment or are distributing the code to customers. ISPs usually lock down the php.ini configuration file - especially on shared hosting. This could cause your application to fail.

If you're lucky enough to be able to use htaccess files, his first method will work for you - using the "php_flag" or "php_value" directives to change settings for your entire application. The other option is more on an as needed basis - using the ini_set method to change configuration options. Be careful, though, only some configuration options can be changed using these methods. Some still require changes to the php.ini and a restart of the web server.

You love coding in Netbeans and you find it pretty uneasy when it does not function the way you want it to. That was the same with me when I started development in drupal and I was unable to associate the .module as PHP in my favorite editor Netbeans. However with little play around with options I was able to associate .module files as PHP file in Netbeans IDE. So for doing so follow [these] steps.

You can change the setting for plenty of different extensions (and add your own custom ones) in the Options under the Miscellaneous section's Files tab. Check out this screenshot to see the location.

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.

He suggests four different alternatives to pick from when making the move up - the old standby of purchasing more hardware, making use of the Amazone Web Services, using a "cloud" like Mosso or implementing a Content Delivery Network to lighten the load and spread it out across a wider range of servers.

It's a universal frustration. You just know that the piece of information you're looking for is somewhere on a site. You click one link, then another, and another. You go back to the home page and try a different branch of the site. After dozens of clicks, you still can't find the information you need. Then it's back to Google and on to another site. At last you find one with an internal search engine. You enter your search term, and voilá!--the information you need pops up in less than a second.

They compare these two types - hosted versus local - and show how to get started on integrating one, the local option, into your site. They start with a few things consider before getting into the choices - the physical issues involved, the page information itself, and how the engine will index.

The rest of the article is devoted to the different options they'd recommend along with ratings, what technology they use, if they're PHP5 compatible, difficulty of installation, and many more criteria. Their list of leading local search engines for your site are:

• Sphider
• MnogoSearch
• TSEP
• PHPDig
• iSearch
• RiSearch