Sunshine PHP 2018 (second half)

And now for the second part of my Sunshine PHP 2018 wrap up. You may want to read the first half before, more for chronological purity than because you won't understand what's happening here.

Day two

After hanging out with a bunch of really smart people too late into the night, the day arrived earlier than I would have liked. Time zones are never fun for developers either because they're hard to code around or they make you get up in the morning at a different time than your body is used to.

Keynote: How to Communicate When You are from Mars and the Business is from Venus - Nancy Gaines

Keeping with the conference's main theme, Nancy identified four different communication styles and had use each try to identify which of those communication buckets we primarily fell in to. It was interesting trying to determine whether I'm more of a Blueprint or Knowledge based communicator, but it was easy for me to know that I didn't fall into the Nurturing or Action buckets. I could immediately see some of the difficulties I have in relating to people that don't communicate with the same style as me. I feel like the accuracy I expect out of communication because I fall into the Knowledge bucket Nancy talked about is why I frequently find myself with a long "So… what's the answer?" after someone answers one of my questions with a diatribe that answers a question, just not the one that I actually asked.

Some of her anecdotes about social engineering her way into situations were pretty funny as well.

Let's Talk Scope - Alena Holligan

I felt like I mostly understand how scope works in PHP before this talk started, and Alena confirmed in my mind that I was mostly correct. This is a very difficult subject to actually talk about. Because you're trying to talk about a variable in one scope overriding the value of a variable in another scope because they have the same name, you have to use the same name for the variable in both contexts, which means no matter what you name the variable, it's going to be confusing about which of the same-named variables you're talking about! She talked about the different access control methods for handling scope like visibility modifiers (public, protected, private), keywords (like final), and scope resolution operators (like self, parent, or static).

10 Things I Hate About Your API - Amanda Folson

Most of my current job involves thinking about and interacting with APIs. Amanda's talk was meant more for people building APIs for public consumption which means I get to feel the pain points she talked about more than I get to actually do something about them. But I see these problems in so many APIs I interact with. I'm not going to include all of my notes here to not steal her thunder in case she's going to give the talk again. But I will include a few of the points that I thought were particularly relevant.

#1. Onboarding - Too long to sign up to use your API. As a developer wanting to interact with your API, if I have to contact your sales team to get any access at all, I'm probably not going to do that. A web form where I can get a basic API key (even with very low rate limits) would give me enough access to decide whether your API is even worth investigating further.

You should measure the time it takes for a user to get to whatever form of interaction you think is important. I remember talking to Keith Casey when he was a developer evangelist for Twilio. He made a big deal about if you want to interact with their API and can't make a phone ring in five minutes, their documentation needs to be fixed.

#4. Your documentation stinks - Outdated, incomplete, not useful, or frequently just plain wrong. As a developer trying to use your API, if I'm reading your documentation and notice that it is different from what I'm seeing your API actually respond with, I'll just stop using your documentation to avoid the frustration. Which means I'll probably end up using some part of your API that you didn't mean to be used, or I'll use it in a way you didn't intend. Which means when you change or "fix" my use case, I'll probably end up filing a bug.

#5. Your API is poorly designed. Inconsistent routes, inconsistent data. I've seen some APIs where one route uses a plural noun while another uses the singular form. That makes it difficult to anticipate how to interact with your API. Another annoyance is how you package your data. If most of your resources are returned in a JSON API format where the payload is in a data element but some resources just return it in the root, that leaves your API users surprised, and not in a good way.

Keynote: Forget accessibility - Think inclusive design - Nic Steenhout

Next up was another keynote, this time about accessibility. Nic totally changed how I think about and more importantly speak about disability. He had some humorous takes on a topic that can make people very uncomfortable. For instance, he has a service dog and uses a wheelchair for mobility. He gave an anecdote of going through a park and overheard somebody say something like "poor guy, in a wheelchair and blind" to which he replied loudly "but I'm not deaf!" It turns out that not all service dogs are used by people with visual impairments. That makes total sense, but isn't something I have ever thought about.

He talked about some of the terms that people commonly use for disabilities. A sports team that wins a lot of games might be playoff-bound. That means they're headed to the playoffs, which is a good thing. Or you might be bound to a chair, meaning you're tied to a chair with rope. As someone that uses a wheelchair, he is not wheelchair-bound. Someone that jumps off a roof might be wheelchair-bound. Words matter.

It really doesn't take much extra effort to think of disabilities when building software, but you have to take a moment to consider the impact of what you're doing, which too few of us do.

