Security is a topic dear to my heart. It’s core to enabling the privacy of many billions of web citizens. We, as web craftspeople, have a duty and responsibility to care for, prioritise and make decisions that benefit our customers, clients, friends and family online. However we so often fall short of the mark either by time, knowledge or the sheer energy it can take. Building secure software can be hard.

When we get security wrong – either by laziness or neglect – the implications can be huge. We’ve seen high profile and high impact breaches like Ashley Madison and it’s with mild irony that I share my thoughts on security on the same day that yahoo shares 1 billion+ user accounts were breached. While each breach and vulnerability might be unique in its own right, it shows us what can happen when things go badly. The recent DDoS against Dyn also demonstrated the sheer scale that the insecure-internet of things has and its ability to be harnessed as a security threat against us. You might not consider PHP to be a popular language for embedded hardware & IoT, but the commonality is the lack of attention to security.

We, as craftspeople of 82.4% of the internet have a crucial role in fixing the security mindset of our community.

As a language, we are getting better. We’ve removed features that perpetuated set-and-forget mindsets, chosen smart and secure defaults, and even removed the ability for ourselves to make insecure decisions.

As a community however, we’re significantly falling short of the mark. In my recent state of the version post I show that – at a best-guess – a maximum of 40% of PHP installs in the wild can be considered probably-secure, leaving over 60% insecure.

A majority 60% of insecure installs merely perpetuates the levels of contempt culture towards PHP as a language and our community at large.

However, my friends and phpellow coders, security is everyone’s responsibility, not just a mailing list on internals.

Bad advice is everywhere, and it’s not helping us. And yet there are also some fantastic resources at our disposal too!

• Familiarise yourself with the OWASP top 10. Read it again and then start to add tests and processes to improve your application over time.
• Read PHP The Right Way – Security. Read it again, and follow it.
• Pick conferences sessions about security. I find Tom Eastman’s The dangerous, exquisite art of safely handing user-uploaded files a great start.
• Familiarise yourself with the PHP Manual – security guide.
• Keep your installations up to date and patched. Follow the PHP migration guides Plan for new versions of PHP and prioritise time to update.
• Take a look at the CVE list and start to understand some of the vulnerabilities that occur.

So here’s my call to arms: let’s make 2017 the year of the responsible, security-minded developer.

For many of us, December is a natural time to reflect on the year, and 2016 has provided plenty to ponder. While there are arguably more important things I should be writing about, I’d rather provide a brief respite from the serious issues facing the world.

In that spirit, here are a few of my favorite things.

1. Copy as cURL

Regardless of how complex a web app is, it’s still just HTTP requests and responses underneath it all. I used to use telnet to debug stuff, but for things like SSL or edge cases that require a particular cookie to trigger, I find curl to be much more useful, particularly with the “Copy as cURL” option in Firefox and Chrome.

It’s easy to miss, because you have to right-click a particular request in the inspector to find it. Here’s how this looks in Firefox and Chrome.

The nice thing about this is that it’s the exact request your browser sent, and it helps you test one change at a time to pinpoint a problem. It can also help you make a bug reproducible, which might be important if you discovered it, but someone else needs to fix it.

2. WonderVPN

The PHP community’s own Paul Reinheimer is one of the people behind WonderNetwork, a global network with servers in 216 locations, covering 78 countries across 6 continents.

I’ve used several of their products, and while all are useful, WonderVPN is my favorite. You don’t have access to the entire network, but you do get a few choices of locations, including the US, UK, and Canada.

3. Blogs

I still believe in RSS! In fact, I still read my own personal aggregator, Planet Chris, almost every day. In 2017, I hope to finally get back on the horse and start blogging regularly again. To those of you who never stopped, thank you.

4. Video Calls

I collaborate with a lot of people remotely, including colleagues, friends, clients, and business partners. For calls, nothing beats video. Here are the ones I use most:

Google Hangouts

As long as you’re signed into a Google account, you can start a hangout whenever you want. Share the link with anyone you want to join. You can also add someone via phone, which is nice.

