Today we talked about working our way through the how and the why of using Vagrant and Puppet to virtualize our development environment, bringing our development environment in line with our production environment, and easy shortcuts to get something simple up and running without having to know the nitty-gritty details of Vagrant and Puppet.
For code reference on on this project, check out my GitHub repository.
Additional resources:
So I have been thinking a lot about hackathons and community participation (and the barriers thereof) lately. Let’s be clear here, I am talking about hackathons which feature a competition of one nature or another, however I’m sure some of this will be applicable and/or helpful generally.
It started with attending the hackathon at SunshinePHP, and then became fueled by talking with members of the Developer Outreach program at Mashery.
The way we generally do hackathons (as a PHP community) right now feels fundamentally broken. A few of the problems I see:
I get that it’s difficult to add a hackathon to a PHP conference and make it a first class citizen. I get it. So instead of saying spend more resources on improving the hackathon, I have some ideas on how to take the current constraints and try to work within them to make the experience better while still fitting in to the traditional timeframes we have allotted.
Having a theme for your hackathon will provide an overall context to how people work at deciding what project to do. It’s been said many times over that having too many choices is bad. Help out your participants and give them a container to think in. Let them wander outside of it if they like, but it will help many people. Any theme will do, contrived or not, provided you follow the other tips below.
A lot of hackathon participants will be new (or relatively new) to the event style, so they enter it with whatever context they generally operate from. Myself, I’m always looking for the product in something, the viable business model, and the polish. Which is incidentally the totally wrong vantage point to use for a few hour hackathon. Let people know this. Tell them you’re expecting (maybe not even fully functional) prototypes of an idea. Tell them to focus on the raw creative pieces, and to leave the polish behind.
If you’re doing an API hackathon, write some wrappers for a few curated APIs (here’s where the theme comes in useful — use that to guide which APIs you pick to promote). If you’re doing a technology hackathon, have hard-copy references of important pieces of information to make it easier for developers to track and reference several places at once. If you care about the final presentation of the submissions (the polish), give developers a template to work from (probably based on Twitter Bootstrap, but not necessarily). Give them the right tools and setup to let them focus on the thing that they are good at.
There are other issues we face with conference bound hackathons (namely placement in the schedule, timing of that placement, and competing interests) but those just come inherent in the form-factor of the two or three day conference. If you don’t like these constraints, be sure to take a look at dedicated hackathons like the SoFloPHP Hack-a-thon that my friend Adam Culp and the SoFlowPHP User Group are putting on in the next few weeks. Florida too far away? Start your own. Need help? Ask me, and I will work to get you in touch with people who can help. Happy hacking!
On Saturday, February 16th, 2013, I talked my way through setting up the same sort of contact form we set up in Code Evolution: Contact Form (part 1) using Silex instead of creating our own framework. There was a lot of invaluable discussion around the room about the value frameworks bring to the table as well.
For code reference, you can see where we started from, and what the code looked like when we were finished.
Related links:
So, for those of you who haven’t heard, I have put in my notice at my current place of employment (the Democratic Communications at Michigan State Senate) and taken a position with Mashery effective March 4th.
Needless to say, I am really excited, but it does put my current team in quite a predicament, because they really need a developer!
The reasoning behind why I am taking a new job is multifaceted, but essentially it boils down to it feeling like it was time to look at what else was out there. There is a lot of interesting stuff going on here, and a ton of benefits, but nothing I was truly passionate about anymore.
The benefits here are great. 5+ weeks of PTO, great insurance, 401k matching, the list goes on and on. And that’s just the standard benefits. Let’s look at a few of the technical benefits:
As with everything, there’s some “less awesome” pieces of the job as well.
Realistically, you need to be able to handle everything involved with building a website beyond the html/css. You will have to set up vhosts in Apache, and understand the basic workings of source control (we’re set up with git and bitbucket). Deployment strategies are varied — new stuff uses capifony and capistrano while older stuff deploys via FTP or (and I’m very very sorry) issuing a git pull on the live directory structure.
Current projects you will maintain will involve Symfony 1.4 (current CMS), Symfony 2 (some internal tools), and Silex (other external sites). Future projects can use… whatever you care to use, provided you’re not intentionally leaving a pile of junk for the next person to pick up.
You will be given all the rope you need to hang yourself many times over, so you have to really be self-reliant on completing your projects, as there is nobody else here who can do your job, for better or worse.
Interested? Check out the job posting on LinkedIn for more information.
If you have any questions, please feel free to contact me, or just ask in the comment area below!
Warning: there is some name dropping. Okay, a lot of it. The only goal of it is to try and convey the extreem importance of attending smaller conferences like Sunshine PHP. Close knit communities in tight quarters breed very interesting opportunities to talk to people you normally might not have a chance to. Take advantage of it every chance you get.
If at all possible, come in the day before the event. Not only will you wake up rested for the conference, but you can take part in pre-conference festivities. The night before the conference, a rather large group of us all went out to dinner together. In no particular order (and please forgive me if I have left anyone out, or added anyone, it has been quite a few days): Jim Ruga, John Kary, Brian Fenton, Jeff Carouth, Sebastian Bergmann, Anthony Ferarra, Matt Davis, Damon Jones, Matt Frost, Beth Tucker-Long (and her family), and Lonnie Brown.
Now even if you’re not super community savvy, a few of those names should stick out like a very sore thumb.
I know, I know. You’re excited to go see all the speakers give their talks. By all means, if there are talks that look like they absolutely cannot be missed, then go watch them! However, don’t forget that you will likely be missing a rare opportunity to sit down and have a (near) one-on-one conversation with someone you normally may not run into. I lost count of the number of times I saw Cal Evans and Paul M. Jones talking at a table with a couple empty chairs, or Anthony Ferarra, or any number of people. If there’s someone you want to be able to have a prolonged conversation with, look out for them between talks and talk to them.
The more you participate in the conference, the more you will get out of it. Join the hackathon, play jeopardy, or just Drink With Friends(tm) (seriously, how is that NOT a game yet??). Introduce yourself. Break out of your shell. As out of place as you feel, others feel the same and are just hoping someone comes and talks to them. If you talk first, then you don’t have to wait so long! Want to meet someone but not feeling up to introducing yourself? Come find me (or, if I’m not there, ping me on twitter and I’ll try to find someone to help you!) and I will go do the “hard awkward part” of the initial introduction.
Seriously. The PHP community is an amazing group of people. If you love the community, it will love you back. I’m not just talking about the publicly visible members, I’m talking about everyone. Each and every one of us contributes to the community in our own way, and it needs all of us to thrive. Coming to events like Sunshine PHP helps to foster the community feeling, because people stop being these faceless nicknames. It makes it easier to communicate with people online, and helps you feel like less of an “impostor” at future events, as instead of simply going to a conference, you get to go see your friends again!