Sunshine PHP 2018

Day Negative One (travel day)

This was my first Sunshine PHP experience. I've been to quite a few PHP conferences both as a speaker and an attendee and helped run Lone Star PHP. Sunshine came highly recommended as a great conference from everyone I know that has attended in the past. They've never accepted any of my talk submissions and my employers have never been receptive to sending me to it until now. Thanks RealPage ! One of the things that have been said about Sunshine was that it was great going to Miami in the middle of winter. I left 30°F weather at DFW to head to Miami, and the 70°F weather in Miami was welcome. I don't much like the cold.

Speakers and other attendees started showing up throughout the day, and it was great hanging out with my old conference friends once again. It's so cool hearing about their new projects, frameworks, and software passions. I could get value attending a conference and spending it in the hallway track. The excitement about software development is really infectious and recharges my development batteries. It was also really cool bringing a coworker to their first conference ever and introducing them to so many luminaries in the PHP community.

But you're probably more interested in thoughts on some sessions, so here we go!

Day Zero (tutorial day)

Tutorial: Guide to UX Testing with Assistive Technology - Andrea Skeries

While the theme of the conference was "Communicate" my personal theme was Accessibility. I have no particular disabilities other than occasional self-induced inebriation that makes typing and operating a mouse difficult. But after seeing a great tech talk at Google by T.V. Raman about how he codes software and the struggles he has as a blind person navigating a sighted world, I've always thought if there are certain things I can do to make it easier to navigate, why not?

Andrea had some great points. Accessibility is not a feature: lack of accessibility is a bug and should be treated as such. At some point, almost everyone experiences some form of disability, whether through aging, injury, sickness, disease, or inebriation. These days it's hard to argue that access to the web isn't a basic human right, and if our sites prevent people from that it should be treated as a blocking bug. While Andrea did talk briefly about ADA laws that can be used to sue websites that are not accessible, I avoid involving the law whenever possible. I'd rather just build my sites to be accessible. She also mentioned that making sites more usable for screen readers can help with search engine optimization. This makes sense since the spiders that search engines use don't have eyes. Well, maybe they're getting to point that they can see the images and figure out what's in them, but I don't think depending on AI is a good long-term accessibility strategy.

One of the best takeaways from the talk was that the things to make a site more accessible aren't particularly difficult but like most things in software development doing them at the beginning of the process is much easier to do than at the end. So going back and changing generic <div> and <span> tags to semantic tags after your site is launched is an order of magnitude more difficult than doing it right from the start. Less difficult a change is adding aria attributes, but again it's easier if you do it while developing a greenfield application.

Other things particularly interesting was that screen readers get hung up on emojis, reading the actual characters like "colon closing parenthesis" for ":)" instead of "smiley face emoji". I've been on projects that for whatever reason chose to do headings with a tag like <div class="heading"> instead of just using the built-in <h1> tags. Screen readers allow users to navigate using the heading tags, so not using headings immediately puts users with screen readers at a navigational disadvantage using your site.

One thing that I had never considered that there are 22 million Americans that have low-vision that might use a screen reader instead of trying to fix the contrast on our sites. Also, some people with dyslexia use screen readers just to avoid having to read the text. As an example: people with dyslexia have issues with large blocks of centered or justified text because of the way spaces between words develop "rivers" that are very distracting. Andrea provided some concrete examples of issues that screen readers have with common HTML. Links are strangely problematic for a part of HTML that we've been using since day one. If you link to something with an image instead of link text but don't include an alt attribute on the image, the reader will read the URL for the link, which is not particularly useful. At the same time, you can add a title attribute to the link tag and the image, and it will helpfully read both. So the experience navigating past <a href="#" title="Going somewhere?">< img alt="Going somewhere?"></a> would read the text "Going somewhere?" twice.

At the same time, alt tags can actually greatly reduce your page's usability. If the image is a spacer (like in the old table layouts) having alt="spacer" on a bunch of images causes screen readers to say "spacer" over and over. Not a good experience. Obviously we don't really design sites that way anymore, but if you have spacers or images that provide no value alt="" is a much better option.

There were also some issues that blew my mind. She mentioned vestibular disorder can be trigger by things moving or sliding around your page. People that have that condition can actually have vertigo induced by moving objects on your page. As someone that has a pathological hatred of things moving on web pages without me doing anything to make it happen, I'm happy to have a better reason to fight against such stupid behavior.

Tutorial: Defensive Coding Crash Course - Mark Niebergall

I unfortunately had to duck out of this session early. I suddenly was having trouble breathing and was really hot. I apologize to Mark for leaving early!

Mark talked about some of the ways to mitigate the risk of security issues, including resiliency and recoverability. There was a third R, but I missed it distracted by people that came to the tutorial late.

Next up was quite a bit of information about your attack surface. I used to work at a company that worked in this space so some of this was not new to me. Your attack surface is basically anything a hostile actor can possibly get at. This means the entry and exit points of your app and everything in between, anything in the public directory of your site (which might include your .git directory), and every route in your APIs (even if not published). Every new feature you add expands your attack surface. While planning new features you need to be thinking about security. How it can be exploited? What is the impact if it is exploited? How difficult is it to exploit?

Mark then went into some detail about some of the unsafe things you might use in your development. Mostly it boils down to don't trust anything. All of the superglobals in PHP should be considered unsafe along with anything from your datastore that you didn't specifically put there. There are eight PHP functions you can use to test that the data you're interacting with is of the type that you expect (is_int, is_double, etc). Your application should be using type hints as well as verifying type and casting user input. Regular expressions can be used to verify that other input is appropriately typed, though that of course means you have to deal with regex.

Day One

Keynote: Apple, Butter, Darmok: A communications primer for developers - Cal Evans

