Programming

What is it with me? Haven't blogged in over a year and whenever I do blog, it always seems to be about those darn unconferences. There really must be something to them, right? Right?

Well, if you've always been intruiged by the raving reviews the PHP Unconference in Hamburg, Germany is getting (which took place again just last weekend, and, again, was a blast), but were put off by the fact that it's in Germany, which is far, far away and people might not speak English and eat only Sauerkraut, wear Lederhosen and are overall silly (hint: only the last part is true), then now is your chance to experience the unconfence spirit in a more international setting:

The PHP Unconference Europe is scheduled to take place in Manchester on February 19/20, 2011

These unconferences are entirely community-driven, noncommercial events and have become kind of a family meeting of the PHP development scene in Germany. I hope the same can be achieved Europe-wide. Mind you, the number of tickets will be limited, though!

Jakob Westhoff was kind enough to provide a small write-up of his impressions of last weekend's unconference in Hamburg. If you've ever wondered how an unconference works or why you should go, this will give you a great overview.

I'm really looking forward to the Manchester unconference and meeting a lot of new folks!

Ladies and gentlemen, I am proud to announce... nothing quite yet

The last two unconferences in Hamburg have been a huge success, which has become somewhat problematic. The first unconference saw about 60-80 attendees, while the second one already clocked in at around 120 - and that's just because that was the number where we pulled the plug and couldn't accept any more registrations.

That in itself is, of course, a Good Thing(tm), as we've reached our goal to make the whole thing into an enjoyable experience. Unfortunately, it also showed us the limits of our current venue: More than 120 people would be hard to accomodate at the local University's Informatikum.

The good news

So the good news is: There will be another unconference in Hamburg in 2009! This time we'll try to organize a venue that will allow us to get a few more people in, so we don't have to leave too many people standing outside in the street, right in the pouring rain, crying, freezing, bumping their bloody fists against the door... yeah, okay, I may be exaggerating. A little. Ahem. Anyway...

The bad news (and question for the audience)

The bad news is: We're highly unlikely (okay, now I'm understating ) to make it for the usual April/May date this time. Sorry, folks. Thus, we're now aiming for mid-September, and we've pre-picked two possible dates we'd like to hear your opinion on:

• September 12th/13th, 2009
• September 19th/20th, 2009

As all who already attended one of the past unconferences know, the event is all about you guys and it's your input that makes it the success it has become! So here's the first thing you can do to make this year's unconference a sure-fire hit - leave a comment and tell us which date you'd prefer. Well, that and any other ideas that you might have for the unconference

The part where I complain you can ignore

While most of you have been sitting under the Christmas tree and happily unpacking presents surrounded by your loved ones, I was reading Matthew's blog post about Zend_ACL. What? I finally got time to to these kinds of things now

In the comments, Lukas already mentioned the good ol' PEAR package LiveUser, of which I was the original author and that has been accused of being over-engineered and way too complex to grasp. Looking back I'd have to say people were right. It was too complex and it was over-engineered. And now I'm seeing similar problems again with Zend_ACL.

I haven't used LiveUser myself in many, many years because all of the projects I've been involved with ever since either did not require any really sophisticated rights management, or when they did there already was an existing system in place. Also, coworkers needed a really long time to grasp its concepts and it was a real pain to initially set up and quite hard to debug at times.

