Midwest PHP 2018

Leave a reply

By Riley Major, 2018-03-13

Radisson Blu and L.L. Bean at Mall of America

Midwest PHP — a Friday and Saturday $275 conference with three tracks of PHP-themed content — was hosted again at the Radisson Blu at the Mall of America on March 9th and 10th, 2018. In addition to 30 individual sessions, the conference opened and closed the event with keynotes highlighting community, inclusion, and accessibility.

This year’s organizers and volunteers included:

Some highlights from selected sessions:

I Community, and So Can You (Opening Keynote)

Midwest PHP Keynote by Margaret Staples

Margaret Staples

Make connections at conferences and user groups, especially with people different from you. Follow the “pac-man rule” — when talking in a group, leave an opening and adjust your body language to make it clear you welcome people to the discussion. Ask people about their interests and really listen to them; don’t just plot your response. But remember, conferences, users groups, Twitter, etc. are not your community; they are just the tools used to build it. The connections you form with other people are your community. Treat people well and don’t brook toxicity.

Writing Clean Code

Jason McCreary

Remember that code is read far more often than it is written. And humans will be reading it. Be consistent about formatting. Don’t leave dead/removed code in the codebase. Try to limit nesting by having guard clauses (if bad thing then exit; instead of if good thing, if another good thing, if another good thing…). Don’t have lots of primitive parameters; make objects out of relevant groupings of parameters. Limit the size of blocks of code by abstracting away details to other blocks of code; there’s only so much a human can keep in mind when trying to understand code. Don’t over abbreviate names. Comment sparingly, and only to explain why, not what. Try not to return null or invalid/empty objects if they are likely to cause exceptions. Don’t separate out repeated code until it’s repeated thrice.

Conquering Continuous Integration & Deployment

Tessa Kriesel

Automate your build process. Use scripts to format code, compile, minify and bundle JavaScript, run tests, deploy to staging servers, and communicate with your team. Start by listing out, in detail, all of the steps required to deploy new features. Pick one to automate. Then use the excitement from that automation to motivate the next challenge.

Go for PHP Developers

Terrance Ryan

Go is a compiled language created by Google. You can compile binaries across platforms (e.g. Windows machine can make Linux executable). Has garbage collection, is strongly and statically typed, and has a syntax style like C. It’s built to use multiple processors and incorporate remote packages. Functions can return multiple results. Local vs Global is controlled by capitalization. Excels at processor-intensive tasks (compared to a language like PHP) or anything which can be run in parallel. To learn more, search for golang, not Go.

Managing the extreme client: PM 101 for devs

Brent Peterson

Reports, reports, and more reports. Communicate frequently, in writing. Send a daily status report which has a visual progress indicator, a short list of open questions and roadblocks, especially highlighting anything the client needs to provide. Send a weekly summary report—again, including only high level detail of progress, preferably visually—and follow up with a discussion, asking about what’s working well and what’s not, from the client’s perspective. Ask for a score or grade. Provide an even higher level, even more visual monthly report for client leadership and send it directly, as sometimes clients don’t communicate up their chain and could throw you under the bus. Get involved in any changes developers are working on and get them documented. Be clear that changes beget more changes; deadlines must be moved or other work must be removed. Resist a cycle of endless changes; it pushes out rewards. Make written deployment plan with client, getting sign-offs on risks (e.g. downtime).

Essential AWS for PHP Applications

Michael Moussa

EC2 are basic virtual servers; spin them up when you need them and turn them off when you don’t. Amazon Machine Image (AMI) are templates for setting up new EC2 instances; they contain the OS, apps, libraries, configuration, and data. Can make custom AMIs and use them for future EC2 instances. EC2 instances have classes comprised of family, generation, and size. Family describes focus—optimized for CPU, memory, or storage. (Storage is expensive on CPU family; CPU is expensive on storage class instances.) Newer generations have more power per dollar than previous generations. Size governs the overall power and price. Can choose to put server right on public IP or a Virtual Private Cloud (VPC) and then access via routing/NAT or a VPN. Can create an Application Load Balancer (ALB) to forward requests to multiple EC2 instances based on various rules; can also use for SSL with AWS Certificate Manager (ACM), which offers free SSL/TLS certs which automatically renew. Amazon Route 53 is cheap, highly available DNS server which can also switch IPs based on rules (for automating DR during failure). Can use Auto Scaling Group (ASG) to automatically spin up and down EC2 instances based on rules like CPU use. Can use Relational Database Service (RDS) to host data—in MySQL, SQL Server, Oracle, and others, including Aurora, Amazon’s own DB. Can use Amazon ElastiCache—in memory cache as a service—with automatic setup and patching; memcached or redis. Amazon Simple Storage Service (S3) provides object/file storage; can host static websites or be used for static content for dynamic websites. S3 is public but you can set up VPC endpoint to get cheap access from your VPC. Amazon CloudFront is global content delivery network (CDN); even cheaper than serving content out of S3.

Practical API Security

Adam Englander

Defense in depth is an ancient concept. Consider castles, with moats, archers, big door, courtyard with inner keep, narrow, winding stairways. Practice that with APIs. But don’t go overboard. Calibrate to your realistic threats or you will go bankrupt defending against imagined nation-state actors. Implement rate limiting to combat denial of service attacks. Requires tracking requests per individual over time. Ideally, perform at edge layer with a cache to avoid load on database. Implement replay prevention to avoid accidental or malicious repetition of a previously successful message. Manage this with individual request tokens. When using authentication, if you put it in the body of the message, you have to decrypt the message to perform the authentication check, which is more resource intensive. Could use an authentication header, but traditional methods (e.g. basic) are subject to snooping. OAUTH is better, but complicated and more resource intensive. Consider hashing message to detect tampering. Research JWT and JSON Web Encryption.

