whateverthing.com

☰

CascadiaPHP is an amazing conference in Portland, Oregon hosted at University Place Conference Center. I attended 2019's edition and it was full of great content and fantastic speakers.

This is the conclusion of a three-part series about the conference.

« Day One: Thursday, Sept 19th

« Day Two: Friday, Sept 20th

Saturday Sept 21st

Why Open Source?

Larry took us on a journey through the history of Free Software and Open Source, highlighting that the two are actually different in some fundamental ways.

For many years, software was encumbered by business rules. Code was locked behind closed doors as Intellectual Property. Innovation wasn't completely stifled, but there was definitely a lot of wasted and duplicated effort due to people not sharing code.

Along came the Free Software Foundation in 1985, promoting the seemingly radical idea that software should be free. Free Software sought to recognize that we are all better off when we can study and change the software we use, redistribute the software for others to use, and improve the software for everyone. These, combined with the idea that you should be able to run software for any purpose, were known as the Four Freedoms of Software.

In the 1990s, some folks created the Open Source development model and founded the Open Source Initiative. This concept made free software more approachable for businesses and ushered in a new way of sharing and collaborating on building the underlying tools of our industry.

After all, almost every company using software isn't actually in the software business. The benefits of Free and Open Source software span a wide gamut, but the main areas Larry covered were Ethics, Economics, and Security.

With open source software, you have choice, you have options, you have an "out" when the company is not functioning properly. OpenOffice and MySQL are two examples - issues came up, and it was possible to fork the projects. LibreOffice and MariaDB are both viable choices that benefit us all thanks to the freedoms allowed by Open Source and Free Software.

Drupal 8 is another example. It was a massive rebuild, and not everyone liked the new paradigm. The project was forked, and the Drupal 7 paradigm continues to exist as BackdropCMS.

Some companies and organizations fear going with Open Source because they wonder "But who will I sue?". They forget that most modern EULAs forbid lawsuits in favour of mediation processes that unfairly benefit the vendors. Other orgs wonder who might provide support at 2am, forgetting that even if you're paying for an SLA and such, the guarantee is just a piece of paper (see prior point about mediation). Who will provide support at 2am? The person you're paying.

Other times, people might suggest that open source software is less secure than closed-source, because there have been so many issues found. Well, those issues were usually found by being able to see the source code - which means, the issues can also be fixed, because the source code is right there. Closed source systems aren't any more secure due to being closed, but by nature of being closed any issue that comes up is entirely on the company's plate to get resolved. And that's if they're still paying attention to that product.

Open source software is also more auditable. Anyone is welcome to fund an audit, and they can even be good community members by contributing fixes based on the findings.

Speaking of the community, that's a huge aspect of Open Source. Time and effort is the currency of free software. It's okay to be a passive user of open source, but the community really thrives when everyone is working to find ways to contribute. This can be by funding developers, contributing code, or even doing things like UX and documentation improvements. Even well-written bug reports are a way of contributing - if you can save the developer 20 hours of time researching an issue, that's huge.

In life, it's rare for selfishness to work for the greater good, but in open source it totally can. Project missing a feature you need? Hire the developer to implement it. Then it gets shared back to the community as a whole.

If you're not invested in an open source project, you're not entitled to a say. Even if you are, the project maintainer is still responsible for the project - but if you really do need to go a different direction, guess what? It's open source. You can fork it and implement your own. But with closed source? Sorry, tough noogies.

In closing, pay it forward. Contribute to the community. Sponsor developers and community conferences, contribute help of all kinds to projects, keep the dream alive.

PHP-FIG (Framework Interoperability Group) Panel

This was a bit of an impromptu addition to the schedule, but Ian, Korvin, Larry and Adam did a great job of answering questions about the FIG and discussing some of the future directions it might take.

The PHP Framework Interoperability Group was started in 2009 as a way for frameworks to write software that could be shared more easily. By collaboratively arriving at well-defined standards, a lot of effort could be saved in the development of software. A pretty valuable thing, effort is, especially in the realm of volunteer-powered open source software.

Becoming a member of the FIG doesn't obligate a framework or PHP project to follow all of the standards, but it does give them more of a voice in the standard-making process.

Three of PHP-FIG's first "PSRs" (PHP Standard Recommendations) were: Autoloader (PSR-0), Coding Style (PSR1/2), and Logging (PSR-3).

Some interesting nuggets to come out of the panel include:

• PHP-FIG is moving away from Medium to a static blog.
• The last few years have seen the FIG focus on improving dealing with HTTP within PHP projects.
• The upgrade plan for PSR-16 (SimpleCache) to support Types is going to be pretty neat.

A few weeks after the panel, a great blog post came out about the PSR-16 upgrade plan. I suppose this saves me from having to recap it :)

