Tim Lytle

Tim Lytle likes making things, is a lover of well built APIs, and hates the top reply. A former mercenary developer, he’s built numerous applications specializing in API consumption and creation. Now Tim’s working on things at PhoneBurner. He also tweets sporadically from @tjlytle.

Where do you work, what is your current role?

My main client right now is PhoneBurner, though technically I’m a self-employed contract developer. I’m not sure I have an official title, but I’m working on building new products for PhoneBurner (hard to believe, it involves working with APIs).

How do you use PHP professionally?

I’ve been a professional (that just means you’re paid, right?) PHP developer since 2003 when I took a job at small web hosting company. Since then I’ve worked for various clients and companies, mostly building custom applications or services – not websites – powered by PHP.

How and when did you get involved speaking or writing in the community?

Years ago I met Keith Casey, and he told me I should go to php[tek], I didn’t make it that year, but found a way to go the next. Though it wasn’t picked as a talk when I submitted it to the conference, I signed up for an uncon talk about my experience as a contract developer. A few years later it was the topic of a php[architect] article, and eventually selected as a ‘real’ conference talk.

What’s your best conference memory?

That’s a tough one. I’d say one of my favorite memories was hanging out in the lobby after tek with Jeremy Kendall going through some unit test exercises and trying to figure out why a simple math test wouldn’t pass. It turns out it was a weird floating point issue since we were running the tests in a 32 bit VM on a 64-bit processor.

What advice do you have for someone going to their first conference?

We’re really all just developers trying to fix our latest bug, so don’t be afraid to tell us what you’re working on. If you’re looking for someone to hang out with, find me. I’m the guy with the long beard. And if you find someone with a long beard that’s not me, no worries—people with beards are cool.

What’s your primary OS: Windows, Mac, or Linux?

Linux. Years ago I figured I should just use the OS I deploy code to.

What makes PHP a great fit for writing back-end APIs?

Really, the same things that make it great for the web in general. It’s incredibly accessible in terms of getting started. It’s very flexible in terms of deployment and hosting. And modern PHP, with PSR-7 / PRS-15, and the wealth of libraries composer provides easy access to, gives you so many options when building an API – from full frameworks, to easily assemblable component libraries.

Will serverless kill APIs?

No, the only thing the serverless concept changes is how your API is deployed.

What’s one lesser-known feature of PHP that you use a lot or appreciate?

I’ve recently started using the splat operator (…), and I’ve found it very useful in cases where I’d normally want to pass an array of the same type—as it adds type safety with having to introduce a typed collection.

public function processEvents(Event …$events) {
    foreach($events as $event) {
        // do something
    }
}

public function someplaceElse() {
    // …
    $create = new CreateEvent($system);
    $assign = new AssignEvent($user);

    $this->processEvents($create, $assign);
}

What’s the most frustrating/challenging thing when building an API?

The biggest challenge common to most web-based APIs is designing the API in a way that is open to future change but without breaking existing use. It involves not making the API interactions too complex, or too tied to a specific use case which may eventually become only one of many use cases. Designing the API can be more of a challenge than writing the code that powers the API. Because that design—the paths, requests/responses, behavior that defines the API—may very well outlive the code that you write.