Welcome to Our Product: Hospitality, Experiences, and Documentation

Heidi Waterhouse

Companies optimize user experience of public website but often neglect API documentation. Those accessing your API documentation are already interested in your product so you don’t have to sell it. Instead, understand what they want to know and present it clearly. They want to connect securely, have you handle data consistently, get confirmations, pass through states accurately, and spend as little time as possible doing so. Make your API easy to experiment with; provide examples and a sandbox with realistic (but not real) data. Humans learn better from concrete examples than abstract descriptions. Don’t confuse API consumers with the eccentricities of your data architecture; present is simplified, idealized view. Strive to keep APIs consistent over time; people rely on them. Changes should be communicated well in advance with plenty of transitional help. Provide useful error messages detailing what went wrong *and* how to fix it.

Improving Technical Annotations and Estimates for Your Projects

Jessica Feigal

Document everything! Customers often don’t know how to tell you what they want. Clients are brand new to this; they’re not web experts. They don’t know what’s all involved and why it takes so much time. When documenting requirements, you have to balance client and developer needs. Too dense and client won’t read it; too scant and developer will have too many questions. Ensure that you document any expectations of the client (content, logos, decisions, etc.). Don’t forget to specify behaviors of all buttons, menus, etc. If text says “related stores” or “other items you might like”, how will those be updated? Algorithm? Manual curation of a list using a tool? Manual text editing? If you’re collecting information (e.g. email address), ask where it goes and what will be done with it (e.g. add to third party email campaign manager using API). Document which web browsers will be supported. Will you support mobile devices? Horizontal view on those devices? Ask about and document ADA compliance and accessibility in general. For estimations, use white board to draw out interface, including buttons and menus, and list out each item and how long it will take. Do that for each view (mobile vs desktop). Don’t break down further than a half hour. Don’t share the final number. Rather, pad it a little bit and use it for the bottom end of a *range*. If you work in agile environment, you don’t really know what you’ll be building (yet), so make range wider. If you get push back on amount, don’t just buckle and decrease. Instead suggest feature removal or simplifications.

Developing a Culture of Mentorship

Tessa Kriesel

Junior devs fresh out of school struggle to get a job, despite a needy market. Trouble is even most junior jobs require years of experience. Companies should ditch those requirements and embrace mentoring junior developers. It makes finding people easier, improves morale (mentoring is rewarding), brings in new ideas and energy. Passion is infectious. Look for recent graduates of Prime Academy or other local schools. Put your interest in mentoring right in your job descriptions. (On the mentee side, CH Robinson is known to hire junior devs and mentor them.) Provide framework and support for senior folks to mentor, but don’t require it, and managers shouldn’t be mentors. Ensure mentees have open communication with mentors. Track progress of mentees. Evolve your early mentees into later mentors. For individuals, mentoring grows your network, feels good, helps you grow and master your own skills. Their successes feel like your successes and you can form lifelong friendships. Be sure to boost their confidence; show them how far they’ve come. Share resources and book recommendations. Give career advice, but don’t force them down a path. Ask open-ended questions about they’re interested in (enjoy look of website or how it functions? enjoy fast paced solo work or more collaborative and process driven?). Try live coding sessions with google hangouts or other tools; provide code reviews; lead a study group. Mentees should be respectful of mentors’ time; come prepared with questions after having put the time into reading and practicing. Remember mentors are volunteers and this might be time away from their family. On community: if there’s not a local user group, start one! See if you can find a local company who’s willing to encourage their developers to attend.

See also:

Open Source, accessibility, and you – the superhero! (Closing Keynote)

Nic Steenhout

You can be heroes and improve people’s lives. Accessibility isn’t expensive. Grafting it onto an existing project—much like retrofitting an old building—can be. So bake it into your process. 1 in 5 people – 20% — have a significant disability in the Western Hemisphere. Vision or hearing impairments, motor or cognitive disabilities. Don’t forget about temporary or situational impairment, like a new parent holding a screaming infant trying to search for advice. Remember, they are all people, and people are the most important thing in the world. Your community is you. People working together can raise a barn in a day; we can organize a hackathon and make strides on accessibility. CRMs (Drupal, WordPress) have made slow progress, but often their admin consoles lag. Disability groups, who use them to manage their websites, need help just to post articles. Use plugins like WP Accessibility. With accommodation, people with severe disability can thrive. Help by getting involved with accessibility in open source software. Participate in OpenAIR. Use accessibility testing tools such as Tota11y, aXe, and Tenon.io. But automated tools can catch at most 40% of issues. Test drive your sites with diverse populations of real people (AccessWorks). Learn more through W3C Web Accessibility Initiative (WAI). Accessibility champions need not be accessibility experts. You can be a hero.

Thanks!

Thanks to the organizers, sponsors, speakers, volunteers, and attendees (and whoever paid for their tickets) for another successful event. Conferences are important opportunities to learn, connect, and reflect. They are key community-building events and I’m pleased the Twin Cities supports so many tech gatherings.

Leave a Reply

Your email address will not be published. Required fields are marked *