Flipping the coin on Iterator or deriving the subject-observer design pattern in php

Continuing from parts one and two of these series of posts I'll stick to iterators for the time being. I'll make a quick overview of the php Iterator and IteratorAggregate interfaces. Then will derive a pair of Observable(Subject) and Observer interfaces as their mathematical duals by flipping the methods (arrows) around and see what comes about. In fact, this technique was used by the C# team to derive the Rx framework.

Iterator design pattern in php (part 2)

Ok, let's continue with iterators. In part 1 I showed an approximation of streams which can be traversed step by step. You may wonder why bother? The answer is simple. I want to show how to build a library of iterative combinators, which can be easily composed to form larger iterative combinators, which can then be executed over an arbitrary collection. The collection, or the stream, together with the logic to enumerate it form an iterator.

Iterator design pattern in php (revisited)

In this post I'll try to sketch a number of related ideas about working with sequential collections, all of them expressed in php. Enumerations, enumerables, interators, iteratees and their cousins have been tortured to death, but as Eric Meijer and his team working on LINQ and Rx frameworks for .net show, it pays off doing it systematically. I'll revisit the Iterator and Subject Observer design patterns and will derive them systematically from first principles.

In php iterators come handy for all kinds of work on sequences - usually using

foreach( $sequence in $key,$value) { ... }

The problem with foreach is that it is not composable, but there are a lot of functions and operations on iterators which are, at least in theory. I will try to show how to achieve composability by, first, composing the processing of each individual step and, later, by composing iterators. This can lead to easily reconfigurable applications and a more declarative style of programming.

Micro-benchmarking php streams includes part 2

In part 1 I've reported the results of a micro-benchmark designed to compare the performance of plain php includes vs includes via streams from a sqlite database. In this post I extend the test cases with two more no-includes same work, to serve as a base case and includes from a mysql database, the code is the same as in sqlite case, the connector differs. You can find the code attached at the end previous post.

Overall, having in mind the random factors like netbook load (CPU and IO), the differences between the different test cases are insignificant on the test machine - Acer Aspire One netbook.

Please let me know if you decide to run these benchmarks. I will be especially interested to see what are the differences.

These results are encouraging enough to merit developing a more substantial test. I'm interested in benchmarking drupal. What scenarios would you suggest?

Micro-benchmarking php streams includes from database vs standard includes

During the drupal plugin/update manager discussions I had an aha moment. One of those weird and wonderful ideas came back to me. What if most of the code lived in the db? One would be able to arrange the co-habitation of several concurrent versions of the same website relatively easy. Backups would mean database backup.

Funnily enough, this can help two opposite (scale-wise) types of users - the bottom end, cheapest or free hosting ones and the load balanced crowd.

Why "back"? Well... I had this idea ever since the user streams appeared in php, version 4.3 or there abouts, but it just nestled cosily in the back of my mind, waiting for love, the shy little thing.

running a conference using openconf

I've been involved in the organisation of a number of scientific conferences over the past few years. For example 4m/ICOMM 2009 (submissions), I*PROMS 2009 (submissions). The conference sites are usually powered by drupal, the submissions using OpenConf. Managing the submission and peer review of papers is a chore, unfortunately, as is often the case, software gets in your way. So here I try to skim over some of the experiences I had with OpenConf - the good and the bad.

I've tested indico, which looks like a very good system, but it is heavy and over-engineered, especially if you want to run a couple of events, and not hundreds or thousands. It might be good for organisations managing a big number of events, but not for us.

After going through a number of trials I've settled on openconf. It was simple. It fitted the current web infrastructure - LAMP. I reckoned, I could eventually integrate it, or simply transfer some of the data into drupal, and maybe even benefit from code reuse. Surprisingly, I ended being both pleasantly surprised and not so.

php closures and lambda functions rfc

There is a discussion going on in php land about introducing closures and lambda functions, there was even a discussion on haskell-cafe about it (chx strikes again ;). About time, I would say. Having this functionality is a bonus. Having it implemented badly or half-arsed is going to do more damage than help. This is a short summary of what do I understand from the rfc and what do I think about it.

drupal 5.0 beta

Sweet. Really. There are not too many big changes, but funnily enough they are felt more than previous betas/pre-releases.

First you are struck with the really nice, simple, stylish, cute, add your own epithet default theme - Garland. You can modify the colour scheme online. So palette builders enjoy and share.

Kudos to the reorganised admin pages and everyone involved in that. At first glance it is allright.

The infamous cck and views leave a lot of traces in core.

All I can say it took me between 5 and 10 minutes to setup a basic group blog site. That includes database creation magic, (php) file uploads, user registration ...

Time for theming, upgrading and code porting I suppose. Just where could I get it from?

Models, records, databases, friends and foes

the beginnings of a long on DB related pattern discussion.

First sketches

Ok, Let's recap:

  • Relational database (SQL) tables are records. We can view them (in our heads) as record type definitions.
  • JOINS define (some kind of) derived union types.
  • SQL CROSS JOINS are full cartesian products, i.e. union types where no name folding/aliasing is done by the imaginary type system

How can we model that in php?

Classes (and objects) are records. Arrays are records too. Both are candidates for doing the job. We need to be able to somehow represent this (meta) type information and manipulate it. The aim is to have a natural feeling/looking abstraction of the database in php. It should be flexible enough, for us to modify the relations at runtime, as we need. It should allow us in the long run to have a near optimal speed and not too much complications in the end code. That is a tough cookie.

Powered by Drupal, an open source content management system