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!

For code reference, you can see where we started from, and what the code looked like when we were finished.

Related links:

• Code Evolution: Contact Form (part 1)
• Silex Framework
• Symfony Framework
• CodeIgnighter Framework
• Slim Framework
• Zend Framework

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!

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!

You can find the source code for where we started and where we ended for this talk on GitHub.

Other links:

• HTML5 Elements
• Email autocorrect – Kicksend’s mailcheck
• Why register globals is bad
• True/False weirdness
• Alternate control structure syntax
• Re: the array trailing comma debate
• Cross-site Request Forgery (CSRF)

I’m looking forward to so many things. I have made many friends over the years, in the Symfony community specifically and the PHP community at large. I want to greet old friends, and new ones. Seriously — come shake my hand and say “HI!” Beware — I will do the same to you!

The Talks

There are SO many good talks. Seriously:

• “Symfony2 + EmberJS for fun and profit” and “PHPUnit Best Practices” — I have no idea which talk I will attend. I know Dustin is an amazing presenter, but I’m curious to see if Sebastian shows underutilized parts of PHPUnit I have yet to discover.
• “From the Ground Up – Coding, Deploying, and Scaling with AWS” and “Building OpenSky with Symfony2“ – I’m sure Rowan’s talk (AWS) will be full of great information, but I’d also love to see Jonathan present about how a large scale application has been built with Symfony2.
• “Silex, the Microframework” — I am already quite experienced with Silex, and will not attend, but if you’re curious, having talked to Ben on IRC, you will enjoy this.
• “From POX to HATEOAS, Our Companies Journey to Build a Hypermedia API”  – I’ve talked to Luke in IRC very rarely, and am interested in building stronger API systems, so I’m curious to see information on how his company has evolved their platform. If you have ever heard me talk about improving as a developer, I always say it happens a day at a time. I’ll bet Luke has a great story about his company’s evolution.
• “Replication with MySQL” — I’m hoping I will have a need for the knowledge bomb Ligaya will drop in this presentation.
• “Dream, Experiment, Create, and Share” — If you haven’t seen Fabien present, this is your chance. He makes it look so easy.
• “DOs and DON’Ts of MongoDB“ – I’m looking forward to getting some great use-cases out of Jeremy’s talk. I don’t have any experience with MongoDB, and I’m hoping that will change.
• “How Kris Writes Symfony Apps“, “Introducing Tests in Legacy PHP Applications“, and “Bringing Good Design to the Table” — I honestly have NO IDEA where I will end up here. Seeing Kris’s process when developing a Symfony2 app has the potential to be quite interesting, as other people always do things differently. However Jeff’s presentation on introducing testing and Brian’s talk about database design also sound excellent. So torn.
• “Cryptography for the Average Developer” and “Symfony and Javascript: Combining the Best of Two Worlds” — Anthony and I have tweeted back and forth on occasion, and I’m curious if he has added any more to the talk beyond what I have read from him online. On the other hand, Nacho is going to talk about JavaScript frameworks and Symfony2. Sorry Jordi — I use composer every day. However, if you like Chocolate, tell Jordi that Jacob said he had some for you.

And that’s ignoring Rasmus, Cal, and Keith’s keynotes — those will be excellent.

The People

It adds an entirely different dimension to your community involvement (on twitter, on IRC, in mailing lists, on GitHub) when you have met the people you are interacting with. Heck — at Symfony Live 2012 in San Francisco, I used Fabien Potencier as my Rubber Duck! Having that context, having met them in person, deepens the interactions you have with people online, and helps to make them more than just an internet handle. I’m looking forward to seeing so many of my friends again, while also taking the opportunity to meet some new ones as well.

The Venue

Seriously. Florida. In February. Do I really need to say more?

And Finally

If I find out you came to SunshinePHP and didn’t shake my hand, I will personally convince GitHub to delete all of your code be very grumpy.

I think the biggest things I want t take away from 2012 are a few key lessons:

Don’t Be Afraid of What Other’s Think

If you spend your life mired in worries about what others will think of what you are doing, you will never get anything done.

Just do.

Too much of our lives (collectively) are spent wondering about what others will think about what we are doing? So what. Who CARES if you are wrong. People are wrong ALL OF THE TIME. What matters is that you are not so attached to your wrong opinion that you don’t change it when presented a valid argument otherwise.

