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.

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.

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 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.

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.

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.

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.

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.

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.

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.