Zoom

If you have a lot of participants, or you just want to be kinder to your processor and battery, Zoom is a great option.

Join.me

Join.me admittedly strays into the enterprise realm, but for good reason. There are dial-in numbers for almost every country, and the app is pretty good for those of us who prefer computers.

5. Using the Clipboard from the Command Line

I had never used pbcopy or pbpaste until I read about them on Sean’s blog, and he takes things one step further by showing you how to use them on remote servers.

Even locally, using the clipboard from the command line is incredibly useful. As the names imply, pbcopy copies to your clipboard, and pbpaste pastes from your clipboard.

6. AWS

With some hand holding from Sean, I’m now hosting my blog on AWS. Their UI is not the best, but the product is great.

Until I made the switch, I thought of AWS as something to consider for large-scale needs, not a simple blog. Now, I expect I’ll never run my own server again (or beg my way onto a friend’s), much like I’d never consider hosting my own email. Let someone else do it; you’ll find plenty of other things to fill your time with.

Google Cloud Platform looks like an interesting alternative, too.

7. Google Docs and Google Sheets

I’ve done everything from collaborate on an email to manage a company’s finances with Google Docs and Google Sheets. I even organize my my backpacking gear in Google Sheets. Being able to easily collaborate and share is a big plus.

8. Amazon Echo

I’ve had the Echo since the pilot in early 2015, and I only bought it because it was cheap. I didn’t expect to be impressed, but I was.

It sits on my kitchen counter, and although we only use it for simple things, we use it every day. Having someone (Alexa is a real person, right?) always available to tell you the time or the weather, set a timer, play music, or turn the lights on is really handy. The voice recognition is better than you’d expect if you’re only familiar with Siri.

9. Mailinator

Ever need to let a site send you an email, but dread the long-term relationship (and spam) you’re signing up for by giving away your email address? That’s exactly where Mailinator thrives. It’s free, public email that lets you check any inbox. Just use something like 24days@mailinator.com as your email address, then check it anytime.

10. Recordit

Recordit is a nifty little tool that lets you record a quick screencast and share it as an animated GIF. It’s a really convenient way to demonstrate something to someone, whether it’s how to reproduce a bug or how to navigate a poorly-designed UI.

I’ve got dozens of other things I could write about, but I decided to stop at 10. Got any personal favorites I missed? Let me know, or just use the #24favs hashtag to share.

Happy Holidays!

The year 2016 has been revelatory for me. It is the year that I finally became hooked to the Community aspect of the tools I work with on a daily basis. To explain why this needed to be explicitly “revealed” to me, I’ll take a step back and tell you about my background.

Changing Careers

I have been working for some time as a government agent before, working on IT integrations amongst others. After several years of working on fruitless tasks and turning in elected circles, I was so fed up that I decided to quit that job and start freelancing. As there’s no such thing as a “general-purpose government freelancer”, I opted to do web development instead.

I primarily chose the platform to specialize on based on sheer market volume, to make sure I had a sizable target audience: WordPress. This meant that I spent the first year mostly working in isolation on smaller client projects to get to grips with WordPress and PHP development (and web development in general, as I had almost exclusively worked on desktop applications up until then). As I have been doing development with varying degrees of intensity for about 25 years now and working on many different platforms and languages, I was able to make rapid progress, and after that initial year, I started to put myself out there to position myself as an advanced developer (in the WordPress space).

Dabbling In Social Interactions

It started with Slack teams, where I made sure that I was the one answering all the more difficult questions. If I didn’t know the answer right away, I looked it up (as I should have known it from the start). I also enjoyed the “watercooler talk”, as working from home can be very isolating. I couldn’t talk about my daily challenges with my wife Carole, so it felt good to have people I was able to speak to regarding these topics. In the beginning, I was not aware how important that aspect was, though.

After some time of doing this, people started to notice the value I was offering, and they often also wanted to meet at Meetups or WordCamps. Now comes the part where I was missing a piece of the puzzle…

