On NetTuts.com today they've posted a list of tips they think will help you learn a new technology faster. They've broken it up into ten different steps, some which could be done at any time but some have a bit more of an order.

We live in a very exciting time. Never before has education been so cheaply available to the masses (if not free). The medium, itself, has made tectonic shifts from a classroom setting, to blogs, screencasts and complete university classes, as a set of videos and interactive forums. Given these resources, there's absolutely no excuse not to dive in and learn. However, with such a wealth of resources, filtering through the options can often become overwhelming. In this article, I will outline a simple process to kick-start your education.

Among the items in their list there's things like:

• "Let the Information Flow Begin"
• "Listen and Watch"
• "Blogging"
• "Feel the Pulse"
• "Meetups and Conferences"

Each tip comes with a bit of description and some links to other resources and tools that can help you along your way.

Pádraic Brady has posted a 20 point list that wants to help you prevent cross-site scripting (XSS) issues in your applications.

Summarising knowledge has as much value as writing a 200 page treatise on a topic, so here is a list of 20 brief points you should bear in mind when battling Cross-Site Scripting (XSS) in PHP. Minus my usual book length brain fart . Chances are good that ignoring or acting contrary to any one of these will lead to a potential XSS vulnerability. It's not necessarily a complete list - if you think something needs to be added, let everyone know in the comments.

His tips include things like:

• Never pass data from untrusted origins into output without either escaping or sanitising it.
• Remember that anything not explicitly defined in source code has an untrusted origin.
• Always include ENT_QUOTES, ENT_SUBSTITUTE and a valid character encoding when calling htmlspecialchars().
• Use rawurlencode() to escape strings being inserted into URLs and then HTML escape the entire URL.
• Validate all complete URLs if constructed from untrusted data.
• Remember that HTMLPurifier is the only HTML sanitiser worth using.
• Ensure that cookies which must only be transmitted over HTTPS are marked Secure.

He points out that XSS is still one of the most "popular" (and easy to exploit) attack methods out there, so keep these tips in mind when writing up your code.

For anyone that's wondered how some of the features they use every day get into the PHP language, Chris Jones has written up a post making the RFC (Request for Comments) process they follow a bit more transparent for the average developer.

The PHP RFC process has been in place for a while, and users new to core PHP development are starting to use RFCs to propose desirable features. Here are some personal observations and suggestions that show how I have seen feature acceptance and the (newish) RFC process work in practice. These notes augment the steps in How To Create an RFC. I hope they help set expectations about the PHP RFC process and feature acceptance in the PHP language.

He lists the steps in the process from start to finish including things like:

• Avoid presenting an RFC idea to the "internals" mail list with email that begins "I don't know much about ... but ...". Do some research first.
• Your RFC should talk about all PHP areas that will be affected: php.ini, different SAPIs, engine, extensions, etc. List similar features. List similar features in other languages. Link to references. Give an estimate of the actual positive impact to user code.
• If you do have an implementation, make it clear whether the implementation is a simple prototype or is expected to be the final code. This is specially important during the vote.
• There is no need to respond to every discussion email individually. You should batch up your responses and manage the discussion intelligently.
• With long, fragmented discussions, not everyone will read every email. Update the RFC at regular intervals, and let people know what has changed.
• Some areas of PHP are complex or niche. Sometimes feature suggestions will be greeted by an apparent lack of interest. Don't be discouraged. This just means you need to take a stronger leadership role, and also prove your credentials by first working on the existing code base.
• During the voting period, it is common for people to continue mail list discussion. You may need to halt the vote and address any issues.

Obviously, there's a lot more to it than that - his post does a great job of letting you know what to expect and includes useful tips on helping you get your idea across.

PHPMaster.com has posted a new article with some high level security tips and reminders for PHP developers when wanting to help prevent issues with their applications. The article provides eight tips, each with a brief description.

When it comes to application security, in addition to securing your hardware and platform, you also need to write your code securely. This article will explain how to keep your application secure and less vulnerable to hacking.

The good practices they recommend include input data validation, protecting against XSS attacks, preventing SQL injections, protecting session data, proper error handling and protecting included files. There's some good reminders here, but it barely scratches the surface of effectively protecting your application. These tips are the "low hanging fruit" for securing your app, so be aware that there's more things to worry about than just these eight.