It’s said the most ‘thought to to be smart’ people aren’t smart because they’re right but because they are quick to change their minds.

I, of course, have the luxury of never particularly caring what others have thought of what I say or do. It’s lead to some pretty awful predicaments — but some pretty awesome ones too. Who, among my close friends, would have pictured me as being one of the ones to immediately volunteer for Symfony Jeopardy at Symfony Live? Especially when I am culturally dumb and (at time time) was quite technically deficient. That didn’t stop me from answering the only then-to unanswered question though!

Just do.

Go up in front of everyone, be a goof ball, have fun, laugh, be silly. Anyone who actually cares in a bad way isn’t anyone you want to associate with anyway.

Just do.

Don’t be afraid of what others will think. Seriously. Most commonly, what most other people will be saying is “Gee, I wish I could do that!” And you know why they can’t? BECAUSE THEY ARE AFRAID! 99% of the people who would say anything negative would never have the nerve to do anything like what you are doing. It’s 100000x easier to criticize than to produce. Be sure to check the background of those who give you negative feedback and take their input with the appropriate level of expertise it warrants.

Just do.

Get out in the community

The PHP Community in general is AMAZING. It’s full of brilliantly smart people you can talk to, and gives you external input to your internal processes. If your local community isn’t as as deep into the things you are? Learn to teach them! Learn about how to talk to other developers, how to share your skills and techniques. You’d be surprised what you’re capable of.

If you haven’t spoken to groups before, consider giving a few talks to a local user group. Most likely they’re running their regular speaker lineup through the wringer, week after week, and offering to talk about something (anything!) that you know even passingly well enough to talk about (I once essentially winged a talk about design patterns — shhhh!).

The other thing being in the community will do is give you a feel for the pulse of where things are heading. There are currents and drafts in the community which you don’t catch unless you’re paying attention. See what’s on the horizon, and pay attention. You’ll never know what you’ll miss if you’re not paying attention.

Prove you can ship

I can’t reiterate this enough. The value of someone who can actually ship a product is waaaaay above someone who can only point to minor contributions in a larger project. If you’re one of those nameless cogs in a giant organization, it’s time to join an open source project or build your own thing on the side. Seriously. Nothing shows your value more than being able to to actually ship something. In the world of business, ideas are cheap, and execution is everything. Show people you can execute, and you will open doors.

Know your stuff

Read up on the important things core to being a high quality software developer: Patterns, Anti-Pattens, and Code Smells, among other things. These will teach you the do’s and don’ts of our industry, our trade. They will show you what to do, and often more importantly, what not to do. It’s the same as new inductees into Martial Arts learn Kata’s, new developers need to learn these patterns, anti-patterns, and code smells. It gives you the tools to reflexively approach similar problems in the future, and tools to expand on when you need to create something out of thin air.

Don’t be afraid to be wrong

Look at my blog, or the advice I give out in #symfony — I’m “wrong” all of the time. There’s usually a much more efficient way to do something than I recommend — but I don’t know it! I help people get stuff done. The academic stuff can be left for those Ivory Tower folk. I’m much more interested in what gets stuff done in the trenches. Getting something done is more often much more important than doing it in the best possible way. Working implementations refactor much quicker than potential implementations grow while wandering in the sea of WTF I HAVE NO IDEA WHAT I AM DOING?!. Being wrong is not a bad thing. It means both that you were strong enough in your opinion that you could voice it, and that when presented with solid contrary evidence, you changed your wrong opinion into a right one. How awesome is that?!

Enjoy what you do

We’re in this because we have a passion for either building better code, or building things people love to use, or hell, even just building things. But if you’re not enjoying your work – seriously the door is right over there. Life is FAR TOO SHORT to spend your days doing things you loathe. If you’re going to do something for your career, make sure it’s something you enjoy. I avoided doing development as an actual full career for many many many many many many many many years, because I was afraid that if I took what I loved and made it a job, it would never be the same. Interestingly, I was right — it was never the same. Now I love going to “work” almost every single day. Seriously, it’s that simple. Do what you love and you never work a day in your life. Honest.

Now with that out of the way

You may be asking yourself “But this is a recap — what do YOU do during this year?” Well, let’s see:

