Thoughts on PHPBridge

Last weekend at the fantastic Lone Star PHP 2014, I (and 3 other awesome people) presented the inaugural PHPBridge tutorial. You can read more about how that went on the PHPWomen blog.

However, I wanted to take a moment to jot down some more personal thoughts on PHPBridge. Why I pushed for it, why I think it’s important, and my ultimate goals for it.

Before going any further, I do want to take a second to thank the tireless efforts of Michelle Sanver who, for almost a month, stepped up and gave up all of her spare time to work with me remotely on the curriculum. I jokingly say we pair-wrote the curriculum, but that’s pretty much the most accurate description. For about 4hrs every night we would get on a Google Hangout and we would discuss what we wanted to do, I would type it out, she would refresh — complain about Ruby syntax errors I had to fix — and she would read it back and offer suggestions and corrections. Rinse and repeat.

I was very concerned that the curriculum would only represent my view of the world, and having at least one other voice along with the reviews from others like Elizabeth Smith, Matt Frost, Daniel Cousineau and Bob Majdak Jr was essential to making a balanced offering.

I was first exposed to RailsBridge via work where we’ve hosted a number of these events in our San Francisco offices. After learning more about them, and their goals, I decided that they were a perfect role model for our efforts — albeit with the minor exception of not restricting our workshops to just women (and those who identify as women, or are invited by a woman) as this is counter to PHPWomen’s goals — though any given workshop organizer can make that decision for themselves if they feel the need. Thanks to their choice of CC-BY license, we’ve been able to use their fantastic Suggestotron idea and the Sinatra app that runs the documentation site.

It has resulted in a curriculum that I am proud of. Prior to starting on this journey, I wrote out a long document that I sent around to the folks at PHPWomen, members of the community, and the community team at Engine Yard for feedback. In it, I stated my goals, and this is a direct quote:

The primary goal with PHPBridge is to give inexperienced people the opportunity to learn to wield this tool they use probably every day for leisure. To empower and delight them by showing them that they can control this machine, and that they can use it not only to browse the web, but to build it.

However, this is the projects primary goal, my own personal goal is a little simpler:

I love what I do, and I want to share it with people that they might love it too.

One of the things we often talked about when starting out the curriculum was how and why we started programming. The why was easy: we wrote some weird words, and our computer did something. Something we made it do. It was pretty awesome! The how was a little harder. We wanted to jump-start our attendees passed some of the unnecessary things we did, while still making it feel like a natural progression from start to finish. An example of this is only presenting them with prepared queries — this is the only way forward, no miss-step, no security issues. Ultimately, however, we wanted our attendees to have that moment of delight, and ownership, not once, but multiple times.

During the creation of the curriculum we hit upon the idea of “Error Driven Development” — try something, if it explodes, try to fix it. This is how most of us started out, but for a newcomer, it can be scary — by giving it a name, and by intentionally including error scenarios in the curriculum, we teach them that errors are a good thing — an opportunity to learn and fix your issues (and we all know the pain of the dreaded white screen!)

This is why our curriculum starts out by creating an index.php, add.php, edit.php, and delete.php, all in the webroot, with one class, also in the webroot, TopicData.php. Through these, we learn basic HTML, forms, CRUD, and about using objects (though not necessarily the why of OOP, we approached this more like this is just how things are).

To move away from the tedium of having done the same thing (DB interaction) four times, we move on to implementing Bootstrap 3. This step is where most folks ended their time with us — but at the end they had a pretty darn good looking app that worked. That they made.

The remainder of the curriculum focuses on refactoring our app to a more framework-like setup, with configs, a router, controllers, models, and templated views. We use pain points to drive this refactoring — templates so we can easily add Bootstrap to all our pages, autoloaders to stop multiple require statements, routers to have pretty URLs, etc.

We end by implementing a new feature (voting) using all the things we’ve setup — our users seeing how it all comes together at that point.

Going in to the workshop I was nervous, and excited — I remembered the ah-hah moment from 30+ people the year before when I managed to demystify (and un-scarify) SQL for them, and it was one of my primary motivators.

So, PHPBridge 0.1 was a success in many ways, not so much in others, but it was a starting point I am happy with. I have many goals for the progression of PHPBridge:

• Revise the curriculum to solve the issues we discovered at Lone Star PHP (and of course, this will be an always evolving document)
• Work with user groups, companies, and conferences to host more workshops
• Provide daycare for attendees (rather: for their kids!) — this is a major barrier for some
  • While we know it won’t always be possible to provide, we do want to provide some framework around it, such as requiring that it always be licensed child care professionals, etc. Attendees should know that if it is provided, it meets a certain standard, and if it cannot be free, will have a reasonable cost.
• Provide loaner hardware for attendees. Another major barrier, especially for disadvantaged minorities, is lack of access to a laptop.
• Provide transportation assistance. Similar to the laptops.

On the curriculum front, I want to review and revise the Frontend curriculum from RailsBridge. I will pursue better ways to collaborate on this as it’s completely backend language agnostic.

I’d also like to move on to an Intermediate Curriculum, and then finally on to a kids curriculum. Currently, there is the amazing Young Coders for Python, and KidsRuby, and I’d like to also bring this to our community too!

Whew… that was a lot of thoughts. I hope that in reading this, you can see why I am passionate about this, and are now excited about the idea of proliferating your love of our craft, and will contribute to the efforts.