Quite a jarring experience for the main part of the conference to kick off getting yelled at in Klingon. Cal talks about the importance of communication with some humorous stories about how the military came up with their phonetic alphabet. While most keynotes are light on technical details (and frequently light on takeaways), the importance of being able to communicate effectively can not be understated and as always, Cal is an effective and interesting communicator.

Securing Web Services - Amrita Jain

Since most of my current position involves building APIs and decomposing things down into smaller web services, I thought I'd check out this session. Amrita came at it from a different perspective than I normally see from generic web security talks. It wasn't just the OWASP Top 10 rephrased, which was refreshing. There were a few acronyms that I thought were particularly interesting takeaways:

AAA - Authentication, Authorization, and Auditing. The difference between authentication and authorization trips developers up all the time. Authentication is how you prove who you are, which is normally a username (who you are) and password (something you know), possibly adding a second factor like a phone or keyfob (something you have). Authorization on the other hand restricts what a given account can or can't do. And finally, the part that is usually ignored when building secure systems is auditing. What happened when things went wrong? Will you notice when something changes from "normal"? If you're not auditing your application from when it's healthy, how will you know when it's not?

STRIDE - Spoofing, tampering, repudiation, information disclosures, denial of service, and escalation of privileges.

Philosophy in Code: I Kant Even - Margaret Staples

This one made my head hurt. Margaret combined philosophy with coding in a thought provoking way, combined with animated GIFs. Not a whole lot of concrete takeaways from this one, in part because of the nature of the material, and partly because of her firehose delivery. "To ignore aesthetics is folly." She talked very quickly, which made it difficult to internalize some of her points. I would have liked to have a second to think about what was just said, really think about it, before moving on to the next point. Some points I really liked:

• Syntax vs coding style - Syntax is either right or wrong. If it's wrong, the parser, compiler, or whatever reads the code will fail it. Code style is less objective.
• Math is a tool, but there's no such thing as a tool so awesome to not need human insight.
• Without your own philosophy in coding, you're racking up technical debt in your mind.

Keynote: How to Go from Developer to Stakeholder - Ann Gaffigan

Ann talked about her career path from intern up to the head honcho. Interesting story of how things progressed, mistakes that she made, and how she got where she ended up (so far).

Converting Your DEV Environment to a Docker Stack - Dana Luther

Dana talked through the why of using Docker real quick in the beginning. Many teams use virtual machines for their development, which means to spin up an environment for a new developer they need a big VM copied to their machine. With a Docker stack the developer needs a docker-compose.yml file, which is quite small. The configuration file defines the services your stack needs (Nginx, PHP, MySQL, etc) and any configuration data you need (volumes, secrets, paths, etc).

A Docker image becomes a container. Similar containers form a service. A bunch of services form a Docker stack. A computer is a node, which is deployed into a swarm. If you're running Docker on your development computer, you end up with a single node swarm. A swarm is built from one or more nodes. The first node is the master, and all the additional nodes are workers. If the master goes down, the remaining workers will vote to promote a node to master. cloud.docker.com helps to manage your swarm. docker swarm init will join a machine to the swarm, or create a new swarm.

store.docker.com provides a bunch of common images (PHP, MySQL, httpd, etc). docker image pull mysql:latest will pull the latest MySQL image. Instead of latest you can use the hash to get a single consistent version.

Labels allow you to give better names to things in order to interact with them.

Volumes allow you to mount directories from a filesystem into a container. Named volumes allow mounting something into it without defining what it necessarily is. So locally you could have a named volume point to a local directory, while on a server that same name would point to an NFS mount.

While Dana's talk was one of the better Docker talks, it had the same flaw as the others: once I have my dev environment running smoothly locally, what then? Someone needs to give the talk about taking it to staging and production environments.

Uncon session: Utopian.io - Luke Stokes

Instead of going to one of the three awesome looking talks in this slot, I opted to go to the Uncon track to hear Luke talk about getting paid for Open Source work. We ended up talking less specifically about Utopian.io and more generally about the blockchain technology that powers it. Luke's passion for and knowledge about cryptocurrency is infectious and I've since signed up for a Steemit account as Omnicolor. While I learned a ton from some of the other sessions I went to, this session may have been the most life changing. It rekindled my desire to write: both blogging about technical topics and creative writing.

Squash Accessibility Bugs - Andrea Skeries

Continuing with my unofficial theme of the conference I attended a second talk from the same speaker on the same topic. I was a little worried that this session would just be a shortened version of her tutorial that I attended. While there was some overlap at the beginning, I think that's important to get everyone on the same page vocabulary-wise for the rest of the talk.

Some interesting points with some extra commentary from me:

• Screen readers need valid HTML more than browsers do to figure out what to read. I've long been accustomed to running HTML through validators to make sure my markup is technically correct. That had more to do with me just wanting to be technically proficient. I also found that correct markup made it easier to debug any issues. The fact that screen readers can very poorly handle broken HTML is yet another reason for me to insist on proper markup.
• No automated tool can catch everything: you need a group of real and diverse people to test your site and your technology.
• CAPTCHAs are particularly difficult for screen readers to read. The links and actual image are almost humorously difficult for me to understand as Andrea demonstrated using one. I would say you'd have to either practice doing CAPTCHAs that way or be an AI-powered bot to successfully pass one.
• Adding help text to input boxes is great, but screen readers won't read them as associated help text unless the help text is linked to the input via the aria-describedby attribute.
• For people with some physical disabilities, anything you can activate with your mouse you should be able to interact with using your keyboard. Semantic elements such as <button> are much better than a <div> that you've added Javascript to in order to make it act like a button.
• 1 in 12 people have some form of color blindness.

That's the end of the first half of the conference. I'll post the second half wrapup as soon as I get it typed up!