ZF Oauth Provider

Zend Framework has pretty good OAuth consumer implementation. However, it has no support for implementing OAuth provider, and it turns out that there aren’t many other libraries for it. Most examples out there base on PECL oauth extension, which works just fine, with one caveat – you have to have this PECL extension installed, while ZF implementation does not require that.

So I went ahead and wrote some code that allows to easily add OAuth provider to your ZF-based or ZF-using application. That should make writing OAuth provider easier.

Note that the code does not implement the whole server – just the OAuth protocol wrapper, you’d still have to do all the work of managing tokens/keys/nonces by yourself. See example server in the repository and the wiki on github for more details on how to do it, but the protocol follows what PECL oauth does pretty closely, so many tutorials for it would be mostly applicable to this one too.

Check out Zend_Oauth_Provider on github, if you want to improve it – please fork and submit pull requests.

 

Shortcuts

Being at OSCON, I’ve attended one good talk about Python oddities, which got me thinking about language syntax in general.

PHP is notorious among scripting languages for it’s verbose syntax – you have to spell out many things that are much shorter in other languages. Some people think it’s very bad that they can’t be “expressive”, meaning writing more clever code with less keystrokes. Sometimes they are right, sometimes they are not. Let’s consider two examples:

From PHP: 5.4 has a new array syntax: ['foo', 'bar'] which is the same as array('foo', bar').

I think it’s a good shortcut – because [] is a common expression for arrays (or structures that work like PHP arrays) in many languages, and it is obvious for most people how it works.

What’s an example a shortcut that isn’t good? Python (version 2) has this syntax for exception handling (this was one of the examples in the talk):

except Foo, Bar:

Now what this means: are we catching two exception types, Foo and Bar, or are we catching exception Foo and assigning it to Bar? The correct answer is the latter – it’s exception Foo assigned to Bar. I think it’s bad shortcut – because it uses a comma – which is common expression for lists and enumeration – to separate the type and the parameter. This leads to people writing things like “except KeyError, IndexError” which doesn’t do what one would expect to.

Pyhton people seem to agree with me, as in Python 3 the syntax has been changed to:

except Foo as Bar:

One could argue it’s not as “expressive” and more verbose – bu it’s definitely much more readable and would lead to less broken code. It’d be even better if they used the word “exception” or try/catch as all the rest of the world does :)

Some people in PHP community think all “shortcuts” are best to be avoided. I think some of them could be useful, provided clarity is not sacrificed and there’s not “too much magic”. I know it’s subjective but my personal criteria is that if it’s not immediately clear what’s going on for a person with reasonable knowledge of the matter – it’s probably too much magic.

On PHP features

When people ask why PHP doesn’t have this or that cool feature which allows to do some tricky mind-bending function and requires a dozen pages of manual to describe it, I find this quote from Brian W. Kernighan is very appropriate:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Corollary of that is that some clever tricks are better left not done and some cool things may not look that cool when you have to deal with the consequences.

That being said, I think there are many cool things yet to be done in PHP. So, I’ve posted a poll on Programmers.StackExchange site about what people want to see in PHP. I know people regularly post on PHP lists about that, etc. but I think SE crowd would be somewhat different from what is found on PHP internal lists, so it would be interesting to see what people’s wishlists for PHP are.

If you happen to want to add your 2c there or just vote on stuff – feel welcome. Absolutely no promises it would have any weight, influence anything (except maybe my own opinion about what people want in PHP), etc. of course.

 

Adding new extensions to Zend Studio

I am using Zend Studio for my everyday PHP work, and I like it. I know many others do too, or use PDT. It has one very cool – though not widely known – feature that allows you you to add unknown extensions to code completion. I.e., if you have some extension, create stub file with PHPDOC descriptions – i.e. something like this:

/**
 * Do stuff
 * @param string $arg
 * @return array
 */
 function dostuff($arg) {}

for each extension function, Studio will know to pick it up. You can put this file into Studio’s prototypes directory – easiest way to find it is just write something like chdir() anywhere, select the name and press F3, the directory of the file that you’ll get is the one you need.

However, the problem is how to create this file. E.g., I’m doing some work with MongoDB lately, and PHP has great Mongo extension – which Studio doesn’t know yet. So how do I create those stubs? Obviously, I am too lazy to manually write them. I went to look for a tool that would allow me to make one – and found none. At least not in 15 minutes I spent looking, so I decided to write my own.

What came out is the Reflector. It uses PHP reflection and PHP’s manual XML sources in order to generate stub file (see example mongo.php on git to check what comes out). Right now it’s not very smart and handles only classes/methods, not functions (probably will fix that soon), but maybe it will be useful to somebody.

Or maybe somebody points me to a tool that does that even better in comments :)

