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 appr
Truncated by Planet PHP, read more at the original (another 2998 bytes)