In my mind, Meetups and WordCamps were mainly targeted at end users and provided a laid-back weekend activity for people that are deeply involved in one single platform/language/project. I was after business value and a return on investment of my time, so I wasn’t interested in meeting with other people to discuss WordPress drama. When I was looking at the session plan of a WordCamp or other conference, I always thought: “That topic has already been covered in a blog post two years ago. Why bother?”. I am a very practical and goal-oriented person, and these events didn’t seem to help me achieve any of my immediate goals. Add to this that I’m more of an introvert, although I can hide it most of the time.

Vienna

Fast-forward to the summer of 2016. Slack as a networking tool had worked wonders for me, and I had been discussing and working on a daily basis with people I had still looked up to one year before. WordCamp Europe was held in Vienna, and it just so happened that a lot of these people were assembling in the same city for a week, because of the WordCamp. I had never met these people in person, so I decided to head there as well. And given that Vienna is a beautiful city, my wife was coming along.

WordCamp Europe was a delightful experience for us both. It had about 2200 attendees, which meant that there was always a dinner or party to go to after sessions, or a fun activity to do on your extra days. It allowed me to get a real feel for the people I was constantly communicating with online. This adds another layer to the communications and prevents a lot of the misunderstandings you constantly face when only communicating in written form. What’s better to defuse a potentially ambiguous statement in Slack or email than to imagine the smiling face of the author while reading?

Carole does not work professionally with computers at all; she merely uses them for basic surfing and communication needs. She was worried that we “nerds” would just talk “nerdish” all day long and exclude her in the discussions. What happened though was quite the contrary. These were people I had come to associate with based on shared interests and values, not on geographical proximity. Apart from this making them generally more diverse and open-minded, it also meant that they were mirroring some of the traits she was valuing in me. She was highly inspired by all the discussions she’d had and felt withdrawal symptoms when we got back home. She also did much better on the following up than I did…

Being Part Of The Community

After this experience, we started to more systematically attend WordCamps. We also made sure that we applied as volunteers whenever it was possible. We felt the need to give back to this great group of people and truly enjoyed doing so.

At one point, Carole also took part in a “Contributor Day”, an optional extra day on WordCamps where everyone gathers to help work on WordPress itself. Several teams are formed, and Carole got to participate in both the Polyglots team as well as the Community team, as these don’t require technical knowledge. At the end of the day, she had localized one free theme into German (which was committed the same day) and joined the discussions for organizing a new type of WordCamp, which she now seems to be an integral part of.

After attending some WordCamps as a “developer + developer’s boss” team, I noticed that our discussions were changing. She knew the people I was talking about, she understood the projects and concepts I was referring to, and she was not bored out of her mind when I talked about my current development issues.

Impact Of The Community

A lot of people will tell you that a Community is a big family by choice, where you’ll meet great people, have lots of fun and reap networking benefits as a perk on top of that. This is all true. But to me, the Community has had an additional impact I didn’t expect. The Community has actually allowed Carole to take part in the life I’m leading during the day, where she was locked out of before that. She still does not code or understand WordPress specifics. But she can finally relate to what I’m talking about.

Thanks for joining me in the more "nerdy" part of my life, @CaroleOlinger ! #WCFRA pic.twitter.com/VuTHtW3EkP

— Alain Schlesser (@schlessera) September 4, 2016

I now intend to get to know the PHP community better as well. I guess this will be a bit more challenging, as I will need to bridge the gap between these two communities that seem to grow further and further apart (because of technical reasons).

But this time around, I know that it’s worth the effort, so I won’t be easily discouraged.

Let’s meet in 2017!

I’m fortunate enough to be releasing this on Day 11 of this grand event and having read some of the other posts that have come before, I’m worried. I’m a worrier anyway, and not just because I suffer from an anxiety disorder; I’m lucky enough to have inherited this worrisome trait from my own father (thanks, Dad!) who suffers from a similarly over-active worry gland. In this case, I’m worried that my measly attempt to educate and entertain will go down badly after such a parade of big names in the community hit it out of the park in the 10 days before me.