In the latest post to his site, Ruslan Yakushev looks at some simple ways you can debug your PHP-based applications running on a Windows Azure platform.

The need to diagnose and troubleshoot application's failures often comes up during deployment to a hosting environment. Some configuration settings in hosting server may differ from what application expects. Often it is not as easy to figure out the cause of the problem in a hosting environment as it is on a development machine. I found the following techniques useful when troubleshooting errors in PHP applications hosted in Windows Azure Web Sites.

He shares seven different tips, some pretty simple, others a bit more difficult requiring other software to be up and working:

• Using phpinfo()
• Checking the wincache settings
• Looking at your error logs
• Turning on the display_errors setting
• Turning on HTTP logging, detailed errors and failed request tracking in the control panel
• Using XDebug
• Getting the statistics for your ClearDB instance

Lorna Mitchell has posted a quick checklist of things you can ask about your API to see if it's RESTful or not (five of them):

I get a lot of emails asking me to get involved with API projects, and that means I see a lot of both implemented and planned "RESTful" APIs. [...] A service of some other description may work better for other scenarios or skill sets, and non-RESTful services can be very, very useful. If you tell me that your service is RESTful, then I expect it to be. If you're not sure, look out for these clues:

• It has a single endpoint
• All requests are POSTs
• Response metadata is in the body, not header
• There are verbs in the URL
• The URL includes method names

She suggests, though, that "being RESTful" isn't a requirement for "being useful" when it comes to APIs.

In a recent post to his site, Brandon Savage has a few helpful hints to keep in mind when you're refactoring your applications to make them easier to maintain (and possibly perform better) in the future.

The downtime [of this week] provides a perfect opportunity for the aspiring software developer to do the one thing they are always told there's no time to do: make the code better for better's sake. With few deadlines and plenty of free time, most developers can get a few hours of refactoring in to their code towards the end of the year. They can rearchitect sections that were implemented with haste in September; they can write tests for sections that were untested in April. Put another way, the "lost week" can be redeemed.

He has a few recommendations, each including their own brief summary:

• Test Everything First
• One Method, One Job (Also One Class, One Job)
• Don't Be Afraid Of More Objects And Classes
• Remove Dead, Unused, Unnecessary or Old Code
• Document Your Code

Check out the full post for the summaries and links to other useful resources.

Oscar Merida has written up a sort of continuation to this series from Adam Culp about clean code, one that shares more tips on knowing when to refctor.

Adam Culp posted the 3rd article in his Clean Development Series this week, Dirty Code (how to spot/smell it). When you read it, you should keep in mind that he is pointing out practices which correlate with poorly written code not prescribing a list of things to avoid. It's a good list of things to look for and engendered quite a discussion in our internal Musketeers IRC.

His suggestions include things like "Comments are valuable", "Using switch statements" and a few other smaller ones involving error suppression, globals and prepared statements in database usage.

PHPMaster.com has a new tutorial posted sharing a few helpful hints about speeding up CakePHP-driven sites to help squeeze the most performance out of your site.

By applying a few simple modifications, and even some more complex enhancements, CakePHP can be sped up quite a bit. By the time you work your way through even half of these changes, the performance of your your CakePHP site will be comparable to many other popular PHP frameworks, with the advantage that your development speed will never falter!

There's several tips in their list - some a bit more difficult to accomplish than others, but worth the results:

• Upgrade CakePHP Versions
• Disable Debug Mode
• Disable Recursive Find Statements
• Cache Query Results
• Install Memory Based Caching
• Removing Apache and Installing Nginx
• Configure Nginx to use Memcached
• Remove MySQL and Install Percona

For more information on the CakePHP framework, see the project's main site.

On the QaFoo.com blog Kore Nordmann shares some insight about the difference between abstract classes and interfaces and how they can be used effectively/correctly.

Features of object oriented languages are often use from a purely technical perspective, without respect to their actual semantics. This is fine as long as it works for you, but might lead to problems in the long run. In this article I discuss the semantical differences between abstract classes and interfaces. I also outline why following the semantics of those language constructs can lead to better code.

He defines "class" and "interface" before he gets too far into the differences, stating that a "class" is more of a "type" while an "interface" describes the type and the structure to use it. He also talks about how to tell them apart (when to use each). There's also some examples and "hints" to help you determine good and bad examples of interfaces and when an abstract class might be a better answer.