While Zend_ACL at first sight is less complex, as it supports only one style of rights management and does not even define any specific persistance mechanism for the storage of resources, roles and their relationships, it deals with a whole different level of complexity: A gazillion of small classes with next to no functionality, a single one for every tiny little aspect involved in the management of rights throughout your application. This sounds like an awful lot of overhead and an extreme case of Javaism (Java-style architecture ported 1:1 to PHP without questioning whether or not it's the right way to do it in the context of PHP).

The idea

Rewind a few years to a previous programming gig, my former Boss Thies came up with a very simplistic way of managing user rights that is a lot more suited to the PHP way of doing things. Basically, you define a list of rights, following a naming scheme that implies a hierarchical structure - like this:

ApplicationName.ModuleName.FunctionName.ActionName

An example of a list of rights for a real-life application could look like this:

• MyGuestbook.FrontPage.ItemList.Show
• MyGuestbook.FrontPage.EntryForm.Show
• MyGuestbook.FrontPage.EntryForm.Post
• MyGuestbook.Admin.ItemList.Show
• MyGuestbook.Admin.ItemList.Delete
• MyGuestbook.Admin.ItemList.Edit
• MyGuestbook.Admin.General.Delete
• MyGuestbook.Admin.General.Activate
• MyGuestbook.Admin.General.Deactivate

...I guess you can see where this is going. A list like this is very easily maintainable and it's so straightforward, you don't even need to think about your rights structure in advance, you can just make it up as you go while you're happily coding away and suddenly feel the need to ask for a user right at some point.

I've written my own implementation of this style of rights management that defines only two methods:

• setRights(Array $rightList)
  Sets a list of rights for a given user. This list could come from a database, a file, anywhere you'd like. Example will follow later on. Invoked only once after a user has logged in.
• checkRight(String $rightName)
  Checks whether the given rights list contains the right with the given name. Invoked at any time a right has to be checked.

Until now, the approach may have sounded a bit too simplistic. What if I have hundreds of rights throughout my application? I'd need to assign every right to every user manually! Not so, because as a shortcut, you can use wildcards to give a user all rights in a given area. In the example above, to give a user access to the front page, but only the item list in the admin section, you could have a rights list like this:

• MyGuestbook.FrontPage.*
• MyGuestbook.Admin.ItemList.*

It's also possible to negate a right by prefixing it with a minus sign. If, for example, I'd like the user to have access to the aforementioned modules, but I don't want him to be able to delete entries, the list could look like this:

• MyGuestbook.FrontPage.*
• MyGuestbook.Admin.ItemList.*
• -MyGuestbook.Admin.ItemList.Delete

Notice the minus sign: It means although the user would have all the rights for the ItemList action because of the wildcard assignment, the Delete function is specifically revoked. You could also use wildcards for revoking a whole bunch of rights, but if you needed to do that, you'd probably have made a mistake with your rights assignments anyway

Groups and roles

I can already hear the outcry: "But I need groups! And roles!". Yeah - about that... there has been a lot of discussion on this topic on the LiveUser mailinglist many moons ago. The general consensus was: Groups and roles are practically the same thing, they're just named differently depending on context. Let me illustrate: A group represents a number of entities (say, "users") sharing the same set of rights. A role represents a set of actions which entities that are assigned to this role are supposed to be able to perform. Such actions can in turn be represented as rights, and there you go - we're back where we were with the group thingy.

Groups (and hence, roles) are easily implemented using the above approach: The simplest method would be to keep a separate rights object for each group the user belongs to, and whenever a right is checked, iterate through the group rights array and do a check on each of the objects it contains. After all groups have been checked, you can then check the individual user rights (non-group rights) that could potentially override group rights. After 10-15 minutes of light coding and the use of only very few brain cycles you'll have your enhanced group rights capable version of the system illustrated above. A more advanced method would be to first merge all rights into one array and do lookups only on the merged structure - the only challenge here would be to think of a system that decides the order in which groups that define the same rights would be able to override each other... but the system is simple enough that nearly anyone could come up with at least something that works.

"Okay", you say, "but if the rights are not defined centrally, but made up as-I-go when I code stuff, how do I find out which rights are actually used?". There are multiple valid approaches to tackle that issue. One possibility would be to do a lookup in some database table and insert the right name if it is not already present. It's an approach I've used myself in the (far) past - it works, but it's quite expensive, especially as right checks are common. You could cache the results, but the caching mechanism results in more code, so we trade in slow database lookups with more logic overhead. A better method is what gettext does - just scan the source for calls to the checkRight() method and write the found right names into some datastore that can be used for writing graphical user interfaces for the administration of user rights. To scan your code you can either use grep or write a really small PHP script.

Examples

I have some example code up that I wrote back in 2006. Be warned that this code has never been tested in production, it is merely the result of a pissing contest with someone who claimed that this would be very complicated to implement - the code was only used to prove him wrong. It should work, but may contain bugs that bite you in places where it really hurts:

• Basic class to check against an array of rights
• A very small and very incomplete unit test.
• Script to scan a directory for right names used in your code

Limitations

What this approach solves (and, I think, solves very well) is the problem of static user rights that are defined for specific actions on the application level. Where it fails is when you have user-generated content for which you want to maintain object-specific ACLs - e.g., user A uploads a document that is supposed to be viewable by everyone, but editable only for users B and C, which are members of user-defined group FooBar. Rights specific to this document would have to be created at runtime. While certainly doable with the above approach, the handling would be a real nightmare, as you'd have to deal with potentially millions of dynamically generated rights. This scenario may be one where Zend_ACL is better suited, although a simpler approach might be to just define four basic rights (create, insert, update, delete) that are dynamically mixed into the user rights array depending on object context - that way, the above approach could even be used in these situations (although it would smell a bit like rape).

Conclusion? Input?

Okay, alright - I haven't really given you the ultimate ready-to-use solution for easy rights management, but hey, Christmas is over
What I meant to illustrate is that rights management can be done in an easy way, a way that IMO suits "the PHP way" much better than all those overly complicated packages like Zend_ACL, phpGACL or, yes, LiveUser. PHP is not about purity, it's about getting things done. People sometimes seem to forget that (including me), so I think a little reminder every now and then can't hurt

What I'd like to know now is what other people (yes, that means you) think about this approach and how would you apply it (or something similar) to user-generated content without abandoning the simplicity illustrated above?

Happy new year to all of the PHP community!

Yes, it is true - I am not dead Just wanted to chime in on the IPC'2008 cheering, as I will be going to Mainz as well and I'm very excited to meet the rest of the crowd once again! I will hold a session titled "Search as a service" in which I will show off my little side-project Marjory. Additionally, you'll be able to find me at the Mayflower booth, which will serve as a Coffee Lounge this year - I'm at the source, Luke! Regarding Marjory, I've just started to port the code to Zend Framework 1.6 (the old version still used some post-1.0/pre-1.5-checkout). I'll also add some new features, two of them having already made it into SVN: JSON-RPC as an alternative to ReST, and Dojo.Data-compatible JSON as alternative to the XML output for search queries, so the service can be used directly with Dojo widgets. Thanks to the latest Zend Framework additions, these features took only about 15 minutes to implement, including looking up the API examples in the manual

Once again, a long time has passed since the last blog post. Why is that? Well, I've been a bit busy with work, the PHP Unconference in Hamburg, getting married, going to Helsinki for our honeymoon and all that kind of stuff, you know - the usual On the PHP-related side of this post, I've created yet another open source project which has already proven useful for the company I've been working with for the last year - namely NorthClick, which are the same guys who are behind Jimdo.com (the free website creator that will undoubtedly one day swallow up Weebly and MySpace, ahem ). While working at some really old code that provided a fulltext search feature, I was at one point incredibly pissed rather unsatisfied due to the fact that said code resisted all attempts to debug it. This lead to the decision to sit down on a rainy weekend to try if I couldn't come up with something more useful, and most importantly, scalable. After about three hours of trial and error with Zend_Service_REST and Zend_Search_Lucene, I came up with a working prototype of a service-oriented fulltext index. The basic idea was to decouple the indexing logic from the application logic, making the fulltext feature completely independent of the main application. The solution for this is a simple XML-based webservice that you throw your documents at, and that will allow querying the index later on. At first I had no idea that a solution like this had already existed until I had a talk with Peter Petermann at last fall's International PHP Conference in Frankfurt, who pointed me to the Apache Solr project, which does pretty much the same thing, but is implemented in Java. Since I wasn't yet happy with the auto-generated XML response syntax and the webservice API of my own project, I then decided to just stealborrow Solr's ideas and make my API and XML syntax somewhat compatible to theirs, so switching between the two projects should be easy (in theory, didn't try it yet). As a result of all this, Marjory was born and can now be found at Google Code. Here's a quick example of how easily a document can be added to Marjory: Well, okay, this will only work for HTML documents located on a webserver. What if your application reads, say, a PDF, extracts text from it and wants to store that in the fulltext index? Just alter the XML: People having experience with Solr will find the above syntax a lot more familiar. The previously shown example is just a nice shortcut for indexing documents located on the web, which was a requirement for the NorthClick CMS. And this is how documents can be searched once they've been indexed: Easy, right? There's more that can be done, like limiting the number of results from a query, specifying the fields returned or specifying the catalog to search in. Marjory also allows to write your own document parsers or adaptors for search engines other than Zend_Search_Lucene. The repository also contains code that shows how to use Marjory with Dropr, the message queueing system developed by fellow Jimdoers Sönke Rümpler and Boris Erdmann. Using a message queue instead of firing the requests against the webservice will further improve your application performance (no more waiting for the indexer to finish processing your document) and make the indexing process more fail-safe (should something go wrong during processing, Dropr will simply try again). If you didn't hear about Dropr yet, have a look - it has proven incredibly useful for distributed architectures like Jimdo.com. If you're interested in how exactly Marjory works and what it can do for you, look at the "basics" section of the documentation or download the slides of the presentation I gave at the recent Unconference in Hamburg.