I’ve come to a conclusion (as I approach my fortieth birthday) that it’s entirely natural and expected to be concerned when you release any kind of content out into the wild. Be it writings, podcasts, videos, conference talks, or worst of all, code. As a stoic and obvious Welshman, I wince every time I hear my own voice on a podcast or video, and I’m sure others (even the non-Welsh) will empathise with that. The first time that I heard myself speak on a podcast, I was pretty close to asking Cal Evans (the podcast host) to pull it down.

“For the love of Phil Sturgeon! I sound like a complete fool, and as soon as people hear this they are going to be all over Twitter mocking my terrible accent!”.

This was a genuine fear I had. Like most people, I forget that I speak with a pronounced accent and thought my voice sounded awful when I heard my voice on tape, but it turns out nobody else cares. I’ve had a few people comment on my accent in videos I’ve released for my heroic employer JetBrains, but it’s mainly been along the lines of “I like your accent” rather than “Why do you sound like your speaking with a whole custard slice in your mouth”. Since that first podcast I’ve done much more, and my career has definitely benefitted from it.

Stepping on stage to give my first talk was another huge fear to be overcome. Public speaking is probably the ultimate way of putting yourself out there; when I speak I leave so much of my actual personality on that stage that I have nothing left to hide. I’m lucky in that even though I have terrible nerves in the hours before stepping on stage, those get shaken off almost immediately once I step up to the podium and start speaking. I fully understand that other’s aren’t as lucky as this (and believe that public speaking isn’t for everyone, but that’s probably another post for another day). But if you can get over to your local user group and deliver a talk, it may well open the door to another hugely rewarding set of experiences that you can only access if you put yourself out there that first time. I know that I wouldn’t be doing this job I love if I hadn’t been brave and got on stage that first time.

Code is a whole different beast. Putting your code out into the wild for other people to read, use, and ultimately critique is putting an entirely different aspect of your professional life out there. Submitting code to open source projects is daunting because you’re opening up your most important professional skill to be judged, and that is very, very scary. But there’s a truly amazing upside to putting your code in a public arena to be commented upon, and that is that people will help you improve for free. You get a complete perspective shift once you stop looking at code reviews as a chance for people to criticise you, and start looking at them as free opportunities to learn. I wouldn’t be half the developer I am if I hadn’t contributed to the Zend Framework open source project and had excellent and completely free teaching from some of the communities most talented programmers.

I recently recorded myself solving the superb Advent of Code problems to try and explain not just my how I solve a problem, but why I make certain decisions when programming. I’m fascinated by the decision-making process that individuals use when coding, but once again was apprehensive to publish such intimate details of how I solve a problem, expecting me to be told I’m doing it all wrong. It turns out this stuff is really helpful to others, and most of the feedback was along the lines of “great video, you could change those three lines to this single line though”. This is amazing as I not only helped some people but learned something too!

I would go so far as to say that every time I’ve put myself out there, the good results have outweighed the bad. I can directly trace a path from my first ever open source pull request to me being sat here writing a blog post for a fantastic series. Sure, I’m worried this won’t go down well, but I think I’ve come to a conclusion; it’s human nature and happens to (nearly) everyone. Having spoken to other speakers, even those people who come across as being confident and well-rehearsed will tell you they were petrified minutes before taking to the stage. So be brave, and put yourself out there. After all, what’s the worst that can happen?

When I think back to the things that have helped me in my career, one of the biggest has to be the community.

The chats during local usergroup meetings, the conference hallway track, the Slack groups. All are great ways to get to know other people in the community, learn something new, and even teach somebody else something they didn’t know.

But another way to grow as a developer is by contributing to open source. It may be unpaid work, but being part of the community can provide many benefits.

It lets you tackle something new

Often, trying out some new tech isn’t commercially viable for a day job. It can be hard to justify the cost and the time when a company needs to make money.