Virtual Machine, Container, or Serverless - Terrence Ryan

Terrence quickly ran through the progression most developers run through when trying to abstract out their development environments. We all start developing on our local machines (or at least, directly on a machine), then move on to a virtual machine. Basically we run a server OS in a virtual machine on our machine so that we at least are working with a common operating system install across the team and eliminates the weird gotchas that different hardware can bring. We then try to go to "serverless", which Terrence humorously defined as a marketing rebrand of Platform As A Service. You pay for what you use. This makes it easy to build out microservices and easy to isolate those microservices from each other. But because of the way that most serverless offerings do billing you may get hit with larger bills if your services are under constant use.

Containers help with some of the issues we have with deployment issues by shrinking the size of the thing we're sharing. Instead of sharing a big virtual machine that contains a full server operating system along with the web server we're trying to ship, we can share a smaller virtual machine that has just enough of the operating system to run the web server we're trying to share.

He then showed some examples on Google's cloud offering, basically running a DDOS on his own system.

You Were Lied To About Optimization - Chris Tankersley

Wrapping up the last of the sessions that I'm going to talk about was a case study of optimization. We've all heard the adage about premature optimization being the root of all evil. Chris went through his experience figuring out where his application was having serious performance issues, using tools like cachegrind to actually diagnose where the problem was, and fixing it. The biggest takeaway from that was that despite the fact that he is a senior developer with so many years of experience, his intuition of where the performance problem was couldn't help fix the problem.

As developers we know certain things are slow, like making network requests, or pulling data from a database. But without using tools to actually measure your performance, you may spend time fixing things that aren't actually broken. I've frequently gotten into disagreements with teammates about this sort of thing. They'd like to add caching to a part of the application to speed things up, but can't tell me how slow that part of the application is compared to others.

Overall thoughts

This was my first time at Sunshine PHP. As a speaker and former conference organizer, I know how difficult organizing and running a conference can be. Adam Culp runs a top-notch conference, but it's not perfect.

Adding constant availability of caffeine would fix most of my issues with the conference. The surly barista was a nice touch, though only being there in the morning meant I started dragging when I would normally have my afternoon cup of coffee. Addictions are such a pain.

The venue (Embassy Suites) was quite beautiful with a fancy waterfall in the middle of the main court. They had apparently redone most of the conference area since the year before. I can't really speak to how it was the year before, but it was pretty nice.

The only knock I had on the layout was the ballroom had a stage in the middle and two screens far off to each side, which made sitting in front of the speaker a choice to see the speaker and not the slides. The other rooms were long and skinny, which meant that if a speaker didn't increase the font size it was difficult to read from the back. Most conference speakers know they need to increase the font size, so for the most part this wasn't an issue.

I managed to get invited to the speaker dinner despite not being a speaker. I know as an organizer of Lone Star PHP we would frequently invite organizers of other conferences or speakers that were just attending to join at our dinner, so this wasn't particularly weird, but it was definitely appreciated. The food we were treated to was tasty and delicious, and was a taste of Miami.

The hallway track of the conference was awesome, hanging out with the movers and shakers of the PHP community. Just being around people out there actually doing stuff refills my developer batteries.

The vendor/sponsor room was neat. Lots of engaging sponsors with some really neat swag. I really enjoyed meeting some of the sponsors' representatives (or hanging out more if I already knew them). My laptop is much better protected from physical abuse with a solid skin of vinyl stickers.

Twilio in particular had a pretty cool presence. They had a retro-styled game that you could do. They had certain activities that you could to and gain experience points. At certain levels you could go to their booth to get a prize. I got a mohawked rubber ducky that I want to attach to the top of my work monitor for me to talk to while working out code, but my son stole it for a bath toy. Oh well. They also had an overall competition for the top experience point earners. The top three would get fancy prizes. I actually came in third, but the second place finisher wasn't there to pick up their prize, so I ended up with the second place prize: a Women of NASA LEGO Set. I haven't put it together yet, but have plans for building it with my seven year old son and Googling each of the women represented in it for a history lesson. I'm sure I'll blog about that as well.

I also got to try a few new Florida beers, which as an avid beer drinker was pretty awesome.

I'm not sure if my employer will send me next year, but I may try to attend either by speaking at it or paying out of pocket. It was a great experience and I highly recommend attending if you're a software developer, not necessarily a PHP developer. Many of the talks that I attended were not PHP-specific.