This summer, several PHP developers (myself included) will be embarking on a 16-city speaking tour called The Crafting Code Tour. This multi-state, multi-country event is designed to bring great outside speakers to user groups around the United States and Canada. Today, I’m pleased to announce the dates for The Crafting Code Tour!
We’ll be visiting the following locations on the following dates:
When a discussion thread on the PHP user group leader’s list started up about the cost and potential for outside speakers, most people generally agreed that user groups have a hard time wrangling outsiders to come and speak. The cost of travel is prohibitive, and small user groups often have trouble getting the funds necessary to bring in someone from far away. The internet surely brings us closer together, but there’s still no substitute for the in-person speaker who can share knowledge and experiences, plus a beer or two.
This challenge of bringing in outside speakers prompted an idea. What if, instead of organizing one speaker for one user group, we could organize a tour of speakers to travel to multiple user groups? What if, instead of expecting the user group to pay the expenses, we sought the help of those who care the most for the community? What if, instead of one speaker bearing the burden of travel, we distribute it to many speakers, each having a small role to play in the overall event?
My last day at Mozilla was yesterday. I will surely miss it.
Most jobs I’ve had experienced only a two week resignation period, during which I wrapped up my projects and usually had some tension with those left behind. I was always moving on to something better (and I am in this case, too, but “better” is different in this sense), and they knew it. When the Vice President of Engineering thinks those who don’t live in the office are not dedicated enough to the company, most people wish to move on. And they resent the lucky few who do.
But Mozilla is different. Between the six week notice period (to finish up my goals) and the fact that I actually LOVE Mozilla, leaving was more like a slow, painful death than a quick, jubilant exit.
Looking through the list of PHP frameworks can be daunting. Zend Framework. Laravel. Cake. Symfony. Picking one and learning it can seem like the most important design decision you’ll make. And yet, picking a framework is actually one of the least important decisions you face.
In fact, you don’t need a framework at all. (more…)
It never fails. Someone will write me after reading my book or taking a class with the same story. They were so jazzed: they felt like they were on top of the world, ready to attack their next programming task with vigor! They had studied hard, connections had been made, understandings had been formed. And then, inevitably, reality sets in. They look at their code, same as it was before, and realize: this is going to be harder than I thought.
It can be easy to feel dejected when looking at a pile of code you inherited from four generations of programmer ago. None of the best practices or principles. No tests. Hell, you’re lucky if you even have objects that don’t rely on PHP 4 style constructors. You’re in legacy code hell.
Design patterns suck. This is a cold hard truth faced by many developers. They’d rather ahve their teeth extracted by a sadistic dentist who uses cayenne peppers instead of Novocaine than try and implement the Abstract Factory or the Mediator Pattern. And can you blame them? Reading the Gang of Four Design Patterns book is about as exciting as being hit over the head with a mallet. Seriously, that thing could double as a sleeping pill; it should carry a “Do not operate heavy machinery” label.
Sure, you might think “I’ll pick up a copy of X instead.” But if you write in pretty much any language besides Java, you’re out of luck on the code examples. Maybe, if you’re lucky, maybe you can understand them. But for most of us, we look at Java and our eyes glaze over. And we start dreaming of that dentist again.