Participation in FIG conversations is encouraged for everyone. You can join the FIG mailing list and also participate via IRC. A FIG Slack may be opened up to the public soon.

One other thing that came up in the panel is that the DocBlocks PSRs (PSR-5 and PSR-19) need some help. Contact Chuck Burgess if this sounds like something you'd like to help get across the finish line.

Dev Parent

Alena gave a great talk about the overlap of Dev life and Parent life, and how one side can often provide lessons to help in the other - even if you weren't expecting it.

Some tips included:

• Use Google. You use it for work, so remember to use it at home. Best way is to search for solutions to highly specific issues.
• Creativity. Parenting requires it. Programming requires it. Unite the two.
• Putting out fires - this is a large part of what parenting is, so some workplace firefighting techniques might be effective.
• Outsourcing - great for some things at work, and some at home too. Figure out what those things are. It's not always perfect, but it can help.
• Frameworks are a big deal for developers. We sometimes allow ourselves to get locked into the idea that there's one way to do things, but kids don't work that way. However, there are still transferable skills that you can pick up.
• Tradeoffs. There is no perfect - it's a moving target. Sometimes you have to focus on the "minimum viable outcome" of a situation.

Ask for help! When programming, don't sit there for six days and not figure it out, ask! But when you're a parent, it can feel harder to ask for help, for fear of being judged. There isn't a four year degree in parenting the way there is for computer science. We need help all the time.

There are community resources for parenting, just like there are for software developers. Reach out. Pick up a new hobby. Engage with local and online communities. Put yourself out there in the community, and also ask for help. This opens up space for others to ask you for help, enabling reciprocity. Great for community building.

Routine. Children need them. Effectiveness can vary from kid to kid, but it can really help take the thought process (and resistance) out of things.

You don't really know something until you can explain it to someone else; and especially a 6 year old. Sometimes they don't need to know the answer, they need you to show them how to find the answer.

Modeling behaviour is a good way to sneakily get kids to learn good behaviour. Model understanding. Empathy. If you need them to calm down, remember that you are the one who needs to calm down. It's not their responsibility to know how to be calm, you need to model that for them. Play-acting is good for modeling, toys/dolls/etc., since it can be done in non-stressful moments. Model for the industry, as well. Defend and push forward the things you feel passionate about; it's not just about you, it's also about modeling for other people.

I know I missed a bunch of other great information in this summary, but hopefully these items are helpful. It was a really great talk.

When did you stop Speaking Up?

Merline's mid-day keynote provided a lot of information about the costs of exclusion and non-diversity, advice on how we can all help each other (because we're all in this together), and suggestions on how to be more inclusive of others and make sure that your voice is heard and contributes to DE&I.

We're doing so much, but we still have people leaving tech. Unfair treatment is the most cited reason for leaving - 40% said it led them to go to a different company (not fully leaving), and 64% said they experienced bullying and hostility. There's $16 billion left on the table in the US because of turnover each year.

Diversity is necessary, because a homogenous team will build a product that serves that team, like when Google built a camera that didn't even consider left-handedness. Or like facial recognition that doesn't recognize African-Americans.

We're all in this together. We can help by asking questions, listening (more than just getting the information we think we need - it's important to truly consider ideas), amplifying folks who speak up infrequently or aren't fully heard, and intervening in potentially hurtful situations. Sometimes the folks who are the target of an offhand comment won't know how to react in the moment, and having a third party chime in to defend them would be a much more inclusive experience. On the defensiveness flip side, sometimes we want to defend people we know, but that can lead to not taking concerns seriously. If someone is speaking up about another person's behaviour, make sure they know that you hear them and you're taking it seriously. Being ignored is going to lead to a non-inclusive environment.

Ways to get your voice back:

• Join a community (meetups, Dev.io, twitter, community slacks, conferences)
• Start a blog. Documenting your experience can help increase your confidence. While writing, you can find opportunities for mentorship.
• Speak at a Meetup or Conference.
• Speak up - make verbal contributions to your team.
• Don't apologize. We all make mistakes. This can sometimes be a symptom of Impostor Syndrome. Good to overcome; no need to apologize for acceptable mistakes.
  • [Kevin's note: If you are Canadian, read this as "don't over-apologize"]
  • [Sorry.]
• Power Poses. This one's a bit fun, but if you need help to mentally get your "mojo" back, trying out a Power Pose or two might be just what you need.
• If you're in a toxic/non-inclusive env, sometimes the best thing is to just leave. Get a new job.
• If a workplace is hiring for diversity, but not practicing inclusivity (or seemingly unwilling to try), that might be a good reason to move on.

"Diversity is being invited to the party. Inclusion is being asked to dance."

Blazing Fast Websites with Gatsby

Preston explored the concept of the JAMstack and how Gatsby integrates it by enabling static sites to drive headless APIs. He also covered some of the business plans of Gatsby the Company, which included a demo of their Gatsby Preview product.

JAMstack is a way of building dynamic web applications using JavaScript, APIs, and Markup. A static site renderer, like Gatsby, generates assets on the server site which are then pushed to the client. Browser-based JS takes over and drives the client experience, which allows things like page loads to be done client-side. The server-side assets can be sourced from local files, or they can come from remote APIs, like Contentful (for CMS) or Algolia (for Search). The browser-based JS can also talk to some or all of those APIs, to further boost the dynamic nature of the web app.

A product like Gatsby is kind of like the glue that binds all of the "content mesh" together.

As an example, you can start with a traditional Drupal site, handling the server-side and frontend. Later, you can bring in Gatsby to generate frontend code that talks to Drupal on the backend.

Eventually, you can start slicing out pieces of functionality that Drupal provides and source them from dedicated vendors using API approaches like GraphQL. Authentication via auth0. Content management via Contentful. Search via Algolia. Or anything else you need via microservices or other vendors.

At a certain point, your site doesn't have a backend.

The Internet is your backend.

Stepping Outside your Comfort Zone: Learning to Teach

Heather's talk covered the principles of teaching in a way that reaches the people being taught. Many great tips were demonstrated, with the goal of covering many different styles of learning and teaching in order to make sure that content is reaching the audience. I took over 1000 words of notes, so it's going to be extremely difficult to distill and summarize.

It's important to understand your audience (if presenting a talk) or students. Learn how to make connections with them, what sort of experiences they relate to. This will help you know where to start, and it will deliver a better experience for the learners. It can also help with overall retention.

One school of thought suggests that there are many different learning styles and that people can be more proficient in some than others. In business, as in education, it can be very helpful to identify the best ways that specific individuals learn and retain information.

Learners can prefer Solitary or Social learning (self-study vs learning in groups), and these traits tend to apply within the rest of the learning styles.

• Visual learners tend to think in pictures, excel at reading maps, and might need to visualize words in order to spell them. They tend to use intuition to solve problems and have uneven subject grades. When teaching a visual learner, it can be helpful to replace words with pictures, use colour consistently to highlight major or minor links between pieces of information, and use system maps to help them see the big picture.
• Logical learners prefer to use logic and reasoning to learn. They feel a need to understand the reasons behind things. They enjoy seeing a logical progression from pieces to a big picture, particularly when diagrams are included.
• Physical learners have a lot of energy that can be challenging to channel. Kinaesthetic learning, with sensations/role playing/physical objects, can help convey ideas.
• Verbal learners rely heavily on speaking and writing. They like to play on the meaning of sounds/words. Active discussions, linguistic roleplay, and "self talk" can help to cement concepts for this style of learner.
• Aural learners have a good sense of pitch and rhythm, and form strong emotions/memories from music. Tips for aiding this learning style include a pump-me-up song after an accomplishment (or to help them overcome anxiety). Recordings, mnemonics, and acrostics can also help.

Anyone can favour multiple learning styles, and people can even train themselves up on unfamiliar styles.

Adult learners (e.g., you and your coworkers) are different from children and have different motivations and expectations. They tend to have a greater ownership of what they're learning. Their life experience allows them to correlate new information with existing lived experiences (which can sometimes make it difficult to connect with them if the topic is too unfamiliar).

They might be approaching the learning process in a goal-oriented way, relevancy-oriented (no time for theory), or purely practical learning. They need to be shown respect as part of the learning process. (The teaching style of "House, MD" is not recommended.)

People will have different motivations for learning. Could be social reasons, self-improvement, external expectations, or boredom/cognitive interest.

It's important to understand your own learning style.

https://learning-styles-online.com/inventory

You can change and grow your learning style.

How you learn defines your teaching style. When pursuing mentorship, mismatched teaching styles can make it very difficult to teach.

Reinforcement, Retention, and Transference are important aspects of the learning feedback cycle. Reinforcement is reward or punishment as a way of teaching. Retention - practice makes perfect. Content that learners easily see the meaning and purpose of is easier to retain. Transference is the ability to take the learned information and then apply it. This is most likely to be successful when learners can associate the new info with something they already know.

When building a presentation, try to appeal to multiple learning styles. Picture? Graph? Demonstration? Maybe an informal chat with the audience?

If you need the audience to take note of an important point in your presentation, make some big changes. Switch up your slides, move around the stage, get the audience to move. Maybe even swap between presenters.

Sometimes micro-level changes are helpful with retention. Organize slides into visual subsections, add short videos, and make the edges between topics clear. Build in a brain break to let people digest what they've just heard, and use pauses for emphasis. Silence is a powerful tool, before and after critical statements, to impress importance upon the audience.

There are many techniques you can use to reinforce retention. First Impressions are really important. If you're presenting and miss a stride, though, don't worry too much about it - ending on a strong note is what the audience will remember.

Have an overarching message. Make it clear. If you don't choose one, your audience will choose one at random.

Balance your presentation. Not all special effects, all text, etc.

Follow the "The Rule of 3". At least keep it mind when building the talk and the slides - 3 points of information on a slide. Don't overload the audience, and make sure you're not staying on the same slide for a long time.

Metaphors are a good way to relate your information, but people will not always relate as you intended. Different life experiences might mean that not all of their experiences are positive. An example that came up was a presenter who compared their product to Bamboo. Easy to tame, versatile, they thought it was a great metaphor. Later, they learned that people have a lot of negative experiences with bamboo. Impossible to get rid of it. This caused the negative experiences to be associated to the product, which was unanticipated.

Key takeaways from this presentation:

• Evaluate your content
• Maintain its relevance to the audience
• Keep the audience's attention
• Have a clear message
• Ensure your presentation is balanced

Welcome to the Community

Matt closed out Cascadia PHP with an epic tour of the PHP community, from the core engineers to the community members and advocates who have contributed in innumerable ways to the success of the PHP project.

He started with a timeline of PHP history. Well, actually, he started with a whisky, but then jumped into the timeline. Well, actually, he made us all shuffle our seats and introduce ourselves to our new seat-mates. THEN he jumped into the timeline.

The timeline explored the history of PHP, from the first version, to the first user groups and conferences, the early frameworks, the PHP FIG, and so on.

After the timeline, he explored how he was introduced to the PHP community. He was at a Sunshine PHP conference and was out at one of the group meals, when someone made a very upfront and disrespectful comment about his height. He tweeted about it and got immediate support from other devs, including some who were at the conference. This grew into a number of close ties with community leaders. The dev who made the original comment apologized, and as I understand it, they are on friendly terms.

After talking about this, he delved into the PHP community: core contributors, community members, open source contributors, and advocates. Many slides and laughs followed.

But then he asked everyone in the audience to raise their hands if they were supporting a community member on Patreon or GitHub sponsorships or other such service.

I didn't see any hands go up.

Granted, I was closer to the front (due to the seat swap - thanks, Matt), but it was disheartening to see. It plays into a larger ongoing conversation about how best to support Open Source in a world where volunteer work is something that is a luxury of a privileged few.

It was at that moment that I resolved to try out this sort of support.

Now I'm donating to three community members and one community project. It's only a tiny bit, but if we can get more people aware of this and onboard with the idea, it could result in great things from Open Source and the PHP community.

And if you're working at a company, it would be good to encourage the company to sponsor projects and developers - it's almost impossible to not be using some form of open source project these days. We can't be freeloaders. But we can express our thanks for not being tied to massive byzantine business rules thanks to open source. So fund someone on Patreon, buy a support contract if the project offers it, or sponsor some conferences.

Ahem. And now back to the talk.

You can help the community out in non-financial ways, as well. Participate in projects like PHPMentoring, PHPWomen, Elewant, Wurstcon, PHP.ug, 24 Days in December, or contribute to Joind.in.

And it's time for a new generation to join us. What can you do next?

Blog. Join a podcast. Start your own podcast. Create memories.

Summary of Day Three / Cascadia PHP / The Journey Home

I thoroughly enjoyed this conference. Driving down from Victoria was definitely the right way to start it off, as I got to take in the Olympic mountain range and west coast shoreline. Meeting everyone was fantastic - some folks I met for the first time, and some I had seen at previous conferences. Portland was nice, I got to try out Voodoo Doughnuts (a tourist staple), and for a 2nd The Simpsons reference, I also got to drive on Terwilliger Boulevard.

On my last day there, I had originally planned to drive out to Multnomah Falls and try to get some waterfall photos. After heading down to breakfast at the hotel, I encountered several other PHP folks and we had a great breakfast chat. I changed my plans to stay and chat longer, and then drive directly up to Port Angeles to catch the ferry home. A great decision, as it turned out!

After an extended chat with folks, I checked out and hit the road. This gave me time to stop in at the Mt St Helens Visitor Center just off of I5. I was able to walk through the museum, watch their video of the days leading up to and following the eruption, and explore the trail that runs along Silver Lake. The crater didn't manage to peak through the clouds and rain, but it was still quite an experience.

After this, I made a beeline to the ferry. Lots of driving. Lots of missed photo opportunities - Puget Sound is lovely in the rain and fog. As I was driving past all these possible stops, I made a deal with myself that once I was 30 minutes away from the ferry, I could stop and take a photo. I, er, neglected to realize that those 30 minutes would be entirely inland. Oops. But, thankfully, I made it to the ferry with minutes to spare before the reservation cutoff.

Having skipped lunch, I grabbed dinner on the ferry and took in the seascape. A beautiful denouement to a wonderful trip.

Thank you to all the organizers, speakers, and attendees for making it amazing!