In 2017, I plan to get more experience in automated testing. As a member of the joind.in community, I am able to contribute to the automated tests on a real project, and a real website, with real peers. I’ll be working with other people’s code, and I will probably also learn from the other contributors.

You’re giving back

We all make use of open source software as part of our day job, so to be able to give back in some small part helps you grow. You’re not only contributing to the world we all work in, but you’re also contributing to the community. A community that you’ve made that little bit better.

You’re making friends

Among the pull requests, bug tickets, and reviewing of code, you soon start to get to know about your fellow contributors. If there’s a project Slack channel, you might find yourself talking about non-project things.

If you contribute to WordPress or Drupal, you might attend a Wordcamp or Drupalcon — or a local WordPress or Drupal usergroup. You might find yourself eating lunch with someone you’ve been talking to over Slack.

If you ask me, this is the most fruitful of benefits to contributing to open source. I don’t always find time to contribute code to open source projects: often it can be months between my pull requests. But I’m always around, in the community, in the background.

And that’s because I made some friends. Friends who have taught me, and friends who I’ve taught. Friends who I’ve shared both a feature ticket and a laugh with.

My year of open source

A few months ago, I set up a local group where once a month, people can come along and spend some time talking, drinking tea, and contributing to open source. I call it Patch:Manchester.

Next year, in 2017, I want to continue learning and growing, and I will be using open source to do that. I’ll also be using Patch:Manchester to do that.

Why don’t you do the same?

Every few months, PHP gets a major bashing from developers who prefer other languages. These jeers are often from those who treat PHP like the runt of the litter; mainly because they’ve not used it in a decade and think it’s still PHP 5.2. Alternatively, they often make fun of it because they switched to some other language and noticed it has some cool stuff.

All of those jeers – as unproductive and annoying as they are – have an element of truth to them. PHP does have plenty of faults, and other languages do have plenty of awesome things. Those other languages have plenty of faults too, and are also often missing a lot of things, but folks who use the same language most of the time grow used to its faults, and don’t notice what they’re missing.

In general, only knowing one programming language blows. It’s certainly ok and absolutely recommended to start out just learning the one, as you don’t want overload yourself learning everything at once. When you’ve got a foothold with one programming language, you should try to start picking up other languages, even if you are only dabbling with them.

I spent a decade only writing PHP before branching out into using Rails, and later ended up doing a few projects in Python and Go. When I was starting out, learning other languages seemed really hard, and in the early 2000s it was all thick books, and trial & error. Now there are educational videos and quizzes, from sites like CodeAcadamy, Treehouse, Teachable, Pluralsight, etc., which make this easier than ever before.

Learning multiple languages widens your career opportunities, makes it easier to work in a service-orientated architecture where things might not all be PHP, and helps you make sure you’re using the right tool for the job, instead of just hammering every nail with the double-claw.

One great benefit of learning multiple languages, is that you get to see how things work in other communities. Most of the time it’s not even the language itself, but the ecosystem. Sure Go has a more consistent standard library, and Ruby has a pile of lovely syntactic sugar, but what really gets my attention is the tooling other languages have.

After a fair chunk of Rails experience, I helped bring back some of the features I liked into FuelPHP and CodeIgniter. Since then those two projects have fallen by the wayside, but all of the Rails-based features that went into FuelPHP seemed to find their way into Laravel, meaning PHP had benefited greatly from Rails. Taylor Otwell himself having a strong background in ASP.NET meant some of his ideas for Laravel were fresh and different to the norm in PHP, which again, benefited PHP.

Since I started playing with Rails back in 2010, a lot of other things I liked from that framework found there way into PHP in some form. I took ideas from OmniAuth and made NinjAuth, but sadly that was FuelPHP-only and is no more. I took some ideas from their oauth 1 and 2 clients, and brought them over, but again they were FuelPHP only.