1. I went to Symfony Live.
2. I started blogging more regularly.
3. I was more active in #symfony, #silex, #phpmentoring, #protalk, and #symfony-dev (yikes, right?).
4. I contributed to the Symfony Documentation.
5. I started attending User Groups regularly (in Lansing, and Ann Arbor).
6. I gave a talk in front of 100+ people.
7. I gave a talk over 30+ minutes.
8. I have at least one person using one of my open source bundles for Symfony2
9. I have given three people technical feedback on their technical products which have (I feel) reasonably improved the quality of their product (I think I have a knack for this — have sent an email to php|arch to be a technical reviewer — look for this in 2013′s recap!).
10. I convinced my 4 best business friends to all be business friends together.
11. I started mentoring officially (Uzo, Luis, and Yitzchok — you guys are the best folks a mentor could ask for, really!).

What do I want to do, going forward?

I’ll tell you what’s on my list.

1. I want to launch a product (in the works)
2. I want to give a mainstream talk at a conference (not an unconf talk)
3. I want to be more involved in the community (you guys are awesome, seriously!)
4. I want to help more people hate their jobs less (hey, it’s what I do…)
5. I want to blog more (is this cliché?)

Anyway — 2012 was great, let’s make 2013 even better!

Our example today will hopefully be pretty close to form, and while generally contrived, will simply illustrate the use of the Decorator Pattern.

Let’s say for instance, you run a video rental service. Let’s call it… SmedRocks. Now your crazy programmers have already built your inventory tracking system as a web service, and you have no control over how they have implemented it, but you have to fight the good fight and soldier on. Features must be implemented. To make this even simpler, our API has one function:

getVideos – This returns all of the titles we have, no matter if they are currently rented or not.

Now getVideos returns a JSON array like so:

{
    {
        'title': 'Some Movie',
        'status': 'rented'
    },
    {
        'title': 'Some Other Movie',
        'status': 'available'
    }
}

I’m sure you can already see the problem with how it’s returning data. Rented movies and available movies are all mixed in! What a pain!

Ok, so let’s look at what we need to do to get started. Let’s make our API. This isn’t how you would ACTUALLY do this, it’s just an example to get us moving along:

class MovieApi
{
    public function getVideos()
    {
        return json_decode(file_get_contents('http://example.org/rest/getVideos.json'));
    }
}

Excellent! We can now get our videos, but wait — we’re in the middle of building this and example.org seems to have gone offline. This isn’t going to help us get this going! So let’s refactor real quick so we can keep going on other things.

interface MovieApiInterface
{
    public function getVideos();
}
 
class LiveMovieApi implements MovieApiInterface
{
    public function getVideos()
    {
        return json_decode(file_get_contents('http://example.org/rest/getVideos.json'));
    }
}
 
class OfflineMovieApi implements MovieApiInterface
{
    public function getVideos()
    {
        $json = '{{"title": "Movie 1", "status": "rented"},{"title": "Movie 2", "status": "available"}}';
        return json_decode($json);
    }
}

Look at that! We’ve now defined a central MovieApiInterface which both implementations conform to, and have both an online and offline implementation which will also ultimately make writing tests easier.

Ok, now for the juicy part: we need to be able to ask this system for just rented or available movies. We could extend each API implementation, but that’s going to be some duplication we can live without.

Enter the Decorator Pattern.

With the decorator pattern, we can build an object that accepts a MovieApiInterface object in it’s constructor, and provides a uniform higher-level way to interact with our lower-level API.

Again, this is basic code to get you thinking, not optimized production-ready code.

class SpecificMovieFinder implements MovieApiInterface
{
    protected $movie_api;
 
    public function __construct(MovieApiInterface $movie_api)
    {
        $this->movie_api = $movie_api;
    }
 
    public function getVideos()
    {
        return $this->movie_api->getVideos();
    }
 
    public function getRentedMovies()
    {
        $movies = $this->getVideos();
        $rented_movies = array();
 
        foreach ($movies as $movie) {
            if ($movie->status == 'rented') {
                $rented_movies[] = $movie;
            }
        }
 
        return $rented_movies;
    }
 
    public function getAvailableMovies()
    {
        $movies = $this->getVideos();
        $available_movies = array();
 
        foreach ($movies as $movie) {
            if ($movie->status == 'available') {
                $available_movies[] = $movie;
            }
        }
 
        return $available_movies;
    }
}