Update: Roy Ganor (who is leading the Zend Studio project) in comments pointed me to the source of the Studio generator script. It will generate stubs for all extensions you have, as I can see. Try it out. Thanks, Roy!

zf book review

As I mentioned before, I got the book Zend Framework 1.8 Web Application Development for review. It took me a bit more time than I though to do this (one of the reasons will become clear soon) but here it finally comes.

I think it is a great book for somebody who is somewhat acquainted with Zend Framework and wants to get really good at working with it. It covers a lot of ground, so if you never worked with ZF before you might be a bit overwhelmed by the amount of stuff going on (then again, maybe I am underestimating you :) ), so you may want either skip some detail to return to it later when the need arises or have a run through a very basic tutorial for getting to know how the framework works before. The book itself has the basic startup section but I feel for a complete newbie it still might be a bit tough to keep up with the amount of the material in the book. That of course will come handy later when you got the basics figured out.

I personally am a big fan of learning by example and I think one line of code is often worth a hundred words, so I was really pleased that this book is based on building a complete application and comes with full application code to accompany it. The application is a storefront with an admin interface, so it covers most of the common tasks in a typical PHP application.
While it means that on the road there were certain decisions to be taken, and certain ways of doing things will be chosen over certain others, the author clearly identifies the decision points and explains the reasons – i.e. why certain things go to a model and not controller, why this extension point and not that one is used, etc. ZF has a very rich set of features, so there’s no single “right way” to do all things – but the book certainly shows you one of the ways to reach the complete and nicely structured application.

I actually took a bit of an experiment – as I was at the time building some ZF-based application, I decided to use the book as a first reference for any question that I needed with the app. I am pleased to report that the book indeed proved very helpful and I was able to find most of the advanced topics – like the use of ACLs, interactions between forms, views and decorators, modifying the behavior of the standard ZF classes, etc. – answered in the book and demonstrated in the code. The author successfully avoided the temptation to quote the manual extensively and instead picks up where the manual leaves off – i.e. how does one use stuff that the manual describes in practice.

The book also covers – albeit somewhat lightly – the topic that is neglected by so many other ZF books – namely testing. It shows how to setup the test environment and how to execute some basic application tests. Ideally, I would like the topic of tests to be much more prominent and featured as something parallel to development and not something you do after (though I know that’s how it rally happens many times ;) ) – but I know there’s only so much you can put into one book :)

Summarily, I think it is a good book to have if you do or about to do serious ZF development.

hiphop for php

By now probably everybody that is connected to PHP world knows about Facebook’s HipHop.
So here are my thoughts about it.

1. This is a very cool and exciting technology. There were multiple attempts to do this in various ways, and from what it looks, HipHop is the most successful and appealing. I know doing these things is not easy – I tried something like that myself somewhere back in 2006 but was unable to go past very basic examples (I also made a mistake of choosing C instead of C++ as target, which I now think was not a smart decision). And the progress and support for almost all of the PHP magic is definitely great. There still are unsupported areas, but mostly are dark corners into which not many people venture (or should venture, at least :)

2. I do not see it as a replacement for php.net code or Zend Engine. The mainstream of PHP development still happens in the community around php.net and I do not think it is going to change anytime soon. I also see the fact that HipHop engine basically re-implements all the extensions as a serious disadvantage, for which the solution should be sought, even though I completely understand the technical reasons for doing so. I do not know which kind of the solution but while for the company like Facebook it might be OK to “freeze” certain set of extensions and features and maybe catch up periodically, I think it is obvious how such model can be a problem for the wider adoption.

3. If we talk about broader adoption of this technology in a wider PHP world, there are some serious challenges to consider:

  • Plugins: right now, you must compile your whole application. However, many real-life applications have extensive plugin models, which consist of their main competitive advantage – take WordPress, Drupal, Magento, any Zend Framework app – all of these allow to write custom plugins and run them alongside the main code base. The model in which you have to rebuild whole application each time you add/change a line of code is not acceptable in these circumstances.
  • Modularity: this is connected to the above, but is a bit different. PHP right now runs on Apache, IIS, Lighty, nginx, and tons of other servers in different environments. For the use of the technology in the wide variety of environments PHP is used in, one must be able to modularize  and separate the application PHP code from the runtime and the environment.
  • Portability: I tried to run a bunch of my scripts through the demo that the HipHop team was very kind to give me – and most of them experiences unsupported functions or some function didn’t work exactly as their PHP counterparts (random example: PHP’s fopen() would error out given empty first argument, while HPHP implementation would open the current directory as file. There are more such things…). Now, I admit, it would be very easy to fix them, to use different functions and they would work, but again I think it’s obvious how it can be a problem for a PHP programmer, if you are not coding targeting HipHop specifically – and especially of you use 3rd-party code. Having different implementations always presents portability challenges.
  • Thread-safety: A huge problem with PHP thread-safety is third-party libraries. Many of them are not thread safe either explicitly, or, even worse, implicitly – i.e. they just have either bugs or information leaks between threads (like changing some setting in one thread and feeling its effect in another – imagine chdir() leaking through the thread boundaries – see how it can be a problem?) HipHop team’s answer to this question was “we had fixed all those extensions” – which, without diminishing the capabilities of this excellent team, I think is not a satisfactory answer. It very well may be that they indeed fixed all the problems they could see in the code they run – but let us not forget they run one (albeit huge) application. I have hard time believing they have fixed every threading problem with every C library in existence that has interface to PHP and will continue to do so as long as C libraries exist. This of course goes back to modularity question, since here we have coupling between compiling and runtime model.
  • Debugging: obviously, debugging C++ code is orders of magnitude harder than PHP code. So you either need ninja debugging skills, or a very good set of tools to allow you to identify a problem in a live server running non-source PHP.