The framework specific thing got a bit annoying, so some friends and I started up The League of Extraordinary Packages, a place where these packages ideas could come, with no ties to any frameworks. A place where folks could bring new and interesting ideas, get some traction, share the responsibilities of maintenance with others, and never get stuck in a situation where they were begrudgingly looking after code they no longer used.

• Fractal – the equivalent of ActiveModel::Serializer or Roar in Ruby.
• Faker – heavily inspired by Perl’s Data::Faker, and by Ruby’s Faker.
• Factory Muffin is Factory Girl
• Flysystem is quite likely inspired by Fog (I never did ask Frank about that)

Other tools have been ported to PHP by other awesome developers:

• Behat is Cucumber
• PHPUnit is an implementation of xUnit inspired by JUnit
• Kahlan is basically RSpec
• StackPHP was inspired by Rack
• PSR-7 and middleware takes a lot from StackPHP/Rack/and NodeJS’ ExpressJS
• PHP-VCR is an attempt to bring Ruby’s VCR into PHP
• vlucas/phpdotenv and josegonzalez/php-dotenv are ports of dotenv
• php-resque is a port of resque
• The list goes on

The PHP community is made stronger by those who use more than just PHP. Folks who take the time to learn multiple languages can share the fruits of their knowledge with everyone, and build some really interesting stuff.

Not only that, but having experience with other languages can really help get you through those awkward “oh you’re a PHP developer?” snarky runnings. We’ve all been there; You mention at a non-PHP conference the tool you use, and folks judge you harshly and immediately. Well, one side benefit of knowing more languages, is that folks generally assume you’re smarter if you know more than “just PHP”.

The amount of times I’d say “PHP” and they’d start being patronizing, then I’d say “Oh I use the best tool for the job, and in many scenarios that’s been PHP. I often write distributed software, and PHP has the largest potential install-base. Of course I’ve plenty of experience with Go, Python, Node and Rails too.” They’ll usually change their tone substantially, but if they keep it up, follow with: “Do you mind if I ask, what’s your issue with PHP? Have you used PHP 7 at all or were you back on PHP 5 something?” Watch as they shrink back when they realize you’re not a fool.

Learning from the progress of other communities is always helpful, for yourself, and for the communities you consider yourself part of. Even if you don’t think of any awesome packages that PHP is needing, learning other languages will generally improve how you write PHP anyway.

So, go learn a another language, and make PHP better while you’re at it.

I hated school as a kid, but learning was always a big part of my life. It wasn’t uncommon to see me with my nose in a book soaking up whatever esoteric thing I could find that day. (Seriously, I read a book on the pasteurization process in middle school. I’ve never lived on a farm but I can tell you a lot about milk.)

As an adult, I’ve found that my time gets split amongst various things like work, hobbies, and random adulting tasks such as fighting with Comcast. The result of this is that I don’t have enough time to read books and learn new things like I used to. Or at least, that’s the excuse I make for not doing the things I desire to do.

You see, I do have enough time. The issue is not that time is finite, the issue is that I prioritize other things over these goals. It’s not that I don’t want to learn new things or that the things I spend my time on are a waste of time, it’s just that I spend a lot of time on things that don’t move the needle towards my goals.

An example of this is that I “don’t have enough time” to keep my apartment spotless. It’s a goal of mine that I regularly fail at achieving. I travel a lot for work and I’m only home for 3-4 days at a time. As I’m unpacking from the last trip and re-packing for my next one, I tornado through my apartment and leave a path of unorganized destruction in my wake. As I write this, there’s an unopened box from Amazon in my living room that contains a paper shredder I ordered 6 months ago. I just “haven’t had time” to open it and start shredding papers.

Lies. All lies. I could have tackled the stack of papers 6 months ago, but I chose to go out with friends instead. I could have shredded those papers 3 months ago, but I chose to wrap up some last minute work projects. I could have shredded those papers last weekend, but I chose to fold laundry and organize my closet. That weekend I chose to binge watch Orange is the New Black again? I definitely could have taken care of those papers while that was playing in the background. None of these choices are wrong, and I’d argue that it’s important to find time to unwind and relax, but none of these choices resulted in my apartment becoming less cluttered. Organizing my closet actually made a larger mess. As I decided to do these other things, I didn’t even realize I was prioritizing them or making a choice — it just happened on its own as if I were on autopilot. The stack of papers never entered my mind as something to do instead of these other things.

