Conferences, Speakers & Presentations

There has been alot of chatter in the PHP community lately about conferences, speakers and specifically the fact that many speakers at conferences seem to be doing last-minute preparations for their presentations instead of being professional and ready well in advance.

Most recently this came out because a number of speakers for ConFoo (A PHP/Python/Ruby/Java conference in Montreal) were tweeting about working on their slides the days/nights before their talks. Some people starting taking offense at this and calling it unprofessional

First of all, I want to point out a simple fact that while yes, a SELECT FEW presenters are the types that only start making slides the night before a talk. The majority of people (myself included) who are presenting, have made our slides at least weeks in advance (if not earlier). However, we continue to tweak them up until the minute we present. We want them to be perfect, and so we keep reviewing them and modifying them. In fact, I’ve been known to change my slidedeck in response to other discussions happening at the conference, or due to information that was passed on in the Keynote.

In those rare other cases, those speakers are ones that know their topic intimately and are simply planning on having a conversation about the topic with the attendees. In those cases, the slides are less important in the first place.

But let’s put that aside for a moment, because I want to focus on something actually completely different.

The mention of the word: “unprofessional”. Speakers at PHP conferences are, by definition, unprofessional. The PHP ‘conference circuit’ if you will, is one that has grown up in a different manner than other conference circuits that I’ve been familiarized with in the past (Java, Adobe, ‘Web’, etc).

In most of these other areas, the speakers are PAID to attend. Some of the speakers in fact make their living (or a good portion of it) via being paid to present at conferences. They will get a significant payment for being there, as well as expenses being covered.

On the flip side, in the PHP conference circuit, every speaker there, in fact, is PAYING for the right to attend that conference and be a part of it. (Or, if they are lucky, their companies are covering their expenses) Sure, most of the conferences do their best to offset the expenses that the speakers will accumulate, but that’s it. The standard package involves a free conference pass, a night or two hotel per presentation, and airfare being covered. (Though some conferences, like OSCon, cover much less).

There are still so many expenses that a speaker will have. Transportation from airport to conference venue. Parking at their home airport. Meals that are not otherwise provided (usually only lunch is). Extraneous flight expenses (checked bags, etc).

All of this is being paid by the speaker (or their company) for the privilege of speaking at the conference. This is a net negative, not even breaking even, let alone being a paid speaker who would be taking their position as a ‘professional’, being paid to do a job. Heck, let’s not even take into account the direct loss of productivity that the companies take by allowing the speakers to attend (though other great benefits are gained by doing so)

In the end, my point is this. I feel that given the nature of all of these conferences. That the organizers and attendees need to understand the situation and treat the speakers not as a ‘professional speaker that they paid good money to see’. But as what they really are. Far more akin to an Open Source Developer, who is donating their time for the better good and education of the masses.

That is until at least, the situation overall changes. Where conference organizers are able to pay a respectable payment/stipend for the amount of time actually spent by a speaker in preparation and execution of a session. Also where attendees are willing to pay a conference fee that accordingly will cover those speaker payments. It would not be nearly so inexpensive as conferences now are.

An intriguing use of lambda functions

I’ve been working hard on Goodsie.com lately trying to bring it to launch. It’s been great being in on a new PHP project from (near) the beginning, as it frees up a number of things.

One of those, is the fact that I can be using PHP 5.3 and all the new features that come with PHP 5.3. While I’ve used my fair share of the short-cut ternary already (?:), the bigger win for me, are the Lambda functions with scoping (anonymous functions).

I found a very specific use out of the blue of Lambda functions that I have now used and I see as a great use-case. Which is specifically passing functions/logic from your Controller to your View.

In the case of Goodsie, I’m using PHP for my templating language and as usual I’m trying to remove as much logic from my View as possible, while still allowing the view to be malleable.

The specific case I had, was a subview that was generating some pagination code for me. You know, the standard ‘previous, page 1, page 1, next’ section of links. The basic HTML template I had, looked looked similar to:

<div class="pagination">
    <a href="<?= $baseurl . '/page:' . ($page - 1) ?>">&larr; Previous</a>
    Page <?= $page ?> of <?= $total ?>
    <a href="<?= $baseurl . '/page:' . ($page + 1) ?>">Next &rarr;</a>
</div>

Rather straight forward, but I quickly ran into a problem. The way it worked, as you see, is that you passed in a base URL, and the page number you are currently on, and it generated appropriate forward/back links. (Ok, there was also some other logic where it determined if you needed the prev/next links at all, but I’ve removed that for clarity)

But I then had a case, where I wanted to reuse this subview in an ajax situation. Where instead of straight URL’s being passed in, I might want to pass in a javascript function, and have that function be called with the page number as a parameter. That would be nice as I could use it in both situations. What pagination looked like, could completely change, and still work on both cases. Perhaps we’d want to give a full list of all possible pages. Or show a couple forward/back, etc. The view could handle all of that without a change to the controller.

But therein lied the problem. When using a URL based pagination, I wanted to concat the page number onto the end of the URL. But when using javascript, it wasn’t pure concatenation, it instead needed to wrap the page number with the function call. Oh the pain a simple ) could cause me.

I started writing code, where I ended up with tons of switch statements and logic inside of the view. I’d have to pass in two different possible values, a URL or a javascript function. The view at every point where it would output a link, would need to see which version was being used, and from that decide what type of output to create. In short, it was a mess.

But then the solution dawned upon me. A lambda function would work admirably here. So what I did, is inside of my controller I created a function on the fly, that would generate the appropriate type of link that I was wanting. It looks something like:

if ($jsfunc) {
    $url = function ($p) use ($jsfunc) { return "javascript:{$jsfunc}({$p})"; };
} elseif ($baseurl) {
    $url = function ($p) use ($baseurl) { return "{$baseurl}/page:{$p}"; };
}

Now I could simply rewrite my original template, to use this lambda function $url to generate it’s URLs.

<div class="pagination">
    <a href="<?= $url($page - 1) ?>">&larr; Previous</a>
    Page <?= $page ?> of <?= $total ?>
    <a href="<?= $url($page - 1) ?>">Next &rarr;</a>
</div>

Now not only would this work for my specific situation, but ANY controller could reuse this pagination subview and define exactly how it wanted it’s URLs to be formed. Now, the view could completely change around how the pagination section is displayed, show as many, or as few pages as it wants to, and all that without ever touching the controller.

This is one simple example, but I’ve become enamored of this approach. Using lambda functions in this way, you are able to have complicated logic represented inside of your view, but encapsulated/created by the controller. Also of note is the fact that the view is managing to use the $jsfunc and $baseurl values, but without actually having to be granted access to them. This allows for another level of encapsulation, as I exposed one function, instead of 2 separate variables. In the future if other data points start being needed to determine what a URL should be, the view never needs know that, as the controller will continue to update the function on it’s behalf.