Now we have a simpler API that actually conforms to how we will use it in practice instead of how the API designers built the service. This is great! They get their way, and we get ours. Everyone wins.

So how do we use it?

// development configuration
$offline_api = new SpecificMovieFinder(new OfflineMovieApi());
 
// live configuration
$online_api = new SpecificMovieFinder(new LiveMovieApi());

Now we get the same functionality on multiple implementations, and as an added bonus, our SpecificMovieFinder also still implements the MovieApiInterface allowing us to use it interchangeably with any other service that may need our api down the line!

My good friend Beau Simensen pointed out that unfortunately, my example is a little deficient. I’ll let his gist do the talking:

Thanks Beau!

What are some other places you can think of using this pattern?

I just wanted to share and provide a further explanation on the Proxy Pattern example I gave at the Ann Arbor PHP/MySQL User Group today.

Source: https://gist.github.com/4302634

Now, Dan had mentioned that this could be done through simple inheritance instead of via interface contract, and after some thought, I realized that I disagree.

Typically with an API object, you will initialize with a remote URL, and perhaps a token:

public function __construct($api_url, $auth_token)

But remember our new Cache API proxy only takes an API object and a Cache object.

public function __construct($cache, $api)

This fundamentally changes the contract that the initial API object creates, and as such, should then NOT extend the original API implementation.

Part of doing OOP well involves the management of contracts we establish. Changing the rules of a function in a sub-classed entity violates the Liskov substitution principle (as referenced in SOLID object oriented design).

Now, you COULD subclass the MyApi class, and add the Cache control via setter injection, but personally I don’t think that implementation is nearly as clean as providing a proxy object to add the caching functionality.

p.s. I’ll leave QuickTime running but I think it did eat the recording of the presentation – sorry guys! I’ll put the slides up soon but I don’t know how much context they will provide given how light they were compared to the commentary that went along with it.

Update (12/07/2012):

It has been pointed out that my example was perhaps a little too contrived, so I think I found a better one.

Let’s say you’re building a system out, and you know you want logging, but you don’t know what sort of implementation you want to do for said logging. Given that instance, let’s start with our basic interface:

1
2
3
4
5
6

interface Logger
{
  public function info($message);
  public function debug($message);
  public function fatal($message);
}

Ok, great! So, because production schedules are tight, we decide to give a very basic implementation first:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class MyBasicLogger implements Logger
{
  public function info($message)
  {
    error_log('INFO: '.$message);
  }
 
  public function debug($message)
  {
    error_log('DEBUG: '.$message);
  }
 
  public function fatal($message)
  {
    error_log('FATAL: '.$message);
  }
}

Alright! We now have our basic logger implemented!

Oh, what’s that you say? You want to use Monolog in place of error_log() in production? sure!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

class MyMonologLogger implements Logger
{
  protected $monolog;
 
  public function __construct($monolog)
  {
    $this->monolog = $monolog;
  }
 
  public function info($message)
  {
    $this->monolog->addInfo($message);
  }
 
  public function debug($message)
  {
    $this->monolog->addDebug($message);
  }
 
  public function fatal($message)
  {
    $this->monolog->addCritical($message);
  }
}

Now we have two ways of logging messages. Now comes the constraint that we want to be emailed when fatal errors are logged. Your first instinct would be to extend MyMonologLogger and add it by overloading fatal(), but then we can’t use that functionality on any other logger we ever build. How do we build this functionality in a way that we can reuse over and over again? The Proxy pattern.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class MyEmailingLoggerProxy implements Logger
{
  protected $logger;
 
  public function __construct(Logger $logger)
  {
    $this->logger = $logger;
  }
 
  public function fatal($message)
  {
    $this->logger->fatal($message);
    mail('admin@example.com', 'A fatal error has occurred', $message);
  }
 
  public function info($message)
  {
    $this->logger->info($message);
  }
 
  public function debug($message)
  {
    $this->logger->debug($message);
  }
}

And now, no matter what we choose as our logging backend, now or in the future, we will always easily be able to have those fatal errors emailed to us by simply putting our chosen logging system inside an instance of MyEmailingLoggerProxy.

I hope this clears some things up!