How we spend our time is a choice that we make every day, but we often don’t realize we have a say in the matter. Every time something “comes up” we’re making a decision to tackle whatever it is that came up. There’s nothing wrong with these choices — you spend your time how you want to, and that’s your business. However, you should become aware of these choices and evaluate whether these choices are the best for you and your goals.

Once we start to focus on the things we spend our time on rather than the things themselves, we can start to manage our time a bit better. Suddenly, we “find time” to accomplish the things we want to accomplish. We can stop feeling like we’re spinning our wheels on all of these projects and ideas and start moving the needle in the right direction. We can start to feel like we’re getting something done.

Just as we budget our money every month (we do do that, right?), we should focus on budgeting our time. Allocate time to the things that REALLY matter (which includes leisure activities, by the way) and stop allocating time to things that don’t matter as much. For 2017, my challenge to you is to start recognizing how you spend your time and start spending time on the things that are important to you. Whether that’s family, learning new things, writing a book, or watching the entirety of the Netflix catalogue, you can always find time for your goals.

As PHP Developers, we are all part of the great worldwide herd that is the PHP Community, whether we realise it or not. From developers working in large departments for big corporations; to small teams; and single, solitary developers working for tiny companies, or freelancing from home: we all have access to that Community of other PHP developers that we can call upon for help when we need it.

We have access to the tools and libraries that have been written by members of that Community, and that they have made freely available to help us all.

Tools such as xdebug and blackfire that help us with debugging and profiling our code; frameworks like Symfony, Laravel and Zend save us rewriting code time and again for every new project, and provide us with a stable and well-tested structure that cleanly and securely handles the basic functionality that our code needs; the myriad of libraries on github give us access to complex functionality without our having to write it ourselves; phpunit, behat, phpspec and codeception help us test it; while composer gives us a simple mechanism to pull libraries and frameworks together. Organisations like FIG help define standards that make it easier for us to develop code that integrates easily with other libraries and frameworks. All are the products of members of the PHP Community to help us become better at what we do.

But the PHP Community isn’t just about providing a few tools, libraries and standards… it’s about learning and sharing knowledge. And even more, it’s about providing support for each other when we need help in any way.

If we can travel to them, then PHP User Groups and Conferences are a great way of learning and sharing our knowledge, and a great way of meeting with other developers face to face to talk about work, about our experiences, about PHP (and almost any other topic, technical or otherwise); but even if we can’t travel, then NomadPHP provides a monthly online learning conference. There are PHP developers who give freely of their time for online mentoring via PHP Mentoring. And the help given within the PHP Community isn’t limited to technical and learning support, but can be called upon to assist with personal problems as well. Open Sourcing Mental Illness is a wonderful initiative that provides resources and support for those who are struggling with mental health. When one of the PHP core contributors found himself and his family homeless and living out of a caravan, they were able to reach out to the PHP Community which donated enough for them to find a new place to live. When another member of the Community found that the twins his wife was carrying were Monoamniotic-Monochorionic, and that they wouldn’t be able to afford the healthcare if he took the time off work to support her, the Community again came together to help out.

So the PHP Community is about far more than simply providing a few helpful utilities, or the occasional meetup… it’s like a family where so many people are willing to help each other, not simply as PHP developers, but as individuals.

I don’t see myself as that infamous 10x ninja rockstar developer; but I have been an active participant in the PHP Community for many years now. I’ve released a few of my own small projects and libraries as Open Source, and contributed to others. I’ve blogged occasionally, and answered a few PHP questions on StackOverflow. I started attending usergroup meetups and conferences, at first just locally, and later in other countries; then speaking at them. In doing so, I’ve met some incredible people, who are willing and happy to do so much helping others to achieve so much more. All of this has helped me improve as a developer; and while I’ll never be that 10x ninja rockstar developer, my understanding of development techniques and practises has grown, and my designs and code quality are far better now than they have ever been because I have learned so much from the members of the PHP Community.
Two of the biggest lessons that I have learned from the PHP Community are:

