In a new post to his blog Sameer Borate shows how to create a lexer and parser in PHP to work directly with the tokens of a PHP script.

After looking around for a while [for a good resource on compilers] I settled for Terence Parr's Language Implementation Patterns. This is exactly what I needed - bit sized patterns on compiler and parser design with working code. The book provides a recipe style approach, gradually moving from simple to complex compiler/parser design issues. As I primarily work with PHP, I thought of porting some code to PHP to see how it works.

He shows examples using his custom tool to show a basic lexer output for a list and a complete listing of the code involved. Ultimately, though, he finds that PHP isn't overly suited to the task - anything more than his simple example could be more trouble than it's worth.

Following up on their earlier simple object iterators post, the SitePoint PHP blog is back with a look at more sophisticated iterators you can use to work with database record objects.

In my previous post, Simple Object Iterators in PHP, we discovered how to iterate over array items defined within an object using a foreach loop. However, what if you need to iterate over items which are not stored in an array, e.g. records from a database or lines of text read from a file?

He shows how to create a script that pulls in the users from a database object (PDO, in this case) and implements the Countable and Iterator interfaces. These interfaces give it some special methods that can give counts of the results and help you iterate through the results - current, rewind, next and valid.

Jeremy Brown, after working tirelessly on a REST API based around the Zend Framework (and a few other technologies), has come up with his three tenets for implementing a REST API to hopefully help you along the straight and narrow path that he forged himself.

In the course of performing my duties at my day job I recently came across the need for our data to be accessible via an API. After researching the various types available, I settled on developing a REST API. The selection process wasn't the interesting part of this exercise though. Actually implementing a REST API is what was.

His advice ranges from the general to very specific, sharing tips on how to most effectively create the service's API:

• REST is a set of principles (and not a specification)
• Do not use custom media types
• Represent the headers in the response payload

On his blog today Matt Williams has a quick tutorial about setting up your CodeIgniter application to use the new oAuth authentication feature that Twitter with the help of this library.

On August 31st Twitter will be axing basic auth GET requests, which is being overtaken by the more secure oAuth, there are a few tutorials out there on how to use oAuth and how to get started creating an app with CodeIgniter, but not many with actually helpful advice so here is my 2 penneth.

The library makes it simple to connect to the Twitter servers with your key/token combination and run a check against the credentials via a simple "oauth()" method call. Sample code is included in the post to make implementing easier.

Aaron McGowan has posted his list of five things he wishes PHP could change (or even had) in future versions of the language.

Recently I have been hard at work trying to finish up a few major source packages and one application - but I have recently found myself thinking about how much better and more "grown" up PHP would be if it had a few things that other technologies such as C++ and C# have.

The five things on his list are:

• Operator Overloading
• Method and function Overloading
• Advancement of Namespaces
• Use of final keyword for class member variables
• 'Getters' & 'Setters' similar to C#'s for class member variables

Each point comes with a summary and a bit of code to show what he's talking about. He sees these things as major steps in PHP "growing up" and as features that could help it make a translation over from things like .NET simpler.

Brandon Savage as a suggestion for anyone doing any kind of development work - use source/version control in your development, you'll be thankful later.

If you ask most developers about source control, they'll agree that it's a wise thing to use. They'll insist that they think it's important. But yet, why are so many companies out there still not using source control in their projects? A good number of companies that I've worked with failed to make use of source control, resulting in issues that would have been trivial otherwise. In this article we'll explore ways to make sure that if your company isn't using source control, that you can help make a change to this policy.

He makes a few suggestions about implementing version control in your environment (it doesn't need to come from the top), how it's best put in place before a crisis and how the real person that might need the convincing could be your fellow cowrokers.

In this recent post to his blog Joe Topjian takes a look at something that has been known to confuse Zend Framework users when trying to set up access control for their application - using the Zend_Acl component.

It seems everyone, myself included, has a bit of a hard time first grasping Zend_Acl. For the time being, I've settled on a simple solution. It's party based on the solution given in the Zend Framework in Action book. I hope you get some use out of it.

His example uses the Zend_Config component to configure his roles and a more centralized approach to validating access for the users - more rules in the INI config file and a custom MyACL class/AclHelper tat are called from the bootstrap file to evaluate where the user can and cant go for each request.

On the Zend Developer Zone there's a new tutorial posted about the Observer pattern (one of many design patterns) and how it can help you create code using an event-driven programming style.

What exactly is an observer pattern ? All the theory is accessible on Wikipedia. Basically we have an object you want to monitor ( observe ) for any changes. Most of the time this object just fires out events and we want to listen to them. We can have more objects observing one or more other objects so basically this can be M:N relationship

He compares them to triggers in the database world - bits of code that are activated when something changes on an object. His example implements an interface (IObservable) to set/get an email address and validate it with a regular expression. When the setEmailAddress method is used and the validate method is called, the observer kicks into action and checks to ensure the value is correct.

Timothy Boronczyk has posted a class that provides a different sort of theory on database access:

I was thinking today about database APIs when inspiration struck. I ended up hacking out the following class, which I think demonstrates a rather interesting approach to interfacing with a database (interesting enough at least to post here).

His class implements an Iterator and lets you bend a few of the rules PHP normally has in place (use of the magic methods, special characters in an identifier). He also includes an example of its use - connecting to the database, selecting information and pulling that information back out.

Brandon Savage has made a few suggestions that can help you with one of the most important parts of any development project - picking the right tool for the job.

You'd never dig a drainage ditch with a pitchfork, or plug a drywall hole with chewing gum. Instead, you'd pick an appropriate tool and you'd use it to accomplish the job (a shovel, or some spackle, for example). So why do software engineers often spend so much time fixing problems with the wrong tools at hand?

He includes three common issues and ways you can overcome/stay away from them:

• Lack of knowledge regarding available tools.
• Inability to implement solutions due to lack of resources.
• Unwillingness to implement a solution.

Of the three, the last one is possibly the most scary - don't let personal feelings or your dedication to Tool X be your undoing and hurt your application in the long run.