Hello fellow readers of PHP-Planet (at least the remaining ones who did not yet go on vacation ). After the success of this year's PHP Unconference in Hamburg, Germany, there was little doubt that the event would not remain a single incident. The remaining question was not if, but when should we do the next one? This question can now be answered: On the weekend of April 26th / 27th, the PHP Unconference 2008 will once again take place in our beautiful city. We want to stick to the proven concept of some pre-announced sessions combined with a spontaneus program that is being proposed and voted for on-site by the attendees, as this has worked tremendously well during the first installment. The unconference will most probably once again be held at the premises of the local University - we don't have a 100% official confirmation yet, but things are looking bright (also, the University officials seemed to have enjoyed this year's unconference just as much as the rest of us ). The only downside is that at the same weekend, there's a huge sports event, the Hanse-Marathon, taking place in Hamburg, which is likely to block some of the traffic on Sunday and will also have an effect on available hotels - so if you're planning on coming (and you should ), and wish to stay in a hotel, you should book well in advance. I will announce more details as they're being fleshed out - all information will become available on the unconference blog first, though, so head over there and subscribe to the RSS feed To the official unconference blog (sorry, German only for now)

In case you haven't noticed, PDT 1.0 has been released. PDT, a.k.a. PHP Development Tools, is the shiny new PHP editor based on Eclipse, on which the successor to the current Zend Studio will be based. Being based on Eclipse, it is very, very powerful. It took a little while for me to get acquainted with the little oddities of the Eclipse platform. One can clearly see that it was originally tailored to fit Java development, and although PHP integration is now pretty good, things sometimes still feel a bit bloated and overly complicated. Having said that, I'm using PDT full-time for all my PHP development now and have kissed the old Zend Studio goodbye. Eclipse brings too many goodies to the table to ignore. For those of you who want to try, here's the major drawbacks that can put you off:

• Piss-poor network performance
  When you open a project, many many things happen in Eclipse. The project builder starts. The validators unleash their wild dogs on the files, checking for stupid things you will seldomly care about in PHP development. A lot of files will be opened and closed in very short time. When you have a really large project with thousands of files, and your project workspace is on a network share, don't expect your server to cope with the load. At best, expect things to become slow. Very slow.
• Frequent slowdowns and out of memory exceptions
  Especially when the project builder runs on a very large project, or if you have Subversive installed to update your source files from the repository, or, even worse, if both happens at the same time, things can get ugly. It's bad enough when Eclipse is getting so slow at times that it becomes totally unresponsive, but it gets worse when Eclipse starts throwing Exceptions because there's not enough heap space left.

Note that this goes for Eclipse running with Sun Java 6 on Ubuntu 7.04, on a workstation with 2GB of RAM. And here's what can be done about it:

• If you can, use NFS instead of Samba
  Hosting the project on NFS shares instead of SMB ones dramatically improved network performance for me. That's not to say that it is really fast now, just a lot faster than with NFS. I wonder if this is due to a borked Samba version on my current Ubuntu, because the Windows clients at the office seem to have fewer problems with network performance (although not what I'd call mindblowingly fast either).