• We are standing on the shoulders of giants.
  There are thousands of developers who have come before us, who have volunteered their time and efforts to make PHP and the PHP infrastructure great, and we owe them a debt.
• Paying the debt forward.
  We can repay that debt by helping others.

Yet there is still so much more that I can (and will) learn from the Community – if you ever stop learning, it isn’t because you know everything that there is to know, it’s because you’ve given up. And I don’t just learn from the 10x ninja rockstars; because even the newest members of the Community can give me new insights and ideas, new ways of thinking about a problem or a solution, new perspectives on design or coding, new tools and libraries that I can use. That’s the beauty of such a Diverse Community.

It’s that Diversity which gives the PHP Community its strength: we all come from different backgrounds, with different and unique experiences that we can share. We can all learn, and we can all teach others. Yet sometimes the PHP Community doesn’t appear as Inclusive or welcoming as it should; and sometimes it seems too much like a clique of like-minded people, that can dissuade others from reaching out to join and participate.

Like all families, the PHP Community isn’t always happy; and while it is more Diverse than many technical communities, it is far from perfect. To many that have yet to embrace the Community, it still seems exclusive and restrictive, and limited to those who “fit”. For many, they don’t believe they could ever be a part of that Community because they are different. They look at a conference schedule, and see no role models for themselves among the speakers that might persuade them to attend. They see photographs of conference “swag” containing playboy magazine (sorry Drupal Camp Munich), and believe that the conference is just for straight men with a liking for pornography, so it’s not for them. They read a few blog posts (or hear a conference talk) that criticises WordPress or Laravel (I use both myself) or <insert other library/framework/tool here>, and feel that they can’t be a part of the PHP Community because they are a WordPress or a Laravel developer.

If we want to maintain or extend that Diversity which is the strength of the PHP Community, we need to show that the Community actively welcomes that Diversity.

Promoting Diversity isn’t simply a matter of putting a “welcome” sign in the Community window. We need to reach out to all those who don’t believe that they are a part of the Community, and show them that they are; and that their thoughts and ideas matter to the Community as a whole. We need to be aware of Diversity Issues and then look at how to address them. Having a “Code of Conduct” for a Community event is like posting a welcome sign; but being prepared and willing to listen and act on breaches to that CoC is a sign of commitment. Saying that your conference runs a blind review of CfP proposals is posting a welcome sign; actively seeking out minority groups and asking them to submit proposals is showing commitment to Diversity. Those are just a couple of examples that spring instantly to mind; but there are many other ways of promoting Diversity within the PHP Community, and there are many people more qualified than myself to highlight and expand on them.

There is no single magical solution to making the Community more inclusive and welcoming to everybody; but Diversity is Enabled by action, and is Blocked by inaction or inertia. Organisations like PHPWomen have been working proactively to promote Diversity within the PHP Community for many years. More recently, my own Enfys, the PHPDiversity Elephpant is intended to make us think more about Diversity Issues, and to remind us that we should be more Inclusive within the Community, and that means Inclusive of all PHP developers regardless of race, gender, sexual orientation, gender identity, age, nationality, disability, religion and technology. Everybody within the PHP Community deserves to have their voice heard. Enfys may only be small step, but each small step can make a big difference; and in the coming year both Enfys and I shall be looking to see what more I can actively do to Enable Diversity within the PHP Community.

So my challenge to everybody reading this for 2017 is to become an Enabler of Diversity, not a Blocker. Think about Diversity Issues; see if there is anything that you can address, and do so. If each of us takes that one small step, then we can change the PHP Community and make it more welcoming, to the betterment of us all.

Diversity Matters.