4. I also see certain danger potential in the success of this project. The danger primary being that the performance is very important in the web world, and it can give an incentive to the PHP community to change PHP in ways that may be better for performance, but would make PHP into being an entirely different language. The obvious example of this is strict typing – strict typing, of course, would help the compiler a lot in figuring out what’s going on with the code. However, I am not convinced at all that it would make the life of a PHP programmer easier. I know there are a number of proponents of this but I am still not convinced it’s the way for PHP to go. And there might be other incentives like this – i.e. to add or drop features to PHP, or avoid using certain constructs and features, for the sole reason of making it more compile-able. Now, there’s nothing wrong with being compiler-friendly, but I don’t think for a language like PHP it should be the primary motivation.

Re-reading these notes I realized some of it might give an impression that I dislike the technology. It is absolutely not so – on the contrary, I think it is a great addition to the PHP world and I want again to congratulate the HipHop team on a huge achievement and thank them for making the PHP world better and more exciting. It would be very interesting to see how this develops and how and if the problems can be overcome and how this technology changes the PHP world and is changed by it.

Ruby-like iterators in PHP

I’ve started playing with Ruby recently, and one of the things that got my attention in Ruby were iterators. They are different inside from regular loops but work in a similar way, and looks like people (at least ones that write tutorials and code examples ;) ) like to use them. For example, you can have:

arr = {"one" => 1, "two" => 2, "three" => 3}
arr.each do |key, val|
print "#{key}: is #{val}\n"
end

which iterates over a Ruby hash and prints:

three: is 3
two: is 2
one: is 1

So it got me thinking – suppose I wanted to do something like this in PHP (suppose I don’t like regular loop-y iterators for some weird reason). Naturally, I wouldn’t get it in the same concise form as Ruby does, since I can’t change the syntax. But I could get the essence. Let’s try it. First, the main iterator:

class RubyIterator {
  protected $_body;

  public function __construct($body) {
    if(!is_callable($body)) {
      throw new Exception("Iterator body should be a callable");
    }
    $this->_body = $body;
  }
  public function yield()
  {
    $args = func_get_args();
    call_user_func_array($this->_body, $args);
  }
}

Next, less try to make some class that uses it:

class RubyArray {
    protected $_arr;
    public function __construct(array $a)
    {
        $this->_arr $a;
    }

    public function each($body) {
        $iter = new RubyIterator($body);
        foreach($this->_arr as $k => $v) {
            $iter->yield($k$v);
        }
    }
}

and then:

/*
arr = {"one" => 1, "two" => 2, "three" => 3}
arr.each do |key, val|
    print "#{key}: is #{val}\n"
end
*/
    
$arr = new RubyArray(array("one" => 1"two" => 2"three" => 3));
$arr->each(function($key$val) { echo "$key: is $val\n"; });

and the result the same, of course. Or, let’s try with ranges:

class RubyRange {
    protected $_from$_to;
    public function __construct($from$to) {
        $this->_from $from;
        $this->_to $to;
    }
    public function each($body) {
        $iter = new RubyIterator($body);
        for($i=$this->_from$i<=$this->_to$i++) {
            $iter->yield($i);
        }
    }
    
}

and use it:

/*
r = 1..10;
r.each do |i|
    print "#{i*i}\n"
end
*/

$rr = new RubyRange(110);
$rr->each(function($i) { echo $i*$i."\n"; });

which indeed produces:

1
4
9
16
25
36
49
64
81
100

And so on – if one wanted, whole set of iterator methods could be implemented (I’m of course too lazy to do that :) ). I wonder if there are use cases that we can’t do there.