• Adjust Java heap space
  Regarding the out of memory errors, I have found a forum post that pointed me in the right direction. Using the settings described there, Eclipse no longer runs out of heap space and seems overall more responsive. The wait times for most operations have visibly increased. In case you don't have write permissions to your eclipse.ini, you could also just start Eclipse with the following options (adjust values if have fewer memory):

  eclipse -vmargs -Xms40m -Xmx1024m

• UPDATE: Turn off unneccessary validators
  Ah, I totally forgot: In the Window/Preferences menu you will find a section called "Validation". There are a lot of validators in here that are activated by default but that you won't ever need for PHP development - such as EJB Validator, JSP Syntax Validator and so on... just turn them off.

Now, where in my directory tree was that class again? Let's just press CRTL-SHIFT-R and find out

It's been a whopping four weeks since the PHP Unconference Hamburg 2007, which I head the pleasure of co-organizing together with a bunch of really cool people from the local usergroup - namely Judith Andreesen, Florian Blasel, Ekkehard Doerre and Hinrich Sager (order is strictly alphabetically ). Just now, after a week of vacation (involving waking up each day to the sound of chainsaws, hammers and nailguns - don't ask) I can finally breathe again and blog about it. It was a blast! I never would have dreamed how successful it came out. We were able to use the facilities of our local university, which sponsored three rooms including beamers and internet access (which was more difficult to set up, but in the end far better than at some commercial conferences I've attended ) and the mensa provided us with lunch (solid, but overpriced). For the smaller in-between snacks, Hinrich's son along with a few friends provided the catering, which turned out to be a really good idea. We didn't just sit, eat and drink, though - the weekend was packed with lots of interesting sessions, and unlike commercial conferences, the attendees were able to suggest and vote for topics they wanted to hear about. In the end, we had one track of pre-planned sessions and two parallel tracks of sessions that were planned just at the beginning of the day. Although this was precisely what we intended, we were a bit sceptical at first how well this would work out - we Germans are notorious for not being spontaneus and needing a plan even for going to the bathroom But all went well nonetheless. Ekke and especially Judith did a very great job moderating the voting sessions. Of course, due to the spontaneous nature of the program, there was not always pre-made material available, so in some cases the speakers had to make the session up as they went along, and reactivate their skills in the long-forgotten art of writing on a blackboard (yes, with actual chalk!) instead of just flipping through Powerpoint slides. I was one of them, hosting a session about form frameworks together with Soenke Ruempler. At one day, we even decided that the lunch break was too long and so a session that could otherwise not fit in the regular timetable anymore was spontaneously squeezed into the lunch break - and it was even pretty well attended I don't even know right now how many people were actually attending, but it must have been way over 50. We could've coped with up to 120, but the fewer people gave the event an athmosphere not unlike a family meeting, just with far more interesting conversations Many prominent people from the PHP, MySQL and PostgreSQL communities attended. In fact, you could have the impression that the event was co-sponsered by eZ systems and MySQL, as there were so many of their employees there From what I've heard, the event was also well-received by the university people, who are keen on getting some more exposure to people working "in the field", as opposed to purely theoretical work. If we did another unconference, the university will without a doubt jump in as a room sponsor again. A few days ago there was a wrapup-meeting, which I was unfortunately unable to attend to, but Judith was kind enough to post a complete checklist of what we did and what we'd need to do if we organized another unconference - should you have similar plans in your area, go and have a look, the post is called How to organize a PHP unconference. I'm sure you'll find the information most helpful. After the huge success of our first unconference, personally, I think that it's not a question of if we're gonna do it again, just when.

The PHP User Group Frankfurt am Main (PHPUGFFM) will be celebrating its 5th anniversary tomorrow and is planning for a big party, so if you're in the area, be sure to drop by! Well, of course it's a geek party (they're developers, what did you expect? ) so there'll be plenty of talks before the actual socializing will start.

Session topics will be Unobtrusive Javascript, $YAJQ ++ (who the hell came up with that one?? ), PHP Homebanking (the sequel), PHP Dos, Don’t and maybes, juicy Joost and ION parser - sounds like a very interesting mix to me.

Go to their website to get all the info on the event

I won't be there, as I live in Hamburg (a.k.a. up north), not in Frankfurt (a.k.a. down there ) and only got word of it today - but I wish all of you guys down there a lot of fun, have a great party

One week left until the PHP Unconference in Hamburg, and finally the goodies have arrived O'Reilly was kind enough to sponsor a care package with lots of cool PHP and MySQL related books, writing blocks, pens and key-holding band thingies (what are they called again?). Among the books are timeless classics like PHP in a Nutshell, PHP Design Patterns, PHP Hacks or MySQL Internals... really great stuff! Here's what I got from them: The books will be given away to the unconference attendees in a raffle on day two... now all I have to come up with is some fun way to raffle them out Thanks a lot to Darren Cooper for contacting O'Reilly and making it happen, and of course to O'Reilly for being a cool company and supporting the Open Source community so much. On a side note, I bought a book from Tim O'Reilly himself once, who was helping out at an O'Reilly booth at FOSDEM in Brussels a few years back. It was really cool to see a Multi-Gazillionaire selling books at a rather improvised table that had a bit of a flea-market vibe to it. One can only like the guy Too bad there isn't a PHP book in my current favourite series of O'Reilly books yet, the "Head First"-series. Kathy Sierra, if you ever read this: Hint, hint