PHP

Decoupling your Composer from GitHub and Packagist made easy

, , , 2 Comments

One of the things I learned very early on about working with a large team, is if you don't make tasks as frictionless as possible, they have a tendency to not get done.

When we bought into using Behat as our functional testing framework of choice, it came with a mandate that when we install Behat, it cannot come from public sources. GitHub goes down. Repositories get updated. There have been instances of repos being compromised. We had to insulate ourselves from all of that risk. Fortunately, Composer has a GREAT tool for this, called Satis.

Satis provides you a way to create your own Packagist repository, complete with distributable tarballs of supported libraries. The one problem that I ran into (and this may have since been fixed? I'm not sure!) is that I couldn't get it to download the dependencies of my dependencies. For example, your composer.json requires Package A which requires Package B. When I tried this, Satis would only build a repository with Package A. Knowing this would cause trouble down the line, I decided there had to be a way to make this simpler.

Out of that, Satis Repository Builder was born.

It will generate a Satis repository and upload it to S3 all with a single command. It's still got some cleanup, but I realized that if I hadn't done it in the last 4 months I wasn't likely to do it in the next 4, and perhaps some feedback (or pull requests!) will spur some new life into my interest in it.

Once you have uploaded your repo, you can simply use the following setup in your composer.json to enforce pulling from your Satis repository:

That's it! I'm sure there's tons that can be done to the repo builder, and I look forward to seeing issues and pull requests!

One last piece of advice from the trenches

When you're using a tool like this to decouple yourself from the risk of third party updates, be sure you are as specific as possible. List all of your dependencies and your dependencies dependencies, so when you do need to go back and upgrade a version of something, you control the scope of the update, not composer. The more specific you are in your composer.json about versions, the less variation you will see between builds of your satis repository.

How we can improve the hackathon experience

, No Comments

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:

  • There generally isn't a lot of clear focus given on what to build, which really becomes an issue when you add the time factor in.
  • The expectation of the quality of 'product' produced is way generally totally undefined for newcomers.
  • They are incredibly short. SunshinePHP had, I think, 5 hours of 'hacking time' available. I think unless it's long enough that you sleep in the middle of it, you're going to miss some of the fundamental magic that can happen, without some help.

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.

1. Pick a theme

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.

2. Explicitly define the level of 'done' you are looking for

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.

3. Give them tools to mitigate the boring parts

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!

Code Evolution: Contact Form (part 2) – A2LAMP

, , , , No Comments

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:

Why you want my old job

, , , , , No Comments

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!

So let's talk about the elephant in the room, shall we?

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.

About those benefits

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:

  1. You get to pick your own platform for new projects -- as the only developer, you decide how to solve the problems handed to you.
  2. You get to work with an awesome team -- everyone here "gets it." The people you will work with here are skillful and creative, and understand how the art/science mesh of things work.
  3. You get to solve actual pain points for actual people -- most of your users are in the office, or next door. Real people that you can see as much (or usually as little) as you like. Building software that you can see the impact of directly is very cool.

The down sides

As with everything, there's some "less awesome" pieces of the job as well.

  1. It's on-site in Lansing, Michigan. No remotesies.
  2. You will be the only full time developer on staff. While that gives you a lot of freedom, if you can't actually swim, you will want to stay out of this water. There is nobody else to blame when your project isn't done on time.
  3. There are on very rare occasions (2-3 times per year, we will say) some very tight deadlines. New websites going up in a matter of days. Usually the scope on these is kept fairly tight however.

The skill set required

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!

Looking back: Sunshine PHP 2013

, , , 2 Comments

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.

First, show up early

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.

Second, don't forget the hallway track

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.

Third, be actively involved

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!

1 2 3 4›»